这是我参与「第五届青训营 」伴学笔记创作活动的第 5 天
这次课程涉及微服务框架，包括微服务框架原理及特征、核心服务治理、字节跳动服务治理实践，这都是一些高级开发技能，我认为，对于这种难度较高的技术我的入门学习就是先夯实基础概念。所以我简单总结了本节课的知识点，主要着重于理清概念和回答思考题。
本节课程主要分为4个方面，所以本文也从4个方面总结。
一、微服务架构介绍
系统架构的演进历史
-
单体架构
所有功能集中在一个系统，模块间相互影响
-
垂直应用架构
按照业务线垂直划分，比如一整个系统划分为电商系统、后台系统、广告系统等，每个系统仍是单体架构
-
分布式架构
抽出与业务无关的公共模块，抽出服务层
-
SOA架构，Service-Oriented Architecture，面向服务的架构
面向服务，拥有服务注册中心，整个系统是中心化的，从上至下设计的，重构困难
-
微服务架构
彻底服务化
微服务架构的三大要素
- 服务治理（本课程内容）、可观测性、安全
二、微服务架构原理及特征
基本概念
- 服务：一组具有相同逻辑的运行实体
- 实例：一个服务中的每个运行实体，一个服务可以有多个实例。
- 一个实例可以有一个或多个进程
- 微服务间通过网络进行通信，常用通信协议是HTTP、RPC
服务注册及服务发现
-
基本问题
服务间调用中，如何指定下游服务实例的访问地址？
-
方案1：直接指定 ip:port？
存在问题：没有任何动态能力，有多个实例下游实例时无法改
-
方案2：使用 DNS？
存在问题：1. 本地 DNS 存在缓存，导致延迟 2. 没有负载均衡 3.不支持服务探活检查 4.DNS 不能指定端口
-
方案3：服务注册发现
- 新增一个统一的服务注册中心，用于存储服务名到服务实例之间的映射关系，其实就是一个哈希表
- 旧服务实例下线前，从服务注册中心删除该实例，下线流量
- 新服务实例上线后，在服务注册中心注册该实例，上线流量
-
微服务流量特征
- 统一网关入口
- 外网通信多数采用 HTTP，内网通信多数采用 RPC（Thrift, gRPC）
三、核心服务治理功能
服务发布
-
什么是服务发布？让一个服务升级运行新的代码的过程，就像是游戏版本更新，但是游戏的服务不能中断。
-
服务发布难点：服务不可用、服务抖动、服务回滚
-
蓝绿部署
- 将服务分成两个部分，一半资源在升级，一半在处理所有流量。分别先后发布。
- 优点简单、稳定，缺点需要两倍资源
-
灰度发布（金丝雀发布）
- 先发布少部分实例，接着逐步增加发布比例
- 优点不需要增加资源，缺点回滚难度大，基础设施要求高
流量治理
-
流量控制
在微服务架构中，可以从地区、集群、实例、请求等维度对端到端的流量在链路上进行精确控制
负载均衡
- 负载均衡（Load Balance）负责分配请求在每个下游实例上的分布
- 常见的LB策略：Round Robin、Random、Ring Hash、Least Request
稳定性治理
- 线上服务总会可能出问题，与程序正确性无关，有一些不可抗力因素，比如网络攻击、机房断电、光纤被挖等，服务故障可能导致服务半天不可用，损失极大。
- 限流：限制服务处理的最大 QPS，拒绝过多请求
- 熔断：中断请求路径，增加冷却时间从而让故障实例尝试恢复
- 过载保护：在负载高的实例中，主动拒绝一部分请求，防止实例被打挂
- 降级：服务处理能力不足时，拒绝低级别的请求，只响应线上高优请求
四、字节跳动服务治理实践
-
重试意义
- 本地函数调用，可能有参数非法的异常导致调用失败，但通常没有重试意义
- 远程函数调用，可能有网络抖动、下游负载高、下游机器宕机的故障导致调用失败，这里重试是有意义的，可以避免偶发性的错误，降低长尾延迟，提高 SLA（Sercice-Level Agreement）（服务水平等级）
-
重试风暴：随着调用链路的增加，重试次数呈指数级上升
-
重试策略：限制重试比例、防止链路重试、Hedged Requests
五、课后思考
- 结合 CAP 等原理，思考微服务架构有哪些缺陷？
CAP定理又称CAP原则，指的是在一个分布式系统中：Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）。微服务框架不满足CAP定理中的C（一致性）原则，微服务之间的数据一致性问题很难解决，这是分布式系统的通病。此外，微服务框架的缺陷还有 系统复杂、延迟高、部署繁琐、调试困难等问题。
- 微服务是否拆分得越“微”越好？为什么？
我认为不一定。微服务拆分的粒度要根据实际业务需求来决定，并不是越微越好。
如果微服务拆分得过小，可能它们之间的通信和协调成本可能会变得过高，从而影响系统的效率和性能。
如果微服务拆分得过大，则可能不能充分利用微服务架构的优势，例如提高可靠性和可扩展性。
因此，拆分微服务的粒度是根据实际业务需求和技术限制来决定的，而不是单纯地追求拆分得越微越好。
- Service Mesh 这一架构是为了解决微服务架构的什么问题？
微服务架构问题有网络复杂、服务治理困难、服务管理困难、安全等，Service Mesh 就是为解决这些问题而提出的。Service Mesh 架构通过在微服务间提供一层代理，来简化服务间的通信和管理，同时也提供了强大的监控、跟踪、配置等功能，从而解决了微服务架构中遇到的这些问题。
- 有没有可能有这样一种架构，从开发上线运维体验上是微服务，但实际运行又类似单体服务？
我认为这种架构是有可能存在的。这可以通过在开发和部署过程中使用微服务架构的思想和工具，但在运行时将所有服务部署在单个节点上来实现。这样的好处是，可以保证开发体验和部署简便，同时也不失灵活性和扩展性。
