rest - 来自业务方法还是技术的微服务架构？

Question

我们的团队正在尝试分离整体 Spring mvc管理应用程序(创建，更新，删除)，并且我们希望采用基于微服务的体系结构。

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

当我们阅读一些定义(如 Wikipedia 的以下内容)时，问题就来了:

In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

基于该定义，我的应用程序不是单片的，因为它是完全分层的，但在微服务架构中也找不到，这令我感到困惑，因为在网络中，所有内容都与有关。 。



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

是否应该基于应用程序的分层组织方式来设计微服务架构？

谢谢。

Answer 1

根据我的经验，微服务最明显的优势是可以水平扩展。用户分析需要花费多长时间？只需再增加10个 worker 即可。做完了然后删除。无需向运行整体的本已昂贵的服务器添加更多RAM / CPU /任何东西。

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

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

敏捷软件方法论是您在此过程中最大的 friend 。一个接一个地处理。 实验，迭代和评估。 随着时间的流逝，微服务应该如何做将变得显而易见。

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

优点:对许多服务，简单的utils共享，通用的依赖关系，通用的部署过程和更容易的自动化的一个请求请求。

缺点:您可以轻松地打破API契约(Contract)并在一个微服务中完成太多工作(这意味着它可能需要其他服务负责)。