【Apollo】(2)--- Apollo架构设计
Apollo架构设计
上一篇博客有讲到:【Apollo】(1)--- Apollo入门介绍篇
这篇来写Apollo的核心架构设计
一、整体架构
Apollo整体架构图,已由作者宋顺已经给出:
这幅图所描述的已经很清楚了。下面来具体解释下上面这张图。
1、四个主要模块和核心功能
ConfigService
提供配置的读取、推送等功能,服务对象是Apollo客户端(client)(最终目的就是把配置数据给到我们自己的微服务对象)
Admin Service
提供配置的修改、发布等功能,服务对象是Apollo Portal(管理界面)(简单理解成就是就是用来在配置中心管理界面来添加或者修改配置)
Client( 客户端)
Apollo提供的客户端程序,为应用提供配置获取、实时更新等功能。
域名访问 Meta Server 获取 Config Service 服务列表(IP+Port),而后直接通过IP+Port访问服务,同时在Client侧会做负载均衡、错误重试
Portal
提供Web界面供用户管理配置。
Portal通过域名访问 Meta Server 获取 Admin Service 服务列表(IP+Port),而后直接通过IP+Port访问服务,同时在Portal侧会做 负载均衡、错误重试
个人理解这四个模块
ConfigService 和 Client 的配合
从这里面可以看出我们自己的微服务不是直接和ConfigService打交道的,而是跟Client打交道,Client才是真正和ConfigService打交道来获取最新配置信息。
Admin Service 和 Portal
这里分类两个模块就很好理解了,因为管理界面的实现有自己的一套代码,而且管理界面操作的一些权限等信息,只会跟它自己有关系,对于微服务来讲,我只关心有没有配置
这条配置数据,而不会去关心在管理界面上什么用户能够添加配置信息。所以就有Portal对于了两个数据库,一个可以理解是它自己的,存放一些权限等信息,另一部分是和
配置有关的,所以通过 Admin Service 存放在 configDB 中。
2、三个辅助服务发现模块
为了保证上面四个模块的高可用,所以这里需要三个辅助模块配合。
Eureka
用于服务发现和注册Config/AdminService注册实例并定期报心跳。
为了简化部署,我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中
官方也有解释为什么我们采用Eureka作为服务注册中心,而不是使用传统的zk、etcd呢?我大致总结了一下,有以下几方面的原因:
1)它提供了完整的Service Registry和Service Discovery实现
首先是提供了完整的实现,并且也经受住了Netflix自己的生产环境考验,相对使用起来会比较省心。
2)和Spring Cloud无缝集成
我们的项目本身就使用了Spring Cloud和Spring Boot,同时Spring Cloud还有一套非常完善的开源代码来整合Eureka,所以使用起来非常方便。另外,Eureka还支持在
我们应用自身的容器中启动,也就是说我们的应用启动完之后,既充当了Eureka的角色,同时也是服务的提供者。这样就极大的提高了服务的可用性。这一点是我们选择
Eureka而不是zk、etcd等的主要原因,为了提高配置中心的可用性和降低部署复杂度,我们需要尽可能地减少外部依赖。
3)Open Source
最后一点是开源,由于代码是开源的,所以非常便于我们了解它的实现原理和排查问题。
MetaServer
Portal通过域名 访问 MetaServer 获取 AdminService 的地址列表。
Client通过域名访问MetaServer获取ConfigService的地址列表。
相当于一个Eureka Proxy 逻辑角色,和ConfigService住在一起部署。
NginxLB
和域名系统配合,协助Portal访问MetaServer获取AdminService地址列表。
和域名系统配合,协助Client访问MetaServer获取ConfigService地址列表。
和域名系统配合,协助用户访问Portal进行配置管理。
二、架构剖析
1、Apollo架构V1
如果不考虑分布式微服务架构中的服务发现问题,Apollo的最简架构如下图(来源 杨波)所示:
要点
1、ConfigService是一个独立的微服务,服务于Client进行配置获取。
2、Client和ConfigService保持 长连接,通过一种拖拉结合(push & pull)的模式,实现配置实时更新的同时,保证配置更新不丢失。
3、AdminService是一个独立的微服务,服务于Portal进行配置管理。Portal通过调用AdminService进行配置管理和发布。
4、ConfigService和AdminService共享ConfigDB,ConfigDB中存放项目在某个环境的配置信息。ConfigService/AdminService/ConfigDB三者在每个环境
(DEV/FAT/UAT/PRO)中都要部署一份。
5、Protal有一个独立的 PortalDB,存放用户权限、项目和配置的元数据信息。Protal只需部署一份
,它可以管理多套环境。
2、Apollo架构V2
为了保证高可用,ConfigService和AdminService都是无状态以集群方式部署的,这个时候就存在一个服务发现问题:Client怎么找到ConfigService?Portal
怎么找到AdminService?为了解决这个问题,Apollo在其架构中引入了Eureka服务注册中心组件,实现微服务间的服务注册和发现,更新后的架构如下图所示:
要点
-
Config/AdminService启动后都会注册到Eureka服务注册中心,并定期发送保活心跳。
-
Eureka采用集群方式部署,使用分布式一致性协议保证每个实例的状态最终一致。
3、Apollo架构V3
我们知道Eureka是自带服务发现的Java客户端的,如果Apollo只支持Java客户端接入,不支持其它语言客户端接入的话,那么Client和Portal只需要引入Eureka的Java
客户端,就可以实现服务发现功能。发现目标服务后,通过客户端软负载(SLB,例如Ribbon)就可以路由到目标服务实例。这是一个经典的微服务架构,基于Eureka实现
服务注册发现+客户端Ribbon配合实现软路由,如下图所示:
4、Apollo架构V4
在携程,应用场景不仅有Java,还有很多遗留的.Net应用。Apollo的作者也考虑到开源到社区以后,很多客户应用是非Java的。但是Eureka(包括Ribbon软负载)原生仅支持
Java客户端,如果要为多语言开发Eureka/Ribbon客户端,这个工作量很大也不可控。为此,Apollo的作者引入了MetaServer这个角色,它其实是一个Eureka的Proxy,将
Eureka的服务发现接口以更简单明确的HTTP接口的形式暴露出来,方便Client/Protal通过简单的HTTPClient就可以查询到Config/AdminService的地址列表。获取到服务
实例地址列表之后,再以简单的客户端软负载(Client SLB)策略路由定位到目标实例,并发起调用。
现在还有一个问题,MetaServer本身也是无状态以集群方式部署的,那么Client/Protal该如何发现MetaServer呢?一种传统的做法是借助硬件或者软件负载均衡器,例如在
携程采用的是扩展后的NginxLB(也称Software Load Balancer),由运维为MetaServer集群配置一个域名,指向NginxLB集群,NginxLB再对MetaServer进行负载均衡和
流量转发。Client/Portal通过域名+NginxLB间接访问MetaServer集群。
引入MetaServer和NginxLB之后的架构如下图所示:
5、Apollo架构V5
V4版本已经是比较完成的Apollo架构全貌,现在还剩下最后一个环节:Portal也是无状态以集群方式部署的,用户如何发现和访问Portal?答案也是简单的传统做法,
用户通过域名+NginxLB间接访问MetaServer集群。
所以V5版本是包括用户端的最终的Apollo架构全貌,如下图所示:
6、结论
- 经过我在第三部分的剖析之后,相信大家对Apollo的微服务架构会有更清晰的认识,作为一个思考题,大家再回头看一下第二部分宋顺给出的架构图,现在是否能够理解?
它和我的架构是如何对应的?提示一下,宋顺的视角是一个从上往下的俯视视角,而我的是一个侧面视角。
- ConfgService/AdminService/Client/Portal是Apollo的四个核心微服务模块,相互协作完成配置中心业务功能,Eureka/MetaServer/NginxLB是辅助微服务之间进行服务
发现的模块。
- Apollo采用微服务架构设计,架构和部署都有一些复杂,但是每个服务职责单一,易于扩展。另外,Apollo只需要一套Portal就可以集中管理多套环境(DEV/FAT/UAT/PRO)
中的配置,这个是它的架构的一大亮点。。
- 服务发现是微服务架构的基础,在Apollo的微服务架构中,既采用Eureka注册中心式的服务发现,也采用NginxLB集中Proxy式的服务发现。
三、可用性考虑
上面设计这么复杂就是为了满足高可用,如果不考虑可用性,那么那么的v1图片就可以满足。我们来下最终的架构图为什么能满足高可用。
很明显这些模块任何一个挂掉,都能满足服务的可以用性。
参考
别人骂我胖,我会生气,因为我心里承认了我胖。别人说我矮,我就会觉得好笑,因为我心里知道我不可能矮。这就是我们为什么会对别人的攻击生气。
攻我盾者,乃我内心之矛(27)