Closed uzdz closed 5 years ago
一个ApolloConfigDB可以用于多个环境,只不过这里的环境是叫cluster。 然后这个架构图有问题
哦 我看错了 没啥问题
哈哈哈,这个流程图部署方案可以应用于线上吗?
对于ApolloConfigDB可以用作多个集群我是理解的,但我问题中所说的环境指DEV、FAT 、UAT 、PRO这类环境,而非集群。
有一点问题,一个环境(Dev,Pro等)只使用一个ApolloConfigDB . apollo并不能直接同步两个ApolloConfigDB的数据,而是需要数据库自己做同步.
是的,你可以看流程图里,我通过正方形将服务器划分成了生产环境PRO、开发环境DEV,这两套环境各自使用不同的ApolloConfigDB。
我线上就是这么部署的
而且这里的库存服务和用户服务划分得也不是很明确,同一层的开发环境例如dev所在的两台服务器的工作是完全一样的,并不存在某一个作为主力,某一个作为备份,他们都是主力,搭两台的意义只是为了防止某一台炸了 . apollo客户端或者portal会负责负载均衡和错误重试,某一台负载高了就尝试切换另一台,但是他们两台的地位是一样的
其实admin-service和config-service都是可以多节点集群部署的,目的就是做高可用。换句话来说,不管是官方给出的架构流程图里还是我上面给出的流程图里,都将应用和admin-service、config-service部署在同一台服务器中,这不是必须的,可以将admin-service、config-service单独部署另一台服务器。
而且这里的库存服务和用户服务划分得也不是很明确,同一层的开发环境例如dev所在的两台服务器的工作是完全一样的,并不存在某一个作为主力,某一个作为备份,他们都是主力,搭两台的意义只是为了防止某一台炸了 . apollo客户端或者portal会负责负载均衡和错误重试,某一台负载高了就尝试切换另一台,但是他们两台的地位是一样的
我的部署和他画的这个图基本完全一致,master-slave这种数据库部署是为了做多机房容灾的,每个前面都部署了多个config-server来保证高可用的
@wkcaeser 在官方给出的流程介绍里说到,config-serivce通过每秒扫表的方式判断是否有数据的变更。 那么当portal通知到admin-service时,这个admin-service是不是只负责操作管理一个环境下的ApolloConfigDB?并且admin-service可以多节点部署,组成集群高可用?
理论上可以说,一组admin-service + 一组config-service服务一套环境,比如:DEV。
而当我们存在多套环境时(DEV、FAT 、UAT 、PRO),我们需要再每套环境中都部署一组admin-service + 一组config-service来服务该环境。
这样理解没问题吧?🙏
对的,就是这样子操作的的.
每套环境都要一组adminserver和configserver来保证高可用,然后adminserver和configserver其实没太多关联,只是因为metaserver和configserver集成了。 adminserver收到变更请求后去写库,然后configserver定时读库。 至于主从mysql 这个主要是跨机房容灾用的,或者是有海外业务这种场景吧
有个小点需要注意一下,目前config service有写操作(InstanceConfigAuditUtil),所以需要连master库
@nobodyiam 请问,config service写操作InstanceConfigAuditUtil,具体目的是什么呢?写入实例信息吗?
@uzdz 是的,页面上的实例列表数据就来自于InstanceConfigAuditUtil的写入
@uzdz 是的,页面上的实例列表数据就来自于InstanceConfigAuditUtil的写入
@nobodyiam 这个是否考虑configservice调admin回写会合理些,这样configservice只配置一个只读库就可以了
@christinkaka
是一个值得考虑的点,好处是config service更纯粹了,坏处是config service依赖admin service了
您好,我在看官方给出的分布式部署方案时存在一些疑惑,我按照官方文档以及自身的理解绘制了以下流程图,请问图中的简易架构图是否部署正确?
还有一个问题请教: