GO 训练营第 1 周总结

微服务概览与治理

微服务

区别与传统的单体架构，微服务采用业务拆分将子业务分配到各个服务上，各服务采用轻量级的通信，并独立部署。

核心目标：

• 单一业务的服务化：

• 解决单一服务的业务过于复杂度，难以维护的问题

• 传统用库的方式组合，微服务用子服务的方式整合成完整业务；

• 按业务对团队进行分工调整

• 服务隔离：

• 解决耦合带来的系统异常问题；

• 实现数据、业务、资源的隔离；

• 去中心化

• 解决服务迭代更新难的问题；

• 治理去中心化：子服务的更新相互不影响，维持接口协议的稳定即可；

• 数据去中心化：缓存、业务独立的数据隔离

• 技术去中心化：减少共享库的依赖

重点特性：

• 基础设施自动化

• CI/CD

• testing

• 监控、告警

• 可用性、兼容性设计

• 隔离

• 限流

• 超时控制

• 负载保护

• 降级

• 重试

• 负载均衡

缺点：

基础建设复杂度高

微服务设计

BFF、网关的设计

毛老师结合 B 站的系统演进历史，对比了：

• 第一版客户端到服务端的直连依赖

• 服务端接口对外暴露，更新迭代困难

• 客户端需要适配、拼接多个服务端数据，业务开发量十分繁重

• 到第二版客户端与服务端通过 BFF 依赖

• 解放了客户端的业务开发量

• 但鉴权、限流等横向切面功能需要各个 BFF 层子服务重复开发或通过共享库依赖，后者有更新迭代困难的缺点

• 到第三版客户端与服务端先通过网关再通过 BFF 依赖

• 将鉴权、限流等横向切面功能抽到网关层，解决了第二版的问题

CQRS

分离命令端和查询端，即写数据的应用和查询数据的应用分离。

这个是举了 B 站稿件发布的场景，写稿件的应用会操作大量的数据，但查稿件状态只需要少量数据，为降低代码 bug 导致数据受影响的风险，可将两个功能隔离到不同服务上。我对此的理解是，它也是单一业务服务化的一种体现。

安全

主要是服务内部怎样做安全，这种场景估计需要一定业务体量和需求，所以只是做个了解，先了解下有这回事。

gRPC 和服务发现

这是为了解决去中心化的核心目标而引入的。

选择 gRPC 的原因

• gRPC 是基于 http2 双向流且可复用连接，比 http1.1 的单向流省 tcp 连接；

• 代码即文档，表现力比 http restful 强，能提高接口的标准化；

• 可支持在公网，统一内网外通信

• healthCheck，端对端异步检测，辅助平滑发布

服务发现

• 客户端：每个客户端实现服务实例的发现和相同的负载均衡算法，并直连服务实例进行通信；

• 服务端：中间加入网关层，网关实现服务实例的发现，客户端只连网关，好处是不需要共享负载均衡算法和服务实例发现的逻辑，可以避免这部分的共享库或多语言重复开发相同功能，但需要保证网关的可用性和扩展性；

• service mesh：k8s pod 部署 app 和 LB（网关），LB 实现服务实例的发现和负载均衡，且 LB 可以通过镜像的方式发布，比共享库要方便；

• B 站由于内部环境，采用的是客户端的发现，因为服务端和 service mesh 都比较复杂；

• 框架：B 站的 discover, 基于 eureka，两者是 AP 系统（最终一致），有注册和注销延迟，更好的是阿里的 nacos；

多集群与多租户

多集群

解决服务可用性问题，多个集群承担流量，避免集群式的故障导致服务不可用。

需要注意缓存热点问题，如果集群平时单独用于某个业务，有其它业务切入时可能会导致缓存 miss，造成数据库的冲击，有可用性的隐患。B 站采用的是集群无状态、数据冗余的方法，让各个集群用于所有业务，相当于各个集群都冗余了数据。

多租户

解决微服务全链路测试的问题。

通过给测试的流量打标签，然后测试环境根据过滤特定标签实现功能隔离，从而能够同时运行任意套测试环境。