微服务是一种模块化、可伸缩的架构，通过去中心化和独立服务实现敏捷开发。优势包括易于扩展团队和系统，但也面临延迟、管理复杂性等挑战。标准化API网关和服务网格可缓解这些问题。未来趋势包括更广泛的应用和与无服务器计算的集成。
译自：Introduction to Microservices
作者：TNS Staff
微服务架构风格代表了软件结构和开发方式的一种转变，强调一种模块化的方法，即将单个应用程序划分为小的、可独立部署的服务。每个服务都专注于执行特定的业务功能，在自己的进程中运行，并通过定义良好的 API 与其他服务进行通信，通常是一种轻量级机制，例如 HTTP 资源 API。 这种方法与单体架构形成对比，单体架构作为一个单一实体部署，并且倾向于更紧密地耦合。
微服务的基本原则包括自主性、可伸缩性和弹性。当服务边界被正确定义时，服务彼此独立运行，松散耦合意味着一个服务中的更改不会直接影响其他服务。当然，这并非总是如此，因为对服务接口的一些更改将导致需要协调，但良好微服务架构的目标是通过内聚的服务边界和服务合同中的演进机制来最小化这些更改。
这种独立性还支持水平扩展，因为可以根据需求单独扩展服务，而不会影响整个应用程序。此外，微服务可以提高弹性；架构的分布式特性允许更好的故障隔离，确保一个服务中的故障不一定会导致整个系统崩溃。
从单体架构过渡到微服务架构提供了其他潜在优势，包括提高开发和部署的灵活性，以及采用多语言方法的能力，在不同的服务中使用多种技术和语言——例如，用 Node.js 编写前端服务，用 Java 编写后端服务。然而，也存在一些权衡，包括增加运营复杂性。此外，正确定义服务以使其能够独立运行可能很困难，并且确保跨服务的一致通信和数据完整性也具有挑战性。尽管如此，微服务架构风格因其支持敏捷和可扩展的应用程序开发的能力而得到广泛采用。
微服务架构的关键特征
微服务架构的特点是几个核心特征，这些特征使其与传统的软件开发范例区分开来。这些特征不仅定义了其结构，而且对旨在实现敏捷性和效率的开发团队的广泛采用做出了重大贡献。
模块化
模块化是微服务的核心概念。这种方法将应用程序分解为更小、更易于管理的部分，每个部分负责特定的功能或业务能力。这种模块化有助于更容易地维护、更新和扩展，因为每个模块都可以独立开发、部署和扩展。
可伸缩性
微服务最引人注目的优势之一是其固有的可伸缩性。由于架构的分布式特性，可以根据需求独立扩展各个服务，而无需扩展整个应用程序。这种细粒度的水平可伸缩性在云环境中尤其有益，在云环境中，可以动态调整资源以满足不同服务不断变化的需求。
去中心化
微服务允许高度的自主性，不仅在服务的部署方面，而且在决策方面，团队围绕业务能力而不是技术层进行组织。每个服务都可以由一个独立的、跨职能的小团队开发和管理。每个团队都对其服务所需的一切负责，例如用户界面、持久存储和任何外部协作。
这种去中心化允许更快速的决策，并且还支持技术和编程语言的多样性，允许每个团队为其特定服务选择最佳工具。然而，这里存在一个重要的权衡，即采用更标准化的方法可以使开发人员更容易在团队之间流动；因此，通常情况下，组织会采用某种程度的“ 黄金路径”，该路径在大多数情况下都会使用。
服务的独立性
独立性是微服务架构的基石。服务被设计为自主运行，通过定义良好的 API相互通信。这种独立性允许持续部署和开发单个服务，从而显著缩短了新功能和更新的上市时间。它还增强了应用程序的弹性，因为单个服务的故障不一定会影响其他服务的功能。
这些特性对开发和部署的好处是深远的。团队可以采用更敏捷的方法，快速迭代单个组件，而不会因单体代码库的复杂性而陷入困境。这种敏捷性能够更快地响应市场变化和客户需求，这是当今快节奏的数字环境中至关重要的优势。此外，微服务有助于更有效地利用资源，因为可以将服务部署在多个服务器和环境中，以优化性能和成本。
总之，微服务架构通过强调模块化、可伸缩性、去中心化和服务独立性，为构建和管理复杂应用程序提供了一个灵活高效的框架。这些特性不仅提高了运营效率，而且还在开发团队中培养了创新和敏捷性。
采用微服务的好处
我们已经研究过的一些微服务特性——特别是它们是可独立部署和可扩展的——提供了切实的业务优势。它们可独立部署的特性意味着可以在不停机的情况下添加新功能和修复程序，因此它们特别适用于任何需要 24/7 全天候提供的产品或服务。它们可独立扩展的特性意味着您可以根据需要向上或向下扩展它们，从而允许以最具成本效益的方式扩展系统。
然而，从业务（区别于技术组织）的角度来看，微服务的关键优势与其说在于扩展系统，不如说在于扩展开发组织。假设您的架构和服务边界正确，微服务会减少交付争用，这意味着更多的开发人员可以同时在同一个系统上工作，而不会互相干扰。
原因是最佳团队规模。杰夫·贝佐斯在亚马逊引入了两张披萨规则——如果一个团队不能用两张披萨喂饱，那就太大了。这显然是一个相当不精确的规则，但尼尔·维德马和理查德·哈克曼的研究（在哈克曼的书《领导团队》中讨论）表明，一个团队的最佳规模约为 4-5 人。但是，如果您将一个团队分成多个较小的团队，所有这些团队都在同一个单体代码库上工作，则会增加所需的沟通和协调量。如果您尝试过这样做，您就会知道，超过一定限度（例如 20 个开发人员左右），一切都会陷入停顿，您必须以某种方式将团队分开。
从历史上看，这种分离是基于 IT 专业知识完成的。例如，对于客户端服务类型的应用程序，您可能有一个数据库团队、一个前端团队和一个后端服务团队。这些团队中的每一个都可以进一步细分，例如，您可以将前端团队拆分为设计、Web、移动和桌面。[这在一定程度上是可行的，但您最终仍然会达到扩展限制。
通过微服务方法，您可以根据需要拥有更多或更少的跨职能团队，至少在理论上是这样。更重要的是，如果它们与业务功能紧密结合，而不是与 IT 专业知识紧密结合，它们可以更容易地与业务客户建立更紧密的关系，并深入了解业务的特定方面。
同样，如果您始终如一地编写微服务，开发人员也可以相对容易地从一个团队转移到另一个团队——他们需要了解业务逻辑，但服务的结构应该对他们有意义。
我们还应该注意到，不要低估您的技术堆栈在招聘中的作用；现代技术堆栈对新开发人员具有吸引力，因为他们可以学习新技能，并且还有助于留住您已经拥有的优秀人才。微服务通常会减少新开发人员的入职时间，这意味着他们可以更快地启动并有效工作。微服务可以提供的自主权以及创新空间通常具有吸引力。
当然，很容易出错地使用微服务，在这种情况下，情况正好相反。常见问题包括缺乏工具、团队之间不一致，以及经验不足的开发人员尝试采用一种与架构风格不太符合的微服务开发方法。
微服务的优势在于，它们允许以更具成本效益的方式扩展系统或服务以及开发团队。它们促进开发人员与业务之间更紧密的关系，打破康威边界，并且可以帮助招聘和留住人才。然而，它们很难做好。
微服务的挑战
虽然微服务架构提供了许多好处，但它也带来了一系列挑战，组织必须克服这些挑战才能充分利用其潜力。管理分布式系统的复杂性、确保跨服务的数据一致性以及集成多个独立服务是主要的障碍。了解这些挑战并实施有效的策略对于成功采用微服务至关重要。
延迟：通过网络进行调用比在进程内调用花费的时间要长得多，因此，如果流量流经多个微服务，您可能会将很大一部分处理时间花在这些网络调用中。如果您的系统对延迟敏感，您需要花一些时间考虑特定操作中涉及的网络调用数量，并且还要注意物理距离。
管理分布式系统：微服务的分布式特性会使系统管理变得复杂，需要强大的监控和管理工具来确保所有服务都以最佳方式运行，并快速识别和解决问题。标准化、集中式日志记录会有所帮助，并且采用现代可观测性工具和监控对于深入了解分布式服务的健康状况和性能至关重要。
服务集成和通信：确保服务之间的无缝通信和集成是另一项重大挑战。每个微服务都是一个独立的实体，可能使用不同的技术开发并在隔离的环境中运行。这使得为开发团队提供工具和集中式支持变得更加困难，并且组织可能需要施加一些约束。
每增加一种新的编程语言，意味着任何共享库和工具及其相应的文档都需要更新以包含该语言。采用标准化通信协议和利用 API 网关可以在一定程度上提供帮助。API 网关充当所有客户端请求的单一入口点，将它们路由到适当的服务，同时还提供额外的功能，例如身份验证、速率限制和缓存。
数据一致性和事务管理：对于在单体架构中常用的单个数据库，您可以使用事务来确保单个逻辑更新完全成功或完全失败。对于微服务系统，维护跨服务的数据一致性可能令人望而生畏，尤其是在面对服务故障或网络问题时。
实施事件溯源和命令查询职责分离 (CQRS) 等策略，或使用 Saga 模式在更改的部分失败时应用补偿性更改，可以帮助管理数据一致性，但会增加额外的复杂性。如果您可以接受最终一致性，则实现起来可能会更简单。
安全性：微服务架构增加了应用程序的攻击面。您需要保护微服务端点和您发送的数据。管理凭证也可能更加复杂。但是，如果您的数据存储在具有不同凭证的不同数据存储中，则攻击者如果获得对其中一个存储的访问权限，则无法访问其他存储。
使用服务网格克服挑战：服务网格（例如 Istio 或 Linkerd）可以通过为管理服务到服务通信提供专用的基础设施层，从而显著缓解与微服务相关的挑战。它提供了诸如服务发现、负载平衡、加密和开箱即用的可观测性等功能，使开发人员能够专注于业务逻辑而不是基础设施问题。但是，服务网格仍然是一项相对不成熟的技术，并且会增加延迟开销。出于这些原因，如果您能够等待，这仍然是一个好建议。
采用 DevOps 和自动化：采用微服务的总体目标是让组织能够更快地进行创新。在传统的组织中，可能有一个集中的架构审查委员会或变更控制委员会，微服务方法根本无法实现这一点。至少，采用 DevOps 实践和自动化对于管理微服务的复杂性至关重要。持续集成和持续部署 (CI/CD)管道应用于自动化服务的测试、构建和部署，确保可靠且快速地将更改引入生产环境。借助基础设施即代码和 GitOps 类型的方案，自动化扩展到基础设施配置和扩展，进一步减轻了运营负担。
总之，虽然转向微服务架构在系统管理、服务集成和数据一致性方面提出了挑战，但可以通过战略性地使用诸如 API 网关和服务网格等技术以及拥抱 DevOps 和自动化文化来在一定程度上解决这些问题。通过承认这些考虑因素并采用最佳实践，组织可以应对微服务的复杂性，并释放其在敏捷、可扩展和弹性应用程序开发方面的全部潜力。
微服务与面向服务的架构 (SOA)
微服务和面向服务的架构 (SOA)都是在软件开发中推广使用服务的架构风格，但在范围、粒度和实施策略上存在显着差异。了解这些区别以及它们的相似之处，是理解从 SOA 到微服务作为现代应用程序开发中首选架构风格的演变的关键。
SOA 是一种架构模式，它出现在 2000 年代初期，旨在应对单体架构的局限性，强调创建松散耦合的服务以支持业务流程。SOA 服务旨在在组织的不同部分中重用，从而导致更大和更通用的服务定义。SOA 中的通信通常通过企业服务总线 (ESB) 进行——这些通常是复杂的、重量级的中间件。
SOA 的一个挑战是缺乏关于如何做好它的共识。这些包括围绕供应商中间件、诸如 SOAP 之类的通信协议以及缺乏关于服务粒度的指导的问题。
另一方面，微服务源于实际使用，并且在某种意义上代表了正确完成的 SOA。每个微服务都专注于特定的业务能力，并且可以独立开发、部署和扩展。与 SOA 相比，这种更精细的粒度导致服务与特定的业务功能更加一致，从而提供更大的灵活性和敏捷性。微服务中的通信是直接且去中心化的，通常使用诸如 HTTP/REST 或消息队列之类的轻量级协议，从而减少了对复杂中间件的依赖。
从 SOA 到微服务的演变反映了应用程序开发中更广泛的转向敏捷性、弹性和可伸缩性的趋势。虽然 SOA 为基于服务的架构奠定了基础，但微服务通过提倡更小、更专注的服务进一步推进了这些原则，从而更好地支持持续交付和部署实践。
这种转变是由于组织需要快速适应不断变化的市场条件和技术进步，这使得微服务成为构建和扩展现代应用程序的有吸引力的架构选择。
案例研究：成功的微服务实施
Netflix 向微服务的转型
Netflix 经常被引述为成功采用微服务的先驱示例。面对其单体架构的可伸缩性挑战，尤其是在用户群快速增长以及需要全球内容交付的情况下，Netflix 过渡到了微服务架构。这种转变使他们能够独立扩展其服务、更快地部署更新并提高整体系统弹性。结果是一个高度可靠的流媒体服务，能够无缝地向全球数百万用户提供内容，展示了微服务在支持业务可伸缩性和服务可靠性方面的强大功能。
亚马逊的微服务演变
亚马逊从单体架构到微服务架构的演变是成功的另一个标志。最初，随着亚马逊的增长，其单体架构成为瓶颈，阻碍了创新并减慢了部署周期。通过采用微服务，亚马逊能够将其应用程序分解为更小的、可独立部署的服务，每个服务都与特定的业务功能保持一致。这种转型使亚马逊能够为其电子商务平台实现前所未有的可伸缩性，提高功能发布的速度，并保持高水平的服务可用性，从而为他们的市场领导地位做出了重大贡献。
Uber 通过微服务实现可伸缩性
Uber 快速扩张到全球市场需要一种能够快速有效地扩展的架构。采用微服务使 Uber 能够针对不同地区优化其服务、处理数百万次并发行程并快速推出新功能。这种架构方法提供了为每个服务使用最佳技术堆栈的灵活性、改进了故障隔离，并通过支持可扩展和弹性的服务部署来支持 Uber 的持续增长。
有关这些案例研究的更深入分析和详细信息，鼓励读者浏览 Netflix、Amazon 和 Uber 的官方博客和出版物，以及提供对这些公司微服务历程的全面见解的技术新闻媒体和架构审查网站。
这些案例研究强调了微服务架构在使公司能够扩展、创新和适应不断变化的市场动态方面的变革潜力，从而肯定了微服务在现代软件开发和业务演进中的战略价值。
微服务入门
过渡到微服务架构是一项战略决策，需要仔细的规划和考虑。对于希望踏上这一旅程的组织和开发人员，以下是一些初始步骤和关键考虑因素，以指导该过程：
- 评估准备情况并确立目标：在深入研究微服务之前，请根据文化、技术和流程评估您的组织的准备情况。为转型确立明确的目标，例如提高可伸缩性、加速部署周期或增强系统弹性。了解您希望实现的目标将指导您的策略和实施。
- 从小处着手：从一个小的、可管理的项目开始您向微服务的过渡。这可能涉及将单体应用程序的一部分分解为一个或两个服务，或者使用微服务方法启动一个新的、低风险的项目。从小处着手使您能够以最小的风险学习和调整您的策略。
- 建立跨职能团队：微服务在可以管理服务整个生命周期（从开发到部署）的跨职能团队中蓬勃发展。确保您的团队包括具有不同技能的成员，包括开发、运营和测试。
- 拥抱 DevOps 和自动化：采用微服务与拥抱 DevOps 实践和自动化齐头并进。实施持续集成和持续部署 (CI/CD) 管道，以自动化测试和部署过程。这将有助于快速迭代和部署服务。
- 关注 API 设计：服务之间有效的通信在微服务架构中至关重要。投入时间来设计强大的、版本化的 API，以确保服务之间的无缝交互。
- 考虑基础设施和工具：评估和选择最能支持微服务架构的基础设施和工具，例如容器编排平台（例如，Kubernetes）、服务网格和可观测性工具。这些技术将帮助您有效地管理和监控您的服务。
过渡到微服务是一个需要文化、流程和技术转变的旅程。通过从小处着手、关注明确的目标以及利用正确的工具和实践，组织可以应对微服务采用的复杂性，并为更敏捷、可扩展和弹性的应用程序前景奠定基础。
微服务的未来
软件开发中微服务架构的发展轨迹表明，在其增强应用程序开发的敏捷性、可伸缩性和弹性的能力的推动下，它将继续增长和创新。展望未来，一些新兴趋势将塑造微服务的发展，进一步巩固其在现代软件工程实践中的作用。
跨行业的更多采用：微服务已经证明了它们在以技术为中心的行业中的价值，我们可以预期它们的应用将扩展到更广泛的行业。从银行到零售，技术以外的企业开始认识到微服务在推动数字化转型和增强客户体验方面的好处。
与无服务器计算集成：无服务器 (FaaS) 是构建松散耦合架构的另一种选择，您绝对可以将 FaaS 视为一种微服务架构。虽然无服务器有可能完全取代其他微服务方法，但我们认为未来更有可能看到各种方法的混合以及微服务和无服务器计算模型之间更深入的集成。这种融合将使组织能够更加专注于构建和部署业务逻辑，而底层基础设施和扩展问题由云服务提供商管理。无服务器架构通过提供一个平台来执行代码以响应事件而无需管理服务器，从而补充了微服务，进一步降低了运营复杂性。
服务网格技术的进步：服务网格技术为处理服务到服务通信提供了专用的基础设施层，预计将变得更加复杂。服务网格内可观测性、安全性和流量管理方面的增强将缓解与微服务相关的许多挑战，使其更易于实施和管理。
关注标准化和最佳实践：随着微服务不断成熟，我们可以预期会更加关注标准化和最佳实践的开发。这可能包括设计、开发和部署微服务的标准化方法，从而使组织更容易采用这种架构并取得成功。
结论
正如我们已经探索了微服务架构的复杂性——从其定义特征和优势到塑造其未来的挑战和新兴趋势——很明显，微服务代表了软件开发和部署方式的关键转变。这种架构使组织能够达到前所未有的敏捷性、可伸缩性和弹性水平，从而使它们能够更有效地应对当今数字环境的复杂性。
在 TheNewStack.io，我们致力于为我们的访问者提供关于 微服务和各种相关技术主题的最新见解、新闻和文章。我们的平台是开发人员、IT 专业人员和业务领导者寻求了解微服务架构的最新发展以及他们如何利用这些进步来推动其数字化转型工作的资源。
无论您是处于探索微服务的早期阶段，还是希望完善您现有的微服务战略，TheNewStack.io 都会提供每日更新和深入分析，以指导您的旅程。我们的内容涵盖广泛的主题，从技术教程和案例研究到战略见解和行业趋势，确保您可以访问做出明智决策所需的信息。
总之，微服务的发展是一个持续的旅程，其特点是持续的学习和适应。随着环境的变化，保持知情并参与最新的趋势和最佳实践将是充分利用微服务架构潜力的关键。我们邀请您加入 TheNewStack.io 的充满活力的社区，在那里我们将深入探讨微服务的未来以及软件开发的下一波创新浪潮，共同塑造技术的未来。
感谢您与我们一起探索微服务的动态世界。我们期待继续对话，并在不断发展的软件开发领域为您提供支持。
