微服务

微服务架构——面向服务架构结构风格的一种变体——是一种架构模式，它将应用程序安排为松耦合、细粒度服务的集合，通过轻量级协议进行通信。 它的目标之一是团队可以独立于其他人开发和部署他们的服务。 这是通过减少代码库中的几个依赖项来实现的，允许开发人员在用户有限的限制下发展他们的服务，并向用户隐藏额外的复杂性。 因此，组织能够开发具有快速增长和规模的软件，以及更容易地使用现成的服务。 通信要求降低。 这些好处是以维持解耦为代价的。 需要仔细设计接口并将其视为公共 API。 使用的一种技术是在同一个服务上有多个接口，或者同一个服务有多个版本，以免干扰代码的现有用户。

微服务没有单一的定义。 随着时间的推移，业界形成了一种共识。 一些经常被引用的定义特征包括：

• 微服务架构中的服务通常是通过网络进行通信以使用与技术无关的协议（例如 HTTP）实现目标的进程。
• 服务是围绕业务能力组织的。
• 可以使用不同的编程语言、数据库、硬件和软件环境来实施服务，具体取决于最适合的情况。
• 服务规模小、支持消息传递、受上下文限制、自主开发、可独立部署、去中心化以及通过自动化流程构建和发布。

微服务不是单体应用程序（例如，Web 控制器或前端后端）中的一个层。 相反，它是一个独立的业务功能块，具有清晰的接口，并且可以通过其自己的内部组件实现分层架构。 从战略的角度来看，微服务架构本质上遵循的是 Unix 哲学，Do one thing and do it well。 Martin Fowler 将基于微服务的架构描述为具有以下属性：

• 适合持续交付软件开发流程。 对应用程序一小部分的更改只需要重建和重新部署一个或少量服务。
• 遵守细粒度接口（独立可部署服务）、业务驱动开发（例如领域驱动设计）等原则。

云原生应用程序、无服务器计算和使用轻量级容器部署的应用程序通常采用微服务架构。 根据 Fowler 的说法，由于服务数量众多（与整体应用程序实施相比），分散式持续交付和具有整体服务监控的 DevOps 是有效开发、维护和运营此类应用程序所必需的。 遵循这种方法的结果（和理由）是可以单独扩展各个微服务。 在单体方法中，支持三个功能的应用程序必须整体扩展，即使这些功能中只有一个具有资源限制。 使用微服务，只需要扩展支持资源受限功能的微服务，从而提供资源和成本优化收益。

关于微服务一词的起源有许多说法。2004 年担任 ThoughtWorks 副总裁期间，Fred George 开始研究基于他所谓的以 Jeff Bay 命名的 Baysean 原则的原型架构。

早在 2005 年，Peter Rodgers 在 Web Services Edge 会议的演讲中就引入了术语微 Web 服务。 与传统思维相反，在 SOAP SOA 架构炒作曲线的顶峰，他主张 REST 服务，并在会议演示文稿的幻灯片 #4 上讨论了软件组件是微 Web 服务。

他接着说，微服务是使用类 Unix 管道组成的（Web 遇到 Unix = 真正的松散耦合）。 服务可以调用服务（+多语言运行时）。 复杂的服务程序集被抽象为简单的 URI 接口。 可以公开任何粒度的任何服务。 他描述了一个设计良好的微服务平台如何应用 Web 和 REST 服务的基础架构原则以及类 Unix 调度和管道，以在面向服务的架构中提供根本的灵活性和改进的简单性。

Rodgers 的工作起源于 1999 年惠普实验室的 Dexter 研究项目，其目的是使代码不那么脆弱，并使大规模、复杂的。