这是我参与「第五届青训营」伴学笔记创作活动的第9天。青训营的第九次课程中对微服务框架相关知识进行了讲解，下面是我对本次课程内容的一些总结。
微服务架构原理及特征
基本概念
在微服务架构中，系统的所有功能均被抽象成服务的概念，系统通过服务与服务之间协作的方式完成任务。在微服务架构中，有如下基本概念：
- 服务：一组具有相同逻辑的运行实体，相同逻辑可以理解为相同代码；
- 实例：一个服务中，每个运行的实体即为一个实例，一个实例可能由一个或多个进程组成
- 集群：指服务内部的逻辑划分，包含多个实例
- 有状态/无状态服务：服务的实例是否存储了可持久化的数据。
- 服务间通讯：服务间通讯意味着网络传输，与单机服务的函数调用不同；
服务发现
在微服务架构中，服务注册及发现机制是非常重要的一点，其为服务之间提供彼此服务实例的地址。其出现原因为，一些简单的方案并不能解决实例地址寻找的问题：
- 若直接指定服务实例的ip地址及端口号，则导致服务实例将没有任何动态调整的能力；
- 若使用域名代替ip地址，使用DNS动态寻找ip地址，则DNS的本地缓存会使得实例切换后存放访问延迟，且DNS也不能指定负载均衡、探活检查等服务功能。并且，DNS不能指定端口，大量的实例使用同一个端口是不合理的。
因此，微服务架构中可以存在一个统一的服务注册中心，其中存储了服务名到服务实例的映射关系。
流量特征
在微服务架构中，由于RPC的效率比HTTP更高，通常使用HTTP作为外网通信接口，RPC作为内网通信方式。
核心服务治理功能
服务发布
服务发布是指微服务架构中，让一个服务升级成新的代码的过程。其存在的难点有如下几条：
- 服务不可用：在服务升级过程中，会停止原有版本实例的工作，如果没有处理方法将会导致服务阻塞；
- 服务抖动：当服务中的部分实例更新时，会导致原有通向它的流量返回错误，导致服务抖动；
- 服务回滚：当新版本代码出现BUG时，需要回滚机制保证服务的可用性。
在这里，解决上述问题的方法有如下几种：
- 蓝绿部署：将服务分成两个部分，分别先后发布。其优点为方法简单稳定；缺点为更新时需要两倍的资源；
- 灰度发布：先发布少部分实例，再逐渐增加发布比例。其优点为不需要增加资源；缺点为当更新比例较大时出现BUG，回滚难度较大。
流量治理
可以基于地区、集群、实例、请求等维度，对端到端流量的路由精确控制，如：
- 基于地区：在一个地区的请求发送到本地的实例，在另一个地区的请求发送到另一个地区的实例；
- 基于集群：可以使得大部分流量打入稳定版本集群，小部分流量打入测试版本集群；
- 基于实例：可以使得较多流量打入高性能服务器实例，较少流量打入低性能服务器实例；
- 基于请求：使得常规的请求打入稳定版本实例，内部测试请求打入测试版本实例。
负载均衡
负载均衡负责分配请求在每个下游实例上的分布，常见的负载均衡策略有：轮询方式、随机访问方式、一致性哈希方式、最少访问方式。
稳定性治理
为了防止网络故障、机器故障等突发问题，需要对服务进行一定的稳定性保障，如：
- 限流：限制服务所处理的最大QPS，防止过多请求的访问；
- 熔断：当实例出现故障时，中断请求路径使得实例尝试恢复；
- 过载保护：在负载高的实例中，主动拒绝一部分请求减少压力；
- 降级：当服务能力不足时，只相应线上高优先级请求；
