问题标签 [microservices]

我正在使用微服务架构构建巨大的应用程序。该应用程序将包含多个后端微服务（部署在多个云实例上），其中一些我想使用 rest api 进行连接，以便在它们之间传递数据。

该应用程序还将向第三方公开公共 API，但上述端点应仅限于同一应用程序中的其他微服务，从而创建某种专用网络。

所以，我的问题是：

如何在同一应用程序中实现对其他微服务的受限 api 访问？

如果有比使用 http 传输层更好的连接微服务的方法，请提及。

如果可能，请保持答案服务器/语言不可知。

谢谢。

I'm working on a Web application that I decoupled it in multiple containerized microservices. I have now around 20 services, but the whole system will definitely need more than 300. Most of the services now and some in the future will not need an entire machine so I'll deploy multiple services on a same host. I'm wondering how others deal with interservice communication. My preferred way was to go with a REST based communication but...

Isn't it too heavy to have multiple web servers running on the same machine? I'm developing in Ruby, but even a lightweight web server like Puma can consume a good amount of memory

I started writing a custom communication channel using UNIX sockets. So, I'd start one web server and my "router" app would communicate with the currently running services on that host through UNIX sockets. But I don't know if it's worth the effort and on top of that, all services have to be written and customized to use this kind of communication. I believe it would be hard to use any framework like Ruby-on-Rails or others, even different languages which is the whole appeal with microservices architecture. I feel like I'm trying to reinventing the wheel.

So, can someone suggest a better approach or vote for one of my current ones?

I appreciate any help,

Thanks,

在为大型系统（如 AWS）部署 SOA 时，有两种方法可用于服务交互。

1. 让每个服务集群都在内部 elb 后面。客户端与相应的 elb 建立连接池，并且 elb 进行循环平衡。

2. 使用像 netflix eureka 这样的服务发现方法。

目前我们正在使用第一种方法，其中每个服务集群都位于内部 elb 后面，客户端通过 elb 进行通信，因此每个客户端实例只需维护 1 个池，即使用 elb 端点。

我对第二个方法有以下疑问。

1. 转向服务发现和智能客户端架构是否有好处，其中服务客户端知道所有服务实例（通过 eureka 服务或等效服务）并进行内部负载平衡？
2. 在上述情况下，连接池如何工作？目前，每个客户端实例必须准确维护 1 个连接池，即与相应服务的 elb。但是对于富客户端，每个客户端都将拥有所有可以直接通信的服务实例端点。在每个请求上建立连接效率不高，我猜每个客户端都有这么多连接池（每个服务实例 1 个）是一种矫枉过正的做法。

需要就上述两个问题提出意见/建议。

我正在构建一个网站后端，该后端涉及客户端提交请求以执行一些昂贵的（及时）操作。昂贵的操作还涉及收集一些信息以完成。

客户提交的工作可以用uuid. 我希望使用面向服务的架构（SOA）（即多个微服务）。

客户端通过 HTTP 使用 RESTful 通信与后端通信。我计划使用一个队列，执行昂贵操作的工作人员可以轮询工作。队列具有持久性并提供了不错的可靠性语义。

一个考虑因素是我是否收集上游昂贵操作所需的所有数据，然后将所有这些数据排入队列，或者我是否只是将这些数据排入队列uuid并让工作人员获取数据。

以下是正在考虑的两种架构的图表：

基于推送（即上游收集数据）：

基于拉的（即工人收集数据）：

我想到的一些事情：

1. 在基于推送的情况下，我可能会在收集所需数据时被阻塞，因此客户端的 HTTP 请求在收集数据然后入队之前不会得到响应。从 UI 的角度来看，请求将处于未决状态，直到响应返回。
2. 在基于拉的场景中，只有工作人员需要知道工作需要哪些数据。这意味着我可以让多种类型的客户端与各种后端进行通信。如果数据需要更改，我只更新工作人员而不是每个上游服务。

还有什么我在这里想念的吗？

我有一个在嵌入式 Tomcat servlet 容器上运行的 Spring Boot 应用程序mvn spring-boot:run。而且我不想将项目作为单独的战争部署到独立的 Tomcat。

每当我将代码推送到 BitBucket/Github 时，都会运行一个挂钩并触发 Jenkins 作业（在 Amazon EC2 上运行）以部署应用程序。

Jenkins 作业有一个 post build action: mvn spring-boot:run，问题是 post build action 完成后作业挂起。

应该有另一种方法来做到这一点。任何帮助，将不胜感激。

在我的应用程序架构中，我有一个单独的登录服务 (REST API)，它处理所有与用户登录/帐户相关的功能，例如创建用户、身份验证等。现在在有效登录时，我正在设置适当的会话变量，但这些似乎是不好的方法。有没有办法为

我正在尝试使用 Dropwizard 和 Gradle 作为构建系统创建一个简单的微服务。没有数据库，只有 REST 端点要公开。

所以我有一个控制器：

我的应用程序主类：

示例是一个带有一个字符串属性的简单值对象，此时 MyConfiguration 是一个空类。

和 build.gradle：

但是在构建之后，当我输入：

我仍然得到：

有任何想法吗？

我在生产中使用 Kafka。许多服务向其中发送和读取消息。

一切正常，但我在一项服务中遇到了错误。出于一个奇怪的原因，它每秒向 Kafka 发送数百万条消息。

由于这个错误，我的 Kafka 崩溃了。

这不是 Kafka 错误，但我怎样才能保护它免受潜在的洪水影响？

我计划开发一个微服务电子商务系统作为概念证明。该架构由 3 个组件组成：

• 一个基于 javascript 的单页应用程序，它将 AJAX 请求发送到

• 带有 REST API 的服务器（API 网关），它提供通过调用其他服务接收的 JSON 数据

• 3 种服务：CatalogProvider、CustomersProvider、CheckoutProvider

目前，这些服务都是 Magento Shopsystem 的 API 端点。

当我尝试通过向 REST Api 发送请求来将用户登录到他们的 Magento 系统时，显然服务器在发送下一个请求时不记得会话。

我还使用 Magento 在服务器端处理购物车，并通过 REST Api 调用添加/更新/删除项目。在这里，由于会话丢失，发送下一个请求时添加的项目也会丢失。

所以我的问题是：

解决微服务架构中会话处理问题的可能方法是什么？

我们正在构建一个相当大的系统，它将公开几个不同的 REST API，包含一个 Mongodb 数据库、一个 Redis 缓存层和一个后端计算库。目前我们正在使用 Flask-Restful 来构建我们的 API，但由于各种原因，我们还需要运行另一个提供数据库资源的 Flask 实例，以及在前端站点之上的另一个层。蓝图并不是真正的解决方案，因为我们可能希望在 ec2 中的不同机器上解耦这些不同的服务。

我们计划使用 Apache+WSGI 作为生产服务器，但是每个烧瓶服务器都需要一个唯一的端口，管理所有这些微服务是一场噩梦。我听说过网关 API 的概念，但我真的找不到关于如何实现一个或在实践中看起来如何的文档。

如今，微服务/SOA 似乎是一笔巨大的交易，从某种意义上说，我们的架构就是围绕它设计的。但是我很难找到有关如何在实践中执行此操作的任何信息，尤其是在我们的特定设置中。管理所有这些服务器似乎是一场潜在的噩梦。感觉使用 Docker 可以解决我们大部分的头痛问题，但我真的很想知道人们在使用容器之前做了什么。

TLDR：有很多烧瓶服务器构成了我们的微服务架构。不知道如何管理。