微服务或微服务架构是一种云原生架构方法，在这种方法中，单个应用程序由很多松散耦合并能够独立部署的更小组件或服务组成。
微服务通常：
- 拥有自己的技术堆栈，包括数据库和数据管理模型。
- 通过代表性状态传输 (REST) API、事件流和消息代理的组合进行相互通信。
- 按业务功能进行组织，具有通常称为有界上下文的服务分隔线。
尽管有关微服务的讨论大多围绕架构定义和特征展开，但通过相当简单的业务和组织优势，我们可以更容易理解微服务的价值：
- 代码更新更容易 - 无需接触整个应用程序即可添加新特性或功能。
- 团队可以对不同的组件使用不同的堆栈和不同的编程语言。
- 组件之间可以独立扩展，从而减少了因单一功能负载过大而不得不扩展整个应用程序所带来的浪费和成本。
哪些对象不属于微服务
通过将微服务与前两种应用程序架构进行对比，也可理解何为微服务：单片架构和面向服务的架构 (SOA)。
微服务和单体架构之间的区别在于微服务由许多较小、松散耦合的服务组成单个应用程序，而非使用大型、紧密耦合应用程序的单体方法。
微服务和 SOA 之间的区别可能不太明显。虽然微服务和 SOA 之间可以进行技术对比，尤其是在企业服务总线的作用方面，但更容易将差异视为范围差异之一。SOA 是一项企业范围的努力，旨在标准化组织中所有 Web 服务相互通信和集成的方式，而微服务架构则是特定于应用程序的。
与对开发人员的受欢迎程度一样，微服务可能至少对高管和项目负责人也一样受到欢迎。这是微服务更加不寻常的特征之一，因为架构热情通常是为软件开发团队而保留的。其中的原因在于：微服务能更好地反映很多企业领导者希望用于构建并运行其团队和开发流程的方式。
换句话说，微服务是一种架构模型，可以更好地促进所需的运营模型。在 IBM 于 2021 年对 1,200 多名开发人员和 IT 主管进行的一项调查中，87% 的微服务用户认同所采用的微服务值得其所投入花费和精力。
下文仅列举微服务为企业带来的部分优点：
可独立部署
微服务最重要的特性可能是由于服务更小且可独立部署，因此不再需要国会法案来更改代码行或在应用程序中添加新功能。
微服务为组织提供了一剂灵药，可以消除与需要花费大量时间的小更改相关的深切挫败感。不需要计算机科学博士学位，就能看到或理解更好地促进速度和敏捷性的方法的价值。
但速度并不是以这种方式设计服务的唯一价值。一种常见的新兴组织模型是围绕业务问题、服务或产品，将跨职能团队聚集在一起。微服务模型恰好契合了这一趋势，因为它使组织能够围绕一项服务或一组服务创建小型的跨职能团队，并让他们以敏捷的方式运营。
微服务的松散耦合还为应用程序建立起一定程度的故障隔离能力以及更出色的弹性。此外，由于各项服务的规模小巧，加之其具有明确的边界和通信模式，从而有助于新的团队成员理解代码库并为其快速做出贡献—这在工作效率和员工士气方面均有明显好处。
适合此项作业的正确工具
在传统的 n 层架构模式中，应用程序通常共享一个公共堆栈，大型关系数据库支持整个应用程序。这种方法有几个明显的缺点 - 其中最重要的就是应用程序的每个组件都必须共享一个公共堆栈、数据模型和数据库，即使对于某些元素来说有一个明确的、更好的工具来完成这项工作。这会导致架构不佳，并且对于不断意识到有更好、更高效的方法来构建这些组件的开发人员来说，这是令人沮丧的。
相比之下，在微服务模型中，组件是独立部署的，并通过 REST、事件流和消息代理的某种组合进行通信，因此每个单独服务的堆栈都有可能针对该服务进行优化。技术一直在发生变化，而由多个小型服务组成的应用程序，在有更先进的技术出现时，更容易与之同步发展，成本也更低。
精确缩放
使用微服务，可以单独部署单个服务，但也可以单独扩展。由此带来的好处是显而易见的：如果正确实施，微服务所需的基础设施比单体应用程序要少，因为它们可以精确扩展需要它的组件，而不是像单体应用程序那样扩展整个应用程序。
微服务也面临若干挑战：
微服务的显著优势伴随着重大挑战。从单体式架构转向微服务意味着更多的管理复杂性 - 更多的服务、由更多的团队创建、部署在更多的地方。一项服务中的问题可能会导致其他服务中的问题。日志数据（用于监控和问题解决）更加庞大，并且不同服务之间可能不一致。新版本可能会导致向后兼容性问题。应用程序涉及更多的网络连接，这意味着出现延迟和连接问题的可能性更大。开发运维方法可以解决许多此类问题，但开发运维的采用也有其自身的挑战。
但是，这些挑战不会阻止非采用者采用微服务，也不会阻止采用者深化其微服务承诺。前述 IBM 调查数据显示，56% 的当前非用户可能或极可能会在未来两年内采用微服务，而 78% 的当前微服务用户则可能会加大对微服务投入的时间、成本和精力。
虽然微服务架构中几乎可以使用任何现代工具或语言，但有一些核心工具已成为微服务必不可少的边界定义：
微服务的关键要素之一是它通常很小。决定某服务是否是微服务不存在一个绝对的代码量限值，但毕竟其名称中有“微”字。
当 Docker 于 2013 年开启现代容器时代时，它还引入了与微服务最密切相关的计算模型。由于单个容器没有自身操作系统的开销，因此它们比传统虚拟机更小、更轻，并且可以更快地启动和关闭，从而与微服务架构中更小、更轻量级的服务完美匹配。
随着服务和容器的激增，协调并管理大量容器迅速成为一项关键挑战。Kubernetes 是一种开源容器编排平台；凭借其出色的编排能力，它已成为最受欢迎的编排解决方案之一。
虽然最佳实践可能是设计无状态服务，但状态仍然存在，服务需要了解它。虽然 API 调用通常是为给定服务初始建立状态的有效方式，但它并不是保持最新状态的特别有效方式。不断进行投票来确认“我们到了吗？”，这种保持服务最新的方法根本不切实际。
相反，有必要将建立状态的 API 调用与消息传递或事件流结合起来，以便服务可以广播状态的变化，其他感兴趣的各方可以侦听这些变化并进行相应的调整。这项工作可能最适合通用消息代理，但在某些情况下，诸如 Apache Kafka 之类的事件流媒体平台可能更合适。通过将微服务与事件驱动型架构相结合，开发人员可以构建分布式、高度可扩展、容错和可扩展的系统，这些系统可以实时使用和处理大量事件或信息。
微服务不一定只与云计算相关，但它们如此频繁地结合在一起有几个重要原因 - 这些原因不仅仅是微服务是新应用程序的流行架构风格，还包括云是新应用程序的流行托管目的地。
微服务架构的主要优势之一是与单独部署和扩展组件相关的利用率和成本优势。尽管这些好处在内部部署基础设施中仍然在一定程度上存在，但小型、独立可扩展的组件与按需、按使用付费的基础设施相结合才能实现真正的成本优化。
其次，也许更重要的是，微服务的另一个主要好处是每个单独的组件都可以采用最适合其特定工作的堆栈。当您自行管理堆栈时，堆栈激增可能会带来同时激增的复杂性和开销，但以云服务方式使用支持堆栈可以大大减少管理难题。换句话说，虽然推出自己的微服务基础设施并非不可能，但这是不可取的，尤其是在刚开始时。
在微服务架构中，有许多常见且有用的设计、通信和整合模式，有助于解决一些更常见的挑战和机遇，包括：
服务于前端的后端 (BFF) 模式
此模式在用户体验和体验调用的资源之间插入一个层。例如在桌面上使用的应用程序将具有与移动设备上不同的屏幕尺寸、显示和性能限制。BFF 模式允许开发人员使用该界面的最佳选项为每个用户界面创建和支持一种后端类型，而不是试图支持可与任何界面配合使用但可能会对前端性能产生负面影响的通用后端。
实体与聚合模式
实体是通过其身份来区分的对象。例如在电子商务网站上，产品对象可能通过产品名称、类型和价格来区分。汇总是相关实体的集合，应被视为一个单位。因此，对于电子商务网站，订单将是买家订购的产品（实体）的集合（汇总）。这些模式用于以有意义的方式对数据进行分类。
服务发现模式
它们可帮助应用程序和服务找到彼此。在微服务架构中，服务实例会因扩展、升级、服务故障甚至是服务终止而动态变化。这些模式提供了应对此类暂时性问题的发现机制。通过将运行状况检查和服务故障用作重新平衡流量的触发器，负载平衡功能可能会使用服务发现模式。
适配器微服务模式
以您对去另一个国家旅行时使用的插头适配器的看法来考虑适配器模式。适配器模式的目的是帮助转换原本不兼容的类或对象之间的关系。依赖第三方 API 的应用程序可能需要使用适配器模式来确保应用程序和 API 可以通信。
Strangler 应用程序模式
这些模式有助于管理将单体应用程序重构为微服务应用程序。这个有趣的名字指的是藤蔓（微服务）是如何随着时间的推移慢慢超越并扼杀大树（单体应用程序）的。
虽然有许多模式可以很好地使用微服务，但也有同样数量的模式可以很快使任何开发团队陷入困境。其中一些微服务“禁忌”如下：
不要构建微服务
更准确地说，不要从微服务开始。当应用程序变得过于庞大和难以驾驭，无法再轻松更新和维护时，微服务就成为管理复杂性的一种方法。只有当您感觉到单体式应用的痛苦和复杂性开始悄悄出现时，才值得考虑如何将该应用程序重构为更小的服务。在感到这种痛苦之前，甚至没有真正需要重构的单体。
不要在没有开发运维或云服务的情况下做微服务
构建微服务意味着构建分布式系统，而分布式系统很棘手，如果做出的选择不当，则分布式系统将更为棘手。尝试在没有适当的部署和监控自动化或托管云服务来支持现在庞大的异构基础设施的情况下实施微服务会带来很多不必要的麻烦。避免这些麻烦，这样您就可以把时间花在考虑状态上。
不要让微服务规模过小而导致数量过多
如果您在微服务中的“微”上走得太远，您很容易发现自己的开销和复杂性超过了微服务架构的整体收益。最好倾向于较大的服务，然后仅在它们开始发展出微服务要解决的特征时才将它们分解 - 即部署变更变得困难且缓慢、通用数据模型变得过于复杂或者服务的不同部分具有不同的负载/规模要求。
不要将微服务转变为 SOA
微服务和 SOA 经常被混为一谈，因为在最基本的层面上它们都对构建可供其他应用程序使用的可重用单个组件感兴趣。微服务和 SOA 之间的区别在于微服务项目通常涉及重构应用程序以使其更易于管理，而 SOA 关注的是改变 IT 服务在整个企业范围内的工作方式。转变为 SOA 项目的微服务项目可能会被自身规模压垮。
不要试图成为 Netflix
Netflix 是微服务架构的早期先驱之一，当时他们构建和管理的应用程序占所有互联网流量的三分之一，这种完美风暴要求他们构建大量普通应用程序不需要的自定义代码和服务。最好从您可以处理的速度开始，避免复杂性，并尽可能多地使用现成的工具。
如果您已准备好了解有关如何使用微服务的更多信息，或者需要提高微服务技能，请尝试以下教程之一：
只需单击一下，即可为您的容器化应用程序部署高度可用、完全托管的 Kubernetes 集群。
跨任何提供商的本地、边缘计算和公有云环境一致地部署和管理容器化应用程序。
将容器映像、批处理作业或源代码作为无服务器工作负载运行，无需调整大小、部署、联网或扩展