Apollo 部署架构全解析从单机 All in One 到多机房高可用【免费下载链接】apolloApollo is a reliable configuration management system suitable for microservice configuration management scenarios.项目地址: https://gitcode.com/gh_mirrors/apoll/apollo本文以 Apollo 配置中心的宏观部署架构为主线系统讲解 Portal、Config Service、Admin Service、Meta ServerEureka与 ConfigDB/PortalDB 之间的依赖关系与包含关系并逐一给出单机 All in One、单机分离部署、单机多环境、高可用多实例、同城双机房等从简到繁的部署方案与资源清单。读完本文你将能够根据团队规模、环境数量与可用性要求为 Apollo 选型出合适的部署形态并理解各 JVM 进程、数据库与端口8080/8090/8070背后的设计逻辑。一、部署架构的读图基础依赖关系与包含关系Apollo 的部署形态会随场景不同而变化本文不讨论每个场景的细节而是从宏观视角介绍各类部署选项。为了统一表达原文档用两种 mermaid 图形语言来描述部署架构理解它们是看懂后续所有方案的前提。1.1 依赖关系Dependencies依赖关系用箭头--表达语义是前者依赖后者即后者必须存在前者才能正常工作。例如表示该应用必须使用 MySQL 才能正常运行。依赖可以是多层、多重的例如Service A 需要注册中心、Service B 和 Redis而 Service B 又需要 MySQL。1.2 包含关系Inclusion Relationships包含关系用subgraph表达语义是外层包含内层即内层是外层的一部分且可以嵌套。例如表示在一台 Linux 服务器上运行着 MySQL、Redis 以及 2 个 JVM每个 JVM 内部又有若干线程。1.3 从源码看模块与默认端口结合本仓库源码可以确认上述概念对应的真实组件与默认端口模块默认端口关键配置/源码位置Meta ServerEureka8080与 Config Service 同 JVMconfigservice.properties 中server.port 8080Config Service8080同上Admin Service8090adminservice.properties 中server.port 8090Portal8070portal.properties 中server.port 8070ConfigDB独立数据库由 Config Service 与 Admin Service 共用PortalDB独立数据库由 Portal 使用值得注意的是Config Service 进程内嵌了 Eureka Server在 ConfigServerEurekaServerConfigure.java 中通过EnableEurekaServer开启并由apollo.eureka.server.enabled控制默认true因此Meta Server、Eureka、Config Service 在同一 JVM 内在源码层面是成立的。而 Config Service 与 Admin Service 启动后都会把自己注册到 Eureka注册中心地址来自 ConfigDB 的eureka.service.url见 configdb.init.h2.sql 中的默认值http://localhost:8080/eureka/。二、单机部署方案Standalone单机部署通常用于新手学习场景或公司内部对性能要求不高的测试环境不适用于生产环境。以下按环境数量与进程分布逐步展开。2.1 单机单环境 All in One这是最简单、最方便的部署方式。所需资源1 台 Linux 服务器带 JRE2 个数据库1 个PortalDB 1 个ConfigDB所有模块部署在同一台 Linux 机器上共 3 个 JVM 进程JVM8080对外暴露 8080 端口内部包含 Meta Server、Eureka、Config ServiceConfig Service 使用 ConfigDB。JVM8090对外暴露 8090 端口内部为 Admin ServiceAdmin Service 使用 ConfigDB。JVM8070对外暴露 8070 端口内部为 PortalPortal 使用 PortalDB。若把模块间的依赖关系补全架构图变为即Config Service 和 Admin Service 会将自己注册到 EurekaPortal 通过 Meta Server 发现 Admin Service进而完成配置的发布、回滚等管理操作。为了让图更简洁可以只画进程之间的依赖进程 JVM8070 依赖进程 JVM8090 与 PortalDB进程 JVM8090 依赖进程 JVM8080 与 ConfigDB进程 JVM8080 依赖自身与 ConfigDB。源码印证仓库提供了 apollo-assembly 模块ApolloApplication.java 会在同一个 JVM 进程中依次启动 common、ConfigService、AdminService、Portal 四个 Spring 上下文。这意味着All in One 单进程其实有两种形态三个独立 JVM 进程或由 assembly 打包在一个 JVM 中全部承载。官方快速开始脚本即采用该方式详见 quick-start.md。2.2 单机单环境分离部署3 个 JVM 进程也可以拆分到不同的 Linux 机器上。2.2.1 分离部署3 台 Linux 服务器所需资源3 台 Linux 服务器3 个进程分别部署2 个数据库2.2.2 分离部署2 台 Linux 服务器推荐实践中通常把 Config Service 与 Admin Service 放在同一台 Linux 服务器上所需资源2 台 Linux 服务器1 台部署 Portal另 1 台部署 Config Service 与 Admin Service2 个数据库为让后续流程图更简洁约定JVM8080 内的 Meta Server 与 Eureka 不再单独画出只显示 Config Service。这一简化规则可以形式化表示为因此单机单环境分离部署可简化表示为2.3 单机双环境SIT UAT单一环境基本无法满足实际应用场景。例如公司有 SIT 测试环境与 UAT 测试环境就需要部署两套配置服务。最直观的想法是把单机单环境的部署架构重复 2 次所需资源2 台 Linux 服务器4 个数据库但该方案会有2 个 Portal 界面无法用一个界面统一管理 2 个环境使用体验不佳。Portal 其实只需要部署 1 套推荐的部署架构如下所需资源3 台 Linux 服务器Portal Linux Server单独部署 PortalSIT Linux Server部署 SIT 的 Config Service 与 Admin ServiceUAT Linux Server部署 UAT 的 Config Service 与 Admin Service3 个数据库1 个 PortalDB 1 个 SIT ConfigDB 1 个 UAT ConfigDB即Portal 通过各环境各自的 Admin Service8090来完成跨环境的管理而各环境内部的 Config Service / Admin Service 通过各自的 ConfigDB 独立工作。源码印证Portal 如何知道每个环境指向哪里答案在 apollo-env.properties 中它通过占位符dev.meta${dev_meta}、fat.meta${fat_meta}、uat.meta${uat_meta}、lpt.meta${lpt_meta}、pro.meta${pro_meta}配置各环境的 Meta Server 地址local.meta固定为http://localhost:8080。部署时只需为每个环境注入对应的xx_meta环境变量Portal 即可通过该地址发现对应环境的 Admin Service。2.4 单机三环境SIT UAT PP假设需要满足 SIT、UAT、PP 三个环境的使用场景在上文双环境的基础上新增 1 个 PP 环境的 Linux 服务器和 1 个 ConfigDB并通过修改 Portal 配置将该环境纳入管理即可2.5 单机多环境原理同上每增加 1 个环境就增加 1 台 Linux 服务器部署该环境的 Config Service 与 Admin Service与 1 个 ConfigDB然后在 Portal 中补充新环境的信息即配置新环境的apollo.meta即可。环境数量理论上可按需线性扩展。三、高可用部署方案High Availability一个环境只有 1 个 Config Service 进程无法满足高可用要求。为避免单点故障影响系统可用性需要多实例部署即在不同的 Linux 服务器上部署多个 Java 进程。3.1 最小高可用单环境回顾常见的非高可用部署方式当 Linux Server 1 宕机时客户端只能读取本地磁盘上的 config-cache配置缓存。要防止单台 Linux 宕机导致 Config Service 不可用可以再增加一台 Linux 机器所需资源3 台 Linux 服务器1 台部署 Portal2 台分别部署 Config Service 与 Admin Service2 个数据库在这种部署下只要 Linux Server 1.1 或 Linux Server 1.2 中有一台存活系统仍然可用。注意两套实例共享同一个 ConfigDB这与单机多环境每环境独立 ConfigDB有本质区别。3.2 高可用单环境横向扩容 Config Service在上述基础上如果客户端数量很大例如数万个 Java 进程可以通过引入 Linux Server 1.3、Linux Server 1.4……横向扩展 Config Service。由于 Admin Service 只被 Portal 访问其数量需求远小于 Config Service。关于如何评估 Config Service 的数量可参考 Apollo 性能测试报告。原理补充多个 Config Service 实例会同时注册到共享的 Eureka 注册中心客户端通过 Meta Server 获取到的是一组 Config Service 地址从而天然实现负载均衡与故障转移。3.3 高可用双环境与 2.3 节单机双环境同理若想让 SIT 和 UAT 都高可用只需给每个环境增加机器。下图每个环境各 2 台 Linux 服务器若有性能需求每个环境可以部署更多 Config Service3.4 高可用多环境在上述基础上新增环境例如 BETA 环境只需新增 2 台及以上 Linux 服务器 1 个 ConfigDB然后在 Portal 中添加新环境的信息将其apollo.meta指向 BETA 环境的 Meta Server 即可。3.5 高可用单环境、单机房实际生产环境中很多公司会隔离测试环境生产环境只有 1 个 PRO 环境。当只有 1 个机房时直接参考 3.2 高可用单环境 的部署方式即可。3.6 高可用单环境、双机房同城双活如果有 2 个机房通常机房之间会有网络隔离。若是同城共址的两个机房 idc1 与 idc2可采用如下部署方式要点如下每个机房各有一套 Portal、Config Service、Admin Service对于 ConfigDB同城双机房场景下两个机房连接的是同一个 ConfigDB而不是 2 个不同的 ConfigDBPortalDB 同理也需要连接同一个图中没有把 ConfigDB 和 PortalDB 画进 idc1 或 idc2因为需要你根据实际情况自行选择适合的 MySQL 架构与部署方式如同城主备、跨机房复制等。四、参考部署图4.1 携程内部的部署策略在携程Ctrip内部Apollo 的部署策略如下Portal 部署在生产环境的机房中通过它直接管理 FAT、UAT、PRO 等各环境的配置Meta Server、Config Service、Admin Service 分别部署在各环境内各环境使用独立的数据库生产环境中Meta Server、Config Service、Admin Service 部署在两个机房实现双机房互备双活Meta Server 与 Config Service 部署在同一个 JVM 进程中Admin Service 部署在同一台服务器的另一个 JVM 进程中。4.2 社区示例部署图以下示例部署图由社区用户 lyliyongblue 贡献可作为中小规模集群落地的直观参考五、部署形态选型小结部署形态所需服务器所需数据库适用场景单机单环境 All in One1 台2PortalDB ConfigDB新手学习、本地开发单机单环境分离2 台2 台2低性能要求的测试环境单机双环境单 Portal3 台31 PortalDB 2 ConfigDBSIT UAT 测试环境单机多环境每环境 1 台 1 台 Portal每环境 1 ConfigDB 1 PortalDB多测试环境最小高可用单环境3 台2共享生产环境入门高可用单环境3 台起步可横向扩容2共享生产环境、大规模客户端高可用双环境/多环境每环境 ≥2 台 1 台 Portal每环境 1 ConfigDB 1 PortalDB多环境生产/预发同城双机房每机房独立整套共享同一套数据库生产环境高可用容灾部署时需把握三条主线Portal 是管理面只连 PortalDB通过各环境的apollo.meta发现并访问其 Admin ServiceConfig Service 是数据面对内嵌 Eureka向客户端提供配置读取与实时推送可横向扩容Admin Service 是管理数据入口只被 Portal 调用与 Config Service 共享 ConfigDB。理解了这条链路无论环境数量与机房拓扑如何变化都能快速设计出符合自身可用性要求的 Apollo 部署架构。进一步阅读各环境地址配置见 apollo-env.properties数据库初始化脚本见 scripts/sql完整快速部署步骤见 quick-start.md。【免费下载链接】apolloApollo is a reliable configuration management system suitable for microservice configuration management scenarios.项目地址: https://gitcode.com/gh_mirrors/apoll/apollo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Apollo 部署架构全解析：从单机 All in One 到多机房高可用
Apollo 部署架构全解析从单机 All in One 到多机房高可用【免费下载链接】apolloApollo is a reliable configuration management system suitable for microservice configuration management scenarios.项目地址: https://gitcode.com/gh_mirrors/apoll/apollo本文以 Apollo 配置中心的宏观部署架构为主线系统讲解 Portal、Config Service、Admin Service、Meta ServerEureka与 ConfigDB/PortalDB 之间的依赖关系与包含关系并逐一给出单机 All in One、单机分离部署、单机多环境、高可用多实例、同城双机房等从简到繁的部署方案与资源清单。读完本文你将能够根据团队规模、环境数量与可用性要求为 Apollo 选型出合适的部署形态并理解各 JVM 进程、数据库与端口8080/8090/8070背后的设计逻辑。一、部署架构的读图基础依赖关系与包含关系Apollo 的部署形态会随场景不同而变化本文不讨论每个场景的细节而是从宏观视角介绍各类部署选项。为了统一表达原文档用两种 mermaid 图形语言来描述部署架构理解它们是看懂后续所有方案的前提。1.1 依赖关系Dependencies依赖关系用箭头--表达语义是前者依赖后者即后者必须存在前者才能正常工作。例如表示该应用必须使用 MySQL 才能正常运行。依赖可以是多层、多重的例如Service A 需要注册中心、Service B 和 Redis而 Service B 又需要 MySQL。1.2 包含关系Inclusion Relationships包含关系用subgraph表达语义是外层包含内层即内层是外层的一部分且可以嵌套。例如表示在一台 Linux 服务器上运行着 MySQL、Redis 以及 2 个 JVM每个 JVM 内部又有若干线程。1.3 从源码看模块与默认端口结合本仓库源码可以确认上述概念对应的真实组件与默认端口模块默认端口关键配置/源码位置Meta ServerEureka8080与 Config Service 同 JVMconfigservice.properties 中server.port 8080Config Service8080同上Admin Service8090adminservice.properties 中server.port 8090Portal8070portal.properties 中server.port 8070ConfigDB独立数据库由 Config Service 与 Admin Service 共用PortalDB独立数据库由 Portal 使用值得注意的是Config Service 进程内嵌了 Eureka Server在 ConfigServerEurekaServerConfigure.java 中通过EnableEurekaServer开启并由apollo.eureka.server.enabled控制默认true因此Meta Server、Eureka、Config Service 在同一 JVM 内在源码层面是成立的。而 Config Service 与 Admin Service 启动后都会把自己注册到 Eureka注册中心地址来自 ConfigDB 的eureka.service.url见 configdb.init.h2.sql 中的默认值http://localhost:8080/eureka/。二、单机部署方案Standalone单机部署通常用于新手学习场景或公司内部对性能要求不高的测试环境不适用于生产环境。以下按环境数量与进程分布逐步展开。2.1 单机单环境 All in One这是最简单、最方便的部署方式。所需资源1 台 Linux 服务器带 JRE2 个数据库1 个PortalDB 1 个ConfigDB所有模块部署在同一台 Linux 机器上共 3 个 JVM 进程JVM8080对外暴露 8080 端口内部包含 Meta Server、Eureka、Config ServiceConfig Service 使用 ConfigDB。JVM8090对外暴露 8090 端口内部为 Admin ServiceAdmin Service 使用 ConfigDB。JVM8070对外暴露 8070 端口内部为 PortalPortal 使用 PortalDB。若把模块间的依赖关系补全架构图变为即Config Service 和 Admin Service 会将自己注册到 EurekaPortal 通过 Meta Server 发现 Admin Service进而完成配置的发布、回滚等管理操作。为了让图更简洁可以只画进程之间的依赖进程 JVM8070 依赖进程 JVM8090 与 PortalDB进程 JVM8090 依赖进程 JVM8080 与 ConfigDB进程 JVM8080 依赖自身与 ConfigDB。源码印证仓库提供了 apollo-assembly 模块ApolloApplication.java 会在同一个 JVM 进程中依次启动 common、ConfigService、AdminService、Portal 四个 Spring 上下文。这意味着All in One 单进程其实有两种形态三个独立 JVM 进程或由 assembly 打包在一个 JVM 中全部承载。官方快速开始脚本即采用该方式详见 quick-start.md。2.2 单机单环境分离部署3 个 JVM 进程也可以拆分到不同的 Linux 机器上。2.2.1 分离部署3 台 Linux 服务器所需资源3 台 Linux 服务器3 个进程分别部署2 个数据库2.2.2 分离部署2 台 Linux 服务器推荐实践中通常把 Config Service 与 Admin Service 放在同一台 Linux 服务器上所需资源2 台 Linux 服务器1 台部署 Portal另 1 台部署 Config Service 与 Admin Service2 个数据库为让后续流程图更简洁约定JVM8080 内的 Meta Server 与 Eureka 不再单独画出只显示 Config Service。这一简化规则可以形式化表示为因此单机单环境分离部署可简化表示为2.3 单机双环境SIT UAT单一环境基本无法满足实际应用场景。例如公司有 SIT 测试环境与 UAT 测试环境就需要部署两套配置服务。最直观的想法是把单机单环境的部署架构重复 2 次所需资源2 台 Linux 服务器4 个数据库但该方案会有2 个 Portal 界面无法用一个界面统一管理 2 个环境使用体验不佳。Portal 其实只需要部署 1 套推荐的部署架构如下所需资源3 台 Linux 服务器Portal Linux Server单独部署 PortalSIT Linux Server部署 SIT 的 Config Service 与 Admin ServiceUAT Linux Server部署 UAT 的 Config Service 与 Admin Service3 个数据库1 个 PortalDB 1 个 SIT ConfigDB 1 个 UAT ConfigDB即Portal 通过各环境各自的 Admin Service8090来完成跨环境的管理而各环境内部的 Config Service / Admin Service 通过各自的 ConfigDB 独立工作。源码印证Portal 如何知道每个环境指向哪里答案在 apollo-env.properties 中它通过占位符dev.meta${dev_meta}、fat.meta${fat_meta}、uat.meta${uat_meta}、lpt.meta${lpt_meta}、pro.meta${pro_meta}配置各环境的 Meta Server 地址local.meta固定为http://localhost:8080。部署时只需为每个环境注入对应的xx_meta环境变量Portal 即可通过该地址发现对应环境的 Admin Service。2.4 单机三环境SIT UAT PP假设需要满足 SIT、UAT、PP 三个环境的使用场景在上文双环境的基础上新增 1 个 PP 环境的 Linux 服务器和 1 个 ConfigDB并通过修改 Portal 配置将该环境纳入管理即可2.5 单机多环境原理同上每增加 1 个环境就增加 1 台 Linux 服务器部署该环境的 Config Service 与 Admin Service与 1 个 ConfigDB然后在 Portal 中补充新环境的信息即配置新环境的apollo.meta即可。环境数量理论上可按需线性扩展。三、高可用部署方案High Availability一个环境只有 1 个 Config Service 进程无法满足高可用要求。为避免单点故障影响系统可用性需要多实例部署即在不同的 Linux 服务器上部署多个 Java 进程。3.1 最小高可用单环境回顾常见的非高可用部署方式当 Linux Server 1 宕机时客户端只能读取本地磁盘上的 config-cache配置缓存。要防止单台 Linux 宕机导致 Config Service 不可用可以再增加一台 Linux 机器所需资源3 台 Linux 服务器1 台部署 Portal2 台分别部署 Config Service 与 Admin Service2 个数据库在这种部署下只要 Linux Server 1.1 或 Linux Server 1.2 中有一台存活系统仍然可用。注意两套实例共享同一个 ConfigDB这与单机多环境每环境独立 ConfigDB有本质区别。3.2 高可用单环境横向扩容 Config Service在上述基础上如果客户端数量很大例如数万个 Java 进程可以通过引入 Linux Server 1.3、Linux Server 1.4……横向扩展 Config Service。由于 Admin Service 只被 Portal 访问其数量需求远小于 Config Service。关于如何评估 Config Service 的数量可参考 Apollo 性能测试报告。原理补充多个 Config Service 实例会同时注册到共享的 Eureka 注册中心客户端通过 Meta Server 获取到的是一组 Config Service 地址从而天然实现负载均衡与故障转移。3.3 高可用双环境与 2.3 节单机双环境同理若想让 SIT 和 UAT 都高可用只需给每个环境增加机器。下图每个环境各 2 台 Linux 服务器若有性能需求每个环境可以部署更多 Config Service3.4 高可用多环境在上述基础上新增环境例如 BETA 环境只需新增 2 台及以上 Linux 服务器 1 个 ConfigDB然后在 Portal 中添加新环境的信息将其apollo.meta指向 BETA 环境的 Meta Server 即可。3.5 高可用单环境、单机房实际生产环境中很多公司会隔离测试环境生产环境只有 1 个 PRO 环境。当只有 1 个机房时直接参考 3.2 高可用单环境 的部署方式即可。3.6 高可用单环境、双机房同城双活如果有 2 个机房通常机房之间会有网络隔离。若是同城共址的两个机房 idc1 与 idc2可采用如下部署方式要点如下每个机房各有一套 Portal、Config Service、Admin Service对于 ConfigDB同城双机房场景下两个机房连接的是同一个 ConfigDB而不是 2 个不同的 ConfigDBPortalDB 同理也需要连接同一个图中没有把 ConfigDB 和 PortalDB 画进 idc1 或 idc2因为需要你根据实际情况自行选择适合的 MySQL 架构与部署方式如同城主备、跨机房复制等。四、参考部署图4.1 携程内部的部署策略在携程Ctrip内部Apollo 的部署策略如下Portal 部署在生产环境的机房中通过它直接管理 FAT、UAT、PRO 等各环境的配置Meta Server、Config Service、Admin Service 分别部署在各环境内各环境使用独立的数据库生产环境中Meta Server、Config Service、Admin Service 部署在两个机房实现双机房互备双活Meta Server 与 Config Service 部署在同一个 JVM 进程中Admin Service 部署在同一台服务器的另一个 JVM 进程中。4.2 社区示例部署图以下示例部署图由社区用户 lyliyongblue 贡献可作为中小规模集群落地的直观参考五、部署形态选型小结部署形态所需服务器所需数据库适用场景单机单环境 All in One1 台2PortalDB ConfigDB新手学习、本地开发单机单环境分离2 台2 台2低性能要求的测试环境单机双环境单 Portal3 台31 PortalDB 2 ConfigDBSIT UAT 测试环境单机多环境每环境 1 台 1 台 Portal每环境 1 ConfigDB 1 PortalDB多测试环境最小高可用单环境3 台2共享生产环境入门高可用单环境3 台起步可横向扩容2共享生产环境、大规模客户端高可用双环境/多环境每环境 ≥2 台 1 台 Portal每环境 1 ConfigDB 1 PortalDB多环境生产/预发同城双机房每机房独立整套共享同一套数据库生产环境高可用容灾部署时需把握三条主线Portal 是管理面只连 PortalDB通过各环境的apollo.meta发现并访问其 Admin ServiceConfig Service 是数据面对内嵌 Eureka向客户端提供配置读取与实时推送可横向扩容Admin Service 是管理数据入口只被 Portal 调用与 Config Service 共享 ConfigDB。理解了这条链路无论环境数量与机房拓扑如何变化都能快速设计出符合自身可用性要求的 Apollo 部署架构。进一步阅读各环境地址配置见 apollo-env.properties数据库初始化脚本见 scripts/sql完整快速部署步骤见 quick-start.md。【免费下载链接】apolloApollo is a reliable configuration management system suitable for microservice configuration management scenarios.项目地址: https://gitcode.com/gh_mirrors/apoll/apollo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考