通常，没有经验的团队想要创建微服务，但最终以分布式的整体构成。它是什么，为什么要避免它
首先，我们需要了解简单的整体和微服务之间的区别。
整体
令人印象深刻的只有名称，单片实际上是最常见的建筑风格。这是一切都包含在一件或换句话说中的时间。
。建筑学
实际上，单片后端看起来像一个提供您需要的所有API的单个和大型代码库。
现在，问题是，为什么整体建筑是传统架构，为什么要创建微服务？
在项目开始时，整体建筑具有更简单的范围，对于大多数项目来说就足够了。
当您的整个代码库都位于同一地点时，开发，测试，监视和部署就会更加简单，更快且更便宜。
挑战
但是，当您的应用程序增长，功能和用户更多时，会出现新的挑战。它们可以在两个主要类别（Codebase的可维护性和可伸缩性）下收集。
在整体中，通过创建摘要（例如模块）来组织代码是一种常见的做法。
但是这些抽象及其边界通常会随着时间而分解，类似的代码开始散布。
使用大型代码库，很难知道需要在哪里进行更改，从而使修复错误并实现新功能变得更加困难。
缩放
然后，带有可伸缩性的问题。当系统需要更多资源时，有两种方法可以扩展：水平和垂直。
垂直缩放是指向现有机器（例如GPU或RAM）添加更多资源。水平缩放是指将您的应用程序传播到多台机器上，并在资源池中添加更多机器。
垂直缩放可以足够，但在某个时候将受到限制，因为单个机器可以拥有多少资源是有限的。
从理论上讲，水平缩放是无限的。另一方面，它要求您的应用程序在分布在多台机器上时能够工作。
，只要它无状态，即使它分布在多个机器上，也可以使用单片应用程序。但是，整体的弱点是微服务在水平缩放时没有的。
作为一个整体包含一个整个系统，必须将所有系统缩放在一起。如果您只需要扩展端点的子集，则别无选择，只能部署整个系统。
微服务
不幸的是，微服务以许多不同的方式描述。
建筑学
我特别喜欢的简洁定义来自Sam Newman的“ Building Microservices”：
微服务是小的自主服务，可以一起工作。
对于第一种方法来说，这已经足够了，但是缺乏细节来了解更深层次的微服务。从“ Microservice Architecture”中，我们了解到微服务应分享以下特征：
- 尺寸很小
- 启用消息
- 受上下文界限
- 自主发展
- 独立部署
- 分散
- 使用自动流程构建和发布
现在，实际上这意味着什么？在现实世界中，您的应用程序分为多个服务，并具有自己的一组相关功能（同时确保它们之间的耦合较低）。
同时，根据要处理的负载，同一服务的多个实例。他们进行异步沟通以确保消息传递并避免耦合。
挑战
与整体相反，为什么通过微服务进行开发，测试，监视和部署较慢且更昂贵？
新挑战在多个应用程序中出现。例如，在单独但相关的数据库中管理数据比单个统一数据库面临的挑战更多。
然后，通常需要通过事件总线之间的服务之间的某种交流。使您的微服务一起工作，正确测试它们以及部署将是一个严重的头痛。
最后，您应该期望开发时间更多，以使用微服务。提高的复杂性还意味着您需要一个更大的团队来管理它，用一个和小型团队建立微服务是一个坏主意。
缩放
微服务有一个主要好处。它们可以根据需要轻松部署它们，并更有效地扩展。
使用微服务，您只需扩展需要扩展的服务，从而可以在较小，功能较小的硬件上运行它。它使其更快，更具成本效益。
与整体相比，微服务提供了其他好处，例如弹性，易于部署和替代性。由于整体包含您的整个应用程序，如果其一个组件之一失败，其他所有内容都变得不可用。
此外，您可能已经经历了重构巨大的代码库有多么困难，而微服务的大小通常受到限制。然后，更换服务的成本更容易管理。
在大型项目中，有许多团队，微服务甚至可能对生产力产生积极影响
分布式巨石
分布式整体是将整体分解为多个服务的结果，这些服务彼此之间很大程度上依赖，而无需采用分布式系统所需的模式。
实际上，这是将整体分成单独的服务的结果，但要保持紧密耦合。
这意味着他们仍然彼此依赖。在这种情况下，您会失去整体建筑所带来的简单性，但不享受独立微服务的好处。
不要这样做！
保持较低的耦合并不意味着您绝对没有关系。例如，您可能会发送和收听事件。
另外，您应该编写一些集成测试，或者要进行更精确的合同测试（如果您做得很好）。
这意味着，在某个时候，您需要有关其他服务合同的信息。有一些关系正在发生，但并没有使您的服务紧密结合。
您想了解有关微服务的更多信息吗？
好消息，我在practical course中教微服务。
Crawford Jolly上的Unsplash上的封面照片