什么是微服务?

Open source resources

Opensource.com

微服务背后的核心思想是,某些类型的应用程序如果分解成更小、可组合的、协同工作的部分,则会更容易构建和维护。每个组件都持续开发和单独维护,然后应用程序只是其组成组件的总和。这与传统的“单体”应用程序形成对比,后者是作为一个整体开发的。

构建为一组模块化组件的应用程序更易于理解、更易于测试,最重要的是在应用程序的生命周期内更易于维护。它使组织能够实现更高的敏捷性,并能够大大缩短将有效改进投入生产所需的时间。事实证明,这种方法是更优越的,特别是对于由地理位置和文化背景各异的开发团队开发的大型企业应用程序而言。

还有其他好处

  • 开发者独立性:小型团队并行工作,迭代速度比大型团队更快。
  • 隔离和弹性:如果一个组件崩溃,您可以快速启动另一个组件,而应用程序的其余部分继续运行。
  • 可扩展性:较小的组件占用更少的资源,并且可以扩展以满足仅该组件不断增长的需求。
  • 生命周期自动化:单个组件更容易融入持续交付管道和复杂的部署场景,这对于单体应用来说是不可能的。
  • 与业务的关系:微服务架构沿着业务领域边界划分,从而提高整个组织的独立性和理解。

微服务的通用定义通常依赖于每个微服务提供一个 API 端点,通常但不总是无状态 REST API,可以通过 HTTP(S) 访问,就像标准网页一样。这种访问微服务的方法使开发人员可以轻松使用它们,因为它们只需要许多开发人员已经熟悉的工具和方法。

这是一个新概念吗?

将应用程序分成更小部分的想法并不新鲜;还有其他编程范例也解决了相同的概念,例如面向服务的架构 (SOA)。然而,最近的技术进步以及对集成“数字体验”日益增长的期望,催生了用于满足现代业务应用程序需求的新一代开发工具和技术。

微服务不仅依赖于技术设置来支持这个概念,还依赖于组织拥有文化、技术和结构,以便开发团队能够采用这种模型。微服务是 IT 部门向 DevOps 文化更大转变的一部分,在这种文化中,开发和运维团队紧密合作,在其生命周期内支持应用程序,并经历快速甚至持续的发布周期,而不是更传统的长周期。

为什么开源对于微服务很重要?

当您从头开始设计应用程序以使其模块化和可组合时,它允许您在许多地方使用即插即用组件,而在过去,您可能需要专有解决方案,要么是因为组件的许可,要么是因为特殊的要求。许多应用程序组件可以是现成的开源工具,并且有无数开源项目实现了微服务架构的跨领域需求,例如身份验证、服务发现、日志记录和监控、负载均衡、扩展等等。

关注微服务也可能使应用程序开发人员更容易为您的应用程序提供替代接口。当一切都是 API 时,应用程序组件之间的通信变得标准化。组件要使用您的应用程序和数据所需要做的就是能够通过这些标准 API 进行身份验证和通信。这允许组织内部以及适当情况下组织外部的人员轻松开发利用您的应用程序数据和服务的新方法。

容器技术在哪里发挥作用?

现代轻量级操作系统容器的概念是在 2000 年代初期作为 FreeBSD 项目的一部分引入的。Docker 提供了改进的用户体验,用于创建和共享容器镜像,因此从 2013 年开始得到了广泛采用。容器与微服务天然契合,满足了对轻量级和灵活组件的需求,这些组件可以轻松管理和动态替换。与虚拟机不同,容器旨在精简到运行容器旨在执行的一件事所需的最小可行部分,而不是将多个功能打包到同一虚拟机或物理机中。Docker 和类似工具提供的开发便利性有助于实现服务的快速开发和测试。

当然,容器只是一种工具,微服务架构只是一种概念。完全有可能构建一个可以描述为遵循微服务方法的应用程序,而无需使用容器,就像在容器内部构建一个更传统的应用程序也是可能的,当您想利用容器编排功能而无需重写大型单体应用程序时,这可能是有意义的。

如何编排微服务?

为了实际运行基于微服务的应用程序,您需要能够监控、管理和扩展不同的组成部分。有许多不同的工具可能允许您完成此操作。对于容器,像 Kubernetes 这样的开源工具可能是您解决方案的一部分。或者,对于应用程序的非容器部分,可以使用其他工具来编排组件:例如,在 OpenStack 云中,您可以使用 Heat 来管理应用程序组件。

另一种选择是使用平台即服务 (PaaS) 工具,该工具使开发人员可以专注于编写代码,通过抽象一些底层编排技术,并允许他们轻松地为应用程序的某些部分选择现成的开源组件,例如数据库存储引擎、日志服务、持续集成服务器、Web 服务器或拼图的其他部分。一些 PaaS 系统(如 OpenShift)直接使用 Docker 和 Kubernetes 等上游项目来管理应用程序组件,而另一些系统则尝试自行重新实现管理工具。

现有应用程序呢?

虽然利用微服务可能是组织未来 IT 战略的重要组成部分,但肯定有许多应用程序不符合此模型,而且这些应用程序也不太可能在一夜之间重新架构以满足这种新范式。迁移到微服务架构存在文化和技术成本,但幸运的是,微服务和传统应用程序可以在相同的环境中协同工作,前提是组织拥有可靠的双模 IT 战略。

根据 Gartner 的说法,双模 IT 是指能够交付传统 IT 应用程序(侧重于稳定性和正常运行时间)以及通过更新的方法(包括开发人员自助配置机器和短开发周期等能力)交付更新、更敏捷但可能未经充分测试的应用程序的能力。

许多甚至大多数组织都需要适应在未来许多年内与这两种方法一起工作。

在哪里可以了解更多信息?

Opensource.com 为那些有兴趣了解更多可能成为面向微服务的应用程序一部分的不同工具和设计模式的人们提供了许多资源。以下是我们建议您查看的一些内容


想要掌握微服务吗?了解如何在自定进度的动手实验环境中运行 OpenShift 容器平台。

Creative Commons License本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.