本文最后更新于 617 天前，其中的信息可能已经有所发展或是发生改变。

由 ChatGPT 生成的文章摘要

本文介绍了微服务架构中的服务治理方式，包括服务注册与发现，服务发布和稳定治理。服务注册与发现通过一个中心化的服务注册中心，实现了服务间通信地址的动态管理。服务发布通过蓝绿部署和灰度部署等方式，让服务的升级更加平滑和可控。稳定性治理通过限流、熔断、降级等方式，增加了服务的稳定性。同时本文指出，微服务架构的复杂度引来了治理、运维难度飙升等劣势，但通过服务治理模式的引入，这些问题可以得到解决。

微服务中的服务治理 | 青训营笔记

这是我参与「第五届青训营」伴学笔记创作活动的第 9 天

前言

本文介绍了微服务架构中的服务治理方式，包括服务注册与发现，服务发布和稳定治理。

什么是微服务

微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。 —— Amazon AWS

对于微服务，有以下基本概念：

服务（Service）：一组具有相同逻辑的运行实体。
实例（Instance）：一个服务中，每一个运行实体即为一个实例。
集群（Cluster）通常指服务内部的逻辑划分，包含多个实例。
有状态/无状态服务：指服务的实例是否存储了可持久化的数据（例如磁盘文件）

微服务架构的出现和应用大幅度的提升了大型程序的开发效率，降低了程序故障率，但其复杂的架构设计也引来了治理、运维难度飙升，观测难度大，安全性较低等劣势。

我们通过引入许多的服务治理模式来解决这些问题。

服务注册与发现

服务注册与发现是为了解决微服务中服务间通信地址难以确定的问题。

想象一个服务 A 试图通过网络请求调用服务 B 的某个接口，他应该如何确定服务 B 的网络地址？

如果我们通过硬编码的方式在服务 A 指定网络地址，灵活性低暂且不说，对于具有多个实例的服务 B，一个网络地址只能指定到同一个服务实例中，这会导致服务 A 的所有实例全部向服务 B 的单一实例进行网络请求，这明显是不符合我们负载均衡要求的。

我们可以尝试使用配合 DNS 的方式，不直接传入 IP 地址，而是传入域名，通过修改 DNS 服务中域名的 IP 地址来解决上文中灵活性的问题。但这依然产生了问题，首先负载均衡问题仍未得到解决，其次本地 DNS 由于存在缓存，因此我们没办法做到服务更改的实时切换，亦无法支持服务实例得探活检查；最后，这种方式由于端口依然是写死在代码里的，我们依然没有办法自定义端口号。

为了解决这些问题，我们引入服务注册与发现的概念。

在服务注册与发现的体系中，我们新增了一个统一的服务注册中心服务，用于存储服务名到服务实例的映射，需要进行跨服务网络请求的服务只需要向服务注册中心查询指定服务名便可得到该服务名包括的所有实例地址。

当需要下线一个旧实例时，会从服务注册中心删除该实例，下线流量；反之，当需要上线一个新实例时，则从服务注册中心注册该实例，上线流量。

同时，所有服务实例自身还会进行健康检查以确定自己的服务始终可用，并以此决定自己是否可以继续提供服务。