系统架构演变 - 阿慕爸爸网

系统架构演变一般会走过以下几个过程：

1.垂直架构

经典的mvc结构，适合项目初期，我们现阶段就是这种架构。

优点：

缺点：

所以为了降低代码重复提高效率，将核心业务抽取出来作为独立服务api，使前端能更快速的响应市场需求；将公共能力api抽取出来作为独立的公共服务供其他调用者消费是必须要做的事情。

应用拆分之后按模块独立部署在不同的机器后，接口调用由本地api演变为跨进程的远程调用方式，此时RPC框架应运而生。

2.RPC架构

RPC全称 Remote Procedure Call,是一种进程间通信方式，允许像调用本地服务一样调用远程服务。

RPC框架的目标就是让远程服务调用更加简单、透明，RPC框架负责屏蔽底层的传输方式，序列化方式和通信细节。

框架使用者只需要知道谁在什么位置提供了什么样的远程服务即可，开发者不需要关心底层的通信细节和调用过程。

在大规模服务化之前，应用只是通过RPC框架，简单的暴露和引用远程服务，通过配置服务的URL地址进行远程调用。

服务越来越多时，服务URL配置管理就会变得越来越复杂，这时就需要一个注册中心动态的注册和发现服务，使服务的位置透明。

随着业务发展，服务间依赖关系变得错综复杂，分不清服务哪个应该先启动，需要一个分布式消息追踪系统可视化展示调用链，用于依赖分析、业务调用路径梳理等，帮助架构师清理不合理的服务依赖。

服务的调用量越来越大，服务的容量问题就暴露出来。某个服务需要多少机器支撑，什么时候该加机器？这时需要采集服务调用数据，进行汇总和分析。

不同的服务安全权限不同，如何保证敏感服务不被误调用？服务的访问安全策略如何制定？

所以服务化之后随之而来的是服务治理问题，必须通过服务框架+服务治理来完成，单凭RPC无法解决服务治理的问题。

3.soa服务化架构

soa(Service-Oriented Architecture)是一种粗粒度、松耦合的以服务为中心的架构，接口之间通过明确的协议和接口进行通信。

soa帮助工程师们站在一个新的高度理解企业级架构中各种组件的开发和部署形式，帮助架构师以迅速、可靠、可重用的形式规划整个业务系统。

服务可复用:不管是否存在复用机会，服务均被设计为可复用。
服务共享一个标准契约:为了与服务提供者交互，消费者需要导入服务提供者的服务契约，可以是接口定义甚至是接口说明文档。
服务是松耦合的：服务功能被设计为相对独立、尽量不依赖其他服务的独立功能提供者。
服务是底层逻辑的抽象：只有经过契约所暴露的服务对外部世界可见，契约之外底层的实现逻辑是不可见的。
服务是可组合、可编排的：多个服务可能被编排组合成一个新的服务。
服务是自治的：逻辑由服务所控制，并位于一个清晰的边界内，服务已经在边界内被控制，不依赖于其他服务。
服务是无状态的：服务应当不需要管理状态信息，因此才能够维持松耦合。无状态就是一次处理的服务请求完全从接口传递到服务，或者服务通过数据库获取数据，不从机器和其他输入存储数据。
服务是可被自动发现的：服务发布上线后，允许被其他消费者自动发现；服务下线后，允许消费者接收服务下线通知。

soa只是结构上更加清晰的规划了各个服务组件的开发协作方式，随着服务数量越来越多，应用给系统运维带来更大挑战：

此时，soa的服务治理就是关键。

服务定义：监控服务的创建过程，必须对服务进行标识，描述其功能，确定其行为范围并设计接口。
服务生命周期管理：服务的规划、设计、实现、部署、维护并最后下线。
服务版本管理：向前兼容原则。
服务注册中心：动态的服务注册和发现。
服务监控：对服务的调用延时、成功率、吞吐率等数据进行实时采样和汇总，方便运维及时采取策略调整。
运行期服务质量保障：包括服务限流、升降级、服务迁入迁出、服务权重调整、服务超时管控等，通过运行期的动态治理，可以在不重启服务的前提下，达到快速提升服务运行质量的目标。
快速的故障定界定位手段：海量日志分析和分布式消息跟踪。
服务安全：是否允许任何人调用任何服务，数据敏感型服务是否允许所有用户访问数据等等。

4.微服务架构

微服务架构是一种服务化架构风格，通过将功能分散到各个离散的服务中以实现对解决方案的解耦。

为了最大复用已有的it资产，大多数异构系统没有进行统一的soa服务化框架改造，而是将业务接口发不成标准的web服务；不同组件服务化使用的技术和划分原则不同，soa服务化之后的质量也良莠不齐，部分设计不合理的服务也没体现服务之后的价值。

soa架构解决了应用服务化问题，随之服务的规模越来越大，服务治理面临的挑战也约来越多，微服务架构风格应运而生。

微服务架构的主要特征：

和soa的差异：

所以，量变引起质变，soa解决的是代码复用问题，微服务是soa规模足够大之后，最大程度解耦问题。