架构的演进

1.1单体架构

将所有业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。

◆ 1.1.1单体架构的优点

1）部署简单: 由于是完整的结构体，可以直接部署在一个服务器上即可。

2）技术单一: 项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发。

3）用人成本低: 单个程序员可以完成业务接口到数据库的整个流程。

◆ 1.1.2单体架构的缺点

1）系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长；

2）系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机；

3）可伸缩性差：系统的扩容只能只对这个应用进行扩容，不能做到对某个功能点进行扩容；

4）线上问题修复周期长：任何一个线上问题修复需要对整个应用系统进行全面升级。

1.2 SOA架构（面向服务架构）

SOA，面向服务架构。SOA中心化的实现方式就是ESB（企业服务总线），依靠ESB，集成不同系统、不同协议的服务，连接各个服务节点，做消息的转化解释和路由工作，让不同的服务互联互通；

1.2.1 RPC远程过程调用

RPC，Remote Procedure Call，即远程过程调用，建立在Socket之上的，在一台机器上运行的主程序，可以调用另一台机器上准备好的子程序。

RPC框架：

• 国内：

Dubbo，阿里巴巴，http://dubbo.I/O/；

Motan ，新浪微博，https://github.com/weibocom/motan；

Dubbox，当当，https://github.com/dangdangdotcom/dubbox；

Rpcx，基于 Golang 的https://github.com/smallnest/rpcx；

• 国外：

Thrift，facebook，https://thrift.apache.org；

gRPC，Google，http://www.grpc.I/O；

Avro，hadoop，https://avro.apache.org；

• 阿里巴巴的Dubbo、HSF，Spring的Spring Cloud等，底层基于NIO；

1.2.2 RMI远程方法调用

让在客户端Java虚拟机上的对象像调用本地对象一样调用服务端java 虚拟机中的对象上的方法。

使用代表：EJB。

远程方法调用步骤：

1. 客户调用客户端辅助对象stub上的方法

2. 客户端辅助对象stub打包调用信息（变量、方法名），通过网络发送给服务端辅助对象skeleton；

3. 服务端辅助对象skeleton将客户端辅助对象发送来的信息解包，找出真正被调用的方法以及该方法所在对象；

4. 调用真正服务对象上的真正方法，并将结果返回给服务端辅助对象skeleton；

5. 服务端辅助对象将结果打包，发送给客户端辅助对象stub；

6. 客户端辅助对象将返回值解包，返回给调用者。

7. 客户获得返回值。

• Java1.2+内置的RMI，底层基于BIO；

1.2.3 区别

1、RMI 只能在 Java 语言中使用，可以把 RMI 看作面向对象的 Java RPC；

2、RPC是一种编程模型。

1.3 微服务架构

微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想。

◆ 1.3.1微服务的特征

1. 通过服务实现组件化

2. 按业务能力来划分服务和开发团队

3. 去中心化（此处中心化指的是去中心化数据管理和去中心化服务治理）

• 单一职责：微服务中每个服务都对应唯一的业务能力

• 微：微服务的拆分粒度很小，例如一个用户管理可以作为一个服务。每个服务很小，但是五脏俱全

• 面向服务：服务对外暴露Rest风格服务接口API，不限制

• 自治：

• 团队独立

• 技术独立：因为面向服务，不关心使用技术/语音，提供Restful接口即可

• 前后端分离：提供统一的Rest接口，后端不再为PC、移动端单独开发不同的接口

• 数据库分离：每个服务都使用自己的数据库，很少情况出现多数据源的情况

• 部署独立：每个服务都是独立的组件、可复用、可替换、低耦合，易维护。

◆ 1.3.2微服务的优点

4. 拆分业务，把整体大项目分割成不同小项目运行在不同进程或者机器上实现数据隔离；

5. 技术栈，每个服务可以由不同的团队或者开发者进行开发，外部调用人员不需要操心具体怎么实现的，只需要类似调用自己方法一样或者接口一样按照服务提供者给出来的参数传递即可；

6. 独立部署，每一个服务独立部署，部署一个服务不会影响整体项目，如果部署失败最多是这个服务的功能缺失，并不影响其他功能的使用；

7. 弹性。

8. 按需部署，针对不同的需求可以给不同的服务自由扩展服务器，根据服务的规模部署满足需求的实例；

9. 局部修改，当一个服务有新需求或者其他修改，不需要修改整体项目只要管好自己的服务就好；

◆ 1.3.3微服务的缺点

10. 运维，微服务由于把业务拆分得细，有可能部署在不同机器上，因此对于 运维人员的管理来说，这部分的成本会加大；

11. 接口调整，微服务之间通过接口进行通信。如果修改某个微服务的API， 可能所有使用了该接口的微服务都需要做调整；

12. 运维，微服务由于把业务拆分得细，有可能部署在不同机器上，因此对于 运维人员的管理来说，这部分的成本会加大；

13. 分布式，由于会把不同服务部署在不同机器上，那么对于这些服务的调用、 容错、网络延迟、分布式事务等等都是一个很大的挑战，当然微服务不一 定全部都是部署在不同服务器上

1.4 SOA架构和微服务架构的差别

1. 微服务不再强调传统SOA架构里面比较重的 ESB 企业服务总线，同时 SOA 的思想进入到单个业务系统内部实现真正的组件化。

2. Docker 容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似 Node或者 Spring Boot 等技术跑在自己的进程中。

3. SOA 注重的是系统集成方面，而微服务关注的是完全分离。

4. 微服务机构和SOA架构都是对系统进行拆分；

5. 微服务架构基于SOA架构；

6. 管理方面：SOA着重中央管理（ESB），微服务注重分散管理；

1.5 SpringCloud微服务组件

SpringCoud中文网：https://www.springcloud.cc/；

• 注册中心：Zookeeper、Eureka、Nacos、Consul。

• API服务网关：Nginx、zuul、gateway、Kong、Traefik等

功能：统一入口、路由功能、负载均衡、统一鉴权、协议转换（统一服务）、指标监控、限流熔断、黑白名单、统一日志等。

流量网关、业务网关。

• 负载均衡

• 硬件负载均衡设备，如F5、Array等。

• 软件负载均衡，如LVS、Nginx等。

• 微服务组件：Ribbon。

负载均衡基本算法：

1. RoundRobinRule轮询。默认；

2. AvailabilityFilteringRule有效性过滤。过滤掉打开熔断的服务或者是高并发连接数量的服务，再轮询；

3. WeightedResponseTimeRule权重。给每一个服务一个权重，响应时间越长，权重越小；

4. RetryRule重试，先按照轮询策略，如果请求服务失败，会在指定时间内（30s）进行重试；

5. BestAvailableRule。先过滤掉断路器的服务，然后选择一个并发量最小的；

6. RandomRule。随机获取一个服务。

• 服务调用

Dubbo、Feign等。

1、协议

Dubbo：

• 支持多传输协议(Dubbo、Rmi、http、redis等等)，可以根据业务场景选择最佳的方式。非常灵活。

• 默认的Dubbo协议：利用Netty，TCP传输，单一、异步、长连接，适合数据量小、高并发和服务提供者远远少于消费者的场景。

Feign：基于Http传输协议，短连接，不适合高并发的访问。

2、负载均衡

Dubbo：

• 支持4种算法（随机、轮询、活跃度、Hash一致性），而且算法里面引入权重的概念。

• 配置的形式不仅支持代码配置，还支持Dubbo控制台灵活动态配置。

• 负载均衡的算法可以精准到某个服务接口的某个方法。

Feign：

• 只支持N种策略：轮询、随机、ResponseTime加权。

• 负载均衡算法是Client级别的。

3、容错策略

Dubbo：支持多种容错策略：failover、failfast、brodecast、forking等，也引入了retry次数、timeout等配置参数。

Feign：利用熔断机制来实现容错的，处理的方式不一样。

4、实际开发的用法上

Dubbo是RPC、二进制流序列化、socket通讯，而Feign是用REST API，http七步走。

• 熔断器

Hystrix、Sentinel。过载保护。

1.6 SpringCloudAlibaba微服务组件

SpringCloudAlibaba实是对SpringCloud实现拓展组件功能，是Spring Cloud 体系下的一套微服务解决方案的一种实现。

1.6.1 Spring Cloud Alibaba 包含组件

1.7微服务架构模型

1.7.1 洋葱架构

洋葱架构从外向里依次包括：用户界面和基础设施、应用服务、领域服务、领域模型。依赖从外向内。

1.7.2 六边形架构

六边形架构和洋葱架构很相似：使用的是端口适配器模式。把最外层定义成端口，通过适配器来完成，中间是应用程序和领域服务。

1.7.3 DDD分层架构

DDD分层包括：用户接口层、应用层、领域层、基础设施层。