Apollo是携程框架部门研发并开源的分布式配置管理中心，它面向微服务架构下的配置乱象，提供了配置统一管理、动态推送、版本回溯和灰度发布等核心能力。在一个典型的互联网系统里，随着服务拆分变多，原本写在application.properties里的参数被散落在几十个仓库中，修改一次开关就要重新发版，风险与成本都很高。Apollo把这类数据收敛到一个可视化的Web平台，业务研发在Portal上改完数值，客户端通过长连接几乎无延迟地收到变更，应用无需重启。
从整体架构看，Apollo由三个基础服务加一个控制台组成。ConfigService负责给客户端提供配置读取和推送能力，AdminService面向管理员接收配置修改请求，Portal则是用户操作的Web界面，背后还有Eureka做服务注册发现，MetaServer做域名收敛。这种分层让读和写压力隔离，也方便在多机房场景下做容灾。理解这几个角色的分工，是后面部署不出错的前提。
部署前的环境与依赖准备
在真正动手安装Apollo之前，必须确认机器满足最基本的软件要求。官方明确支持JDK 1.8及以上版本，推荐使用Oracle JDK或者OpenJDK均可，但要注意JAVA_HOME环境变量必须正确指向安装目录，否则启动脚本会直接退出。另一个关键是MySQL，Apollo需要5.6.5以上的版本，因为里面用到了utf8mb4字符集和某些新语法，低版本导入SQL会报语法错误。
除了上述两点，还要规划好网络与端口。ConfigService默认占用8080，AdminService占用8090，Portal占用8070，如果同一台机器上已经跑了别的服务，需要提前在启动脚本里改掉这些端口。另外，Apollo各个服务之间通过Eureka内部互通，防火墙要放行相关IP段，尤其是做分布式多节点时，跨机器通信失败是最常见的排障点。建议准备一台干净的开发机或虚拟机，先跑通单机版再谈扩展。
数据库初始化与脚本导入
Apollo的元数据和配置内容都落在MySQL里，因此第一步是建库并执行官方提供的SQL文件。通常需要创建ApolloConfigDB和ApolloPortalDB两个库，前者存放各个环境的配置历史与灰度规则，后者存放用户、权限和项目信息。脚本可以从GitHub仓库的scripts/sql目录拿到，文件名类似apolloconfigdb.sql和apolloportaldb.sql，用source命令或者Navicat这类工具导入均可。
导入完成之后，必须修改ApolloConfigDB里ServerConfig表的eureka.service.url值，把它指向你实际部署的ConfigService地址，例如http://10.0.0.12:8080/eureka/。这个动作决定了AdminService能否被Portal发现，很多新手部署后页面打不开配置，就是因为这里还是localhost。Portal库里也要检查apollo.portal.envs参数，确认你启用的环境标识，比如dev、fat、pro，和后面启动参数保持一致。
服务模块启动与联通验证
拿到官方编译好的安装包后，解压会看到apollo-configservice、apollo-adminservice、apollo-portal三个目录，每个里面都有scripts/startup.sh。启动顺序没有强制要求，但习惯上先起ConfigService，再起AdminService，最后起Portal。每个服务都通过-Dserver.port和-Dspring.datasource.url等JVM参数绑定自己的库和端口，这些参数写在startup.sh里，按机器情况改好再执行。
服务起来后，访问http://机器IP:8070就能进入Portal登录页，默认账号apollo/admin。登录后新建一个项目，绑定到对应环境，然后新增一条配置并发布，再到客户端引入apollo-client依赖，配置app.id和meta地址，启动示例程序打印该配置。如果能实时看到值且修改后不重启就生效，说明整套链路通了。下面用一张表列出核心服务默认参数，方便对照排查。
| 服务模块 | 默认端口 | 对应数据库 | 主要职能 |
|---|---|---|---|
| configservice | 8080 | ApolloConfigDB | 客户端读配置、推变更 |
| adminservice | 8090 | ApolloConfigDB | 接收Portal写请求 |
| portal | 8070 | ApolloPortalDB | Web管理后台 |
当验证通过后，就可以考虑从单机走向高可用。生产环境至少给ConfigService和AdminService各部署两个节点，前面挂一层Nginx做负载，Portal也可以多实例。需要注意的是Apollo本身不提供配置加密存储，如果配置里有数据库密码等敏感信息，应结合Vault或KMS做外挂处理。日常运维中，定期备份两个MySQL库，监控Eureka里服务是否掉线，基本就能保障配置中心长期稳定。
常见部署错误与处理思路
实际落地时，大家经常遇到Portal打开后环境下拉框为空，或者点进项目提示无权限。前者大多是ApolloPortalDB里envs只写了dev，但启动参数没带-Dapollo_profile=github，导致读取了默认空环境；后者一般是demo库导入后没跑assign_users角色脚本，管理员账号没绑到项目。遇到这类问题，先查库再查启动日志，比盲目重启更有效。
另一个高频故障是客户端一直连不上MetaServer，日志里报Could not find config service。这通常是机器双网卡，Eureka注册的是内网地址而客户端在外网，需要在ConfigService的startup.sh里加-Deureka.instance.ip-address=公网IP来显式声明。还有人把三个服务塞进同一台小内存机器，结果JVM频繁GC导致推送延迟，建议配置服务至少2核4G起步，Portal可稍低。理清这些坑，Apollo的部署其实是一条很顺的主线任务。