语言 Chinese, Simplified

SEO Title

Introduction to Microservices for CTOs: microservices pros and cons for business

微服务——在这种程度上，很少有软件趋势能吸引IT决策者的注意。他们应该能够让你的应用程序更高效和可扩展。但这到底意味着什么？什么时候投资于它们而不是其他类型的软件架构是个好主意？软件公司将技术细节转化为可操作的信息，供您在业务中使用。

对于许多软件开发人员来说，基于微服务的架构已经成为他们日常工作的一个重要组成部分，因为越来越多的应用程序是这样制作的。但是，由于宣传太多，很容易把微服务当成一个时髦词。本文试图让每个可能从微服务中受益的人更容易就微服务在组织中的使用做出明智的决定。让我们来谈谈微服务；它们使用的利弊等等。

微服务——它们到底是什么？

根据Gartner的一个流行定义，microservice是应用程序的一个“紧密限定范围、强封装、松散耦合、可独立部署和独立扩展”的组件。让我们把它分解。

严格的范围-它有一个明确的定义，通常是非常狭窄的用途。
强封装——作为代码的一部分，它包含其功能的整个实现。
松散耦合——在大多数情况下，它是独立的，不需要其他微服务来工作。
独立部署-它可以单独部署，而不必损害其他微服务。
独立的可扩展性——即使一个微服务处理了大部分流量，我们也不需要扩展整个系统，而是只关注于扩展受影响的微服务。

还在困惑吗？基于微服务的应用程序的一个很好的例子可以是一个电子商务商店，其中每个业务领域（例如处理订单、产品目录、内部搜索、帐单、付款、交货单、PCI DSS认证）都是一个单独的微服务。微服务通常按照特定的业务用例进行组织，但是诸如身份验证或通知之类的功能也可以作为单独的微服务工作。

这种将所有这些功能划分为完全独立的块的独特能力使微服务成为分散/分布式团队的理想选择。因此，拥有诸如Netflix或Twitter这样的分布式团队的大公司可以通过将不同的微服务分配给不同的团队来高效地工作。但这并不是许多创新科技公司选择微服务的唯一原因。当你继续读下去的时候，这些优势应该会越来越明显。

微服务是如何工作的？

让我们更深入地研究微服务是如何工作的。如您所知，在一个标准的单片应用程序中，代码库可以大致分为两部分：前端和后端。每一个都有一个独立的代码库。通常，不同的团队会处理这些问题，并且每一层都可以拥有自己的主导技术（例如，针对前端和节点.js用于后端）。如下所示。

An image explaining how monolith architecture works.

在基于微服务的体系结构中，前端层保持不变，但后端被分成多个部分，专门用于特定功能。它们中的每一个都可以有自己的存储库。由于它们是强封装的，每个微服务都可能用不同的语言编写，如下图所示。

An image shows how microservices architecture works with multiple technologies.

对于许多项目——在这些项目中，没有必要（或能力）涉及这么多不同的技术，而且存在如此多的存储库会造成混乱（复杂的项目结构、存储库之间代码组织的差异等等），这些都超过了这种分离的好处——可以使用简化的版本。通过使用monorepos，可以创建包含所有使用相同技术堆栈的微服务的代码的存储库。

An image explains how microservices architecture works with monorepos.

回到单片与微服务的问题。基于微服务的体系结构与整体式架构还有什么不同？

	微服务	单体
开发	每个服务都是一个独立的应用程序。它可能（但不一定需要）有一个单独的代码存储库，因此冲突不太常见。为了共享一些代码，您需要有一个单独的库。您可以更容易地扩展团队，因为每个团队可能被分配到特定的服务。添加新功能可以扩展现有服务之一，也可以添加新服务。	所有的东西都放在一个地方，所以共享代码要容易得多。同时，它可能会导致一个不可维护的状态，所有的东西都是耦合的。在同一领域工作可能会导致代码冲突，这将导致更长的开发时间。添加新功能是指向现有应用程序添加新代码。更难扩大团队规模。
测试	每个服务都是一个单独的应用程序，不仅需要单元测试，还需要组件/契约测试。更重要的是，我们应该添加一个额外的层，允许我们同时测试多个服务之间的集成。	易于测试。一切都在一个地方。大多数时候，它可以被单元和E2E测试覆盖。
部署	每个服务都需要单独的CI和部署过程。您需要为整个系统协调整个基础设施和配置。但是，如果出现问题，只有一个服务将无法启动。	你设置了一次。不需要太多的编排。但是，如果出现问题，您根本无法部署应用程序。
维护	需要DevOps关于Docker、Kubernetes等的知识	易于维护
可靠性	中断一个服务并不会破坏其他服务，因此只有一组功能可能会受到影响。	破坏了应用程序中的一个地方，破坏了一切。
可扩展性	每个服务都是独立扩展的。我们只使用我们需要的资源。	为了扩展系统的单个部分，您必须扩展整个系统，这可能导致资源没有得到充分利用。
发布	您发布了一个服务，因此只需要与此特定服务相关的测试。	一次发布整个系统，所以每次都需要整个回归。

使用微服务的好处

为您的软件选择基于微服务的体系结构对您的组织有很多潜在的好处。

代码库与业务领域保持一致—您的微服务通常是围绕组织的实际业务功能/目标来组织的，这意味着开发人员和业务人员更容易理解技术和业务是如何联系在一起的。
非常适合分布式团队——不同的开发人员/团队可以在不同的微服务上工作，而不会相互妨碍。对于分布式团队来说，这比一个整体式的团队要方便得多。
更易于构建和维护——根据功能将代码库拆分为更小的独立片段意味着它们更易于理解和维护。Docker等许多工具简化了新微服务的创建。
易于部署–因为您不会中断整个应用程序，所以您可以经常修改和部署新的和现有的微服务。还有一些工具可以让它变得更简单，比如Kubernetes。
提高生产力——从事特定微服务的开发人员不需要等待其他开发人员完成他们的工作。接管自己的工作也更容易，因为较小的代码库更容易理解。质量保证也在这个过程中得到了突破。
选择技术的自由度——每个微服务都可以用不同的技术开发，这样就可以为每个问题选择最有效的解决方案。这也在很大程度上消除了技术和供应商的锁定——你的应用程序并不完全依赖于任何第三方软件。
高性能、高效率和可扩展性–您可以单独扩展每个微服务。这意味着单个服务可以部署在多个服务器中，以服务于增加的流量，而其他服务同时只消耗标准数量的资源。您可以以经济高效的方式保持高性能。
可靠性—故障隔离意味着单个服务的故障不太可能影响其他服务的性能。在一个巨石应用程序中，类似的错误可能会导致整个系统崩溃。

微服务：不同场景下的利弊

到目前为止，您可能已经对微服务能够很好地配合的项目有了一个很好的想法。总而言之：

由于微服务提供了出色的可伸缩性并鼓励基于敏捷的工作流，因此它们非常适合于在这些领域有高要求的应用程序。
由于代码库可以根据功能划分为完全独立开发的单元，因此对于分布式团队来说，这是一个明显的选择，特别是对于代表各种技术堆栈的开发人员。
项目越复杂、流量密集、面向长期，就越适合基于微服务的架构。

现在，让我们来看看微服务什么时候不是最好的选择——微服务的缺点。让我们考虑几个场景。

对Netflix有利的事情可能对我们不利

大型公司，如Netflix，在各地都有不同的开发团队，可以从微服务的模块化特性中获益匪浅。实现基于微服务的体系结构的成本往往比构建一个单一的应用程序要高（您需要考虑日志监视系统、请求跟踪和部署整个系统以及任何单个微服务的能力）。对于那些不希望出现大流量、可伸缩性问题和混合各种技术的系统来说，这可能不值得。

太过敏捷会让你变得僵硬

多亏了微服务，您可以通过单独部署每个微服务来更轻松地进行迭代。测试和部署成为日常工作流程的重要组成部分，而不是很少发生。但随之而来的是巨大的责任。随着动态变化的微服务数量的增加，需要大量的DevOps功能和丰富的经验才能掌握它们。

我只是在试水！

你在创建一个新的（绿地）项目吗？你是否有一个想法，并想创造一个最有价值球员？你最好的选择可能是一块巨石。你不仅不知道你需要什么样的微服务，而且从一开始就不需要微服务的复杂性。毕竟，如果有必要的话，将来您总是可以从一个整体式架构转向基于微服务的架构。

如何开始使用微服务？

有几件事你应该记住。首先，让我们考虑一下在任何情况下都成立的观点

从头开始

不要急于求成-确保项目证明了微服务的合理性。根据我们上面所做的所有考虑，确保您的项目适合微服务。
不要仅仅从理论上讲敏捷。如果没有强大的敏捷文化，您将无法从微服务中获益。
投资于您的DevOps文化/能力。DevOps也是如此——你的架构越大，你需要管理的微服务越多，它就越明显。

现在，谈谈更具体的问题（很有可能！）从单一体系结构到微服务的场景。

从单体到微服务

不要从头开始！既然你已经有了一个应用程序，你应该从它开始作为你的基础。即使你不打算马上去“微服务一路走来”，你也可以简单地在微服务中开发新功能，同时暂时保持你的基础作为一个整体。
避免分散的整体。不要从传统的巨石直接进入微服务。否则，你可能会得到一个分布式的整体——一个表面上模块化的应用程序，其中所有模块实际上都高度依赖于彼此。
去做一个模块化的整体。最好的方法是将你的整体分割成更小的、独立的部分，然后逐步地将它们转化为服务。