模块化软件架构：使用单体、微服务和模块化单体的优缺点

【squids.cn】 全网zui低价RDS，免费的迁移工具DBMotion、数据库备份工具DBTwin、SQL开发工具等

近年来，微服务架构在大多数软件解决方案中已经处于领先地位，而且在很多情况下，它经常被选择为我们开始开发的架构。然而，值得问自己的是，这是否始终是最佳选择。而且，如果你选择微服务作为你想坚守的一套规则，你确定你知道这个选择的后果吗？

微服务的优势 

在我看来，微服务提供了两个主要的优点：

• 无停机时间的独立部署。

• 系统（包括数据库）的逻辑（有时是技术的）划分为业务模块和子模块。

“分布式单体”问题 

不幸的是，在大多数情况下，当选择微服务架构时，团队最终会创建一个所谓的“分布式单体”。如果在工作开始时，你依赖于服务或数据库之间的依赖关系，并且最后同时部署了90%的服务，你应该承认，将其作为一个单一的部署单元会更容易。这将减少与微服务的实施、自动化和维护相关的工作量，并允许你集中精力解决业务问题。

长话短说，你必须记住微服务软件架构风格并不简单，并带有很多技术复杂性。不要用大锤砸核桃！为一个应用程序或服务运行一个Kubernetes集群是没有意义的，因为基础设施的成本和所有的配置将超过开发的成本。还有其他“更简单”的云解决方案，例如 AWS ECS、AWS Fargate、AWS Beanstalk，或者甚至是 EC2 + 简单的负载平衡（其他云提供商有类似的解决方案）。

以下是一些可以帮助你决定选择哪种架构的启示法。

你需要什么？	微服务	单体架构
独立实施单位	是的，但只有良好的逻辑分离	是的
简单快速地构建基础设施	不	是的
动态缩放	是的	不
业务逻辑自治	是的 – 如果我们正确划分域	是的 – 如果我们正确划分域
特定系统组件的动态水平缩放	是的	不
技术自主权	是的	不
独立开发团队	是的	不
快速项目启动（开发启动）	不	是的

单体架构并不一定是坏事——尤其是在模块化软件架构中 

“单体”这一术语经常被用作旧应用的同义词。通过适当地设计一个单体应用（适当选择内部架构），你可以确实地缩短开发启动时间，而不排除未来可能的变化。你仍然可以过渡到微服务。这就是模块化单体方法——或者特别是“首先考虑单体”的方法——派上用场的地方。如果你不知道项目在未来几年内的范围，也不知道它会增长多快，那么从一个结构良好的单体应用开始可能是个好主意。

模块化单体提供了什么？

• 一个单独的部署单元

• 更简单的维护

• 后续可能迁移到分布式架构的开放之路

• 简单的基础设施

• 整理代码

当然，还有许多其他因素可能会影响系统架构的选择。但是，考虑到我上面提到的因素，最好不要开始一个基于微服务的项目。如果你不确定整个系统在2-3年内会是什么样，通常最好选择模块化架构。你从一个计划良好的单体开始，然后——如果需要的话——逐渐将其转化为模块化单体。

你还应该记住一些可用的、简单的解决方案，它们根本不需要系统架构——例如无服务器解决方案、AWS Lambda等。它们在相对简单，不过于复杂的问题中表现良好。

在Pretius，我们专注于长期项目和长生命周期（维护和开发），这就是为什么可持续性和可扩展性对我们来说通常非常重要（但，当然，你的特定情况可能会有所不同）。系统架构的选择通常归结为部署方法和随之而来的系统启动的基础设施。

然而，从软件开发者的角度看，基础设施和应用部署正在逐渐成为次要话题——有专门的岗位的专家（例如DevOps工程师）做出重要决策并处理这些问题。我们只希望系统得到良好的维护，无故障地运行，不产生技术/商业债务。为了实现这一目标，我们需要专注于应用代码。

内部应用架构 

一旦你决定了系统架构，就该关注单个应用的架构了。不幸的是，大多数项目都基于层（n层架构）。在复杂的项目中，最终结果通常都是一样的：→ 大泥球（下面的截图中有例子）。

对于简单的CRUD应用或几个/几十个服务，这并不是一个糟糕的选择，但当你试图将复杂的逻辑放入这样的框架时，很