什么时候应该选择微服务架构？

随着人们转向云原生策略，我们需要一个支持它的架构。作为面向服务架构的一种变体，微服务架构有助于数字世界中的服务多样化。,,我们来看一些报道：,在微服务架构中，服务是松耦合且相互独立的。简单来说，让我们考虑一个电子商务平台；如果购物车出现错误，它不会干扰其他功能，如登录、结帐、浏览、支付等。如果是单体架构，整个系统就会崩溃。从而不允许任何事情发生。,基于医疗保健和金融服务的平台发现隔离敏感数据并单独处理它们至关重要。这些敏感数据属于受保护的健康信息 (PHI) 和个人身份信息 (PII)。在处理 PHI 和 PII 信息时，公司需要遵守特定的安全措施和合规标准，例如 GDPR 和 SOC2。识别需要访问 PHI 和 PII 数据的信息并通过更好的监督、审计和治理将它们分开处理变得至关重要。,微服务架构确保责任在不同的成员、团队或部门之间分配。使团队能够独立做出决策并自主开发软件。基于微服务的架构实施了一种模块化结构，可以缩小团队规模。这进一步有助于提高开发人员的生产力，因为他们的注意力集中在单一服务上。,微服务架构主要受益于此，因为职责分工要容易得多。,构建单个服务在理论上可能听起来很简单，但实际上要复杂得多。当我们将应用程序分解为单个服务时，如果有一个庞大的团队构建单个服务，事情就会变得更顺利。,微服务架构的主要优势之一是在开发单个服务时可以灵活地使用各种技术基础。这意味着工程团队必须维护多种工具来维护这些微服务，只是因为每个服务使用不同的技术。,在这里，每个微服务组件都不同，不是因为任何技术要求，而是基于开发人员的个人喜好。这不仅在开发人员切换团队时成为技能问题，而且在应用程序进入维护模式时会缩减所有操作。突然之间，鉴于技术的多样性，我们需要更多的人力和资源来维护应用程序。,从财务角度来看，它在维护技能和运行时资源方面都涉及更多成本。,基于微服务的架构强制执行模块化结构，其中应用程序被分解为多个独立部署的微服务。区别就在这里——当我们使用单体架构时，所有的依赖关系都被隐藏并编码在组件之间的依赖关系规则中。
在微服务架构中，所有这些依赖项都必须在基础架构配置中进行编码（引入基础架构即代码的概念）。这包括基础设施的维护和配置。,需要注意的另一点是，在单体应用中，通信是作为内存调用发生的，而在谈论微服务时，通信在进程之间移动，可能通过网络进行。这带来了新的挑战，例如延迟和速度损失。假设我们循环调用远程微服务；它会在每次循环迭代时增加延迟，使服务调用无法使用。,这个问题的一个可能的解决方案是，如果我们以一种避免服务调用循环的方式设计我们的服务。,如果您已经考虑迁移到微服务架构，那么您正计划迁移现有的单体应用程序，将每个域分解为新服务。,当我们知道基于微服务的架构强制执行模块化结构时，我们必须在将单体分解为新的单个组件时引入新的连接及其依赖关系。现在从传统应用程序调用微服务可能有点麻烦。为什么？因为缺少事务管理可能会出现一些问题，因为它们都在单体应用程序中交织在一起。,我们都知道基于微服务的架构强制执行模块化结构。然而，真正的问题是每个应用程序是否都需要分解为模块/片段/微服务。,软件架构风格推动产品发挥其全部潜力。这不是要遵循任何架构模式的规则并根据样式进行构建。这更像是一次了解我们如何使我们的服务交付无缝的旅程。如果您认为您的产品交付能力可以通过微服务架构得到放大，那么您应该这样做。今天，我们看到许多企业级托管微服务平台出现在市场上。借助这些平台，DevOps 团队可以跨环境管理和部署微服务。确保微服务可投入生产，以缩短上市时间、增强应用稳定性并增强应用安全性。,