版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/q1052196521/article/details/86627169
好久没有写博客了，原因是啥呢？没错，就是懒。不过作为一个程序员学习是不能停止滴，这一系列的笔记我之间都是记录在某笔记软件上的，所以这一系列可能会发的比较快，但是可能有些语无伦次（毕竟都是ctrl+c，ctrl+v）~
总的说起来，服务端架构演变可以表达成这样
mvc垂直架构->rpc远程调用架构->soa->msa
各种架构都曾经红极一时，以下是它们的特点：
- mvc适合小型项目：所有功能部署在同一进程中，通过双机或者前置负载均衡器来实现负载均衡（前后端不分离）
- rpc：在垂直应用越来越多时，应用之间的交互不可避免，将核心和公共业务抽取出来（前后端分离）
- soa：在服务数量增多时，服务的生命周期管理以及运行态的治理成为瓶颈，此时可以使用soa的服务治理
- msa：随着敏捷开发，持续交付，devops理论的发展，已经基于docker的轻量级容器（LXC）技术的成熟，微服务架构开始流行。主要优点是交付周期缩短，运维成本大大下降。
MVC垂直框架
mvc分为model view control三层。优点在于项目足够小时，开发便捷，成本低。
mvc面临的难点：
- 复杂应用的开发维护成本变高，部署效率逐渐降低：代码量膨胀之后打包部署越来越慢
- 团队协作效率差：不同团队之间开发重复的api
系统可靠性变差：当流量过大，引起一个节点崩溃，这个节点的流量会分摊到其他节点从而引起“雪崩效应”。 - 维护和定制困难：代码量过多的情况下，对于已有的复杂业务难以进行拆分。有时候改一处代码会引起许多地方报错
- 新功能上线周期变长：公共api变更的时候，因为好几个地方都是使用同样的代码，所以需要改很多很多地方，还要测试；新特性不能够单独打包，必须要跟老功能一起打包，新老功能之间耦合性过大。
随着业务增大，mvc应运淘汰。
RPC框架
rpc的技术重点：
- 远程服务提供者需要以某种形式来提供服务调用相关的信息
- 远程代理对象
- 通信
- 序列化
rpc面临的问题：
- 服务越来越多时，负载均衡的压力变大。此时需要一个服务注册中心来动态的注册和发现服务
- 随着业务的发展，服务之间的依赖越来越复杂，耦合性越来越大
- 服务的调用量增大，需要增加服务来采集数据，根据此来得出需要加多少机器来满足当前调用量
- 服务上线容易，下线难
当业务发展足够大时，可以发现此时需要努力的方向是后端服务拆分（垂直拆分或者纵向拆分）；此外，一旦开始服务拆分，服务治理技术也需要开始运用。
SOA（面向服务的架构）框架
soa设计原则：
- 服务可复用
- 服务共享一个标准契约
- 服务是松耦合的
- 服务是底层逻辑的抽象
- 服务是可组合的，可编排的
- 服务是自治的
- 服务是无状态的
- 服务是可被自动发现的
soa服务治理是关键点，包括：
- 服务定义
- 服务生命周期管理
- 服务版本治理
- 服务注册中心
- 服务监控
- 运行期服务质量保障
- 快速的故障定界定位手段
- 服务安全
soa的生命周期：
- 计划：确定服务治理的重点
- 定义：定义服务治理模型
- 启用：实现并实施服务治理
- 度量：根据实施效果，改进服务治理模型
soa应该是大部门公司使用的架构。对于中型业务来讲，soa的服务拆分相对比较简单。
MSA 微服务架构
当服务化越来越大，soa面临的服务治理问题越来越大。此时msa应运而生。
微服务的主要特征如下：
- 原子服务
- 高密度服务
- 敏捷交付
- 微自治
msa与soa的差异如下：
- 服务拆分粒度：soa的拆分粒度较大，msa强调原子性，要求粒度尽可能的小
- 服务依赖：soa由于需要重用已有的资产，所以会存在大量的服务间的依赖；
- 而msa的设计理念是服务自治，避免与其他服务进行过度的耦合
- 服务规模：传统soa的服务粒度比较大，多数会采用将多个服务合并打包成war包的方案，所以服务的实例数有限；而微服务强调尽可能的拆分，很多服务会独立部署。这将导致服务数量急剧扩增
- 架构差异：微服务化后，由于服务数量的急剧扩增会导致架构质量属性的变化，比如企业集成总线ESB逐渐被P2P的虚拟总线替代
- 服务治理：传统基于SOA governance的静态治理转型为服务运行态微治理，实时生效
- 敏捷交付：微服务强调敏捷
msa的服务数量远大于soa，量变引起质变。而且msa相比于soa更加适合于敏捷开发的项目管理流程。