发现服务如何在多语言微服务架构中工作？
如果我们使用spring boot构建所有微服务，那么可以使用Eureka服务器（@EnableEurekaServer）发现所有微服务（@EnableEurekaClient）。如果某些微服务是使用其他技术构建的，那么在云（PCF、AWS等）中如何实现发现、负载平衡、反向代理（网关）？
我在网上读了很多关于微服务的博客，我没有得到适当的信息。
共有2个答案
您还可以利用polyglot sidecar支持，将其他技术与Eureka服务器集成以进行发现。例如，非JVM语言可以通过使用@EnableSidecar创建Spring Boot应用程序来启用sidecar。这将有效地触发@enablebuircuirtbreaker，@EnableDiscoveryClient和@EnableZuulProxy支持。应用程序应与非JVM应用程序在同一主机上运行。更多细节将在本Spring文档中提供。您还可以在这里查看一个示例实现
Eureka服务器本身有一个REST api，允许您管理它。您可以在这里找到留档：https://github.com/Netflix/eureka/wiki/Eureka-REST-operations如果您使用的框架或语言不提供与Eureka的直接集成，如Spring Boot，您必须手动完成。
-
我读了一些文章，看了一些视频，但在为这些微服务提供服务方面，没有找到具体的建议。我的理解是，他们应该使用自己的应用程序服务器。 我的问题是它们应该部署在不同的服务器上，还是没关系。 当它们在同一台服务器（计算机）上提供服务时，不会有端口冲突吗？
-
Kubernetes 设计之初就是按照 Cloud Native 的理念设计的，Cloud Native 中有个重要概念就是微服务的架构设计，当将单体应用拆分微服务后， 随着服务数量的增多，如何微服务进行管理以保证服务的 SLA 呢？为了从架构层面上解决这个问题，解放程序员的创造性，避免繁琐的服务发现、监控、分布式追踪等事务，Service mesh 应运而生。 微服务 下图是Bilgin Ibr
-
在单体架构时，因为服务不会经常和动态迁移，所有服务地址可以直接在配置文件中配置，所以也不会有服务发现的问题。但是对于微服务来说，应用的拆分，服务之间的解耦，和服务动态扩展带来的服务迁移，服务发现就成了微服务中的一个关键问题。 服务发现分为客户端服务发现和服务端服务发现两种，架构如下图所示。 这两种架构都各有利弊，我们拿客户端服务发现软件Eureka和服务端服务发现架构Kubernetes/SkyD
-
背景 当前有两个服务，分别是user-service和order-service，nacos服务列表中无法发现两个服务 排查 Nacos v2.2.3 依赖已引入，配置文件已配置addr 运行时未出现连接nacos的日志： 希望大佬们可以帮忙看看是什么问题 问题程序链接 https://oss-20001.oss-cn-qingdao.aliyuncs.com/cloud-demo.zip
-
让我们讨论一下微服务环境的体系结构。我们正在公司内部进行讨论，我想得到一些反馈。我认真考虑的是编排层（代码复制、更多移动部件改变api）。 网络应用- 原料药- 在这种情况下，服务不允许相互对话。业务流程层中的聚合服务 网络应用- 原料药- 这里允许服务相互对话，这里存在聚合服务。 账单属于哪里
-
本文向大家介绍微服务架构是如何运作的？相关面试题，主要包含被问及微服务架构是如何运作的？时的应答技巧和注意事项，需要的朋友参考一下 微服务架构具有以下组件： Clients – 来自不同设备的不同用户发送请求。 Identity Providers – 对用户或客户端身份进行身份验证，并颁发安全令牌。 API Gateway – 处理客户端请求。 Static Content – 容纳系统的所有内