在编写代码的过程中,我们常常运用各种设计模式来优化代码结构和提高代码效率。此前,我已经用灸哥特有的风格对三大类的设计模式进行了详尽的阐述,并通过福利放送的形式将相关电子合集分享给了各位读者。领取方式请参见文章底部。
值得注意的是,在云原生架构中,同样存在一系列典型的设计模式,例如服务化架构模式等。本文将和大家一起深入探讨这些在云原生架构中常用的设计模式,助力大家提升设计灵活、高效、可扩展解决方案的能力。同时,我们还将分析一些典型的反模式,以帮助大家规避潜在的陷阱和误区。
一、服务化架构模式
服务化架构通常也被称为面向服务的架构 SOA,在通信双方之间约定好服务规约,然后基于规约发布和调用服务,服务化架构模式的核心价值主要体现在:
- 更好地面向业务:通信双方是基于自己的实际业务需求设计接口(服务规约)
- 松耦合和灵活性:在约定好服务规约之后只要遵循规约即可
- 服务共享和复用:服务通常是可共享的,多个服务消费者可以同时调用共享服务
在实际服务化架构模式实践过程中,具体可用于实现服务规约的技术方案主要有三种:服务接口定义、IDL、OpenAPI。
1、 服务规约
服务规约,简单说就是双方定义好的接口,一般由以下三种实现方案:
服务规约技术实现方案一:服务接口定义
服务接口定义是指对应的编程语言对服务接口的描述。比如 Dubbo 是通过 Java 接口来实现的。比如:
public interface ItemService {
Item findById(Integer id);
Boolean createItem(Item item);
}
基于编程语言提供的特性可以帮助我们很好地实现服务规约,但是这种实现方式有利有弊。利好是能够很好地支持某种支持的编程语言,比如 Java,但是并不是每一种编程语言都支持接口定义的,比如 JavaScript。
服务规约技术实现方案二:IDL
IDL 是指通过 IDL(Interface Definition Language,接口定义语言)对服务进行规约的定义,比如 gRPC、Thrift 等。使用步骤:
- 基于 IDL 定义对应的服务接口
- 基于 IDL 文件生成与编程语言对应的代码
- 实现对应的服务接口或者调用对应的服务
以 gRPC 为例,首先要基于 Protocol Buffers 编写 IDL 文件
service ItemService {
rpc FindItem (GetItemRequest) returns (ItemResponse);
rpc FindById (google.protobuf.Int32Value) returns (ItemResponse);
}
message GetItemRequest {
int32 id = 1;
}
message ItemResponse {
int32 id = 1;
string name = “”;
}
接口定义之后,根据 protoc 命令行为不同的编程语言生成对应的代码,可支持面向 C++、Go、Java、Node.js 等编程语言。
服务规约技术实现方案三:OpenAPI
OpenAPI 是基于 HTTP REST 通信的接口规范,它本身与具体的编程语言无关,任何语言都可以基于 OpenAPI 规范发布和调用服务。
2、 服务分组
服务分组的目的是为了满足不同的地理空间和服务等级需求。比如在不同的数据中心,即使是相同的服务,也要通过不同的集群部署方式来区分。此外,如果你的场景需要考虑到服务等级要求,像 VIP 的服务,也会涉及到同样的服务在不同分组中的不同要求。
3、 服务版本
服务发布后,随着需求的变更,需要在原有的服务规约上提供更多的服务接口,可能会涉及到具体的逻辑变更。这样在考虑兼容性的时候,需要用服务版本来区分前后服务的接口规约。
4、 服务元信息
当服务数量超级多的时候,为了便于查找接口方便,是需要给服务添加一些元信息,比如服务描述、提供者信息、Tag 等,便于对服务的管理。
5、 服务注册与发现
这里的内容就不多做介绍了,前面已经讲了好多了,放一张图,不熟悉的去翻阅我之前关于服务注册与发现的内容。
6、 其他
- 服务健康检查
- 服务优雅上下线
- 服务调用负载均衡
- 服务接口隔离
二、Service Mesh 化架构模式
Service Mesh 是在服务化架构的基础上,引入了一个专门的网络代理层,负责处理服务间的通信。这减轻了应用程序的负担,提供了更好的可观测性、安全性和流量管理。
Service Mesh,服务网格,是专用的基础结构层,主要用于保障服务之间安全、快速和可靠的通信。
- Service Mesh 是基础设施层,在某些场景下可能要与其他基础设施交互,比如基础网络、PaaS 平台、运维系统等
- Service Mesh 可用于解决个服务之间的通信问题,服务之间通信机制比较复杂,包括通信协议、负载均衡等,因此 Service Mesh 是能够支持多种协议的适配,同时能够支持相关的特性,比如负载均衡等
- Service Mesh 是安全、快速和可靠的
Service Mesh 包括三种模式:
1、 模式一:Sidecar 模式
Sidecar 模式在 Service Mesh 架构中起了关键作用,尤其是 Istio & Envoy 的结合,在此模式下,每个服务旁边都会部署一个 Envoy 代理,该代理负责处理服务间的所有网络通信。
核心流程
- Service A 要与 Service B 通信, Sidecar 要求双方首先与应用侧的 Envoy 连接
- 在发起服务间调用时,服务消费者 Service A 首先将服务调用请求发送给自己的 Envoy 代理人
- Service B 的 Envoy 代理人再将请求转发给正式服务提供者 Service B,完成服务的调用
- 服务调用的响应