微服务架构：它们是什么以及为什么要使用它们

微服务是当今软件开发界的热门话题。还有一些很好的理由。

简单地说，随着应用程序变得越来越大、越来越复杂，使用单片方法构建企业应用程序的传统方法已经成为问题。因此，开发人员正在转向微服务软件开发体系结构，在该体系结构中，应用程序被构造为松散耦合服务的集合。这使得它们更容易构建，更重要的是更容易扩展和扩展。

让我们仔细看看微服务方法与单一方法的区别，并检查它们的相对优势和劣势。

巨石：我们过去的样子

传统上，软件开发人员创建大型单片应用程序。单个整体将包含应用程序执行的所有业务活动的所有代码。当然，随着应用程序需求的增长，monolith也在增长。

下面是一个图表，显示了有多少个单片应用程序启动。您编写了一个简单的应用程序，由一个团队开发和管理。

但是如果你的应用程序被证明是成功的，会发生什么呢？用户喜欢它并开始依赖它。交通量急剧增加。而且几乎不可避免的是，用户要求改进和附加功能，因此更多的开发人员被吸引来开发不断增长的应用程序。不久，您的应用程序看起来更像这样：

您曾经简单的应用程序已经变得庞大而复杂。多个独立的开发团队正在同时进行开发。

但这些所谓的独立团队实际上根本不是独立的。他们同时在相同的代码库上工作，同时更改相同的代码部分。

当您有五个独立的开发团队在处理应用程序时重叠时会发生什么？几乎不可能知道谁在做什么。代码更改会发生冲突。代码质量以及应用程序质量和可用性受到影响。对于单个开发团队来说，在不计算对其他团队的影响的情况下进行更改变得越来越困难，团队可能会忽略他们的代码如何与其他代码不兼容，以及其他问题。这通常会导致应用程序速度较慢、可靠性较低，更不用说开发时间越来越长。

其影响不仅仅是技术上的：如果它是业务中的一个重要应用程序，那么开发延迟、应用程序性能差和崩溃最终可能会使您的公司客户和金钱蒙受损失。

幸运的是，这种情况并非不可避免。您可以重新构建和重新构建应用程序，以根据公司的需要而不是针对公司的需要进行扩展。使用现代的、基于微服务的应用程序体系结构是构建应用程序的一种越来越流行的技术，这种应用程序可以扩展，而不会让您的组织陷入单一的泥潭。

微服务：入门

那么什么是微服务架构呢？马丁·福勒（Martin Fowler）是一位软件大师，他曾就这一主题撰写了大量文章。他认为，微服务体系结构由“围绕业务能力、自动化部署、端点智能以及语言和数据的分散控制”组织的“独立部署服务套件”组成

微服务体系结构背后的主要思想是，将应用程序分解成更小的部分并无缝地协同工作时，构建和维护起来更简单。使用微服务时，您将软件功能隔离到多个独立模块中，这些模块分别负责执行精确定义的独立任务。这些模块通过简单、通用的应用程序编程接口（API）相互通信。

使用微服务构建的应用程序具有某些特征。特别是：

• 被分割成多个模块化、松散耦合的组件，每个组件执行一个离散的功能
• 将这些单独的功能构建为与业务能力保持一致
• 可以跨云和数据中心分布
• 将每个功能视为一个独立的服务，可以在不中断应用程序其余部分的情况下对其进行更改、更新或删除

微服务体系结构允许您将应用程序拆分为不同的独立服务，每个服务由软件开发组织中的各个组管理。它们支持对构建大规模应用程序至关重要的职责分离，允许在单个服务上独立完成工作，而不会影响其他组中处理相同总体应用程序的其他开发人员的工作。

简而言之，您的应用程序可以随着公司及其需求的增长而增长。您的应用程序看起来更像这样：

此图显示了作为一系列微服务构建的应用程序。正如您所看到的，每个微服务都有一个明确的团队所有者，每个团队都有一组明确的、不重叠的职责。然而，在实践中，一些服务可能来自第三方，通过API连接，并且可能对应用程序所有者不完全可见。

微服务简史

Martin Fowler记录了“微服务”作为一个术语首次在2011年的软件架构师研讨会上使用，当时参与者发现他们正在并行地探索软件架构中的类似概念。该组织在第二年的会议上确认了microservices这个名称，它描述了这种新的范式。

2012年，詹姆斯·刘易斯在克拉科夫33度的演讲中发表了一篇题为“微服务Java，Unix之路”的演讲，该演讲概述了微服务是一种通过分裂和征服，利用康威定律来组织团队，从而更快地构建软件的方法。

尽管微服务有很多优点，但它并不特别新鲜或创新。它的起源可以追溯到30年前的Unix世界。包括本文作者在内的许多人都说，这不过是面向服务的体系结构（SOA）的一种新理念——一种几十年前风靡一时的设计原则。（由于太多失败且成本高昂的实现，SOA名声不佳。）

Fowler指出了使微服务独一无二的许多主要特征，其中最重要的可能是保持服务的独立性，以便在不影响整个应用程序的情况下单独替换它们。他还制定了诸如围绕业务功能组织服务和使用“智能端点和哑管道”等要求，所有这些都是行业专家Greg Young在2016年伦敦微服务会议上的一次演讲中所描述的“正确完成SOA”的方面。

从那时起，微服务的使用速度加快了。事实上，福勒认为，微服务体系结构正迅速“成为构建企业应用程序的默认样式”

尽管传统观点认为微服务项目最适合实施全新的分布式软件项目，但Red Hat最近的一项调查显示，大多数使用微服务的企业正在成功地部署它们，以重新构建遗留应用程序。超过三分之二（69%）的受访者表示，他们将微服务用于新应用程序和现有应用程序的现代化。

而且好处很快就会产生：根据红帽调查，三分之一的组织在首次部署微服务后的两到六个月内取得优势。

微服务和容器

谈论微服务时，很难不谈论容器，这一概念在21世纪初随着FreeBSD项目首次浮出水面。许多开发人员认为容器是微服务的天然选择。

组成应用程序的服务可以放在容器中，容器拥有该服务或应用程序所需的最小库和可执行文件，使每个容器成为一个自包含的包。Docker提供了一种创建、共享和测试容器映像的简单方法，并且在致力于使用容器开发软件的企业中非常流行。

尽管容器中的应用程序独立于其他容器中的应用程序运行，但它仍然响应内核或其他编排工具的指令。此类编排工具对于管理大量容器至关重要。虽然Docker有自己的编排功能，但许多开发人员、操作人员和开发人员更喜欢Kubernetes。（Kubernetes最初由谷歌设计，是一个开源平台，协调多个容器的操作。）

当然，您可以在不使用容器的情况下构建微服务。但是，当实际运行由许多不同的微服务组成的应用程序时，您需要一种方法来管理它。容器和容器编排非常适合该任务。

微服务如何支持DevOps

微服务方法也与DevOps配合得很好，它通过打破软件开发和IT运营团队之间的障碍，加快了软件从开发到生产的过程。在DevOps环境中，开发人员和操作工程师以迭代的方式无缝协作，以更快地生成更高质量的软件。

从理论上讲，这与微服务体系结构非常吻合，微服务体系结构可以帮助您在极短的生产计划内快速更改应用程序。通过同时利用微服务和DevOps，软件组织可以完成不久前被认为是不可能的事情。例如，亚马逊可以每11.7秒发布一次新代码，而Netflix每天可以部署数千次新代码。

微服务的10个主要好处

根据leanIX最近的一项调查，使用微服务的组织将新软件推向市场的速度比不使用微服务的组织快五倍。大多数使用微服务的公司对结果非常满意，他们计划在未来六个月内继续使用微服务。其中71%计划在未来12个月内增加微服务的使用

组织通过部署微服务实现的十大好处包括：

1. 改进的可伸缩性。因为微服务允许您独立地向上或向下扩展服务，所以扩展的容易性和成本比单一系统中的要低得多。添加新功能通常意味着添加离散的新微服务，而不是重做整个应用程序，这提高了开发速度和应用程序稳定性。

2. 更好的故障隔离。如果一个微服务失败，其他所有微服务都可能继续工作。这是微服务体系结构设计的关键部分。

3. 优化的扩展决策。借助微服务架构，可以在更细粒度的级别上做出扩展决策，从而实现更高效的系统优化和组织。

4. 局部复杂性。微服务架构让开发人员将服务视为黑匣子。服务所有者只需要了解其服务中内容的复杂性。其他服务所有者只需要知道服务提供什么功能，而不必担心它在内部如何工作。这种知识和复杂性的划分使得创建和管理大型应用程序更加容易。

5. 提高了业务灵活性。微服务相对较小且简单，而微服务的故障只会影响该服务，而不会影响整个应用程序，因此企业可以尝试新的流程、算法和业务逻辑。微服务让您可以自由地进行实验和“快速失败”

6. 提高开发人员的生产力。新开发人员可以很快跟上进度，因为理解一个小的、孤立的功能比理解整个单片应用程序更容易。

7. 简化了调试和维护。出于构建单个微服务比为单片体系结构编码更容易的相同原因，开发人员在调试代码和执行维护时可以更高效。

8. 更好地协调开发人员与业务用户。由于微服务体系结构是围绕业务能力组织的，因此开发人员可以更容易地理解用户的观点，并创建与业务更协调的微服务。

9. 经得起未来考验的应用。当创新发生，新的或更新的技术扰乱了您的软件开发过程时，microservice体系结构通过替换或升级受影响的单个服务而使响应变得更容易，而不会影响整个应用程序。

10. 更小、更敏捷的开发团队。在现代软件组织中，团队通常由他们工作的微服务组织。这些团队涉及的人员更少，他们更专注于手头的任务。杰夫·贝佐斯（Jeff Bezos）著名的“两个比萨饼规则”——声称一个不能吃两个比萨饼的软件团队太大了——完全符合微服务哲学。

微服务的潜在缺陷

然而，没有什么是免费的，微服务体系结构也有自己的成本。

1. 微服务架构可能很复杂。虽然单个微服务可能更容易理解和管理，但作为一个整体，应用程序最终可能会有更多的活动部件。通常涉及更多的组件，并且这些组件具有更多的互连。这些相互依赖性增加了应用程序的总体复杂性，这可能会产生问题。

2. 微服务方法需要仔细规划。由于应用程序中的所有微服务必须协同工作，因此开发人员和软件架构师必须仔细规划如何分解所有功能和依赖关系。在从头开始应用程序或修改旧式应用程序时，您也可能遇到数据挑战。除了仔细地规划单个微服务之外，还可能需要多次迭代，直到您将其做好为止。

3. 正确调整微服务的大小至关重要，而且很难计算。如果你把你的微服务做得太大，你最终可能会遇到巨石的所有缺点。如果将它们设置得太小，则会将复杂性从单个服务转移到依赖关系映射中，从而使应用程序更难理解和大规模管理。更糟糕的是，处理复杂的依赖关系通常需要经验更丰富、报酬更高的开发人员和架构师。

4. 您可能无法控制第三方微服务。许多微服务体系结构包括来自第三方的服务，这些服务由您无权访问的团队维护。第三方服务可以随时以可能破坏应用程序的方式更改其API（或依赖项）。如果他们确实修改了API，您需要知道并能够尽快做出响应。

5. 下游依赖关系很难跟踪。微服务成功的一个关键是限制相互依赖，并仔细跟踪无法避免的相互依赖。应用程序必须能够经受住单个微服务的失败，然而下游问题经常发生，并且可以通过生态系统级联。在使用微服务构建的应用程序中构建容错可能比在单片系统中构建容错更复杂。

6. 多个微服务可能会为坏演员提供更多机会。随着微服务的普及，它们可能会增加应用程序对黑客和网络罪犯的脆弱性。由于微服务体系结构允许您在构建应用程序时使用多种操作系统和语言，因此可能会有更多恶意入侵的“软目标”。此外，您可能无法了解应用程序使用的第三方服务的漏洞或行为。

当微服务得到有效使用时，它将获得回报

有效地使用微服务体系结构，可以随着开发应用程序的开发人员数量的增加而扩展应用程序。关键是构建应用程序，而不在宏级别创建复杂、笨拙的beast。这意味着每次向系统添加新服务或微服务之间建立新连接时，都要保持跟踪。

它还意味着检查复杂性的增加，并确保它是有根据的和被充分理解的。定期检查整个应用系统对于保持一组相互连接的微服务高效可靠地工作至关重要。

尽管不是万灵药，但对于越来越多的现代软件组织来说，微服务的好处显然是值得的。通过改变软件开发团队的结构，组织可以创建以特定业务服务为中心的团队，并赋予他们以最佳方式行事的责任和权限。这种方法使团队能够在业务发展过程中快速应对市场需求，而不会中断中心业务活动。光是这条路线就值得入场费。

诸如New Relic之类的监控解决方案可用于帮助跟踪微服务之间的互连依赖关系。New Relic APM以及诸如New Relic Synthetics和New Relic Alerts之类的产品可以监视这些连接的性能、操作特性和SLA，并在检测到问题时向您发出警报。

原文地址：https://newrelic.com/blog/best-practices/microservices-what-they-are-why-to-use-them