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

前言

这是我在青训营学习发布的第八篇笔记，本文介绍了微服务架构中服务治理的方式，包括服务注册与发现、服务发布和稳定性治理。

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

在微服务中，有以下基本概念：

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

微服务架构的出现和应用大大提高了大型程序的开发效率，降低了故障率。但其复杂的架构设计也带来了治理和运维难度的增加，观测难度高，安全性较低等问题。

为了解决这些问题，我们引入了许多服务治理模式。

服务注册与发现旨在解决微服务中服务间通信地址不确定的问题。

假设服务 A 希望通过网络请求调用服务 B 的接口，那么服务 A 如何确定服务 B 的网络地址？

如果我们通过硬编码的方式在服务 A 中指定网络地址，灵活性较低。对于具有多个实例的服务 B，一个网络地址只能指定到同一个实例，导致服务 A 的所有实例都向服务 B 的单个实例发送网络请求，不符合负载均衡的要求。

我们可以尝试使用与 DNS 配合的方式，不直接传递 IP 地址，而是传递域名。通过修改 DNS 服务中域名的 IP 地址来解决灵活性问题。然而，仍存在负载均衡问题，并且由于本地 DNS 缓存的存在，无法实现实时切换服务。此外，这种方式仍然需要在代码中硬编码端口号，无法自定义端口。

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

在服务注册与发现系统中，我们引入一个集中的服务注册中心，用于存储服务名和服务实例的映射关系。需要进行跨服务网络请求的服务只需向注册中心查询指定服务名，就可以获取包括所有实例地址的信息。

在下线旧实例时，将从服务注册中心中删除该实例以停止流量。而在上线新实例时，将在服务注册中心中注册该实例以接收流量。

同时，所有服务实例还会进行健康检查，以确保自身服务的可用性，并根据检查结果决定是否继续提供服务。

在实际工程中，我们经常需要对代码进行更新。对于小型单体服务，通常的做法是将服务暂时下线，然后进行更新后重新上线。但对于大型服务，尤其是微服务，这样的服务不可用情况是绝对不可接受的。为了避免服务更新过程中导致的服务不可用、服务抖动或服务宕机问题，我们引入了服务发布的概念。

服务发布有两种主要方法：蓝绿部署和灰度部署（金丝雀发布）。

蓝绿部署是将服务实例划分为两个部分并分别发布的一种发布方式。这样，其他服务访问该服务时总能够正常运行，因为始终有一部分服务实例是正常运行的。蓝绿部署的优点是简单稳定，缺点是需要提供双倍资源以保证服务的稳定性。

灰度发布（金丝雀发布）是先发布少部分实例，然后逐步增加发布比例。其优点是不需要增加资源，缺点是回滚困难，且对基础设施要求较高。

在微服务架构中，可以使用限流、熔断、过载保护、降级等方式来增加服务的稳定性。