微服务架构是从业务方法还是技术？答案

【问题标题】：Architecture of microservices from a business approach or technical?微服务架构是从业务方法还是技术？
【发布时间】：2018-10-12 20:36:12
【问题描述】：

我们的团队正在尝试解耦单体 spring mvc 管理应用程序（创建、更新、删除），我们希望采用基于微服务。

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

当我们阅读一些定义时，问题就出现了，例如来自 Wikipedia 的以下定义：

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

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

那么，微服务架构应该根据它解决的业务问题来设计吗？

是否应该根据应用分层组织的方式来设计微服务架构？

谢谢。

【问题讨论】：

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

根据我的经验，微服务最明显的优势是能够横向扩展。用户分析需要很长时间？只需再增加 10 个工人。完毕。那就去掉吧。无需为运行单体应用的成本高昂的服务器添加更多 RAM/CPU/其他任何东西。

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

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

在这个过程中，敏捷软件方法是您最好的朋友。一个一个地处理这些过程。 实验、迭代和评估。随着时间的推移，微服务应该如何做会很明显。

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

【讨论】：

实际上，在不同的项目中有很多操作都在做同样的事情，并且它们在不断变化，如果添加功能我们需要停止所有项目进行更新，即使它是一个库也会发生这种情况。我们认为使用微服务，软件扩展更加容易和高效。现在，我们正在设计该 API。
如果您在多个项目中做类似的事情，那么我认为您应该拥有一个具有版本化 API 的抽象微服务。这样，您可以为新的 API 版本部署更改，但仍支持其他项目的旧流程。这样，您就没有停机时间。我已经在 API 的生产环境中做到了，每秒处理 2k 个请求，停机时间为零。