微服务中的服务治理 | 青训营笔记
前言
本文介绍了微服务架构中的服务治理方式，包括服务注册与发现，服务发布和稳定治理。
什么是微服务
微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的API 进行通信的小型独立服务组成。 这些服务由各个小型独立团队负责。 微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。 —— Amazon AWS
对于微服务，有以下基本概念：
- 服务（Service）：一组具有相同逻辑的运行实体。
- 实例（Instance）：一个服务中，每一个运行实体即为一个实例。
- 集群（Cluster）通常指服务内部的逻辑划分，包含多个实例。
- 有状态/无状态服务：指服务的实例是否存储了可持久化的数据（例如磁盘文件）
微服务架构的出现和应用大幅度的提升了大型程序的开发效率，降低了程序故障率，但其复杂的架构设计也引来了治理、运维难度飙升，观测难度大，安全性较低等劣势。
我们通过引入许多的服务治理模式来解决这些问题。
服务注册与发现
服务注册与发现是为了解决微服务中服务间通信地址难以确定的问题。
想象一个服务 A 试图通过网络请求调用服务 B 的某个接口，他应该如何确定服务 B 的网络地址？
如果我们通过硬编码的方式在服务 A 指定网络地址，灵活性低暂且不说，对于具有多个实例的服务 B，一个网络地址只能指定到同一个服务实例中，这会导致服务 A 的所有实例全部向服务 B 的单一实例进行网络请求，这明显是不符合我们负载均衡要求的。
我们可以尝试使用配合 DNS 的方式，不直接传入 IP 地址，而是传入域名，通过修改 DNS 服务中域名的 IP 地址来解决上文中灵活性的问题。但这依然产生了问题，首先负载均衡问题仍未得到解决，其次本地 DNS 由于存在缓存，因此我们没办法做到服务更改的实时切换，亦无法支持服务实例得探活检查；最后，这种方式由于端口依然是写死在代码里的，我们依然没有办法自定义端口号。
为了解决这些问题，我们引入服务注册与发现的概念。
在服务注册与发现的体系中，我们新增了一个统一的服务注册中心服务，用于存储服务名到服务实例的映射，需要进行跨服务网络请求的服务只需要向服务注册中心查询指定服务名便可得到该服务名包括的所有实例地址。
当需要下线一个旧实例时，会从服务注册中心删除该实例，下线流量；反之，当需要上线一个新实例时，则从服务注册中心注册该实例，上线流量。
同时，所有服务实例自身还会进行健康检查以确定自己的服务始终可用，并以此决定自己是否可以继续提供服务。
服务发布
在工程实践中，我们经常需要对一套代码进行更新，对于小型单体服务，我们通常的做法是直接暂时下线该服务，然后更新后重新上线。但对于大型服务尤其是微服务，这种可能造成服务不可用的情况是绝对不可接受的。为了避免服务更新过程中导致的服务不可用，服务抖动，服务宕机问题，我们引入服务发布的概念。
有两种主要方法来进行服务发布：蓝绿部署和灰度部署（金丝雀部署）。
蓝绿部署的服务发布方式是，将服务实例分成两个部分，分别先后发布，这样访问该服务的其他服务总是可以正常运行，因为始终有一部分服务实例时正常运作的。这种部署方法的优点是简单稳定，缺点是需要提供双倍的资源来保证服务稳定。
灰度发布（金丝雀发布）的服务发布方式是，先发布少部分实例，接着逐步增加发布比例。优点是不需要增加资源，缺点是回滚难度大，且对基础设施要求高。
稳定性治理
在微服务架构中，可以使用限流，熔断，过载保护，降级等方式来增加服务的稳定性。
引用
该文章部分内容来自于以下课程或网页：
- 字节内部课：微服务架构原理与治理实践
- 什么是微服务？| AWS (amazon.com)
