Apache ServiceComb ServiceCenter 1.3.0版本已于2019年11月07日发布,在这次版本中带来了异构、多服务中心同步工具 Syncer,在这里将从我们的已有的实践经验出发,带来对Syncer的介绍。
项目地址:https://github.com/apache/servicecomb-service-center/tree/master/syncer
1.3.0版本下载:http://servicecomb.apache.org/release/service-center-downloads/
为什么使用服务中心同步工具
从传统架构到微服务,为了解决微服务之间动态变更带来的问题,各微服务框架百花齐放,从而衍生出Service-center、eureka、consul等一系列服务中心;在云环境大行其道的今天,公/私有云并存、混合云部署在企业实践中似乎已成为趋势。在这过程中不得不面临一些问题:
- 异构服务中心间的实例如何发现?
- 跨区域间的实例信息怎么同步?
- 统一企业内部微服务架构过程中,如何平滑迁移?
中心化解决方案带来的思考
在最初的项目中,我们应用了ServiceCenter的中心化解决方案 ServiceCenter Aggregate,详细介绍请参考:https://github.com/apache/servicecomb-service-center/blob/master/docs/multidcs.md
在使用这样的中心化解决方案后,异构服务中心的实例被同步到 Aggregate 中,服务只需指定服务发现地址到 Aggregate,即可实现对异构、跨区域实例的发现,同时也支持了微服务架构之间的平滑迁移。
经过一段时间的使用,集中式、中心化方案的不足逐渐显现,于是便有了如下的思考:
- 对业务服务不透明,需要修改服务发现地址
- 设计理念倾向于对自身服务中心的迁入,对异构服务中心并存支持不够友好
- 中心化的架构,单点故障会造成同步的暂停,影响依赖服务的正常运行
- 同步、数据结构转换的工作集中在单个服务中,容易造成性能瓶颈
- 增加新的服务中心支持时,需要重新编译、启动同步服务
- 维护成本增加,运维人员配置规则时需要理解所有服务中心的信息
Apache ServiceComb Syncer
针对以上的问题与思考,我们带来了无中心化的解决方案 Apche ServiceComb Syncer。Syncer是一个多服务中心的同步工具,专为大型微服务架构设计,用于在网络互通的情况下,不同技术栈服务中心、跨区域的实例同步,未来将对跨网络、跨云等场景提供支持。
Syncer的架构设计
Syncer以服务中心的伴生系统的形式而存在,主要负责从当前服务中心发现实例,并向网络其他成员进行广播;接收其他成员的广播,并拉取实例信息向当前服务中心进行注册。Syncer 有如下特点:
- 业务架构零侵入,Syncer 以透明的形式为服务中心同步实例信息,不参与原业务流程,服务无需感知其存在。
- 不绑定服务中心,兼容生态,支持不同技术栈服务中心的接入。
- 基于Serf(gossip 协议的实现)构建无中心的对等网络,成员的自由加入与退出,对 Syncer 网络、服务中心均无影响。
- 以统一的数据结构在网络中进行传递,数据结构的转换被分散到各个 Syncer 中,其只需要处理当前服务中心数据结构与 SyncData 之间的转换,即可做到数据的最大兼容。
- 以 golang 插件的形式对服务中心提供支持,用户可自由的扩展需要接入的服务中心。新的服务中心加入,只需在其伴生的 Syncer 进行向 SyncerData 的转换,数据即可在 Syncer 网络中进行同步,无需其他成员配合。
- 服务的配置、部署、升级、维护等仍在单服务中心内完成,没有额外的业务维护成本增加。
下面我们通过具体的业务流程来进一步了解 Syncer。
组网流程
上图左侧绿色 SyncerN 是一个待加入网络的成员。
- SyncerN 在启动之后,通过向 JoinAddr 所指向的 SyncerB 发起 Join 请求
- 通过 serf 的自动发现与广播机制,一段时间后,SyncerN 的信息会传播到网络中所有成员处,组网成功
- 若 Syncer 是以 cluster 模式启动的,Syncer 通过标记的 cluster tag 将相同的 cluster 归为一组,从而实现内部的高可用集群
数据同步流程
Syncer的同步流程同步流程并不复杂,下图具体描述了两个Syncer将不同服务中心的实例进行同步的过程。
适用场景
- 网络互通的异构、多服务中心实例信息同步,支持异构服务中的并存、多服务中心实例共享