微服务

menu icon

微服务

微服务架构是一种方法,用于在单个应用中包含众多松散耦合而且可单独部署的小型服务。

什么是微服务?

微服务(或称微服务架构)是一种云原生架构方法,在单个应用中包含众多松散耦合而且可单独部署的小型组件或服务。 这些服务通常

  • 拥有自己的技术栈,包括数据库和数据管理模型;
  • 通过 REST API、事件流和消息代理的组合相互通信; 以及
  • 按照业务能力进行组织,具有通常称为有界上下文的服务分隔线。

虽然关于微服务的讨论大多围绕架构定义和特征展开,但通过相当简单的业务和组织优势,可以很容易地理解其价值:

  • 可以更轻松地更新代码 - 可以在不触及整个应用的情况下添加新的功能或特性
  • 团队可以针对不同的组件使用不同的技术栈和不同的编程语言。
  • 组件可以相互独立地扩展,从而减少与必须扩展整个应用相关的浪费和成本(因为单个功能可能面临过多的负载)。

在理解微服务是什么时,也可以从微服务“不是什么”入手。 与微服务架构最常见的两项比较是单体架构和面向服务的架构 (SOA)

微服务与单体架构之间的区别在于,微服务由许多松散耦合的小型服务组成单个应用,而不是紧密耦合的大型应用的单体方法

要了解有关微服务与单体架构之间差异的更多信息,请观看此视频 (6:37):

 

微服务与 SOA 之间的差异可能并不明显。 虽然可以对微服务和 SOA 进行技术对比,尤其是在企业服务总线 (ESB) 的作用方面,但比较两者的范围差异可能更为容易。 SOA 是企业范围内的工作,旨在使组织中所有 Web Service 相互之间的通信和集成标准化;而微服务架构则特定于应用。

帖子“SOA vs. 微服务:有何区别?”中提供了进一步的详细信息。

微服务如何使组织受益

微服务在高管和项目负责人中的受欢迎程度可能至少像在开发人员中一样。 这是微服务较为独特的特征之一,因为通常是软件开发团队对架构充满热情。 之所以会这样,是因为微服务更好地反映了许多企业领导组建并运行团队和开发流程的期望方式。

另一方面,微服务是一种能够更好地促进期望的运营模式的架构模型。 在最近对超过 1200 位开发人员和 IT 主管的 IBM 调研中,87% 的微服务用户同意值得花费资金和努力以采用微服务。 可使用以下交互式工具,探讨有关微服务的优势和挑战的更多观点:

(来源: “企业中的微服务之 2021:切实的益处,值得承受挑战。

以下只是微服务的几个企业效益。

可单独部署

也许微服务最重要的特征就是服务规模较小而且可单独部署,因此不再需要大动干戈,以更改代码行或在应用中添加新功能。

微服务承诺,组织不再会经历微小变更花费大量时间这样的噩梦。 它不需要计算机科学的博士学位,就能查看或理解有助于促进速度和敏捷性的方法的价值。

但速度并不是以这种方式设计服务的唯一价值。 常见的新兴组织模式是围绕业务问题、服务或产品建立跨职能团队。 微服务模型与这种趋势完全吻合,因为它使组织能够围绕一个服务或一组服务创建小型跨功能团队,并以灵活的方式开展运作。

微服务的松散耦合也在应用中建立了一定程度的故障隔离和更好的弹性。 而小型的服务,加上其清晰的边界和通信模式,使新团队成员更容易了解代码库并快速做出贡献 - 在速度和员工士气方面都有明显的好处。

作业的合适工具

在传统的 n 层架构模式中,应用通常共享公共栈,而且由关系数据库支持整个应用。 这种方法有几个明显的缺点,其中最重要的缺点是,应用的每个组件都必须共享公共栈、数据模型和数据库,即使对于作业的某些要素有更明确、更理想的工具,也是如此。 这样会形成糟糕的架构,对于不断意识到可以用更出色、更有效的方法构建这些组件的开发人员来说,这无疑令人沮丧。

相比之下,在微服务模型中,组件单独部署,并通过 REST、事件流和消息代理的某些组合进行通信 - 因此,可以针对该服务优化每个单独服务的技术栈。 技术改变了一切,随着令人向往的技术成为现实,由多个较小的服务组成的应用也变得更简单、成本更低。

精确缩放

通过微服务,各个服务可以单独部署,也可以单独扩展。 由此带来的收益显而易见: 如果实施得当,微服务所需的基础架构比单体式应用更少,因为它们能够精确扩展仅需要它的组件,而不是像单体式应用那样需要扩展整个应用。

但也存在挑战

微服务的显著收益也伴随着重大挑战。 从单体式向微服务转变意味着更大的管理复杂性 - 更多的服务,由更多的团队创建,部署在更多的地方。 一个服务中的问题可能会导致其他服务中的问题。 日志记录数据(用于监视和问题解决)的数量更多,并且在各个服务中可能不一致。 新版本可能会导致向后兼容性问题。 应用涉及更多网络连接,这意味着有可能产生更多延迟和连接问题。 DevOps 方法(请阅读下面的内容)可解决其中的许多问题,但采用 DevOps 本身具有挑战性。

然而,这些挑战并不能阻止未采用者采用微型服务 - 也无法阻止采用者深化其微服务承诺。新的 IBM 调研数据表明,56% 的当前非用户可能或很可能在未来两年内采用微服务,而 78% 的当前微服务用户可能会增加他们在微服务方面投入的时间、资金和精力(见图 1)。

显示 56%、78% 和 59% 的三个饼图

图 1:微服务被普遍接受。在未来两年中, 56% 的非用户可能会采用微服务,78% 的用户将增加对微服务的投资,59% 的应用将使用微服务创建。(来源: “企业中的微服务之 2021:切实的益处,值得承受挑战。

微服务支持和需要 DevOps

微服务架构通常被描述为针对 DevOps 和持续集成/持续交付 (CI/CD) 进行优化,并且用于可以频繁部署的小型服务环境中,这很容易理解。

但另一种看待微服务与 DevOps 之间关系的方法是,微服务架构确实需要 DevOps 才能成功。 虽然单体式应用具有本文中先前讨论过的一系列缺陷,但它们的好处是不存在包含多个移动部件和独立技术栈的复杂分布式系统。 相反,鉴于微服务的移动部件和依赖关系所带来的巨大复杂性,如果不在部署、监控和生命周期自动化方面进行重大投资,实施微服务是不明智的。

Andrea Crawford 在以下视频中对 DevOps 进行了深入研究:

关键的支持技术和工具

虽然在微服务架构中可使用任何现代工具或语言,但有少数核心工具已成为微服务不可或缺的一部分:

容器、Docker 和 Kubernetes

微服务的关键要素之一在于,它通常很小。(并没有任意数量的代码确定是否为微服务,但名称中的“微”还是恰如其分的。)

Docker 在 2013 年迎来现代容器时代时,它还提出了与微服务最密切相关的计算模型。 由于各个容器没有自己的操作系统开销,因此它们比传统的虚拟机更小、更轻巧,并且可以更快地缩放,从而能够完美匹配微服务架构中更小、更轻量级的服务。

随着服务和容器数量的激增,精心编排和管理大型容器组迅速成为关键挑战之一。 Kubernetes 是开源容器编排平台,由于出色的功能,已成为最受欢迎的编排解决方案之一。

在视频“Kubernetes 详解”中,Sai Vennam 全面介绍了 Kubernetes 的所有要素:

 

API 网关

微服务通常通过 API 进行通信,尤其是在首次建立状态时。 尽管客户端和服务可以相互直接通信,但 API 网关通常是有用的中介层,特别是当应用中服务的数量随着时间推移而不断增加时。 API 网关充当客户端的逆向代理,在多个服务中传递请求、发出请求,并提供额外的安全性和认证功能。

有多种技术可用于实施 API 网关(包括 API 管理平台),但如果微服务架构是使用容器和 Kubernetes 实现的,那么网关通常使用 Ingress 或更新的 Istio 实现。

消息传递和事件流

虽然最佳实践可能是设计无状态服务,但状态仍然存在,服务需要了解。 尽管 API 调用通常是为特定服务最初建立状态的有效方式,但这并不是保持最新状态的有效方式。 不断的轮询使得服务基本上无法保持最新状态。

相反,需要将状态建立 API 调用与消息传递或事件流耦合,以便服务可以广播状态中的变化,而其他相关方可以侦听这些变化并相应地进行调整。 此作业可能最适合通用消息代理,但也存在适合使用事件流平台(如 Apache Kafka)的情况。 通过将微服务与事件驱动的架构开发人员结合,可以构建高度可扩展的分布式容错系统,能够实时使用和处理大量事件或信息。

无服务器

无服务器架构将某些核心云和微服务模式用于其逻辑结论。 在无服务器的情况下,执行单元不仅仅是一个小型服务,而是一个函数,通常可能只有几行代码。 无服务器函数与微服务的分隔线通常很模糊,但函数通常比微服务更小。

无服务器架构和函数即服务 (FaaS) 平台与微服务的共同点在于都适合创建较小的部署单元以及精确地按需扩展。

微服务和云服务

微服务不一定完全与云计算相关,但有几个重要原因导致它们频繁结合 - 主要原因在于,微服务是新应用的流行架构样式,而云是新应用的热门托管目的地。

微服务架构的主要优势是与单独部署和扩展组件相关的利用率和成本效益。 虽然本地基础架构在某种程度上也存在这些优势,但可单独扩展的小型组件与按使用付费的随需应变型基础架构相结合,可以实现真正的成本优化。

其次,也许是微服务更重要的优点 - 每个单独组件都可以采用最适合自己特定作业的技术栈。 当您自己管理技术栈时,技术栈激增会导致严重的复杂性和巨大的开销,但使用支持栈作为云服务可显着减少管理挑战。 另一方面,虽然并非不可能推出自己的微服务基础架构,但不建议这样做,尤其在刚起步的时候。

常见模式

在微服务架构中,有许多常见和有用的设计、通信和集成模式,有助于应对一些较常见的挑战和机遇,包括:

  • 后端面向前端 (BFF) 模式:此模式在用户体验与体验调用的资源之间插入一层。 例如,在桌面上使用的应用具有与移动设备不同的屏幕大小、显示和性能限制。 BFF 模式支持开发人员使用最适合用户界面的选项,为每个用户界面创建和支持一个后端类型,而不是尝试支持适合任何界面但可能会对前端性能产生负面影响的通用后端。
  • 实体和聚集模式:实体是由其身份区分的对象。 例如,在电子商务站点上,产品对象可能由产品名称、类型和价格区分。 聚集是视为一个单元的相关实体的集合。 因此,对于电子商务站点,订单是买方订购的产品(实体)的集合(聚集)。 这些模式用于以有意义的方式对数据进行分类.
  • 服务发现模式:这些模式帮助应用和服务彼此找到对方。 在微服务架构中,服务实例由于缩放、升级、服务故障甚至服务终止而动态变化。 这些模式提供了发现机制以应对这种转变。 负载均衡可通过使用运行状况检查和服务故障作为重新平衡流量的触发器,使用服务发现模式。
  • 适配器微服务模式:可以像前往其他国家或地区时使用的插头适配器那样考虑适配器模式。 适配器模式的目的是帮助转换原本不兼容的类或对象之间的关系。 依赖于第三方 API 的应用可能需要使用适配器模式来确保应用和 API 可以进行通信。
  • “绞杀者”应用模式:这些模式有助于将单体式应用重构为微服务应用。 五颜六色的名称是指藤(微服务)如何随着时间的推移缓慢地超越和绞杀一颗树(一个单体式应用)。

可在“如何使用开发模式和微服务(第 4 部分)”中了解有关这些模式的更多信息。 如果想要了解其他微服务代码模式,可访问 IBM Developer 中的丰富信息。

反模式

虽然许多模式适合实施微服务,但也有大量的模式可能让开发团队迅速陷入困境。 其中一些如以下“不”规则所述:

  • 微服务的第一条规则是,不构建微服务:更准确地说,是不从微服务开始。 微服务是一种在应用变得过于庞大而不易轻松更新和维护时,用于管理复杂性的方法。 仅当您感到单体式应用的痛苦程度和复杂性开始加剧时,才值得考虑如何将该应用重构为更小的服务。 除非您感到痛苦,否则意味着您甚至没有真正需要重构的单体式应用。
  • 如果没有 DevOps 或云服务,不实施微服务:构建微服务意味着构建分布式系统,而分布式系统很困难(如果您做出更困难的选择,那么这些系统尤其困难)。 如果没有适当的部署和监控自动化功能,并且没有管理云服务来支持目前不断扩展的异构基础架构,那么尝试实施微服务会带来许多不必要的麻烦。 避免麻烦,您就有时间关注状态。
  • 不要实施太小的微服务,导致微服务数量过多:如果在微服务中的“微”方面走得太远,那么您很容易发现开销和复杂性超过微服务架构的总体收益。 最好实施较大的服务,然后在开始开发微服务要解决的特征(即,部署变更变得困难而缓慢;公共数据模型变得过于复杂,或者服务的不同部分具有不同的负载/规模需求)时,才对服务进行分解。
  • 不要将微服务转变成 SOA:微服务和面向服务的架构 (SOA) 通常彼此混合,因为在最基本的层面,它们都适合构建可由其他应用使用的可复用的单独组件。 微服务和 SOA 之间的区别在于,微服务项目通常涉及重构应用,使之更易于管理;而 SOA 则涉及改变 IT 服务在企业范围的工作方式。 变为 SOA 项目的微服务项目很可能被自身“重量”压垮。
  • 不要成为 Netflix:Netflix 是微服务架构的早期开拓者之一,他们构建和管理占所有因特网流量三分一的应用 - 这是一场“完美风暴”,要求他们构建大量的定制代码和服务,而这些代码和服务对于普通应用是不必要的。 您最好从可以适应的节奏开始,避免复杂性,并使用尽可能多的现成工具。

教程: 培养微服务技能

如果您已准备好了解有关如何使用微服务的更多信息,或者如果需要培养微服务技能,请尝试以下某个教程:

微服务和 IBM Cloud

微服务能以现代企业的速度实现创新开发。 了解如何通过将独立微服务部署到云环境中,利用云的可扩展性和灵活性。 在 IBM 的帮助下,了解如何使应用实现现代化。 

采取下一步行动:

立即开始使用 IBM Cloud 帐户