架构演进

单体

项目中所有的功能模块都放在一个工程中编码、编译、打包并且部署在一个应用服务器。

优点：简单使用、便于维护、成本低

缺点：代码复杂不宜维护、耦合度（核心业务和边缘业务混杂在一起，一崩全玩完）、新增业务困难

垂直应用架构

根据业务特性进行模块化拆分，减少系统之间的耦合度。

（如一个招聘网站可分为 单点登录、主站、简历管理、职位管理等等）

优点: 业务之间互不影响（分流）、分模块开发提高开发效率。

缺点：服务之间调用协议、方式不稳定、不统一。没有规范化；集群化，负载均衡实现较复杂。服务监控不到位。

SOA

面向服务的架构。根据实际业务，把系统拆分成合适的、独立部署的模块，模块之间相互独立。（通过WebService\Dubbo等技术进行通信）

优点：分布式、松耦合、扩展灵活

缺点：服务抽取粒度较大、服务调用方和提供方耦合度较高（接口耦合度）

微服务

在SOA的基础上进行服务的更细一步拆分（粒度更小），实现业务彻底组件化、服务化。

• 不同服务可以采用不同的开发语言
• 服务之间通过restful轻量级通信

RPC与HTTP

rpc是远程过程调用,其调用协议包含：

传输协议：grpc——http2； dubbo ——自定义报文的tcp协议

序列化协议：基于文本编码的json协议；二进制编码 hession ；高性能、高吞吐的kryo

为什么要使用自定义tcp协议的rpc做后端进程通信？

1.相对于http的tcp协议，减少了请求头报文中的内容，精简了传输内容。

2.成熟的rpc库相对http容器，封装了“服务发现”、负载均衡、熔断降级，是面向服务的高级封装。

rpc底层是如何实现的

第一、调用方调用的是接口，必须得为接口构造一个假的实现。显然，要使用动态代理。这样，调用方的调用就被动态代理接收到了。

第二、动态代理接收到调用后，应该想办法调用远程的实际实现。这包括下面几步：

1. 识别具体要调用的远程方法的 IP、端口

      2. 将调用方法的入参进行序列化

            　　　　3. 通过通信将请求发送到远程的方法中

第三、这样，远程的服务就接收到了调用方的请求。它应该：

1. 反序列化各个调用参数

      2. 定位到实际要调用的方法，然后输入参数，执行方法

       　3. 按照调用的路径返回调用的结果

微服务架构

各个组件协同工作，才能支持一个完成的微服务架构。

• 注册中心负责服务的注册与发现，将各个服务连接起来。
• APP网关提供统一入口，负责转发所有外来的请求
• 断路器负责监控服务之间的调用情况，连续多次失败进行熔断保护
• 配置中心提供了统一的配置信息管理服务，可以实时的通知各个服务获取最新的配置信息。