Apollo配置中心部署架构详解
前言
Apollo作为一款开源的分布式配置中心,其部署架构设计直接影响系统的可用性和扩展性。本文将深入剖析Apollo的各种部署方案,帮助开发者根据实际业务场景选择合适的部署方式。
基础概念
依赖关系
在部署架构中,我们使用流程图表示组件间的依赖关系:
graph LR
A --> B
表示A组件依赖B组件,即B必须正常运行A才能工作。例如:
flowchart LR
应用服务 --> MySQL数据库
包含关系
包含关系表示组件间的层级结构:
graph
subgraph 服务器A
进程B
end
表示服务器A包含进程B。这种关系可以多层嵌套。
单机部署方案
单机部署适合学习测试或对性能需求不高的内部环境,不推荐生产使用。
2.1 单机单环境全量部署
这是最简单的部署方式,需求:
- 1台Linux服务器(需安装JRE)
- 2个数据库(PortalDB和ConfigDB)
架构示意图:
flowchart LR
subgraph Linux服务器
subgraph JVM8080
Meta服务
Eureka注册中心
Config配置服务
end
subgraph JVM8090
Admin管理服务
end
subgraph JVM8070
Portal门户
end
end
JVM8080 --> ConfigDB
JVM8090 --> ConfigDB
JVM8070 --> PortalDB
各组件说明:
- JVM8080:包含核心服务组件,对外端口8080
- JVM8090:管理服务,端口8090
- JVM8070:管理门户,端口8070
2.2 单机单环境分离部署
方案一:三服务器部署
将三个JVM进程分别部署在三台服务器上,提高隔离性。
方案二:双服务器部署(推荐)
更实际的部署方式:
- 服务器1:Config Service + Admin Service
- 服务器2:Portal
2.3 单机多环境部署
实际业务通常需要多个环境(如SIT/UAT/PP等)。推荐架构:
- 共享Portal服务
- 每个环境独立部署Config和Admin服务
flowchart LR
Portal --> SIT_Admin
Portal --> UAT_Admin
Portal --> PP_Admin
优势:
- 统一管理界面
- 环境间完全隔离
- 灵活扩展新环境
高可用部署方案
生产环境必须考虑高可用,避免单点故障。
3.1 最小高可用架构(单环境)
基本要求:
- 3台服务器:
- 2台部署Config+Admin(互为备份)
- 1台部署Portal
flowchart LR
Config1 & Config2 --> ConfigDB
Admin1 & Admin2 --> ConfigDB
Portal --> Admin1
Portal --> Admin2
特点:
- 任意单台服务器宕机不影响服务
- 客户端自动故障转移
3.2 完整高可用架构
根据客户端规模水平扩展:
- Config Service可无限扩展
- Admin Service少量即可(仅Portal访问)
- 建议参考性能测试报告确定实例数量
3.3 多环境高可用
每个环境独立部署高可用集群:
flowchart LR
Portal --> SIT_Admin1
Portal --> SIT_Admin2
Portal --> UAT_Admin1
Portal --> UAT_Admin2
3.5 单机房生产部署
生产环境通常单独部署,架构同3.2,但需要注意:
- 数据库高可用
- 监控告警机制
- 灾备方案
3.6 双机房部署
跨机房部署建议:
- 每个机房完整部署
- 数据库主从同步
- 考虑网络延迟问题
部署建议
- 测试环境:单机多环境部署(2.3方案)
- 中小型生产:3.1最小高可用架构
- 大型生产:完整高可用+多机房
- 扩展性:Config Service无状态,可随时扩容
总结
Apollo提供灵活的部署方案,从单机测试到大规模生产集群都能满足。实际部署时应考虑:
- 环境隔离需求
- 可用性需求
- 性能压力
- 运维成本
通过合理的架构设计,可以构建稳定高效的配置中心服务。
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考