基于微服务的web应用程序的体系结构

Question

我对网络应用程序分散到微服务这一点感到困惑 - 它是在url级别还是在模型级别？举个例子,假设我有一个3页的单片应用程序.假设每个页面都有一个单独的用例,我想用他们自己的微服务来支持它们.现在,哪些是实现基于微服务的架构的正确方法:

• 我创建了三个不同的应用程序(微服务),每个应用程序包含其中一个页面的(路径,控制器,模型,模板).然后根据请求的页面,我将请求路由到该特定应用程序.这意味着从数据库到HTML的整个页面由一个单独的应用程序提供.基本上,同一网站中的不同页面完全由后端的不同应用程序提供服务.
• 3个微服务不处理UI内容,只处理其用例(模型,控制器,无模板)的数据,并通过REST API进行公开.我有一个面向公众的应用程序.此应用程序仅查询三个不同的应用程序(微服务),然后构建要返回给浏览器的html页面.在这种情况下,Web应用程序中的所有页面都由一个应用程序提供,该应用程序在内部使用三种不同的微服务.

Answer 1

你麻烦的是如何为你的微服务建模.

在微服务方面,第二种方法是最合适的,它通过API公开其逻辑.

总是当你为微服务建模时,请记住以下事实.

• 松耦合:当服务是松散耦合的,改变一个服务应该不需要切换到另一个.这个微服务的重点是能够对一个服务进行更改并进行部署,而不需要更改系统的任何其他部分.这非常重要.

• 强大的凝聚力:我们希望相关的行为坐在一起,并且无关的行为可以坐在其他地方.为什么？好吧,如果我们想改变行为,我们希望能够在一个地方更改它,并尽快释放该更改.

Answer 2

和软件工程中一样，答案取决于它。我现在无法想象一个原因，但是选项1在某些特定情况下可能很有用。

但是，考虑到微服务的正式定义，选项2对其进行了更好的说明。拥有微服务的主要优势之一是能够重用它。不同的应用程序在呈现信息时有不同的要求和需求。使您的微服务返回数据的JSON表示形式将使您在格式化此信息方面更具灵活性。