请教，Apollo如何支持多环境？

[zrweng]

在ApolloPortalDB的ServerConfig表修改了apollo.portal.envs，增加了UAT,PRO 两种环境，在Portal环境列表中出现DEV,UAT,PRO三种环境，但在任意一种环境下添加变量，所有都会添加该变量而且值也一模一样，这样如何能在不同的环境下使用不同的配置呢？

[nobodyiam]

那是因为你把meta server在每个环境都配置成一样了。

在build.sh里面有设置meta server地址的地方，需要确保都设置对了。

更多内容，可以参考文档。

[zrweng]

哦，明白了，意思是不同的环境需要有不同的config service，对应不同环境的ApolloConfigDB，如：
dev_meta=http://localhost:8080
fat_meta=http://localhost:8081
uat_meta=http://localhost:8082
pro_meta=http://localhost:8083

Portal只是对不同环境的Config Service配置操作

[nobodyiam]

是的，Portal只是对不同环境的Admin Service配置操作，更多信息可以参考Apollo配置中心设计

[songwie]

这种配置为什么不配置在表里面 感觉这个设计比较奇葩

[nobodyiam]

放在表里的话，客户端如何知道meta server地址？

[songwie]

去注册中心拿

[songwie]

你们的这个配置中心目前为止感觉所有的开源的里面最好用的，最全的 只有这点 有多地方需要构建，这点设计待商榷 ，其实可以很多的配置可以 配到表里发布到注册中心
不过总体还是很强大的

[nobodyiam]

我们的meta server就相当于你说的注册中心。。。

所以，问题来了，客户端怎么知道注册中心在哪里。。。

[songwie]

这个。。。应该是设计的风格了 客户端其实只需要配置一个注册中心的地址，然后所有的都去拿

[nobodyiam]

恩，这个就和网络策略有关了，我们的设计思路是各环境间严格隔离，也就是比如测试环境的应用无法访问到生产环境的服务（只对极少量的工具应用开放访问其它环境的服务，如apollo-portal），所以我们是在每个环境都部署了一个meta server，用来作为客户端的注册中心。

所以必须在客户端配置上各个环境的meta server地址，才有了把meta server地址打包在jar包里的做法。

这块确实不是最完美的方式，之前我们还考虑过把配置服务的地址写在机器上的server.properties中，这样就不需要在jar包里面设置不同环境的地址了。不过这个运维成本略高，最后没有采用。

[xinyu7git]

恩，这个就和网络策略有关了，我们的设计思路是各环境间严格隔离，也就是比如测试环境的应用无法访问到生产环境的服务（只对极少量的工具应用开放访问其它环境的服务，如apollo-portal），所以我们是在每个环境都部署了一个meta server，用来作为客户端的注册中心。

所以必须在客户端配置上各个环境的meta server地址，才有了把meta server地址打包在jar包里的做法。

这块确实不是最完美的方式，之前我们还考虑过把配置服务的地址写在机器上的server.properties中，这样就不需要在jar包里面设置不同环境的地址了。不过这个运维成本略高，最后没有采用。

我们现在急需要环境能够自定义添加的功能，我们全球现在由20多个数据中心，希望能公用一个portal。

每个数据中心内部可能有多个机房，在数据中心内部使用多台服务器部署config/admin/meta服务，通过服务中心内部的load balance服务对外暴露统一service ip（不支持load balance的情况下使用多个固定ip的meta地址）。

对于portal服务来说，在portal数据库中增加一个environment表，environment表支持用户添加自定义的环境：
环境名称 + 环境的meta地址 + 测试可用按钮。

用户添加environment时候，输入环境名称（支持中文），以及对应该环境的meta地址即可，添加完成后可以点击测试按钮，测试该环境是否可用，可用后，才能够使用。

分布式部署中，只要完成一个数据中心的分布式部署即可（config/admin/meta+mysql），config/admin/meta可以都部署在同一个容器中（k8s使用同一个pod）。

我觉得这样的方式会好很多。希望能够继续交流！

[nobodyiam]

@xinyu7git 多谢建议!

[fenggeHu]

经过比较apollo是同类产品里做得最好的。在配置管理方面，这种多环境多库的设计可能适合平台/产品型的应用，通常只有确定的开发、预发、线上等环境。当我们在做项目的时候，同一个应用有N个项目多套环境，就不知道怎么用了

[nobodyiam]

@Brightfox 可以看看集群是否能解决你们的场景

[DiamondBug]

不能让conf和admin服务配置一下portal的地址，让他们自己去找portal注册吗，我想知道这样做的难点在哪里。
反正这样做就可以很方便，甚至可以把配置维护任务交给非技术人员做。
现在这种设计，每增加一个环境就需要重新配置、重启portal，感觉挺麻烦的，docker的话可能好点，还没试。
最后，你们这项目做得很好，先点个赞，我只是提出我的想法，希望继续改进完善。

[nobodyiam]

@DiamondBug 感谢建议，其实之前也有想过在portal提供一个环境管理页面的，不过由于环境的配置非常低频，所以该功能还没做