apollo-client为啥不是通过serviceId (eureka)去找configserver ？

[endypark]

apollo-client为啥不是通过register(eureka)去找configserver？ 在微服务体系中，本来就是使用register和ribbon综合来去除掉 ip直连，而且方便增减对应service； 为何apollo设计时，还专门设计ip直连（Nginx也是ip直连，要增减一个service，Nginx也要改配置吧），而不是使用register去通过serviceId去访问各个组件。 尤其是meta server的配置，使用serviceId:meta-server或lb://meta-server 是不是更好。 dev.meta=http://1.1.1.1:8080 fat.meta=http://apollo.fat.xxx.com uat.meta=http://apollo.uat.xxx.com pro.meta=http://apollo.xxx.com

目前1.4.0 是否支持我想要的这种？ 当初为啥要client单独去练meta server的设计思想是什么啊？

在微服务群组内，还要求另外添加Nginx去做内网的复杂均衡，是不是不太符合 微服务治理 的倡议啊 ？

谢谢。

[wkcaeser]

微服务中实际不也是ip直连么？feign和dubbo最后都是ip直连吧，涉及到注册中心的最后貌似都是ip直连吧

[wkcaeser]

还有你说的Nginx做负载均衡这个，他背后实际上是注册中心，这个和你其他地方配多个ip或者eureka域空间是同样的东西吧

[endypark]

微服务中实际不也是ip直连么？feign和dubbo最后都是ip直连吧，涉及到注册中心的最后貌似都是ip直连吧

我的意思是编码层面，不是最终运行。。运行中，肯定是client本地缓存从register获取的service列表，然后进行ip直连啊。。。我说的是编码层面通过serviceId进行解耦合，如果使用了ip（包括域名和Nginx），那么不太符合 微服务治理 的日常行为约定啊。

[wkcaeser]

serviceId和域名、多ip或者负载均衡，有啥本质区别么？ 可以理解成都是一个东西吧

[wkcaeser]

你配置serviceId，这个serviceId的信息去哪获取不还是要配置地址吗，这里还少配置了一步

[wkcaeser]

也不是少配置了一步，这步帮你做了，只是你部署的时候需要去配置获取serviceID的地址

[endypark]

meta server一般和config service是在一个 实例（系统） 中的，大概相当于一个系统内的两个模块， 那么想找到meta server，只需要通过register找到config service就好了呀，为啥是找config service用register，找meta server要ip ？

[endypark]

serviceId和域名、多ip或者负载均衡，有啥本质区别么？ 可以理解成都是一个东西吧

serviceId是只认名字，不认地址，，，有利于增减service。 达到解耦合效果。

[endypark]

你配置serviceId，这个serviceId的信息去哪获取不还是要配置地址吗，这里还少配置了一步

微服务的某个服务本身就会配置eureka（为例），，如果是使用serviceId就不需要再配置了，而这里另外加一个ip （meta server）配置, 怎么会是减少配置？ 而且相当于高可用和负载还需要自己搞定，如果增加meta server，还需要自己去修改LB的配置文件。

[wkcaeser]

你配置serviceId，这个serviceId的信息去哪获取不还是要配置地址吗，这里还少配置了一步

微服务的某个服务本身就会配置eureka（为例），，如果是使用serviceId就不需要再配置了，而这里另外加一个ip （meta server）配置, 怎么会是减少配置？ 而且相当于高可用和负载还需要自己搞定，如果增加meta server，还需要自己去修改LB的配置文件。

那问你个问题，微服务绝大部分都是异构的系统，如果这个应用不支持eureka怎么办

[endypark]

也不是少配置了一步，这步帮你做了，只是你部署的时候需要去配置获取serviceID的地址

在整个apollo中，serviceId只有apollo-portal, apollo-config, apollo-admin三个，又不是有个几百上千的，也不需要根据业务自动增加serviceId，，为啥还专门弄个meta service ？ 并不是说，这样 有问题，而是起码现在我不理解为啥这么设计。

[endypark]

你配置serviceId，这个serviceId的信息去哪获取不还是要配置地址吗，这里还少配置了一步

微服务的某个服务本身就会配置eureka（为例），，如果是使用serviceId就不需要再配置了，而这里另外加一个ip （meta server）配置, 怎么会是减少配置？ 而且相当于高可用和负载还需要自己搞定，如果增加meta server，还需要自己去修改LB的配置文件。

那问你个问题，微服务绝大部分都是异构的系统，如果这个应用不支持eureka怎么办

那可以提供 两个 mode啊， register版 和 Nginx版。 register版应该符合90%以上的场景吧。

[wkcaeser]

现在这种可以满足任何情况，为啥要去再做个register版呢。这两个的区别我的理解就是在客户端需要配置个域名，这点成本和开发两套比起来不值一提吧。

PS：我的理解，官方怎么想的我也不知道

[endypark]

现在这种可以满足任何情况，为啥要去再做个register版呢。这两个的区别我的理解就是在客户端需要配置个域名，这点成本和开发两套比起来不值一提吧。

PS：我的理解，官方怎么想的我也不知道

但是对运维人员来说，工作量增加了。。。 至少新增加了一个nginx（或其他）中间件，并要维护nginx.conf文件，还要有test、uat、pre、prod多个环境。。Nginx本身也要高可用啊，还得添加keepalive或HAProxy来保证Nginx高可用。。。都是事儿啊。

我这里说的主要是：只有微服务群，才会用 配置中心，，而微服务群的最核心的就是 服务治理，以register为核心，，register（加上配套的register-client）核心目的是解耦合（包括ip解耦合，加 无感增减服务实例），，，那么为微服务群设计开发的配置中心，为啥又使用了 违背 服务治理 理念的 设计思想。。。？ 用肯定是能用，但是是不是不够 友好 和 符合理念。 （是不是我也不确定啊，所以问问官方 什么想法，，是才有 serviceId有什么坑 绕不过去吗）

[wkcaeser]

服务增减现在的模式也是除了运维其他人员不会有感知吧。因为涉及到机器增减，无论怎么做运维肯定是有感知的。但是对于接入方来说，集群的变动从头到尾都是无感知的

[endypark]

服务增减现在的模式也是除了运维其他人员不会有感知吧。因为涉及到机器增减，无论怎么做运维肯定是有感知的。但是对于接入方来说，集群的变动从头到尾都是无感知的

不能只考虑开发人员啊，得综合考虑，，，还有部署方案是开发组提供的吧，增加Nginx，然后Nginx还得高可用，改了conf，得重启，得保证不影响服务使用的重启，，，死很多脑细胞的。。

[wkcaeser]

我用的是阿里云的slb，每次增删节点的时候业务线完全没有感知。 就是设计部分方案的时候麻烦点，实际部署和业务方接入都超级简单。后期基本也没有维护成本

[nobodyiam]

apollo没有对外暴露eureka的原因是希望做成一个通用的配置中心客户端，能够支持不同的语言、不同的开发框架接入，比如目前已经有Java、.Net、Go、Python、NodeJs、PHP等客户端，对Java的话也支持任意的开发框架（不只是支持spring cloud）。

[stale[bot]]

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

[stale[bot]]

This issue has been automatically closed because it has not had activity in the last 14 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.