微服务（或称微服务架构）是一种云原生架构方法，在单个应用中包含众多松散耦合且可单独部署的小型组件或服务。 这些服务通常：
虽然关于微服务的讨论大多围绕架构定义和特征展开，但通过相当简单的业务和组织优势，可以很容易地理解其价值：
- 代码更容易更新 - 可以直接添加新特性或功能，而不必更新整个应用
- 团队可以对不同的组件使用不同的技术栈和不同的编程语言。
- 组件可以相互独立地扩展，从而减少与必须扩展整个应用相关的浪费和成本（因为单个功能可能面临过多的负载）。
微服务不是什么
我们还可以通过比较两种上述应用架构（单体架构和面向服务的架构 (SOA)）来理解微服务。
微服务与单体架构之间的区别在于，微服务通过许多松散耦合的小型服务组成单个应用，而单体方法则是一个紧密耦合的大型应用。
微服务与 SOA 之间的差异可能并不明显。 虽然微服务和 SOA 之间存在一些技术区别，尤其是企业服务总线 (ESB) 作用方面，但二者更明显的一个区别是范围。 SOA 是企业范围内的工作，旨在使组织中的所有 Web Service 相互之间的通信和集成标准化；而微服务架构则特定于应用。
“SOA 与微服务：有何区别？”这篇帖子做了更详细的介绍。
要了解有关微服务与单体架构之间差异的更多信息，请观看此视频：
微服务在高管和项目负责人中的受欢迎程度可能至少像在开发人员中一样。 这是微服务较为独特的特征之一，因为通常是软件开发团队对架构充满热情。 之所以会这样，是因为微服务更好地反映了许多企业领导所期望的组建并运行团队和开发流程的方式。
另一方面，微服务是一种更有助于实现所期望运营模式的架构模型。 在 IBM 最近对 1200 多位开发人员和 IT 主管展开的调研中，87% 的微服务用户一致认为，花费资金和努力采用微服务是非常值得的。
以下只是微服务为企业带来的几个优势。
可单独部署
也许微服务最重要的特征就是服务规模较小而且可单独部署，因此不再需要大动干戈，以更改代码行或在应用中添加新功能。
微服务为组织带来了有效的解决方案，彻底消除了花大量时间进行小幅更改的困扰。 无需具备计算机科学的博士学位，就能查看或理解有助于提升速度和敏捷性的方法的价值。
但速度并不是以这种方式设计服务的唯一价值。 常见的新兴组织模式是围绕业务问题、服务或产品建立跨职能团队。 微服务模型与这种趋势完全吻合，因为它使组织能够围绕一项服务或一组服务建立小型跨职能团队，并以灵活的方式开展运作。
微服务的松散耦合形式也在应用中建立了一定程度的故障隔离，并提升了安全永续性。 而小型的服务，加上其清晰的边界和通信模式，使新团队成员更容易了解代码库并快速做出贡献，这在加快速度和鼓舞员工士气方面都有明显的好处。
适合作业的工具
在传统的 n 层架构模式中，应用通常共享公共栈，而且由大型关系数据库支持整个应用。 这种方法有几个明显的缺点，其中最重要的缺点是，应用的每个组件都必须共享公共栈、数据模型和数据库，即使对于作业的某些要素有更明确、更理想的工具也不例外。 这样会形成糟糕的架构，对于不断意识到可以用更出色、更有效的方法构建这些组件的开发人员来说，这无疑令人沮丧。
相比之下，在微服务模型中，组件单独部署，并通过 REST、事件流和消息代理的某些组合进行通信，因此可以针对每个单独服务优化该服务的技术栈。 技术改变了一切，随着令人向往的技术成为现实，由多个较小的服务组成的应用也变得更简单、成本更低。
精确缩放
通过微服务，各个服务可以单独部署，也可以单独扩展。 最终效益十分明显：如果实施得当，微服务所需的基础架构比单体式应用更少，因为它们能够仅精确扩展需要它的组件，而不是像单体应用那样需要扩展整个应用。
但也存在挑战
微服务的显著收益也伴随着重大挑战。 从单体架构迁移到微服务意味着管理复杂性显著增加 - 更多团队创建了更多服务并部署在更多位置。 一个服务中的问题可能会导致其他服务中的问题。 日志记录数据（用于监视和问题解决）更加庞大，并且在各个服务中可能不一致。 新版本可能会导致向后兼容性问题。 应用涉及更多网络连接，这意味着有可能产生更多延迟和连接问题。 DevOps 方法（请阅读下面的内容）可解决其中的许多问题，但采用 DevOps 本身即具有挑战性。
尽管如此，这些挑战也没能阻止未采用者去采用微服务，同时也没能阻止采用者加强他们的微服务承诺。 最近的 IBM 调查数据表明，当前 56% 的非用户可能或很可能在未来两年内采用微服务，而 78% 的现有微服务用户可能会增加他们在微服务方面投入的时间、资金和精力。
虽然在微服务架构中可使用任何现代工具或语言，但有少数核心工具已成为微服务不可或缺的一部分：
容器、Docker 和 Kubernetes
微服务的一个关键元素是它通常很小。 （关于微服务所含的代码量并没有明文规定，但其名称中确实包含了“微”字）。
当 Docker 于 2013 年开创了现代容器时代时，它还引入了与微服务最密切相关的计算模型。 由于各个容器没有自己的操作系统开销，因此它们比传统的虚拟机更小、更轻巧，并且可以更快地增加或减少，从而能够完美匹配微服务架构中更小、更轻量级的服务。
随着服务和容器数量的激增，编排和管理大型容器组迅速成为关键挑战之一。 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 是微服务架构的早期开拓者之一，他们构建和管理占所有互联网流量三分一的应用 - 这是一场“完美风暴”，要求他们构建大量的定制代码和服务，而这些代码和服务对于普通应用是不必要的。 您最好从可以适应的节奏开始，避免复杂性，并尽可能地使用更多的现成工具。
如果您已准备好了解有关如何使用微服务的更多信息，或者需要培养微服务技能，请尝试阅读以下某个教程：