PolarisMesh源码系列--Polaris-Go注册发现流程
导语
北极星是腾讯开源的一款服务治理平台,用来解决分布式和微服务架构中的服务管理、流量管理、配置管理、故障容错和可观测性问题。在分布式和微服务架构的治理领域,目前国内比较流行的还包括 Spring Cloud,Apache Dubbo 等。在 Kubernetes 的技术领域,也有以 Istio 为代表的 ServiceMesh 技术。本篇 Blog 主要分析北极星的优势,及其服务注册发现的技术实现。
我是如何看待这些技术
要做好一个服务治理框架,核心功能和要素至少包括以下几点:
-
服务注册发现
-
路由,熔断,限流
-
配置中心
-
可观测性, 日志、度量、链路追踪
从功能实现方面来看,不管是 SpringCloud,Apache Dubbo,Istio 还是北极星,基本都实现了这些功能,那它们的实现思路有什么不同呢?
SpringCloud
SpringCloud 是完全架构在 SpringBoot 基础上的,是 SpringBoot 开发框架很自然的延伸,因此继承了 SpringBoot 框架所有的优点,可以非常灵活的集成各类服务注册发现、服务治理、可观测组件。例如 SpringCloud 框架自身开发了 Spring-Cloud-Config 和 Spring-Cloud-Sleuth 组件,分别提供了配置和部分可观测性的能力;在其他能力方面,早期版本主要由 Netflix 提供的 Eureka, Ribbon, Hystrix等组件提供了服务注册发现,服务治理的能力; 随着 Netflix 很多组件生命周期结束, SpringCloud 又通过自定义的 Abstract LoadBalance/Route 接口及实现, 以及集成的 Resilience4J/Sentinel 等熔断限流组件,继续为用户提供统一的服务注册发现,服务治理等方面的能力。
SpringCloud 在实际使用过程中, 可能会给人一种没有一个统一的服务治理模型的错觉, 这是因为 SpringCloud 保持了自身的胶水框架的特性和思路, 可以集成和融合各类治理组件,例如熔断限流就提供了 Hystrix、Resilience4J、Sentinel 等方式。这样的框架特性,优势是灵活,可以融合各类框架,劣势是抽象统一的治理模型比较困难,因此 SpringCloud 并没有提供一个统一的服务治理控制面,即使是 Spring-Cloud-Admin 的扩展,也更多是基于 SpringBoot Actuator 提供可观测的管理,并没有提供服务治理的控制面能力。
ServiceMesh-Sidecar 模式
ServiceMesh 解耦了业务逻辑和服务治理逻辑,它将服务治理能力下沉到基础设施,在服务的消费者和提供者两侧以独立进程的方式部署。这种方式提升了整体架构的灵活性,减少对业务的侵入性并很好的解决了多语言支持的复杂性。劣势是一方面服务通过 sidecar 的调用多了一道 iptables/ipvs 的转发,降低了一些性能,Sidecar 也增加了少量的资源使用;另一方面是中小团队很难对框架灵活扩展,虽然 Envoy 提供了 WASM 机制,其自身也能通过 C++ 扩展 Filter,但是不管哪种方式,都需要团队有一定经验的人员来完成,中小团队很难提供这样的人员保障。
另外,Istio 虽然也能提供基于虚拟机/物理机的部署,但是本身还是基于Kubernetes 设计的,也对 Kubernetes 部署最友好,对于未使用 Kubernetes 的团队有一定的挑战。
PolarisMesh
PolarisMesh 从个人的角度看,是融合和兼容了很多技术的解决方案。
一方面,它可以看作是 SpringCloud 服务治理实践的一种自顶向下的正向思考过程,SpringCloud 是自底向上的一种构建思路,它提供了各类服务发现、服务治理、可观测组件的集成和融合,但是并没有提供统一的顶层治理模型(或者仅提供了一部分);而 Polaris 是先基于下一代架构基金会所制定的服务治理标准,制定和扩展了服务治理的模型,然后基于该模型,分别构建了服务治理的控制面和数据面(各类语言的 SDK、开发框架、JavaAgent、Kubernetes Controller)。当然,基于该模型,也能很好的对接到 ServiceMesh 的治理方式, 这样就给未来的发展也留足了空间。
另一方面,PolarisMesh 也通过插件机制,为框架扩展预留了空间,如果当前的开源 Polaris 不满足你的需求,可以较灵活的进行扩展。
polaris-go SDK 服务注册发现技术分析&源码阅读
本篇 Blog 重点对 Polaris-Go SDK 的服务的注册和发现做下技术分析, 以及源码阅读。主要是服务注册和发现是各类服务治理框架最基础和核心的功能,因此先从它开始吧~
公共部分 SDKContext
在客户端 SDK, 不论是服务注册的 API, 还是服务发现的 SDK,其内部都是封装了 SDKContext 的上下文, SDKContext 内部构成如下图所示:
ConfigurationImpl: 主要是客户端 polaris.yaml 配置文件的映射, 分为4个部分,分别是 GlobalConfig, ConsumerConfig, ProviderConfig 和 ConfigFileConfig 。
ConnectionManager: gRPC 连接的连接池管理接口。
plugin.Manager: 插件管理接口,SDK 内部实现的各类功能- 熔断,限流,配置,健康检查,路由,负载均衡等都是按照插件的方式实现, 插件需要实现 Plugin 接口,通过 PluginProxy 包装后交给 plugin.Manager 管理。
Engine:SDK 执行的各类动作,都交由 Engine 处理, 例如服务的注册发现,限流,路由,熔断等,都是调用 Engine 内的 API 实现。也就是 SDK 能执行的功能,都是由 Engine API 统一实现。
服务注册流程
服务注册的粗略流程如下图所示 :
go 客户端 SDK 的整体服务注册流程比较线性, 没有涉及特别复杂的逻辑, 相关 gRPC service 如下:
service PolarisGRPC { // 客户端上报 rpc ReportClient(Client) returns (Response) {} // 被调方注册服务实例 rpc RegisterInstance(Instance) returns (Response) {} // 被调方反注册服务实例 rpc DeregisterInstance(Instance) returns (Response) {} // 统一发现接口 rpc Discover(stream DiscoverRequest) returns (stream DiscoverResponse) {} // 被调方上报心跳 rpc Heartbeat(Instance) returns (Response) {} // 上报服务契约 rpc ReportServiceContract(ServiceContract) returns (Response) {} }
服务发现流程
服务发现流程相对于服务注册流程要复杂很多, 主要原因是北极星的服务发现会涉及本地 Cache 与 远程 Server 端信息的懒加载同步,同时加载的服务信息也比较复杂,包括实例信息,服务信息,路由信息,限流信息等内容。
服务发现的粗略流程如下图所示 :
可以看到,服务发现中的关键点包括:
-
SDK 内部实现了 LocalCache 缓存机制, 同时 LocalCache 缓存具备以懒加载方式同步远程 Server 中服务信息的能力。
-
SDK 与远程服务信息的同步,是由插件 Serverconnector 实现, SDK客户端通过专门的 Routine 和 Channel 队列,在服务信息第一次远程懒加载完成后, 定时拉取远程 Server 中的服务信息,并更新本地缓存和插件数据。
-
获取到服务信息后,通过路由和负载均衡机制,选取出可用实例,参考官网-流量管理。
-
其他细节包括: 与服务端通信后的异步回调更新机制,超时计算,重试 ,缓存实现,插件加载机制等 。
go SDK 服务发现的 gRPC 接口如下:
// DiscoverClient 服务发现客户端接口 type DiscoverClient interface { // Send 发送服务发现请求 Send(*apiservice.DiscoverRequest) error // Recv 接收服务发现应答 Recv() (*apiservice.DiscoverResponse, error) // CloseSend 发送EOF CloseSend() error }
结语
上面的技术分析因为时间有限,难免有错误和遗漏,欢迎大家指正, 也特别感谢社区的帮助。北极星通过对服务治理标准的实现,提供了完善的服务发现和治理方案。同时, SDK客户端与 Server 服务端的数据同步与交互,也有设计良好的服务治理模型和健壮的通信机制提供了可靠的保障。此外,通过插件机制,SDK框架 也提供了灵活扩展的能力 。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
仅两家!云原生向量数据库 PieCloudVector 全项通过信通院「可信数据库」评测
7月16日,2024 可信数据库发展大会在北京隆重举行。大会以“自主、创新、引领”为主题,近百位数据库领域的专家、学者齐聚一堂,带来高质量的数据库技术洞察与实战经验。 本次可信数据库发展大会中,中国信通院正式公布 2024 年上半年“可信数据库”系列评测结果。拓数派旗下的云原生向量数据库 PieCloudVector 通过了向量数据库基础能力测试并获得证书, 同时入选中国信通院《中国数据库产业图谱(2024)》 至今,所有参加信通院向量数据库测评的产品中,只有两款通过了全部测试项目,而 PieCloudVector 是其中之一。 PieCloudVector 获得可信数据库测评证书 1 PieCloudVector 通过信通院“可信数据库”评测 “可信大数据”系列评估测试是面向大数据产品的权威测试体系,旨在从基础能力、性能、可靠性、安全等维度全面衡量企业级大数据产品的能力。 本次评测依据《向量数据库技术要求》,经过严格的测试与评审, PieCloudVector 在基本功能、运维管理、安全性、兼容性、扩展性、高可用、工具生态七大能力方面表现优异。测试结果表明,PieCloudVecto...
- 下一篇
Apache BookKeeper 一致性协议解析
导语 Apache Pulsar 是一个多租户、高性能的服务间消息传输解决方案,支持多租户、低延时、读写分离、跨地域复制(GEO replication)、快速扩容、灵活容错等特性。Pulsar 存储层依托于 BookKeeper 组件,所以本文简单探讨一下 BookKeeper(下文简称 BK) 的一致性协议是如何实现的。 背景 Pulsar相对于 Kafka 根本的区别在于数据一致性协议,这也是为什么 Pulsar 可以做到两副本就能保障高可用、高可靠,在磁盘使用方面更均衡,也不会存在单分区容量上限,同时在扩缩容、故障屏蔽等日常运维方面更加灵活和方便。 一致性协议简介 我们常见的一致性协议,比如 Raft、Kafka、ZAB 等,都是服务端集成协议(协议控制和数据存储绑定),简单来说一致性协议由服务端存储节点来执行。数据流向通常是客户端写数据到 Leader 节点,其他节点再通过推或拉的方式从 Leader 获取数据。 而 BK 的一致性协议控制和存储是分开的,协议控制是在客户端执行,可以称之为外部一致性协议,或者客户端一致性协议。数据流向为客户端向多台存储节点同时写入数据,存储节...
相关文章
文章评论
共有0条评论来说两句吧...