微服务与Monolith：选择哪一个？

“微服务”是业界的流行词，对吗？ 除微服务外，设计的其余设计标记为“ Monolith”。 但是作为一名架构师，当您尝试基于特定域创建新软件时，会做什么？ 采用微服务时，无需判断任何问题，因为这很受欢迎，每个人都在后面运行，或者停下来一秒钟，然后考虑您的公司基础架构，员工专业知识，并根据选择微服务来考虑。

作为一名架构师，我们有责任在需要时选择微服务，而不是顺其自然，而是使用微服务。 在本教程中，我将讨论几个方面，在您采用微服务之前，我认为这是最重要的。 我很乐意听到我错过的任何其他建议或方面，甚至是反逻辑。 这是我在微服务和所谓的Monolith这两种架构中工作时的实现。

让我们从选择微服务作为默认架构之前要考虑的方面开始。

1.项目助理的优势：在获得项目时，要考虑的第一个参数是要在该项目中工作的助理人数以及他们的经验是什么。 如果您的实力很弱，例如10-12则不要使用Microservices，因为Microiservices意味着独立的服务，而座右铭是“您构建它，然后运行它”。 因此，一个团队应该完成对微服务的所有权。 如果从统计角度来看您的助理人员人数很少，则每个人或两个人将拥有两个或三个微服务的所有权，这会造成严重问题。 知识仅限于他们，他们将成为Pivot员工。 另一方面，如果座右铭是一个人/两个人拥有两个或三个微服务，那么开发人员应该只关注一小部分，但要知道有关该服务的一切都将崩溃。 那么您对此有何看法？

2.微服务及其相关知识：微服务是一种新架构，与微服务有很多相互关联的概念，例如分布式Artechtures规则，例如高可用性，弹性，服务发现，CAP定理，域驱动设计，断路器模式，分布式缓存机制，路由跟踪等。不仅仅是DevOps文化与微服务紧密结合，以释放微服务的全部功能。 因此，您需要了解CI / CD工具及其文化（自动部署）。 该团队应该高效地为微服务驱动所有这些。 如果将微服务部署在云或容器中，则团队应该了解云架构（PCF，Amazon，Bluemix等）或容器架构（Docker，Docker Swarm，Messos，Kubernetes等）。 仔细考虑团队知识，始终认为当您与微服务打交道时，它意味着多个服务和多个团队，因此每个团队成员应清楚地了解所有相关知识，以独立运行其微服务。 如果您没有这样的休闲时间，请确保每个团队都有一个或两个人，他们知道所有相关知识，以便他们可以教育自己的团队。

3.组织基础架构：另一个重要方面是组织基础架构。 适应微服务之前，请务必检查您的组织采用哪种模式。 根据Conway的法律，无论您的组织结构在代码实现中得到体现。 那么检查一下，您的组织是否采用了敏捷技术？ 是由跨技术成员（如UI，中间层，数据库）组成的团队吗？部署和QA测试模式是什么？您的组织是否遵循手动部署和手动测试，或者他们已经或将要采用DevOps文化？组织将要部署的工件是组织中安装了应用程序服务器并部署工件或组织迁移到云的服务器很少。 基于这些参数，选择是否要采用微服务。 如果组织有自己的服务器（很少）安装了应用程序服务器，那么在这种情况下，所有不同的微服务构件都将部署相同的服务器空间，这将无法满足水平扩展的要求，因此采用微服务的情况将很危险。 同样，在手动测试和手动部署的情况下（如果您采用微服务），对于运营团队和质量检查团队来说也是一场噩梦。 对于开发人员而言，将更改集成到SIT中并进行测试也是一场噩梦。

4.域的重要性：检查您正在处理的域的性质。 坐在Business analysist上，了解这有多重要，是否需要将域划分为子域，以便在Domain不是很复杂的情况下，根据该决策将相关功能封装在上下文中？ 最好坚持使用Monolith。 无需创建上下文映射并在绑定上下文中封装子域。

5.项目预算 ：这是需要注意的另一个重要方面。 考虑一下该项目的预算。 项目的性质是固定投标或TNM类型。 微服务项目比整体方案昂贵，因为它需要更多的服务器或云基础架构，自动化管道，资源计数，所有团队都应该是跨技能的团队。 因此，就基础架构和资源水平而言，它比Monolith的成本高得多。 因此，请考虑与您的项目相适应的预算（我想给您一个提示：请不要向任何人发布。作为一名优秀的Loyal Architect，请务必考虑收入边际，在预算较小的情况下，模块化的整体结构要优于微服务它用于收益。将来，如果您希望转用微服务，那也是可能的。）

结论：如今，微服务技术以这种方式受到打击。 新手或中级开发人员认为Monolith不好，这是所有模块相互绞死的BBOM（大泥巴）。 但是，如果您维护模块化方法，那么这是很好的，并且在很多情况下，当我们的资源有限时，它比微服务更好。 因此，请谨慎选择不要顺其自然。 我总是建议首先使用Monolith，但将其模块化。 如果您使用Java 9和Module，则可以采用SOA，但可以从模块化的一个开始，并且在实际需要时（例如，模块边界将泄漏，或者您无法在模块之间维护非循环图（DAG）），然后考虑一下喙Monolith基于DDD，可以向微服务倾斜。

在此之前，我想说的是：不要像其他人采用微服务那样使用微服务。 在需要时采用它。 我看到很多情况下某些项目尝试采用微服务，但是由于缺乏知识，他们创建了一个既不是微服务也不是Monolith的项目。 他们创建了许多服务，没有适当的封装，并且每个服务彼此链接在一起，因此一个敏捷团队无法独立决定是否部署一个微服务，多个团队，多个工件相互依赖，团队互相指责为：功能跨越许多服务，这是一个可怕的情况。 我将在以后的文章中对此进行讨论。 但是现在，在采用微服务之前，请三思而后行，因为Ben叔叔曾说过“强大的力量伴随着巨大的责任感”。

翻译自: https://www.javacodegeeks.com/2018/10/microservice-monolith-choose.html