下载掌阅APP，畅读海量书库
立即打开
微服务（microservices）是一种软件架构风格，将复杂的应用程序拆分成一系列专注于单一责任与功能的服务，各服务之间使用对外开放不受语言限制的API进行交互。
与微服务相对的一种传统架构是单体架构，早期互联网应用功能较为单一，多采用这种单体架构，即一个应用程序内包含了所有需要的业务功能，并使用主从式架构或多层次架构实现。显然，单体架构具有部署简单、技术单一、易于测试等优点，至今小型项目开发等应用场景下仍然占有巨大优势。然而，随着互联网规模的不断扩大，面对中大型项目复杂的应用形态，单体架构存在着扩展性差、技术升级困难、开发效率低、不利于安全管理等问题，具体而言：
❑扩展性差：单体架构中应用功能之间耦合度高，一个功能点的变更所带来的影响往往难以评估，无法有效地组织测试，测试与发布都需要整体部署，非常耗时。
❑技术升级困难：如果整个项目周期内需要对技术框架或类库版本等升级，由于单体架构无法模块化地进行升级，牵一发而动全身，导致技术升级困难。
❑开发效率低：每个成员都需要有完整的环境依赖，开发环境的搭建成本高，协同开发时容易存在版本冲突，每次调试都需要对整个系统进行编译，这都使得整体的开发效率降低。
❑不利于安全管理：由于所有开发成员都拥有完整的代码，项目的安全管理存在一定的风险。
为了应对这些问题而产生了微服务架构。微服务的概念于2014年由Martin Fowler与James Lewis共同提出，定义了微服务架构是以一组由单一应用程序构成的微服务集群共同开发一个应用系统 [16] 。每个微服务都拥有自己的进程和轻量化处理，服务功能根据应用业务设计，可以使用不同的编程语言和数据库存储技术，与其他服务之间使用HTTP等通信协议和轻量级API来实现通信。这些微服务能够通过自动化部署工具独立发布，并且会保持最小规模的集中管理。图3-8展示了传统单体架构和微服务架构的区别。
图3-8 单体架构和微服务架构对比图
与单体架构相比，微服务架构具有以下特点：
❑实现应用组件化：微服务架构通过将整体应用切分为多个可独立部署和升级的微服务，从而能够进行组件化设计，对单个组件的修改也不会影响到整个应用系统。
❑围绕业务功能组织团队：微服务架构根据业务功能将整个系统分解为多个微服务，每个微服务团队可以专注于此服务的独立开发，自由选择符合服务API契约的各种开发技术，具有更高的灵活度。
❑基础设施自动化：为了确保持续交付，利用基础设施自动化技术极大降低微服务构建、部署和运维的成本。
❑故障处理设计：由于微服务架构将单个应用拆分为多个组件，这使得发生故障的概率大大提升，因此必须要应用系统的容错能力。微服务架构通常采用对相关指标进行实时监控以及日志机制来发现问题，以便后续开发团队进行调查恢复。
❑演进式设计：微服务应用注重快速更新，因此通常采用演进式设计，并将对完整应用的分解视为一个额外的工具，使得开发人员能够在一定范围内控制变化。
微服务架构虽然具有部署简单、可扩展性强、组合灵活、可靠性高和支持技术异构等优点，但仍然存在着一些不足之处。首先，微服务架构构建的是一个分布式系统，分布式系统在系统容错、网络延迟和事务调度等方面会带来巨大的挑战。其次，微服务之间都通过接口进行交互，当某个微服务的接口发生改动时，所有的调用方都会受到影响，因此，接口的调整成本较高。此外，采用微服务架构的系统由多个独立的微服务构成，微服务越多，对服务的管理、部署将会变得越复杂，这使得运维的成本也随之提升。
目前业界已经出现了一些比较成熟的微服务开发框架，如Spring Cloud、Dubbo等，然而它们都只适用于特定的应用场景和开发环境，设计之初并不是为了支持通用性和多语言性，开发人员需要将原有的业务代码进行修改才能正常工作。因此便出现了称作第二代微服务的服务网格（service mesh），它作为服务间通信的基础设施层，负责服务的网络调用、限流、熔断和监控等问题，一定程度上解决了微服务架构在实际部署中所面临的各类挑战。