2.2 通过 SDK 方式进行服务治理
独立SDK模式
阿里巴巴通过五彩石项目开始了微服务化的改造,逐步诞生了服务框架,消息队列,数据库分库分表三大中间件。这些中间件都是通过SDK的方式被业务项目直接依赖。
在这个阶段,由于基础设施团队对部署、开发模式比较熟悉,业务接入的模式也比较单一。业务方单独对接每个SDK是比较合适的。
我们以Java应用为例,理论上的依赖应该是这样的:
在这个阶段的服务治理,主要依赖于各个SDK提供的能力。比如HSF/Dubbo提供了同可用区优先、标签路由能力;消息队列提供了高可用能力;数据库分库分表提供了读写分离、动态分库能力。
Fat-SDK模式
通过单一SDK提供服务治理能力后,各个SDK的提供方需要对提供出去的SDK进行支持,需要及时替换、升级旧版本的SDK,并及时督促SDK使用方进行升级。
在这个过程中,总是发现SDK之间会有依赖冲突,常常遇到sdk冲突导致应用无法启动、sdk被第三方包降级导致功能丢失;督促使用者升级也越来越耗费了大量的时间和精力。
业务研发同学作为SDK的使用方,需要关注各个SDK提供的新功能、旧版本是否已经不再支持等。业务研发同学的时间和精力越来越多的被中间件组件消耗了。
为了解决这个痛点,2013年诞生了代号 “Pandora” 的项目。Pandora借助类加载器隔离能力,让各个中间件组件能够有自己独立依赖且互不冲突;Pandora也作为一个应用容器,给业务开发同学提供了一整套中间件解决方案。
业务同学只需要使用指定版本的Pandora,后续的维护、升级只需要跟着Pandora版本走就可以。
中间件维护同学,也只需要提供SDK与Pandora集成,并通过统一的发版周期交付给业务同学,极大地减轻了支持维护成本。