一种基于微服务的web应用程序体系结构
我对web应用程序向微服务的发散点感到困惑--它是在url级别还是模型级别？举个例子，假设我有一个单片应用程序，它提供3个页面。假设每个页面都有一个单独的用法，我想用它们自己的微服务来支持它们。下面哪一种是实现基于微服务的体系结构的正确方法：
- 我创建了三个不同的应用程序（微服务），每个都包含一个页面的（路由、控制器、模型、模板）。然后根据哪个页面被请求，我将请求路由到那个特定的应用程序。这意味着从数据库到HTML的整个页面都由一个单独的应用程序提供服务。基本上，同一网站中的不同页面完全由后端的不同应用程序服务。
- 3个微服务不处理UI内容，而只处理它们的用途（模型、控制器、没有模板）的数据，并通过REST API公开这些数据。我有一个面向公众的应用程序。这个应用程序只查询三个不同的应用程序（微服务）的数据，然后构建html页面返回给浏览器。在本例中，web应用程序中的所有页面都由一个应用程序提供，该应用程序在内部使用三个不同的微服务。
共有1个答案
-
我最近开始使用Node.js，我必须构建一个应该使用多个Express.js服务的体系结构。其中一些服务必须位于一台服务器上，另一台则位于其他服务器上。我想构建一个基础服务（像API网关），但是我不知道在这个网关和微服务之间，或者在两个微服务之间进行通信的合适方式是什么。 目前我正在研究一个基于此的解决方案：
-
我正在尝试查找有关在 azure 上设计全局解决方案的资源/信息。以下是我方面的要求： 系统需要有一个master数据库，需要ofc备份机制。 系统需要为各种角色等提供Web应用程序。 系统需要对移动客户端提供某种服务。（在同一个MVC应用程序中还是移动服务中？） 问题来了： 系统将分布在全球。我认为如果移动 客户端/Web客户端（来自世界各地）访问一台服务器（在Azure数据集群中，例如托管解决
-
问题内容： 让我们分享基于Java的Web应用程序体系结构！ Web应用程序有许多不同的体系结构，这些体系结构将使用Java来实现。这个问题的答案可以用作各种Web应用程序设计的库，各有其优缺点。虽然我意识到答案将是主观的，但让我们尽可能做到客观，并激发我们列出的利弊。 使用您喜欢的详细程度描述体系结构。为了使您的答案具有任何价值，您至少必须描述所描述的体系结构中使用的主要技术和思想。最后但并非最
-
gRPC以其性能和效率似乎成为微服务内部通信的热门选择。 然而，gRPC使得查询关系数据变得更加困难，并且需要更多的工作来挂接到我们的API网关。 另一个选择是每个微服务实现它们自己的GraphQL模式，这样它们就可以使用API网关中的Apollo Federation轻松地拼接在一起。 我们如何决定使用哪种方法？ 有没有什么值得我们考虑的显著优势？例如。在易用性、可维护性、可伸缩性、性能等方面？
-
我有一个微服务体系结构，它的日志必须发送到远程Kafka主题。在它旁边，本主题的使用者将把日志发送到麋鹿堆栈（另一个团队） 我想要一个专用的微服务（fwk proxy elasticsearch），其职责是收集其他人的日志，并将其发送到远程Kafka主题。 将从我的微服务聚合的所有日志分派到fwk-代理-弹性搜索微服务的最佳协议是什么？ 我希望这个模式不会重复远程Kafka主题的安全配置。我想把它