微服务简介

一、项目架构演变

项目架构随着时间的演进，出现了三个：单体架构、SOA、微服务。

单体架构：即我们日常学习接触到的最简单的，传统的一种架构方式，在中小型项目里出现居多。一个归档包里包含了整个项目所有功能的单体应用，通常称作单体应用，比如个人的小型博客，打成war包就可以直接上传到服务器里进行发布。

单体架构的缺点：复杂性逐渐变高，技术债务逐渐上升，部署速度逐渐变慢，阻碍技术创新，无法按需伸缩。

二、微服务是什么

把一个庞大的系统拆分为小的可以独立应用的服务，各个服务之间采用HTTP等轻量级的机制类相互通信。这些服务围绕业务功能进行构建，通过全自动部署进行独立部署。各个服务可以采用不同的语言编写，使用不同的数据存储技术。

1、微服务的特性

（1） 每个微服务可独立运行在自己的进程里；

（2） 一系列独立运行的微服务共同构建起了整个系统；

（3） 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理、用户管理等；

（4） 微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。

2、微服务的原则

（1）单一职责原则

（2）服务自治原则

（3）轻量级通信原则

（4）接口明确原则

3、微服务的优点

（1）易于开发和维护

（2）启动较快

（3）局部修改容易部署

（4）技术栈不受限

（5）按需伸缩

（6）DevOps

4、微服务的挑战

（1） 运维要求较高

（2） 分布式的复杂性

（3） 接口调整成本高

（4） 重复劳动

三、微服务的基本组件

1、服务描述

服务调用首先要解决的问题是服务如何对外描述。比如，你对外提供了一个服务，那么这个服务的服务名叫什么？调用这个服务需要提供哪些信息？调用这个服务返回的结果是什么格式的？该如何解析？这些就是服务描述要解决的问题。
常用的服务描述包括RESTful API、XML配置已及IDL文件。

通常情况下，如果企业内部之间的服务，都是Java语言，选择XML配置最简单。如果内部存在多个服务，并且服务采用的是不同语言平台，建议使用IDL文件方式进行描述服务。如果还存在对外开放服务调用的话，使用 RESTful API 方式更加通用。

2、注册中心

注册中心解决服务的发布和订阅。服务提供者将自己提供的服务以及地址登记到注册中心，服务消费者则从注册中心查询所需调用的服务地址，发起请求。

3、服务框架

通过注册中心，服务消费者就可以获取到服务提供者的地址，有了地址后就可以发起调用。但在发起调用之前你还需要解决以下几个问题。服务通信采用什么协议？是 RESTful API 还是 gRPC ？数据传输采用什么方式数据压缩采用什么格式？这些活通常集成到了我们的服务框架里面。

4、服务监控（ 发现问题 ）

一旦服务消费者与服务提供者之间能够正常发起服务调用，你就需要对调用情况进行监控，以了解服务是否正常。通常来讲，服务监控主要包括三个流程，指标收集，数据处理，数据展示。监控是为了发现问题和异常，如果要进一步跟踪和定位问题，则需要进一步了解服务追踪。

5、服务追踪（ 定位问题 ）

除了需要对服务调用情况进行监控之外，你还需要记录服务调用经过的每一层链路，以便进行问题追踪和故障定位，最后达到接近问题的目的。服务监控和追踪可以合并起来，但是要明确各自的职责是不一样的。

6、服务治理（ 解决问题 ）

服务监控能够发现问题，服务追踪能够定位问题所在，而解决问题就得靠服务治理了。服务治理就是通过一系列的手段来保证在各种意外情况下，服务调用仍然能够正常进行。就目前开源的服务框架，大部分都不包括服务治理的内容，所以有可能这块是需要你和你的团队进行定制化开发，就看你做到什么程度了，就好比你有数据库但是你没有ER图描述，并不影响你用微服务，当然如果有就是锦上添花的东西了。

四、微服务组件选型

1、注册中心

① Eureka - 停更弃用
② zookeeper
③ Consul
④Nacos - 推荐

2、服务调用

① Ribbon
② RestTemplate
③ Feign
④ RPC (gRpc、Dubbo、Motan)

3、服务降级

① Hystrix - 弃用
② Sentinel - 推荐

4、服务网关

① Zuul - 弃用
② Gateway

5、服务配置

① Config - 弃用
② Nacos - 推荐

6、服务总线

① Bus
② Nacos - 推荐

五、CAP 定律

这个定理的内容是指的是在一个分布式系统中 Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）三者不可得兼。

（1） 一致性（C）：在分布式系统中，如果服务器集群，每个节点在同时刻访问必须要保持数据的一致性。

（2）可用性（A）：集群节点中，部分节点出现故障后任然可以使用 （高可用）

（3）分区容错性（P）：在分布式系统中网络会存在脑裂的问题，部分 Server 与整个集群失去节点联系，无法组成一个群体。

分布式系统只能在 CP 和 AP 选择一个平衡点。

（1）CP 情况下：虽然我们服务不通用，但是必须要保证数据的一致性。
（2）AP 情况下：可以短暂保证数据不一致性，但是最终可以一致性，不管怎么样，要能够保证我们的服务可用。

注册中心产品对比

1、Zookeeper

Zookeeper 采用 CP 保证数据的一致性的问题，原理采用(ZAP原子广播协议)，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。
当我们 ZK 领导者因为某种情况下部分节点出现了故障，会自动重新实现选举新的领导角色，整个选举的过程中为了保证数据一致性的问题，客户端暂时无法使用我们的 Zookeeper，那么这意味着整个微服务无法实现通讯，这就导致在选举期间注册服务瘫痪。在云部署环境下， 因为网络问题使得 zk 集群失去 master 节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。

注意：可运行的节点必须满足过半机制，整个 zk 采用使用。

2、Eureka

Eureka 采用 AP 设计思想实现分布式注册中心。Eureka Server 采用的是Peer to Peer 对等通信，完全去中心化、无 master/slave 之分，每一个 Peer 都是对等的，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点，每个节点都可被视为其他节点的副本。

中心化：必须围绕一个领导角色作为核心，选举为领导和跟随者角色。
去中心化：每个角色都是均等。

在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点上，当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会在节点间进行复制（replicate To Peer）操作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。
当一个新的 Eureka Server 节点启动后，会首先尝试从邻近节点获取所有注册列表信息，并完成初始化。Eureka Server 通过 getEurekaServiceUrls() 方法获取所有的节点，并且会通过心跳契约的方式定期更新。
Eureka 的集群中，只要有一台 Eureka 还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪。

3、Nacos

Nacos 从 1.0 版本选择 AP 和 CP 混合形式实现注册中心，默认情况下采用 AP，CP 则采用 Raft 协议实现保持数据的一致性。

如果选择为 AP 模式，注册服务的实例仅支持临时模式，在网络分区的的情况允许注册服务实例。
选择 CP 模式可以支持注册服务的实例为持久模式，在网络分区的产生了抖动情况下不允许注册服务实例。

Nacos 除了服务的注册发现之外，还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。

Nacos = Spring Cloud 注册中心 + Spring Cloud 配置中心。

常见分布式一致性算法

（1）ZAP 协议（底层就是基于Paxos实现），核心底层基于 2PC 两阶段提交协议实现。
（2）ratf 协议：Nacos中集群保证一致性算法采 ratf 协议模式，采用心跳机制实现选举的。

（1）ZAP 底层实现原理

Zookeeper 基于 ZAP 协议实现保持每个节点的数据同步，中心化思想集群模式，分为领导和跟随者的角色。
1）在程序中如何成为某个节点能力比较强：

对每个节点配置一个myid 或者 serverid,数据越大表示能力越强；
整个集群中为了保持数据的一致性的问题，必须满足大多数情况（ 可用节点数>n/2+1） 可运行的节点环境才可以使用；
ZAP 的协议实现原理是通过比较 myid 谁最大，谁就是可能领导角色，只要满足过半的机制就可以成为领导角色，后来启动的节点不会参与选举。

2）如何保持数据的一致性的问题

所有的写的请求统一交给我们的领导角色实现，领导角色写完数据之后，领导角色再将数据同步给每个节点.
注意：数据之间同步采用 2pc 两阶段提交协议.

3）选举过程：

先去比较 zxid 谁最大谁就是领导角色，如果 zxid 相等的情况下，myid 谁最大谁就为领导角色。

（2）Ratf 底层实现原理

在 Raft 协议中分为的角色：跟随者、竞选者、领导

大多数： >n/2+1

任期：每次选举一个新的领导角色，任期都会增加。

默认情况下选举的过程：

1）默认的情况下每个节点都是为跟随者角色
2）每个节点随机生成一个选举的超时时间，大概为100-300ms，在这个超时时间内必须要等待。
3）超时时间过后，当前节点的状态由跟随者变为竞选者角色，会给其他的节点发出选举的投票的通知，只要该竞选者有超过半数以上即可选为领导角色。
核心的设计原理其实就是靠的 谁超时时间最短谁就有非常大的概率为领导角色。

故障的重新实现选举：

如果我们跟随者节点不能够及时的收到领导角色消息，那么这时候跟随者就会将当前自己的状态由跟随者变为竞选者角色，会给其他的节点发出选举的投票的通知，只要该竞选者有超过半数以上即可选为领导角色。

是否可能会产生两个同时的竞选者呢，同时实现拉票呢？

如果集群节点总数是奇数情况下，就算遇到了该问题也不用担心。
当我们的节点是为偶数的情况下，可能会存在该问题，如果两个竞选者获取的票数相等的情况下，开始重置竞选的超时时间，一直到谁的票数最多谁就为领导。