这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天
什么是架构(软件架构)？ 它是有关软件整体结构与组件的抽象描述，指导软件系统各个方面的设计。通俗来说，实现一个软件有很多方式，架构在方法选择上起着至关重要的作用。将架构比作地基，只要地基打好打坚实了，大厦才能既稳且高，才能看得远。架构设计好了，软件更稳定，也为软件的未来发展提供了更多可能。
以下内容围绕着架构演进内容展开：
- 架构演进：蛋糕坊例子
- 单机架构
- 单体和垂直架构
- SOA和微服务
- 存在问题
- 小结
1. 架构演进：蛋糕坊例子
架构的整个演进路线如下：
graph LR
单机 --> 单体 --> 垂直应用 --> 面向服务SOA --> 微服务
在单独说明这些架构之前，先以卖蛋糕为例来梳理整个演进流程，同时建立对这些架构的初步理解。我们的主任务是开张兰师傅蛋糕坊并发展蛋糕坊。下图是蛋糕坊的发展流程，与架构的演进流程相对应。
单机架构：
开张蛋糕店，如何做蛋糕和如何卖蛋糕？ 由兰师傅独家秘方自己做，刚开始客流量不大边做边卖。
面临问题：卖更多蛋糕
- 承载能力有限：兰师傅一个人能卖的蛋糕有限
- 运维停服：兰师傅生病了有事不能来就只能关店。
-->雇佣更多师傅边做边卖。
单体架构：
最开始只有兰师傅一个人边做边卖，再雇佣两个师傅边做边卖，由一个大堂经理分配用户到哪个师傅处买。
面临问题：提高效率
- 职责太多：一个师傅要负责整个做蛋糕流程以及做各种各样的蛋糕效率不高
- 爆炸半径大：如果在某个师傅刚好缺了做戚风蛋糕的某种材料，则该师傅只能暂时停工等待材料到来，影响了其他类型蛋糕的制作和售卖，影响大。
-->分工合作，每个师傅只负责边做边卖一种蛋糕。
垂直应用架构：
现在有5个师傅，每个师傅只用做一种类型的蛋糕，效率提高一些。由一个大堂经理分配用户到哪个师傅处买。如果缺了某种蛋糕材料只会对做该种类型蛋糕的师傅产生影响。
面临问题：进一步提高效率
- 职责虽然减少了，但依然很多
- 爆炸半径虽然减少了，但依然很大
--> 进一步分工合作，给做卖蛋糕分为杂活、和面、烤箱、各种蛋糕售卖的任务。
面向服务架构： SOA
现在的蛋糕坊，将做卖蛋糕分为了杂活、和面、烤箱，各种蛋糕售卖的任务，每一个任务都雇佣至少一位人员来负责，由兰师傅本人负责指挥所有人员。同样由一个大堂经理分配用户到对应的售卖人员处买蛋糕。
面临问题： 兰师傅本人负责的负责过于复杂且多，如果蛋糕店继续扩张人员增多，兰师傅沟通技巧这个点将会越来越大，对于兰师傅本人来说将会是巨大的挑战。
--> 兰师傅沟通技巧点去中心化(拆分兰师傅的工作)
微服务架构：
微服务架构在SOA架构的基础上，除了将兰师傅蛋糕店沟通技巧点去中心化外，还将任务拆分得更细化，每个任务人员之间得沟通将会更自由，更高效。每个任务也会更独立。
回顾整个演进流程：
-
整个演进初衷如下： 需求量越来越大-->增加人手 ，越做越复杂-->分工合作
分工合作怎么分： 垂直切分-->任务按量切，水平切分-->按照某种规则拆分 -
而在架构演进流程中，发生了以下的概念对换，重新带入到整个蛋糕坊演进流程，即可明白架构演进流程。
一个边做边卖的师傅：一台机器。
做卖蛋糕任务：进程
做卖戚风，肉松和慕斯蛋糕任务：应用，由做卖蛋糕任务切分而来的小任务，也是进程。
烤箱和面装货台售卖等：服务，由应用切分而来。
大堂经理：客户引流，负载均衡。
兰师傅蛋糕店沟通技巧：ESB（企业服务总线）
2. 单机架构
把软件系统对外提供的所有服务，实现在一个进程里，并部署在一台机器上。
优点： 简单
缺点：
- 一个服务在单机架构上承载的话,它所能提供的服务能力是有瓶颈的。(c10k问题)
c10k问题：C10K 就是 Client 10000 问题，即「在同时连接到服务器的客户端数量超过 10000 个的环境中，即便硬件性能足够， 依然无法正常提供服务」，简而言之，就是单机1万个并发连接问题
- 如果想要更新或者扩容，运维需要整个服务停止。
3. 单体架构和垂直应用架构
单体框架：在单机架构基础上，将一个进程部署到多个机器上。
垂直应用架构：在单机架构基础上，将进程按照某种依据切分为应用，再按照单体模式思路部署在多个机器上。
优点：
- 具备水平扩容能力
水平扩容：通过增加节点(也就是加机器)的方式来增加整个缓存系统的容量。这种方式一般需要应用程序支持。
垂直扩容：增加内存方式(比如2G->4G配置升级)来增加缓存实例的系统容量。
- 运维无需整个服务停止
缺点：
- 后端进程职责太多，开发效率也不高。
- 爆炸半径大，一旦进程中小模块出现问题，整个进程崩溃。
垂直应用与单体框架的区别在于给进程拆分了一下，这略微降低了这两个缺点的影响。（一个进程切分成多个子进程，进程中小模块出现问题，只会挂掉对应子进程。不切分整个进程都得挂）
4. SOA和微服务
SOA(Service-Oriented Architecture，面向服务架构)：将应用(进程)按照不同功能单元切分为服务并定义服务之间的通信标准。
优点：
- 各服务的职责更清晰
- 运维粒度减小到服务，爆炸半径可控
缺点：
- ESB(企业服务总线)往往需要一整套解决方案：所有服务都有一个交互的地方，即ESB,长久来看,它会变成一个复杂的单点,会面临一个设计和挑战.
微服务：SOA的去中心化演进，解决ESB 服务会拆的更加细化, 提倡服务之间去自由的建立之间的沟通方式,避免中心化的组件承载,使得整个服务运作起来更加的高效和低耦合性。
5. 存在问题:
- 数据一致性： 不同服务中的同一数据是一致的。eg：负责交付数据的多个服务,怎么保证所有服务交付数据的总量在每个服务存储中都是一样的。
- 高可用性： 服务之间的合作方式，中间链路出现问题。怎么保证整个网络尽可能通畅。
- 治理： 中间某一个链路出现问题,怎么对这种紧急情况做容灾
- 解耦 vs 过微： 从一个进程拆分到多服务，看起来运维成本像是提高了，值得做吗？
小结
随着整个演进，后端会拆分的更加细微，服务数量也越来越多，部署机器从一台变为了多台。
整个演进中任务的概念也发生了转化：进程-->应用-->服务。
