微服务

SOA架构的一种变体

微服务（或称微服务架构）是一种云原生架构方法，在单个应用中包含众多松散耦合且可单独部署的小型组件或服务。这些服务通常拥有自己的技术栈，包括数据库和数据管理模型；通过一个REST API、事件流和消息代理组合彼此通信；以及按照业务能力进行组织，具有通常称为有界上下文的服务分隔线。

架构特点

微服务架构最经常得出的两个比较是整体架构和面向服务的架构（SOA）。

微服务和整体架构之间的区别在于，微服务由许多较小的，松散耦合的服务组成一个应用程序，与大型，紧密耦合的应用程序的整体方法相反。

微服务和SOA之间的差异可能不太清楚。虽然可以在微服务和SOA之间形成技术对比，尤其是围绕企业服务总线（ESB）的作用，但将差异视为范围之一更容易。SOA是企业范围内的一项工作，旨在标准化所有服务之间相互交流和集成的方式，而微服务体系结构则是特定于应用程序的。

微服务在管理人员和项目负责人中至少与在开发人员中一样受欢迎。这是微服务的较不寻常的特征之一，因为架构热情通常是为实际工程师保留的。这样做的原因是微服务更好地反映了许多业务主管想要组建和运行其团队以及开发流程的方式。换句话说，微服务是一种架构模型，可以更好地促进所需的运营模型。

独立部署

微服务的最重要的单一特征可能是，由于服务较小且可独立部署，因此不再需要繁琐的行动才能更改应用程序中的一行文字。

微服务向组织承诺了解决方案，以解决因细微变化而引起的内在挫折，这需要花费大量时间。在计算机科学中可以看到或理解更好地促进速度和敏捷性的方法的价值。

但是，速度并不是以这种方式设计服务的唯一价值。一种常见的新兴组织模型是将跨职能的团队聚集在业务问题，服务或产品上。微服务模型非常适合这种趋势，因为它使组织能够围绕一项服务或一组服务创建跨职能的小型团队，并使它们以敏捷的方式运作。

最后，服务的小规模加上清晰的边界和沟通模式，使新团队成员更容易理解代码库并快速做出贡献，这在速度和员工士气方面均具有明显的好处。

在传统的n层体系结构模式中，应用程序通常共享一个公共堆栈，而大型关系数据库支持整个应用程序。这种方法有几个明显的缺点-最主要的缺点是，即使对于某些元素有一个清晰，更好的工具，应用程序的每个组件也必须共享一个公共的堆栈，数据模型和数据库。它造成了糟糕的体系结构，并且使开发人员感到沮丧，他们不断意识到可以使用更好，更有效的方式来构建这些组件。

相比之下，在微服务模型中，组件是独立部署的，并通过REST，事件流和消息代理的某种组合进行通信-因此，可以针对该服务优化每个单独服务的堆栈。技术一直在变化，由多个较小的服务组成的应用程序随着更理想的技术的发展而变得更容易且成本更低。

精确缩放

使用微服务，可以单独部署单个服务，但是也可以单独扩展它们。由此带来的好处是显而易见的：如果正确完成，微服务比单片应用程序所需的基础结构要少，因为微服务仅支持对需要它的组件进行精确缩放，而对于单片应用程序则不需要整个应用程序。

技术工具

尽管几乎任何现代工具或语言都可以在微服务体系结构中使用，但仍有一些核心工具已成为微服务必不可少的基本定义：

容器

微服务的关键要素之一是它通常很小。（没有任意数量的代码来确定某项内容是否为微服务，但名称中恰好有“微”字。）

当Docker的容器技术迎来了2013年，它也推出了计算模型，将成为微服务最密切相关。由于单个容器没有自己操作系统的开销，因此它们比传统虚拟机更小，更轻，并且可以更快地上下旋转，从而使其与微服务架构中的更小，更轻便的服务完美匹配。

随着服务和容器的激增，对大型容器进行编排和管理很快成为关键挑战之一。Kubernetes已经成为世界上最受欢迎的容器编排技术之一，因为它做得很好。

API网关

微服务通常通过API进行通信，尤其是在首次建立状态时。虽然确实可以实现客户端和服务之间的直接通信，但API网关通常是有用的中介层，尤其是随着应用程序中服务数量的不断增长。API网关通过路由请求，将请求散布到多个服务中并提供额外的安全性和身份验证，充当客户端的反向代理。

有迹象表明，可用于执行API网关，包括API管理平台的多种技术，但如果正在使用集装箱和Kubernetes实现的微服务架构中，网关使用的入口或更近，通常实现Istio。