index：
[toc]
- 传统垂直应用架构
- RPC架构
- SOA服务化架构
- 微服务架构
传统垂直应用架构
MVC垂直架构
分三层：
- 前端视图展示层（view）：不执行实际的业务逻辑，也不改变数据模式。
- 中间为调度控制层（control）：前端Web请求的分发，调度后台的业务逻辑执行。
- 第三层为应用模型层（Model）：应用程序的主体部分，代表业务数据和业务执行逻辑。
垂直应用架构弊端
- 复杂应用的开发维护成本变高，部署效率逐渐降低。
- 团队协作效率差，部分公共功能重复开发，代码重复率高。
- 系统可靠性变差。单点故障对系统影响较大。
- 新功能上线周期长。
RPC架构
RPC（Remote Procedure Call）是一种进程间通信方式，允许像本地调用一样调用远程服务。
RPC框架的目标就是让远程调用更加简单、透明，屏蔽底层的传输方式、序列化方式等通信细节。
RPC框架实现的几个核心技术点：
1. 远程服务提供者需要以某种形式提供服务调用相关信息，包括但不限于服务接口定义、数据结构等。
2. 远程代理对象：服务调用者调用的服务实际是远程服务的本地代理。
3. 通信：RPC框架与具体的协议无关。
4. 序列化。
RPC框架面临的挑战：
1. 当服务越来越多后，需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。
2. 服务依赖关系错综复杂，需要分布式消息跟踪系统可视化展示服务调用链，用于依赖分析、业务调用路径梳理等。
3. 服务容量问题：需要上线多少服务可以满足要求。
4. 服务生命周期管理等服务治理有关问题。
SOA服务化架构
SOA是一种粗粒度、松耦合的以服务为中心的架构，接口之间通过定义明确的协议和接口进行通信。
SOA面向服务设计原则：
1. 服务可复用。
2. 服务共享一个标准契约：为了与服务提供者交互，消费者需要导入服务提供者的服务契约。
3. 服务是松耦合的：服务被设计为功能相对独立，尽量不依赖其他服务。
4. 服务是底层逻辑的抽象。
5. 服务是可组合、可编排的：多个服务可能被编排组合成一个新服务。
6. 服务是自治的：逻辑由服务所控制，并有一个清晰的边界，不依赖于其他服务。
7. 服务是无状态的：服务应尽可能设计为无状态。
8. 服务是可被自动发现。服务上线后，允许被其他消费者自动发现；下线后，允许消费者接收下线通知。
SOA服务治理：
1. 服务定义。
2. 服务生命周期管理。
3. 服务版本治理。
4. 服务注册中心。
5. 服务监控。
6. 运行期服务质量保障。
7. 快速的故障定界定位手段。
8. 服务安全。
微服务架构
微服务架构特征：
1. 原子服务，专注于做一件事。
2. 高密度部署。
3. 敏捷交付。
4. 微治理。
微服务架构与SOA对比：
1. 服务拆分粒度：SOA主要解决异构应用的服务化；微服务强调服务拆分尽可能小，最好是独立的原子服务。但拆分粒度大小没有具体理论说明。
2.\ 服务规模：微服务拆分粒度较小，服务数量会急剧增加，对服务治理和运维带来新的挑战。
3.\ 架构差异：SOA通常是用ESB实现服务间通信，而微服务若使用ESB的话，ESB会是架构的系统瓶颈，所以一般实现P2P的虚拟总线替换。
4. 服务治理：微服务服务治理难度更大。
5. 敏捷交付：微服务由于服务粒度较小，单个服务可以由几个人的小团队单独设计、开发、测试、部署、维护、下线，运维整个生命周期支撑，实现真正的DevOps。
