一、Apollo:从架构入手
参考文章:微服务架构~携程Apollo配置中心
分为七个模块,其中四个负责核心功能,剩余三个为辅助模块
1、四个核心模块:提供配置中心的主要功能
(1)ConfigService
- 提供配置获取接口
- 提供配置推送接口
- 服务于Client客户端
(2)AdminService
- 提供配置管理接口
- 提供配置修改发布接口
- 服务于Portal管理界面
(3)Client
- 为应用获取配置内容,实时更新到应用中
- 通过MetaServer获取ConfigService的服务列表
- 使用客户端软负载SLB方式调用ConfigService
(4)Portal
- 提供配置管理可视化页面
- 通过MetaServer获取AdminService的服务列表
- 使用客户端软负载SLB方式调用AdminService
2、三个辅助模块:辅助服务发现
(1)Eureka
- 用于服务注册与发现
- Config/Admin Service注册实例并定期心跳报告
- 和ConfigService绑定部署
(2)MetaServer
- Portal通过域名访问MetaServer获取AdminService的地址列表
- Client通过域名访问MetaServer获取ConfigService的地址列表
- 相当于一个Eureka Proxy,是逻辑角色,和ConfigService住在一起部署
(3)NginxLB
- 和域名系统配合,协助Portal访问MetaServer获取AdminService地址列表
- 和域名系统配合,协助Client访问MetaServer获取ConfigService地址列表
- 和域名系统配合,协助用户访问Portal进行配置管理
3、简化架构:核心功能
(1)ConfigService和AdminService都是独立的微服务;
- 前者服务于Client,进行配置的获取
- 后者服务于Portal,进行配置的管理和发布
(2)Client和ConfigService保持长链接,通过推拉结合的方式实现配置实时更新,同时保证配置不丢失(本地副本)。
(3)存在两个数据库Config DB和Portal DB
- Config DB:存放项目在某个环境中的配置信息。ConfigService/AdminService/ConfigDB三者在每个环境(DEV/FAT/UAT/PRO)中都要部署一份
- Portal DB:存放用户权限、项目和配置的元数据信息。Protal只需部署一份,它可以管理多套环境
4、架构升级V1:服务注册问题
为了保证服务高可用,Config Service和Admin Service都是通过集群的方式部署;
此时为了解决Client/Portal在集群模式下找到Config Service/Admin Service的问题,引入了Eureka服务注册中心组件,实现微服务的注册和发现!
(1)Config Service/Admin Service启动后会注册到Eureka服务中心,并且通过定期发送心跳包的方式证明存活。
(2)Eureka也采用集群方式部署,使用分布式一致性协议保证每个实例状态最终一致。
5、架构升级V2:服务发现问题
- 我们知道Eureka是自带服务发现的Java客户端的,如果Apollo只支持Java客户端接入,不支持其它语言客户端接入的话,那么Client和Portal只需要引入Eureka的Java客户端,就可以实现服务发现功能。
- 发现目标服务后,通过客户端软负载(SLB,例如Ribbon)就可以路由到目标服务实例。这是一个经典的微服务架构,基于Eureka实现服务注册发现+客户端Ribbon配合实现软路由,如下图所示:
6、架构升级V3:引入Meta Server兼容其他语言
- 为在兼容其他语言的同时减小开发成本(不需要开发Eureka/Ribbon客户端),引入中间处理角色Meta Server,可以理解成为Eureka的一个Proxy代理,将Eureka的服务发现接口通过HTTP接口的形式暴露出来。
- 方便Client/Protal通过简单的HTTPClient查询得到Config/Admin Service服务的地址列表,获取到服务地址后,再通过客户端软负载(Client SLB)策略路由定位到目标实例,发起调用。
- 现在还有一个问题,MetaServer本身也是无状态以集群方式部署的,那么Client/Protal该如何发现MetaServer呢?一种传统的做法是借助硬件或者软件负载均衡器,例如在携程采用的是扩展后的NginxLB(也称Software Load Balancer),由运维为MetaServer集群配置一个域名,指向NginxLB集群,NginxLB再对MetaServer进行负载均衡和流量转发。Client/Portal通过域名+NginxLB间接访问MetaServer集群。
7、架构升级V4:Portal访问
- Portal也是通过无状态集群方式部署,用户如何发现访问Portal?
- 通过域名 + NginxLB 间接访问Portal集群
二、实体关系图
E-R Diagram(Entity Relationship Diagram)
1、配置主体相关
配置主体主要是与App相关的Entity,对应不同应用的配置信息,我们可以在portal中操作到的有app/namespace/cluster等对象,但实际对象还包含版本更改内容(支持灰度/回滚等功能)。
- (1)App:App信息
- (2)AppNamespace:App下的Namespace元信息
- (3)Cluster:集群信息
- (4)Namespace:集群下的Namespace
- (5)Item:Namespace的配置,以k-v值存储
- (6)Commit:Namespace下的配置更改记录
- (7)Release:Namespace发布的配置,每个发布包含该发布时Namespace的所有配置
- (8)Audit:审计信息,记录用户在何种时候使用何种方式操作哪个实体
2、权限相关
通过用户角色赋予不同的权限。
权限相关的主体主要有User/Role/Consumer等,在Portal门户可以进行权限操作,对应权限分层功能(可以给不同的用户给予不同权限)
- (1)User:Apollo Portal用户
- (2)UserRole:用户和角色的关系
- (3)Role:角色
- (4)RolePermission:角色和权限的关系
- (5)Permission:权限,对应具体的实体资源和操作
- (6)Consumer:第三方应用
- (7)ConsumerToken:发给第三方的Token
- (8)ConsumerRole:第三方应用和权限的关系
- (9)ConsumerAudit:第三方应用访问审计