服务化应用架构演进

发布于:2021-10-17 16:07:33

index:
[TOC]


传统垂直应用架构
MVC垂直架构

分三层:
1. 前端视图展示层(view):不执行实际的业务逻辑,也不改变数据模式。
2. 中间为调度控制层(control):前端Web请求的分发,调度后台的业务逻辑执行。
3. 第三层为应用模型层(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。

相关推荐

最新更新

猜你喜欢