从业务方法或技术方面的微服务架构？

Question

我们的团队正在尝试解耦单片 spring mvc管理应用程序（创建，更新，删除），我们希望采用基于微服务<的架构/ strong>即可。

经过一些研究后，最好的是根据问题 创建微服务 ，该软件的特定部分可以解决，例如，管理客户端。

当我们阅读一些定义时出现问题，例如 Wikipedia 中的以下内容：

  

在软件工程中，单片应用程序描述了一个   单层软件应用程序，其中用户界面和   数据访问代码从单个程序组合成一个程序   平台。

基于该定义，我的应用程序不是单片，因为它在层中完全分离，但在微服务架构中也找不到，这对我来说很困惑，因为在网络一切都是关于单片与微服务。

那么，微服务架构是否应该根据它解决的业务问题进行设计？

是否应根据应用程序在图层中的组织方式设计微服务架构？

感谢。

Answer 1

我喜欢将每个微服务视为自包含较小的整体块。当您强迫自己将遗留应用程序拆分为较小的巨石时，您会发现：

1. 60％的代码都是脚手架，需要在多个服务中重复。

2. 如果你事先确定了什么去哪里的规则，那么分割事物（并保持这种方式）会更容易。

最常见的方法是按功能区域拆分应用程序。因此，为了回答您的问题，我同意更多关于右上角的图片，假设您打算在那里展示多个容器。

关于上面的＃1，通常会有一大堆脚手架模块，你可以避免手工编写。

Answer 2

根据我的经验，微服务最明显的优势是水平扩展的能力。用户分析需要多长时间？再添加10个工人。完成。然后删除。无需为运行整体的昂贵服务器添加更多RAM / CPU /等等。

不要提前计划将ClientManager微服务分开 - 这应该只是一个类。

您正在考虑迁移到微服务的原因。有些东西耗尽了太多资源。 找出最有问题的流程，减慢一切，并为其创建微服务。它可以是例如报告生成，用户创建，数据聚合。从规划API开始。它将清楚地说明它将承担什么责任以及它将使用多少资源。当您知道它应该做什么时，正确命名。

敏捷软件方法是您在此过程中最好的朋友。逐个完成这些过程。 实验，迭代和评估。随着时间的推移，微服务应该是多么明显。

关于如何使用微服务组织代码还有一个热门话题 - 我倾向于 monorepo - 包含所有代码的单个存储库。

• 优点：对许多服务的一次拉取请求，简单的utils共享，常见的依赖关系，通用的部署过程以及更容易的自动化。
• 缺点：您可以轻松破解API合约，并在一个微服务中做太多工作（意味着，它可以承担其他服务的责任。）