多数据中心部署疑惑

[enjoycodingfun]

您好，帮忙看下如下场景的部署方案是否正确：
背景：公司项目生产环境有多个集群，比如上海，杭州，日本，新加坡，我们想通过部署一个portal管理多个集群，目前的方案是：

一个环境PRO，下面创建多个集群，上海，杭州，日本，新加坡，然后在各集群服务器上各部署一套configService，adminService，configDB（数据库是各个节点一套，但实际数据我们通过专线做了DB同步，也就是各集群的configDB数据一模一样）。portalDB及portal服务只部署在杭州节点，修改配置的时候通过杭州的portal去修改各集群的配置。

我的疑问点是：看官方文档阿波罗client感知配置变更是根据configDB，如果是的话，那我们这种部署方式应该不会导致portal修改配置后，由于我们把杭州节点的数据同步到了其他节点，其他节点的应用感知不到配置有变更吧？另外我们这种部署是不是adminservice也只要部署一个杭州节点就行了，毕竟底层的configDB数据各节点已经做了数据同步

[nobodyiam]

admin service 单点写入，通过 db 同步分发到其它站点，其它站点的 config service 通过 db 感知配置变化，这应该也是可以的

[enjoycodingfun]

感谢您的回复，那我再复述下我的方案您看对不，按照您的回复，下面我准备按照如下架构部署，portal服务和portalDB以及adminservice只部署在杭州节点，configDB和configservice各个节点各部署一套（杭州，北京，日本......），其中各节点的configDB数据全部由杭州节点同步而来，各节点通过自己的configService来感知configDB的变化来感知配置变化。这个方案应该是可行的哦？

[nisiyong]

感谢您的回复，那我再复述下我的方案您看对不，按照您的回复，下面我准备按照如下架构部署，portal服务和portalDB以及adminservice只部署在杭州节点，configDB和configservice各个节点各部署一套（杭州，北京，日本......），其中各节点的configDB数据全部由杭州节点同步而来，各节点通过自己的configService来感知configDB的变化来感知配置变化。这个方案应该是可行的哦？

看起来应该没啥问题，configdb供海外节点使用都只是readonly，adminservice操作configdb的变更通过数据库同步方式最终一致即可。

[nobodyiam]

#1294 has more information.

[wang-qijia]

您好，帮忙看下如下场景的部署方案是否正确： 背景：公司项目生产环境有多个集群，比如上海，杭州，日本，新加坡，我们想通过部署一个portal管理多个集群，目前的方案是：

一个环境PRO，下面创建多个集群，上海，杭州，日本，新加坡，然后在各集群服务器上各部署一套configService，adminService，configDB（数据库是各个节点一套，但实际数据我们通过专线做了DB同步，也就是各集群的configDB数据一模一样）。portalDB及portal服务只部署在杭州节点，修改配置的时候通过杭州的portal去修改各集群的配置。

我的疑问点是：看官方文档阿波罗client感知配置变更是根据configDB，如果是的话，那我们这种部署方式应该不会导致portal修改配置后，由于我们把杭州节点的数据同步到了其他节点，其他节点的应用感知不到配置有变更吧？另外我们这种部署是不是adminservice也只要部署一个杭州节点就行了，毕竟底层的configDB数据各节点已经做了数据同步

我这边也遇到类似问题，存在上百服务在边缘节点部署，如果在每个边缘节点部署一份 Admin Service 和 Config Service 会产生几个问题
第一个问题： Portal 端 环境数量众多，如果每一个边缘节点存在 开发、生产两个环境，那在 Portal 端回产生 100 个边缘节点 * 2 = 200个环境，会许带来易用性、可维护性问题
第二哥问题： 数据同步问题
想了解一下多数据中心部署这块目前有没有可靠的方案容易实施，谢谢

[nobodyiam]

多数据中心之间延时情况如何？如果延时低的话，可以直接连中心节点的 config service 或者部署在边缘节点部署 config service，config service 再连中心节点的数据库。
如果延时较大的话，可以参考 #1294，在边缘节点部署 config service 和 apolloconfigdb，apolloconfigdb 保持和中心节点的单项同步即可。

[wang-qijia]

多数据中心之间延时情况如何？如果延时低的话，可以直接连中心节点的 config service 或者部署在边缘节点部署 config service，config service 再连中心节点的数据库。 如果延时较大的话，可以参考 #1294，在边缘节点部署 config service 和 apolloconfigdb，apolloconfigdb 保持和中心节点的单项同步即可。

首先感谢你的回复，目前来看国内数据中心延时不高 有专线
目前想法是这样的:
在国内中心数据中心部署开发、生产环境,其他边缘节点去直连中心节点，海外数据中心部署有个前提,如果配置和国内不同则重新部署一套 AdminService、Config Service、Config DB 通过环境区分,如果配置相同则只部署 Config Service、Config DB 数据从国内 DB 同步
麻烦你看下这样部署模式是否合理，谢谢你

最终实现统一配置中心管理，通过 Portal 管理多数据中心、多环境

[nobodyiam]

首先感谢你的回复，目前来看国内数据中心延时不高 有专线 目前想法是这样的: 在国内中心数据中心部署开发、生产环境,其他边缘节点去直连中心节点，海外数据中心部署有个前提,如果配置和国内不同则重新部署一套 AdminService、Config Service、Config DB 通过环境区分,如果配置相同则只部署 Config Service、Config DB 数据从国内 DB 同步 麻烦你看下这样部署模式是否合理，谢谢你

最终实现统一配置中心管理，通过 Portal 管理多数据中心、多环境

这个方案应该是可行的，有一个补充的点是如果复用国内 DB 的话，InstanceConfigAuditUtil 的写操作也需要代理回国内，具体可以参考下 #1294 的讨论。

[wang-qijia]

InstanceConfigAuditUtil 改造方案可以描述下吗？是在 Config Service 工程引入多数据源还是通过国内服务提供接口支持

[wang-qijia]

建议：
目前多数据中心部署比较常见，建议多数据中心（涉及国内、国外）部署方案放在官方文档中，方便第一时间获取减少后期沟通成本

[nobodyiam]

InstanceConfigAuditUtil 改造方案可以描述下吗？是在 Config Service 工程引入多数据源还是通过国内服务提供接口支持

目前没有标准产品方案，可以在国内的 config service 开一个接口给国外的 config service 调用。

[enjoycodingfun]

按照之前的部署方案我这边本地验证了下，没有问题，准备上生产环境，但是发现我的java应用引入apollo-client后构建失败，报错如下：
Failed to collect dependencies at com.ctrip.framework.apollo:apollo-client:jar:2.0.0 -> com.ctrip.framework.apollo:apollo-core:jar:2.0.0: Failed to read artifact descriptor for com.ctrip.framework.apollo:apollo-core:jar:2.0.0: Could not find artifact com.ctrip.framework.apollo:apollo:pom:${revision} in hz_repo。
我看了下是apollo-client依赖的下面的版本号读取不到，因为我看这个版本号的定义在pom文件中使用地方的下方，是不是因为maven版本低的原因啊，我们maven版本3.2.5
</groupId/>com.ctrip.framework.apollo</groupId/>
</artifactId/>apollo</artifactId/>
</version/>${revision}</version/>
</name/>Apollo</name/>
这个定义在占位符引用的下方，低版本maven是不是读取不到？？？我本地的应用没什么问题
</properties/>
</revision/>2.0.0</revision/>

[nobodyiam]

这个 2.0.0 是你自己打的包吗？中央仓库上的 apollo-core 里面是替换成具体版本号的

https://search.maven.org/artifact/com.ctrip.framework.apollo/apollo-core/2.0.0/jar

[enjoycodingfun]

我的包也是直接在最新master上切了一个本地分支后构建的，我这边看的是这样的

[nobodyiam]

代码中是${revision}变量没错的，打完包会被替换掉的。

[enjoycodingfun]

昨天我的java应用引入的apollo-client升级了下2.0.1，构建没问题了，不知道什么原因导致2.0.0就是构建不成功。另外我准备升级的apollo服务端，但是源码clone下来看到master上版本是2.1.0，这不是写错了吧？

[nobodyiam]

2.0.1 has been released, you may retrieve it via the tag - https://github.com/apolloconfig/apollo/tree/v2.0.1

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had activity in the last 7 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.