问题标签 [microservices]

我正在开发一系列将部署为微服务的应用程序。每个都有一个单独的数据库，我希望通过像 Apache Kafka 这样的单一统一事件存储/日志来协调数据。我已经开始尝试使用 Kafka，大多数用户似乎都在使用具有集群和相当复杂的容错设置的相当大规模的 kafka。我们最初预计不会有特别大的容量，所以我想知道 Kafka 是否是正确的选择？这是否适合卡夫卡，或者鉴于我们目前的规模，我应该寻找更轻量级的替代品。

可能是一个有点不寻常的场景，但我们需要在 Spring MVC 控制器中重定向：

至：

迄今为止，我尝试的所有解决方案都导致了重定向循环，因为 Spring 执行重定向，但随后在重定向 URL 中重复匹配 /browser.html，而不管附加信息如何。我需要说的是“仅当它是路径的结尾时才匹配/browser.html”。

我尝试过setUseSuffixPatternMatch(Boolean.FALSE);无济于事PathMatchConfigurer，还在请求映射本身中尝试了以下 URI 模板正则表达式模式：

..但仍然得到一个重定向循环。想法赞赏 - 这是 SpringBoot 1.2.3 微服务中的 Spring 4.1.6，通过上下文。

更新： 在进一步调查和更好地理解 HAL 浏览器使用的 URL 片段以确定它将在微服务本身内向哪个路径发出请求时，我相信解决方案可能不在于尝试重定向 off browser.html，因为 Spring 会无论片段值如何，都将其映射到每个请求的相同控制器方法，而是恢复到/HAL 浏览器已设置为其默认入口点的应用程序 ( ) 的默认上下文路径，或者找到一种方法来配置即使应用程序映射到 /some_path，嵌入式 tomcat 容器也会在默认上下文路径上响应一些合理的内容（不仅仅是 404）。

作为进一步的上下文，我们可以毫无问题地从便捷路径/browser（或其他路径）重定向到 HAL 浏览器，并使用正确的入口点片段作为服务的上下文路径——效果很好。问题是浏览器本身有一个“转到入口点”按钮，当将其作为webjar拉入时，该按钮被硬编码为/. 另一种选择是放弃 webjar，只复制浏览器的静态文件并更新入口点。

在开发后端组件时，我需要决定这些组件如何相互交互和通信。特别是，我需要决定使用（RESTful，微）Web 服务与消息代理（例如 RabbitMQ）是否更好。是否有某些标准可以帮助决定为每个组件使用 Web 服务还是使用消息传递？

假设我们有许多 Web API 微服务，它们是用不同的语言/框架编写的（有些是 ASP.NET Web API，有些是 NodeJS，有些是 Flask 等）。

我想记录对任何服务的每个请求，我更喜欢集中式日志。

我应该使用什么方法/工具？

问候，丹尼尔

我在 Bluemix 上有两个应用程序，我需要将一个应用程序的 URL 提供给另一个应用程序。

在我的源代码中对 URL 进行硬编码似乎是个坏主意……如果 url 发生变化怎么办？

我创建了一个非常简单的 REST 微服务，它接收有关电子邮件的信息并发送它。微服务发送方法如下所示：

现在在我的应用程序中，我使用 RestSharp 调用它，如下所示：

我的问题：

1. 这是打电话的最佳方式吗？显然，我稍后将不得不添加错误处理等，但我说的更多是我使用 RestSharp 进行调用的方式。

2. 我发现我的应用程序需要知道微服务期望接收的对象有点不舒服 - 没有任何定义/接口/合同可以用来确定。这是否被普遍接受为 REST 可以接受，还是我应该实现我的应用程序具有的某种接口，以便它可以以更明确的方式调用我的微服务。REST 甚至可以做到这一点吗？

谢谢你的帮助！

我有一个分成几个组件的 Web 应用程序。由于某些原因（定价），我正在考虑在不同的云中部署未来的组件。

有没有人有这方面的参考和经验来告诉我这是否肯定不好？我知道位于不同网络中的组件会降低性能。同时，我不喜欢失去选择新组件的权力的想法。

基于微服务的系统必须都在同一个网络中吗？你如何处理这个问题？

我对在我们的微服务架构中使用 swagger 很感兴趣。每个微服务都是用 .NET (WebApi2) 编写的，并且是一个单独的应用程序（相同的主机，但是只是不同的路径）。理想情况下，我想要一个描述所有 API 的大张旗鼓的规范，然后想用它来生成客户端 c#，因此这些 API 的所有消费者都有模型的定义以及服务的调用者。

这可能吗？我读过它是从 2.0 开始的，但还没有找到任何具体的例子。我已经开始使用一些 .NET swagger 库，它们似乎都在应用程序本身中安装了 swagger-ui - 因此每个微服务都有效地托管了自己的 API。

谢谢你的帮助。

我们通常使用消息传递来向解耦的服务发送消息。这使得服务发现不再是问题，因为（例如，使用 RabbitMQ 中的 AMQP）您可以使用代理的路由功能将消息分派到正确的队列以提供正确的服务。负载平衡也由消息代理处理。

进入 Kubernetes。

在谈论服务复制和重新生成失败的服务时，通常会布置用例，即当您的客户端使用一些活动协议（如 http）来联系服务时，即使该服务异步处理请求也是如此。在这种情况下，拥有复制控制器是很自然的，它管理一组服务和一个入口点以在它们之间进行负载平衡。

我喜欢 kubernetes 直观的概念，比如滚动部署，但是如何控制这些没有 http 接口的野兽呢？

更新： 我不想建立一个消息代理集群。我将消息消费者视为服务。服务客户端不直接连接到服务，它们将消息发送到消息代理。消息代理在某种程度上充当负载平衡器，并将消息分派给订阅的队列消费者。这些消费者实现服务。

我的问题围绕着这样一个事实，即演示中的大多数使用模式都处理通过 http 调用的服务，而 kubernetes 在这里做得很好，可以为这些服务创建服务代理和复制控制器。是否可以为我的这种服务创建复制控制器，它本身没有 http 接口，并具有滚动更新和最少实例的所有好处？

微服务作为一种软件架构风格正在获得关注，它将更好地支持持续交付，提供快速部署和关注点分离的模型。

Vert.x 3 和 Vert.x-Apex 为构建微服务提供了一个有趣的模型。如其中一个示例所示，一个简单的 Verticle 可以公开 HTTP 服务，因此可以使用 REST 服务。verticle 绑定了自己的 tcp 端口。

当扩展到多个微服务以支持完整的应用程序时，您最终会有很多选择。关于哪种风格最终可以支持持续交付并最大程度地减少升级停机时间的任何想法？

选项

1. 运行多个 verticles 可能是一个解决方案，它们都包含自己的路由，因此 http 处理包含在 verticle 中。请求/响应可以完全由 Verticle 处理。这可能意味着每个 Verticle 在它自己的 tcp 端口上运行。
2. 使用路由器，您可以在单个端口上公开所有路径，并相应地处理它们。数据将由包含路由器的 Verticle 处理，可能会将其传递给其他 Verticle。然后这开始看起来像一个更单一的方法。
3. 运行包含服务的单独的 vert.x 实例（可能对它们进行集群）。这可以更容易地使用持续交付，因为整个事情是独立的。
4. 其他可能的选择？

部署

在部署方面，需要快速部署新服务，而不会使整个应用程序瘫痪。

• 选项 3. 可以为此提供一种方法，但也可能导致开销，尤其是当每个 Verticle 中都有一个 DB Verticle 运行时。
• 选项 1. 可能更容易，但是重新加载新的和更新的 Verticle 怎么样。

单独的微服务提供了一种有趣的开发方式，但在编排和部署方面存在一些挑战。

有什么想法吗？