架构

什么是云原生 为了解决传统应用升级缓慢、架构臃肿、不能快速迭代、故障不能快速定位、问题无法快速解决等问题，云原生这一概念横空出世。 Pivotal 是云原生应用的提出者，并推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。 早在 2015 年 Pivotal 公司的 Matt Stine 就写了一本叫做迁移到云原生应用架构的小册子，其中探讨了云原生应用架构的几个主要特征： 符合 12 因素应用 面向微服务架构 自服务敏捷架构 基于 API 的协作 抗脆弱性 后来 Pivotal 对云原生的定义做过几次更新， 最新的 Pivotal 官网上对云原生应用的最新介绍是关注以下四点： 集成 DevOps 持续交付 微服务 容器化 DevOps 是软件开发人员和 IT 运营之间的合作，目标是自动执行软件交付和基础架构更改流程。它创造了一种文化和环境，可在其中快速、频繁且更可靠地构建、测试和发布软件； 持续交付使得单个应用更改在准备就绪后即可发布，而不必等待与其它更改捆绑发布或等待维护窗口期等事件。持续交付让发布行为变得平淡可靠，因此企业可以以更低的风险频繁交付，并更快地获得最终用户的反馈，直到部署成为业务流程和企业竞争力必不可少的组成部分； 微服务是将应用作为小型服务集合进行开发的架构方法

上篇： 架构漫谈（七）：不要空设架构师这个职位，给他实权 　　在 第六篇 文章中，我们得出一个结论，软件架构实际上包括了：代码架构，以及承载代码运行的硬件部署架构。实际上，硬件部署架构最终还是由代码的架构来决定。因为代码架构不合理，是无法把一个运行单元分拆出多个来的，那么硬件架构能分拆的就非常的有限，整个系统最终很难长的更大。 　　所以我们经常会听说， 重写代码，推翻原有架构，重新设计等等说法，来说明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。 这也并不是架构进化的事情，而是个人对问题领域的逐渐深入理解的过程。所以有必要再讨论一下，代码的架构应该是怎样的。 　　本文会在之前几篇文章的基础上，进一步探讨如何把架构的思考进行落地，细化到我们代码的实践当中，尽量不要让代码成为系统长大的瓶颈，降低架构分拆的成本。 　　在前面我们提到， 软件实际上是对现实生活的模拟，虚拟化 。这是一个非常重要的前提，直接决定了我们的代码应该分为几部分。结合每个部署单元所承担的责任，可以明确的拆分为两个不同的责任： 表达业务逻辑的代码。很多人把这部分叫做Domain Logic，或者叫Domain Model。这部分实际是来源于生活的，必须保持和现实生活中的切分一致，并非人为的抽象而成。 对用户提供访问并保存业务逻辑运行结果的代码。计算机的状态保存有一个缺陷

服务化架构的演进历史 Dubbo官网上的一张图 1 单体应用架构 部署到一个war里 部署到一个web容器里（如tomcat） 公用一个DB 优点： 容易测试 容易部署 缺点： 开发效率低 代码维护难 部署不灵活（如构建时间特别长，如任意小的修改，需要重新构建整个项目） 稳定性不高（如任一一个小问题，可能让你整个系统挂掉） 扩展性不够（如购物场景，商品服务和订单服务，浏览的人比下单的人多，商品服务的流量会大一点。如果是微服务，商品服务部署10台，订单服务部署5台） 如下图架构图： 2、MVC（垂直应用架构体系） 主要解决前后端、界面、控制逻辑和业务逻辑的分层问题。 比较流行的技术栈SSM，SSH等。 解决了单一架构面临的扩容问题，流量可以分散到各个子系统中，且体积可控，提高了开发效率。 缺点：垂直应用越来越多，应用间的相互交互，相互调用已无法避免，不同系统之间存在重叠的业务。 3、RPC 随着业务发展，业务规模的扩大，模块化逐步成为一种趋势。此时解决模块之间远程调用的RPC应用而生。 缺点： RPC本身不负责服务化。例如自动发现不管，服务的应用和发布不管、服务运维和治理不管。 4、SOA 为了解决垂直应用架构重复造轮子，提取出来作为单独的系统对外提供服务，形成业务之间的相互重用，这是SOA就出现了。（面向服务的体系价架构） SOA服务化架构，企业级资产重用和异构系统间的集成对接。

上篇： 架构漫谈（六）：软件架构到底是要解决什么问题？ 　　 什么是架构师 　　在之前的几篇文章中，经常会提到架构师这个词。我们已经定义了什么叫架构，那怎么定义架构师呢，是不是做架构的就叫架构师了？ 没有这么简单，本篇尝试讨论一下这个问题。 　　 架构师的前提条件 　　如果一个人在工作中，只是致力于完成自己的工作，以做好自己的工作为主要目标，那么最多只能成为一个工匠，无法成为一个架构师。因为这个过程解决的还是自己的问题，并没有时间的压力，可以随意什么时候做完都可以。 　　当我们所做的工作是处于社会的分工的一环，需要帮助别人解决问题，并且按时解决别人的问题成为我们自己的问题的时候，我们就有了时间压力，潜意识里会自然而然的有一种对时间的恐惧。这个恐惧在潜意识里面会想方设法推动我们采用各种手段，以便及时的完成工作，换取报酬。甚至会加班加点，不择手段。 　　如果我们还生活在这个恐惧下面，是不可能成为架构师的。要成为架构师，必须要超越这个恐惧才能够看清楚，我们要解决的是别人的问题，不是自己完成工作的问题。因为仅仅是完成了自己的工作，也并不一定就解决了别人的问题。如果别人的问题没有解决——即使我们认为自己的工作完成了——我们的工作实际也没完成，因为我们工作是否完成，是别人说了算的，不是我们自己。 　　为什么会有这个对时间的恐惧和压力呢？这是因为我们把完成自己的工作当成了我们的最大利益

REST（Representational State Transfer）是一种Web服务的架构，其目的是创建具有良好扩展性的分布式系统。它的约束包含： 使用C/S模型。client和server之间通过一个统一的接口来互相通讯。 层次化的系统。分层系统通过限制组件的行为，将架构分解为若干等级的层。通过将组件对系统的知识限制在单一层内，为整个系统的复杂性设置了边界，提高了底层独立性。 无状态。server不会保存有关客户端的任何状态，即client自身负责用户状态的维持，并在每次发送请求时都需要提供足够的信息。 可缓存。减少client和server之间的信息传输，以提高性能。 统一的接口。核心特征。一个REST系统需要使用一个统一的接口来完成子系统之间以及服务与用户之间的交互。这使得系统中的各个子系统可以独自完成演化。 资源的识别。每个资源都拥有一个资源标识，可以唯一地表明该资源（如URI） 消息的自描述性。消息需要能够提供自身如何被处理的足够信息。 资源的自描述性。一个REST系统所返回的资源需要能够描述自身，并提供足够的用于操作该资源的信息，如如何对资源进行添加，删除以及修改等操作。 HATEOAS。即客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息，如到底是向哪个URL发送请求等。 如果一个系统满足了上面所列出的五条约束

上篇： 架构漫谈（五）：什么是软件 　　前一篇文章简述了什么是软件。那么什么是软件架构呢？按照惯例，我们来看看是什么问题，是谁的问题。 　　 要解决谁的问题？ 　　如前所述，软件实际上就是把现实生活模拟到计算机中，并且软件是需要在计算机的硬件中运行起来的。要做到这一点需要解决两个问题： 　　 一、业务问题 　　具体的现实生活状态下，没有软件的时候，所解决的问题的主体是谁，解决的是什么问题，是如何解决，如何运作的？ 　　 二、计算机问题 如何把现实生活用软件来模拟？ 模拟出来的软件，需要哪些硬件设施才能够满足要求？ 并且当访问量越来越大的时候，软件能否支持硬件慢慢长大，性能线性扩展？ 因为硬件是可能会失效的，软件如何在硬件失效的情况下，仍然能够保证可用性，让用户能够不中断的访问软件提供的服务？ 怎么收集软件产生的数据，为下一阶段的工作提供依据？ 　　 分别是谁的问题呢？ 业务的owner需要提升业务的效率，降低业务的成本，这是动机。这个实际上就是业务的问题，所以一般软件开发的出发点就在这里。 是软件工程师的问题，要解决业务owner把业务虚拟化的问题，并且要解决软件开发和运营的生命周期的问题。 　　 分别有什么问题？ 业务问题的本质，是业务所服务的对象的利益问题，明白了这个，就很容易搞清业务的概念和组织方式。再次强调一下，有了软件，可以降低业务的成本，没有软件的情况下，业务是一样跑的

上篇： 架构漫谈（四）：如何做好架构之架构切分 　　前面通过四篇文章，把什么是架构，如何做好架构等必要的概念澄清了一下。这些概念对于在各种不同的领域都应该也是有用的，需要读者自行思考，并应用到自己所在的领域中。在这篇文章开始，我们用同样的思考，来看看软件是怎么回事，以及如何运用架构思维，更好的设计和实现软件。 　　 冯诺依曼结构，图灵机，以模拟人为目标 　　软件的历史，实际上可以说是用机器模拟人的历史。不管大家（包括在这个历史过程中的参与者）有没有意识到，我们都有意无意的在计算机上模仿人类的行为。从冯诺依曼结构开始，程序逻辑开始脱离硬件，采用二进制编码。加上存储，配合输入输出，一个简化的大脑就出现了。图灵机则是模拟大脑的计算，用数学的方式把计算的过程定义了出来，著名的邱奇-图灵论题：一切直觉上能行可计算的函数都可用图灵机计算，反之亦然。软硬件两者一结合，一个可编程的大脑出现了，这也是现在为什么我们把计算机叫做电脑。在硬件上编写出的程序，就是软件，是用来控制硬件的行为的。 　　 成本为王 　　在初期，软件使用二进制编写的，从硬件到软件，成本都非常的高。随着半导体技术的进步，硬件的成本越来越低，性能越来越高，甚至出现了摩尔定律：当价格不变时，集成电路上可容纳的元器件数目，约每隔18-24个月增加一倍，性能提升一倍。软件方面，为了简化难度，开始采用汇编

目录 web框架 web应用本质 Web应用程序的优点 Web应用程序的缺点 BS架构优点 web框架的分类 web框架包含了三部分 web框架分类 Http协议 路由系统 自定制的web框架案例 web框架 web应用本质 web应用程序是一种可以通过web访问的应用程序，程序的最大好处就是用户很容易访问应用程序，用户只需要浏览器就可以，不需要再安装其它软件。 在我们之前的网络编程中，有学过三种架构，单机架构，C/S架构和B/S架构 socket网络编程： 架构：C/S架构 协议：TCP/UDP协议 OSI七层：传输层 web应用： 架构：B/S架构 协议：Http协议 OSI七层：应用层 Web应用程序的优点 网络应用程序不需要任何复杂的‘展开’过程，只需要一个浏览器就可以了； 网络应用程序通常耗费很少的用户硬盘空间，或者一点都不耗费； 网络应用程序和服务端的网络产品都很容易结合，如email功能和搜索功能； 因为他们在网络浏览器窗口运行，所以大多数情况下他们是跨平台使用的（如Windows，Mac等） Web应用程序的缺点 网络应用程序强调浏览器的适用性。如果浏览器方没有提供特定的功能，或者弃用特定的平台或操作系统版本（导致不适用），就会影响大量用户； 网络应用依靠互联网远程服务器端的应用文件。因此，当连接出问题时，应用将不能正常使用。 许多网络应用程序不是开源的

前言 一个成熟的大型网站（如淘宝、京东等）的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性，它总是随着用户量的增加，业务功能的扩展 逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统 架构是随业务扩展而完善出来的，并不是一蹴而就；不同业务特征的系统，会有各自的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、支付，例如腾讯， 要解决数亿的用户实时消息传输，百度它要处理海量的搜索请求，他们都有各自的业务特性，系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下， 找出其中共用的技术，这些技术和手段可以广泛运行在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段。 一、最开始的网站架构 最初的架构，应用程序、数据库、文件都部署在一台服务器上，如图： 二、应用、数据、文件分离 随着业务的扩展，一台服务器已经不能满足性能需求，故将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。 三、利用缓存改善网站性能 在硬件优化性能的同时，同时也通过软件进行性能优化，在大部分的网站系统中，都会利用缓存技术改善系统的性能，使用缓存主要源于热点数据的存在，大 部分网站访问都遵循28原则（即80%的访问请求

摘自： https://www.cnblogs.com/mrhelloworld/p/12388859.html 技术架构演变 　　 　　 　　随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。 　　 　　 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。 缺点：随着应用功能的增多，代码量越来越大，越来越难维护，那怎么解决代码一体化的问题？ 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。 缺点：垂直架构中相同逻辑代码需要不断的复制，不能复用。每个垂直模块都相当于一个独立的系统。 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 缺点：服务越来越多，需要管理每个服务的地址，调用关系错综复杂，难以理清依赖关系，服务状态难以管理，无法根据服务情况动态管理。 流动计算架构