Apollo(阿波罗)架构深度剖析 | 您所在的位置:网站首页 › 公司框架什么意思 › Apollo(阿波罗)架构深度剖析 |
】、、通过学习 Apollo 的架构,带你深入理解微服务架构的基本原理 一、介绍Apollo(阿波罗)[参考附录] 是携程框架部研发并开源的一款生产级的配置中心产品,它能够集中管理应用在不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。 Apollo 目前在国内开发者社区比较热,在 Github 上有超过 5k 颗星,在国内众多互联网公司有落地案例,可以说 Apollo 是目前配置中心产品领域 Number1 的产品,其成熟度和企业级特性要远远强于 Spring Cloud 体系中的 Spring Cloud Config 产品。 Apollo 采用分布式微服务架构,它的架构有一点复杂,Apollo 的作者宋顺虽然给出了一个架构图,但是如果没有一定的分布式微服务架构基础的话,则普通的开发人员甚至是架构师也很难一下子理解。为了让大家更好的理解 Apollo 的架构设计,我花了一点时间把 Apollo 的架构按我的方式重新剖析一把。只有完全理解了 Apollo 的架构,大家才能在生产实践中更好的部署和使用 Apollo。另外,通过学习 Apollo 的架构,大家可以深入理解微服务架构的一些基本原理。 二、架构和模块下图是 Apollo 的作者宋顺给出的架构图:
下面是 Apollo 的七个模块,其中四个模块是和功能相关的核心模块,另外三个模块是辅助服务发现的模块: 四个核心模块及其主要功能 模块主要功能ConfigService提供配置获取接口提供配置推送接口服务于Apollo客户端AdminService提供配置管理接口提供配置修改发布接口服务于管理界面PortalClient为应用获取配置,支持实时更新通过MetaServer获取ConfigService的服务列表使用客户端软负载SLB方式调用ConfigServicePortal配置管理界面通过MetaServer获取AdminService的服务列表使用客户端软负载SLB方式调用AdminService三个辅助服务发现模块 模块主要功能Eureka用于服务发现和注册Config/AdminService注册实例并定期报心跳和ConfigService住在一起部署MetaServerPortal通过域名访问MetaServer获取AdminService的地址列表Client通过域名访问MetaServer获取ConfigService的地址列表相当于一个Eureka Proxy 逻辑角色,和ConfigService住在一起部署NginxLB和域名系统配合,协助Portal访问MetaServer获取AdminService地址列表和域名系统配合,协助Client访问MetaServer获取ConfigService地址列表和域名系统配合,协助用户访问Portal进行配置管理 三、架构剖析 Apollo 架构 V1如果不考虑分布式微服务架构中的服务发现问题,Apollo 的最简架构如下图所示: 为了保证高可用,ConfigService 和 AdminService 都是无状态以集群方式部署的,这个时候就存在一个服务发现问题:Client 怎么找到 ConfigService?Portal 怎么找到 AdminService?为了解决这个问题,Apollo 在其架构中引入了 Eureka 服务注册中心组件,实现微服务间的服务注册和发现,更新后的架构如下图所示: 我们知道 Eureka 是自带服务发现的 Java 客户端的,如果 Apollo 只支持 Java 客户端接入,不支持其它语言客户端接入的话,那么 Client 和 Portal 只需要引入 Eureka 的 Java 客户端,就可以实现服务发现功能。发现目标服务后,通过客户端软负载 (SLB,例如 Ribbon) 就可以路由到目标服务实例。这是一个经典的微服务架构,基于 Eureka 实现服务注册发现 + 客户端 Ribbon 配合实现软路由,如下图所示: 在携程,应用场景不仅有 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 之后的架构如下图所示: V4 版本已经是比较完成的 Apollo 架构全貌,现在还剩下最后一个环节:Portal 也是无状态以集群方式部署的,用户如何发现和访问 Portal?答案也是简单的传统做法,用户通过域名 +NginxLB 间接访问 Portal 集群。 所以 V5 版本是包括用户端的最终的 Apollo 架构全貌,如下图所示: 附录: https://github.com/ctripcorp/apollo |
CopyRight 2018-2019 实验室设备网 版权所有 |