分布式架构设计学习笔记——架构演变过程

好久没有写博客了，原因是啥呢？没错，就是懒。不过作为一个程序员学习是不能停止滴，这一系列的笔记我之间都是记录在某笔记软件上的，所以这一系列可能会发的比较快，但是可能有些语无伦次（毕竟都是ctrl+c，ctrl+v）~

总的说起来，服务端架构演变可以表达成这样
mvc垂直架构->rpc远程调用架构->soa->msa

各种架构都曾经红极一时，以下是它们的特点：

• mvc适合小型项目：所有功能部署在同一进程中，通过双机或者前置负载均衡器来实现负载均衡（前后端不分离）
• rpc：在垂直应用越来越多时，应用之间的交互不可避免，将核心和公共业务抽取出来（前后端分离）
• soa：在服务数量增多时，服务的生命周期管理以及运行态的治理成为瓶颈，此时可以使用soa的服务治理
• msa：随着敏捷开发，持续交付，devops理论的发展，已经基于docker的轻量级容器（LXC）技术的成熟，微服务架构开始流行。主要优点是交付周期缩短，运维成本大大下降。

MVC垂直框架

mvc分为model view control三层。优点在于项目足够小时，开发便捷，成本低。

mvc面临的难点：

1. 复杂应用的开发维护成本变高，部署效率逐渐降低：代码量膨胀之后打包部署越来越慢
2. 团队协作效率差：不同团队之间开发重复的api
   系统可靠性变差：当流量过大，引起一个节点崩溃，这个节点的流量会分摊到其他节点从而引起“雪崩效应”。
3. 维护和定制困难：代码量过多的情况下，对于已有的复杂业务难以进行拆分。有时候改一处代码会引起许多地方报错
4. 新功能上线周期变长：公共api变更的时候，因为好几个地方都是使用同样的代码，所以需要改很多很多地方，还要测试；新特性不能够单独打包，必须要跟老功能一起打包，新老功能之间耦合性过大。

随着业务增大，mvc应运淘汰。

RPC框架

rpc的技术重点：

1. 远程服务提供者需要以某种形式来提供服务调用相关的信息
2. 远程代理对象
3. 通信
4. 序列化

rpc面临的问题：

1. 服务越来越多时，负载均衡的压力变大。此时需要一个服务注册中心来动态的注册和发现服务
2. 随着业务的发展，服务之间的依赖越来越复杂，耦合性越来越大
3. 服务的调用量增大，需要增加服务来采集数据，根据此来得出需要加多少机器来满足当前调用量
4. 服务上线容易，下线难

当业务发展足够大时，可以发现此时需要努力的方向是后端服务拆分（垂直拆分或者纵向拆分）；此外，一旦开始服务拆分，服务治理技术也需要开始运用。

SOA（面向服务的架构）框架

soa设计原则：

• 服务可复用
• 服务共享一个标准契约
• 服务是松耦合的
• 服务是底层逻辑的抽象
• 服务是可组合的，可编排的
• 服务是自治的
• 服务是无状态的
• 服务是可被自动发现的

soa服务治理是关键点，包括：

• 服务定义
• 服务生命周期管理
• 服务版本治理
• 服务注册中心
• 服务监控
• 运行期服务质量保障
• 快速的故障定界定位手段
• 服务安全

soa的生命周期：

• 计划：确定服务治理的重点
• 定义：定义服务治理模型
• 启用：实现并实施服务治理
• 度量：根据实施效果，改进服务治理模型

soa应该是大部门公司使用的架构。对于中型业务来讲，soa的服务拆分相对比较简单。

MSA 微服务架构

当服务化越来越大，soa面临的服务治理问题越来越大。此时msa应运而生。
微服务的主要特征如下：

• 原子服务
• 高密度服务
• 敏捷交付
• 微自治

msa与soa的差异如下：

1. 服务拆分粒度：soa的拆分粒度较大，msa强调原子性，要求粒度尽可能的小
2. 服务依赖：soa由于需要重用已有的资产，所以会存在大量的服务间的依赖；
3. 而msa的设计理念是服务自治，避免与其他服务进行过度的耦合
4. 服务规模：传统soa的服务粒度比较大，多数会采用将多个服务合并打包成war包的方案，所以服务的实例数有限；而微服务强调尽可能的拆分，很多服务会独立部署。这将导致服务数量急剧扩增
5. 架构差异：微服务化后，由于服务数量的急剧扩增会导致架构质量属性的变化，比如企业集成总线ESB逐渐被P2P的虚拟总线替代
6. 服务治理：传统基于SOA governance的静态治理转型为服务运行态微治理，实时生效
7. 敏捷交付：微服务强调敏捷

msa的服务数量远大于soa，量变引起质变。而且msa相比于soa更加适合于敏捷开发的项目管理流程。