服务化架构模式

SECTION 01

核心定义与本质内涵

定义DEFINITION

服务化架构(Service-Oriented Architecture Pattern) 是云时代构建云原生应用的标准架构模式。它要求以应用模块为颗粒度划分一个软件,以接口契约(如 IDL)定义彼此业务关系,以标准协议(HTTP、gRPC等)确保彼此的互联互通,结合 DDD(领域模型驱动)、TDD(测试驱动开发)、容器化部署提升每个接口的代码质量和迭代速度。

⚑ 关键三要素

颗粒度划分:以应用模块为颗粒度划分软件
接口契约:用 IDL 等定义业务关系
标准协议:用 HTTP、gRPC 等保证互联互通

记忆口诀:模块为粒、契约定关系、协议保互通。

典型模式

服务化架构的典型模式是 微服务(Microservice) 和 小服务(MiniService) 模式:

微服务模式

颗粒度最细,每个服务独立部署、独立数据库、独立技术栈,适合中大型系统。

小服务模式 (MiniService)

可看作一组关系非常密切的服务的组合,这组服务会共享数据。通常适用于非常大型的软件系统,避免接口颗粒度太细导致过多的调用损耗(特别是服务间调用和数据一致性处理)和治理复杂度。

SECTION 02

云原生架构主要架构模式总览

根据教材第14章,云原生架构有非常多的架构模式,其中对应用收益更大的主要架构模式共有七种:

云时代构建云原生应用的标准架构模式,典型为微服务和小服务。

Mesh 化架构模式

中间件框架从业务进程中分离,实现 SDK 与业务代码解耦。

Serverless 模式

将"部署"从运维中收走,应用整个运行委托给云。

存储计算分离模式

各类暂态数据、结构化和非结构化持久数据采用云服务保存。

分布式事务模式

根据场景选择 XA、BASE、TCC、SAGA、SEATA AT 等。

可观测架构

包括 Logging、Tracing、Metrics 三个方面。

事件驱动架构 (EDA)

本质上是一种应用/组件间的集成架构模式。

★ 助记

"服 Mesh 无存事观件" — 服(服务化)、Mesh(Mesh化)、无(Serverless无服务器)、存(存储计算分离)、事(分布式事务)、观(可观测)、件(事件驱动)。

SECTION 03

服务化架构模式详解

3.1 设计要点

颗粒度划分:以应用模块为颗粒度划分软件
接口契约:以接口契约(例如 IDL)定义彼此业务关系
标准协议:以标准协议(HTTP、gRPC等)确保彼此互联互通
方法论结合:结合 DDD(领域模型驱动)、TDD(测试驱动开发)、容器化部署提升代码质量和迭代速度

3.2 核心优势

✓ 服务化架构的双重收益

① 部署经济性:通过服务化架构,把代码模块关系和部署关系进行分离,每个接口可以部署不同数量的实例,单独扩缩容,从而使得整体的部署更经济。

② 迭代高效性:由于在进程级实现了模块的分离,每个接口都可以单独升级,从而提升了整体的迭代效率。

3.3 注意事项与风险

⚠ 服务拆分的代价

服务拆分导致要维护的模块数量增多。如果缺乏:

服务的自动化能力
服务的治理能力

会让模块管理和组织技能不匹配,反而导致开发和运维效率的降低。

SECTION 04

服务化原则(云原生架构七大原则之一)

云原生架构有 7 大架构原则:服务化、弹性、可观测、韧性、所有过程自动化、零信任、架构持续演进。其中服务化原则排在首位:

服务化原则PRINCIPLE 01

当代码规模超出小团队的合作范围时,就有必要进行服务化拆分了,包括拆分为微服务架构、小服务(MiniService)架构。

通过服务化架构把不同生命周期的模块分离出来,分别进行业务迭代,避免迭代频繁模块被慢速模块拖慢,从而加快整体的进度和稳定性。

服务化的两大目的

面向接口编程,高内聚低耦合:服务化架构以面向接口编程,服务内部的功能高度内聚,模块间通过公共功能模块的提取增加软件的复用程度。
抽象关系,标准化流量,实现治理:分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等,本质上都是基于服务流量(而非网络流量)的控制策略。服务化的目的还在于从架构层面抽象化业务模块之间的关系,标准化服务流量的传输,从而帮助业务模块进行基于服务流量的策略控制和治理,不管这些服务是基于什么语言开发的。

⚑ 易考要点

服务化架构治理的本质是基于 "服务流量"(而非网络流量)的控制策略,这是与传统网络治理的根本区别。

SECTION 05

微服务架构(服务化的典型实现)

5.1 微服务的定义

微服务架构MICROSERVICE

微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。

每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 协议的 RESTful API)。

每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。

应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。

5.2 微服务的核心特点

特征 1

小,且专注于做一件事情

按业务领域拆分,单一职责。

特征 2

轻量级的通信机制

通常基于 HTTP RESTful API。

特征 3

松耦合

服务之间相对独立,互不影响。

特征 4

独立部署

每个服务可独立部署到生产环境。

5.3 单体架构 vs 微服务架构

┌──────────────────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ 单体应用架构 │ │ 微服务A│ │ 微服务B│ │ 微服务C│ │ ┌────────────┐ │ └───┬──┘ └───┬──┘ └───┬──┘ │ │ 展示层 │ │ │ │ │ │ ├────────────┤ │ ┌───┴──┐ ┌───┴──┐ ┌───┴──┐ │ │ 业务层 │ │ │数据库A│ │数据库B│ │数据库C│ │ ├────────────┤ │ └──────┘ └──────┘ └──────┘ │ │ 数据访问层 │ │ │ └─────┬──────┘ │ (微服务架构 - 去中心化) │ │ │ · 独立进程 · 独立数据 │ ┌───┴──┐ │ · 独立部署 · 独立技术栈 │ │ 数据库│ │ │ └──────┘ │ └──────────────────┘

SECTION 06

微服务的优势(7 项)

优势	说明
① 技术异构性	每个服务都是相对独立的个体,可以选择适合于自身的技术来实现。可以混合使用多种编程语言、开发框架以及数据存储技术。新技术应用时,完全可以只在一个微服务中采用新技术,熟练后再推广。
② 弹性	系统中一部分出现故障引起多大问题。单块系统中一个部分出问题可能导致整体故障;微服务架构中每个服务可以内置可用性的解决方案与功能降级方案。
③ 扩展	单块系统只能整体扩展;微服务架构可以针对单个服务进行扩展。
④ 简化部署	简单的服务更容易部署,每个服务的部署都是独立的,单个服务出问题不会导致整个系统的故障。可以更快地对特定部分的代码进行部署。
⑤ 与组织结构相匹配	强调模块化结构,可以将架构与组织结构相匹配,避免出现过大的代码库,获得理想的团队大小及生产力。服务的所有权可以在团队之间迁移,避免异地团队问题。
⑥ 可组合性	系统会开放很多接口供外部使用,当情况发生改变时,可以使用不同的方式构建应用。而整体化应用程序只能提供粗粒度的接口。
⑦ 对可替代性的优化	单块系统中删除上百行代码可能引起未知问题;微服务架构中可以在需要时轻易地重写服务,或删除不再使用的服务。

★ 助记 — 微服务七大优势

"异弹扩部组合替" — 异(异构)、弹(弹性)、扩(扩展)、部(部署)、组(组织匹配)、合(可组合)、替(可替代)。

SECTION 07

微服务面临的挑战(6 项)

⚠ "软件开发没有银弹"

微服务并不能解决所有问题,使用微服务架构时可能面临以下挑战:

挑战 1

分布式系统的复杂度

性能方面:服务间通信通过网络,性能受影响;可靠性也受影响;数据一致性需要严格控制,成本比单块高。

挑战 2

运维成本

每个服务都需要独立的配置、部署、监控、日志收集等,运维成本呈指数级增长。

挑战 3

部署自动化

每个服务的修改都需要独立部署。如亚马逊每天数十次甚至上百次部署,人工部署行不通,需要自动化部署流水线。

挑战 4

DevOps 与组织结构

需要传递 DevOps 文化价值,构建全功能团队。开发者承担服务整个生命周期责任(包括部署和监控),运维表现为顾问式角色。

挑战 5

服务间依赖测试

服务数量较多时,如何有效地保证服务之间能有效按照接口的约定正常工作,成为巨大挑战。

挑战 6

服务间依赖管理

微服务个数增多后,如何清晰有效地展示服务之间的依赖关系,成为挑战。

★ 助记 — 微服务六大挑战

"复运部 D 测依" — 复(复杂度)、运(运维成本)、部(部署自动化)、D(DevOps与组织)、测(依赖测试)、依(依赖管理)。

SECTION 08

微服务设计约束(4 类)

设计一个优秀的微服务系统应遵循以下设计约束:

8.1 微服务个体约束

所完成的功能在业务域划分上应是相互独立的。
不同业务域有不同的技术选择权(如推荐系统用 Python 比 Java 更高效)。
微服务对应的团队更小,开发效率更高。
名言隐喻: "一个微服务团队一顿能吃掉两张披萨饼"、"一个微服务应用应当能至少两周完成一次迭代"。
微服务的"微"并不是为了微而微,而是按照问题域对单体应用做合理拆分。
遵循 SOLID 原则中的单一职责原则(SRP, Single Responsibility Principle) — 一个微服务修改或发布时,不应影响同一系统里另一个微服务的业务交互。

8.2 微服务与微服务之间的横向关系

可发现性

当服务 A 发布和扩缩容时,依赖服务 A 的服务 B 如何在不重新发布的前提下自动感知到服务 A 的变化?需要引入第三方服务注册中心来满足。对于大规模微服务集群,服务注册中心的推送和扩展能力尤为关键。

可交互性

服务 A 采用什么样的方式可以调用服务 B。需要采用与语言无关的远程调用协议(如 REST 协议)。在高性能场景下,基于 IDL 的二进制协议可能是更好的选择。

▷ 增强服务韧性

面向失败设计的原则在微服务体系中尤为重要。对于微服务应用个体,限流、熔断、隔仓、负载均衡等增强服务韧性的机制成为标配。为进一步提升系统吞吐能力、充分利用机器资源,可以通过协程、Rx模型、异步调用、反压等手段来实现。

8.3 微服务与数据层之间的纵向约束

数据存储隔离原则 (DSS, Data Storage Segregation):数据是微服务的私有资产,对该数据的访问都必须通过当前微服务提供的 API 来访问。否则造成数据层耦合,违背高内聚低耦合原则。
读写分离 (CQRS):出于性能考虑,通常采取读写分离手段。
无状态设计原则:微服务的设计应当尽量遵循无状态设计。意味着上层应用与底层基础设施的解耦,微服务可以自由在不同容器间被调度。
计算与存储分离:对于有状态微服务,通常使用计算与存储分离方式,将数据下沉到分布式存储,做到一定程度的无状态化。

8.4 全局视角下的微服务分布式约束

从技术上要准备全自动化的 CI/CD 流水线满足开发效率诉求。
支持蓝绿、金丝雀等不同发布策略,满足业务发布稳定性诉求。
面对复杂系统,全链路、实时和多维度的可观测能力成为标配。
从微服务体系多种事件源汇聚并分析相关数据,然后在中心化的监控系统中进行多维度展现。
核心诉求:故障发现时效性和根因精确性。

SECTION 09

常见微服务架构设计模式(6 种)

微服务是一种架构风格,是设计思想而非固定开发模式。开发团队可根据业务场景灵活设计。常见的微服务设计模式有:

9.1 聚合器微服务

▶ 聚合器模式

聚合器调用多个微服务实现系统应用程序所需功能,具体有两种形式:

将检索到的数据信息进行处理并直接展示;
对获取到的数据信息增加业务逻辑处理后,再进一步发布成一个新的微服务作为更高层次的组合微服务(从服务消费者转换成服务提供者)。

变种 — 代理微服务器:客户端并不聚合数据,只会根据实际业务需求差别选择调用具有不同功能的微服务,代理微服务器仅进行委派请求和数据转换工作。也有自己独立的缓存和数据库。

变种 — 分支微服务器模式:客户端或服务允许同时调用两个不同的微服务链。两个微服务调用链相互独立,互不影响。

9.2 链式微服务

▶ 链式模式

客户端或服务在收到请求后,返回一个经过合并处理的响应。例如:服务 A 与服务 B 通信,服务 B 再与服务 C 通信,依次往下游发送,并对结果合并后作为请求响应返回上游。

注意:该模式下所有服务调用都采用同步消息传递方式,完成之前客户端或调用服务会一直阻塞。因此服务调用链不宜过长,避免客户端长时间等待。

9.3 数据共享微服务

▶ 数据共享模式

运用微服务架构重构现有单体架构应用时,SQL 数据库反规范化可能导致数据重复与不一致。按照微服务自治设计原则,在单体到微服务的过渡阶段,可以使用数据共享微服务设计模式。在该模式下,当服务之间存在强耦合关系时,可能存在多个微服务共享缓存与数据库存储的现象。

9.4 异步消息传递微服务

▶ 异步消息模式

目前流行 RESTful 风格的 API,但 REST 设计模式是同步的,容易造成阻塞,耗费大量时间。

消息队列将消息写入队列中,实现业务逻辑以异步方式运行,加快系统响应速度。

权衡:对于不必要以同步方式运行的业务逻辑,可以使用消息队列代替 REST。但该模式可能降低系统可用性、增加系统复杂性,要做好消息队列的选型。

常用消息队列:ActiveMQ、RabbitMQ、RocketMQ、Kafka。

★ 助记 — 设计模式

聚合器(及其变种代理、分支) — 聚 / 代 / 分
其他三种 — 链(链式)、共(数据共享)、异(异步消息)

SECTION 10

微服务与 SOA 的对比

⚑ 核心观点

微服务可以讲是 SOA 的一种,但仔细分析又能发现一些差异。微服务架构是 SOA 架构思想的一种扩展,更加强调服务个体的独立性、拆分粒度更小。

10.1 SOA 与微服务的主要区别

对比维度	SOA 架构	微服务架构
粒度	粗粒度,模块级	细粒度,服务级,更精细
独立性	服务之间相互依赖较强	独立的进程,互相之间并无影响
接口方式	WSDL/SOAP 等较重的协议	HTTP RESTful 等通用方式,无关语言、平台
部署	集中式,依赖 ESB 企业服务总线	分布式去中心化部署
架构中心	ESB(集中式技术架构)	去 ESB,真正意义上去中心化
数据库	不同微服务可共用数据库	不同微服务采用不同数据库,服务独立、数据源唯一
响应速度	应用间交互使用远程通信,响应速度较慢	更快,适合互联网业务场景

10.2 架构演进示意

SOA 架构微服务架构 ═══════════════════ ═══════════════════════ ┌──────┐ ┌──────┐ │ 用户 │ │ 用户 │ └───┬──┘ └───┬──┘ │ │ ┌───┴──┐ ┌───┴──┐ │ UI │ │ UI │ └───┬──┘ └───┬──┘ │ ┌───┬──┴──┬───┐ ┌────┴─────┐ │ │ │ │ │ ESB 企业 │ ┌──┴┐ ┌┴─┐ ┌┴──┐ │ 服务总线 │ │微 │ │微│ │微 │ └─┬──┬──┬─┘ │服 │ │服│ │服 │ │ │ │ │务A│ │务B│ │务C │ ┌─┴┐┌┴┐┌┴┐ └─┬┘ └─┬┘ └─┬─┘ │服││服││服│ │ │ │ │务││务││务│ ┌─┴┐ ┌─┴┐ ┌─┴┐ │A ││B ││C │ │DB│ │DB│ │DB│ └──┘└──┘└──┘ └──┘ └──┘ └──┘ │ (去中心化、独立数据源) ┌───┴────┐ │ 共享数据库│ └────────┘ (集中式、ESB为核心)

10.3 SOA 的微服务化发展三要点

微服务相比于 SOA 更加精细,更多地以独立的进程的方式存在,互相之间并无影响。
微服务提供的接口方式更加通用化,例如 HTTP RESTful 方式,各种终端都可以调用,无关语言、平台限制。
微服务更倾向于分布式去中心化的部署方式,在互联网业务场景下更适合。

SECTION 11

主要微服务技术框架

框架	出身	核心特性
Apache Dubbo	阿里巴巴(开源)	源自阿里巴巴的开源高性能 RPC 框架。基于透明接口的 RPC、智能负载均衡、自动服务注册和发现、可扩展性高、运行时流量路由与可视化的服务治理。国内使用最广泛的微服务框架。
(Dubbo 生态)	阿里巴巴	Spring Cloud Alibaba(分布式应用框架)、Nacos(注册中心&配置中心)、Sentinel(流控防护)、Seata(分布式事务)、Chaosblade(故障注入)。
Spring Cloud	Spring	开发者主要微服务选择之一,提供配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性 Token、全局锁、决策竞选、分布式会话与集群状态管理等能力。
Eclipse MicroProfile	Eclipse	Java 微服务开发的基础编程模型。提供指标、API 文档、运行状况检查、容错与分布式跟踪等能力。可自由部署在任何地方,包括服务网格架构。
Tars	腾讯(开源)	腾讯内部使用的微服务框架 TAF (Total Application Framework) 的开源版本。兼顾多语言、易用性、高性能与服务治理。
SOFAStack	蚂蚁金服(开源)	Scalable Open Financial Architecture Stack。用于快速构建金融级分布式架构的中间件。MOSN 是其组件,是 Go 语言开发的服务网格数据平面代理。
DAPR	微软	Distributed Application Runtime,分布式应用运行时。可移植的、无服务器的、事件驱动的运行时,易于构建弹性、无状态和有状态微服务,运行在云和边缘上。

SECTION 12

关联模式:Mesh化与Serverless

服务化架构往往与其他云原生模式结合使用。以下两种是与服务化模式关联最紧密的:

12.1 Mesh 化架构模式

Mesh 化架构SERVICE MESH

Mesh 化架构是把中间件框架(如 RPC、缓存、异步消息等)从业务进程中分离,让中间件 SDK 与业务代码进一步解耦。从而使得中间件升级对业务进程没有影响,甚至迁移到另外一个平台的中间件也对业务透明。

分离后在业务进程中只保留很"薄"的 Client 部分,Client 通常很少变化,只负责与 Mesh 进程通信,原来需要在 SDK 中处理的流量控制、安全等逻辑由 Mesh 进程完成。

Mesh 化的收益

实施 Mesh 化架构后,大量分布式架构模式(熔断、限流、降级、重试、反压、隔仓等)都由 Mesh 进程完成,即使在业务代码的制品中并没有使用这些三方软件包。同时获得:

更好的安全性(比如零信任架构能力)
按流量进行动态环境隔离
基于流量做冒烟/回归测试

服务网格(Service Mesh)技术

服务网格是分布式应用在微服务软件架构之上发展起来的新技术,旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施,实现应用与平台基础设施的解耦。

开发者无需关注微服务相关治理问题,聚焦于业务逻辑本身
大量非功能性从业务进程剥离到另外进程中
以无侵入方式实现应用轻量化

Istio 服务网格的主要组件

PILOT

Pilot

服务发现、流量管理

MIXER

Mixer

访问控制、可观测性

CITADEL

Citadel

终端用户认证、流量加密

整个服务网格关注:连接和流量控制、可观测性、安全和可运维性。

12.2 Serverless 模式

Serverless无服务器

Serverless 将"部署"这个动作从运维中"收走",使开发者不用关心应用运行地点、操作系统、网络配置、CPU 性能等。

当业务流量到来/业务事件发生时,云会启动或调度一个已启动的业务进程进行处理,处理完成后云自动关闭/调度业务进程,等待下一次触发,把应用的整个运行都委托给云。

Serverless 的 4 项特征

全托管的计算服务:客户只需要编写代码构建应用,无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作。
通用性:结合云 BaaS API 的能力,能够支撑云上所有重要类型的应用。
自动弹性伸缩:让用户无需为资源使用提前进行容量规划。
按量计费:让企业使用成本得有效降低,无需为闲置资源付费。

Serverless 的适用与不适用场景

✓ 适合

事件驱动的数据计算任务
计算时间短的请求/响应应用
没有复杂相互调用的长周期任务

✗ 不适合

有状态的应用(云调度不会做状态同步,可能导致上下文丢失)
长时间后台运行的密集型计算任务(无法发挥 Serverless 优势)
涉及频繁外部 I/O 的应用(网络/存储/服务间调用,负担重、时延大)

FaaS(Function as a Service,函数计算) 是 Serverless 中最具代表性的产品形态。

SECTION 13

考点速记与综合总结

13.1 知识脉络图

┌─── 服务化原则 (云原生7大原则之一) │ ├─── 服务化架构模式 (云原生7大架构模式之一) │ │ 服务化架构 ────┤ ├──── 微服务模式 (典型实现) │ │ ├──── 优势 (7项) │ │ ├──── 挑战 (6项) │ │ ├──── 设计约束 (4类) │ │ ├──── 设计模式 (6种) │ │ └──── 主流框架 │ │ │ └──── 小服务模式 (MiniService) │ ├─── 与 SOA 的对比 (粒度、独立性、协议、部署) │ └─── 关联模式 ├──── Mesh化架构 (中间件下沉) │ └──── Service Mesh (Istio) └──── Serverless (FaaS)

13.2 高频考点速记表

考点	记忆要点
服务化架构的三要素	模块为粒、契约定关系、协议保互通
服务化的典型模式	微服务 + 小服务(MiniService)
小服务适用场景	非常大型的软件系统,避免颗粒度太细的调用损耗和治理复杂度
服务化的两大目的	① 面向接口编程、高内聚低耦合 ② 抽象关系、标准化流量、治理
云原生 7 大原则	服务化、弹性、可观测、韧性、自动化、零信任、持续演进
云原生 7 大架构模式	服务化、Mesh化、Serverless、存储计算分离、分布式事务、可观测、事件驱动
微服务优势(7 项)	异、弹、扩、部、组、合、替
微服务挑战(6 项)	复、运、部、D(DevOps)、测、依
微服务设计模式(6 种)	聚合器、代理、链式、分支、数据共享、异步消息
微服务核心原则	SRP(单一职责)、DSS(数据存储隔离)、CQRS(读写分离)、无状态设计
微服务 vs SOA	更精细 / 更通用 / 更分布式去中心化
Mesh 化核心思想	中间件 SDK 从业务进程分离,业务进程只保留"薄"的 Client
Serverless 关键特征	全托管、通用性、自动弹性伸缩、按量计费

13.3 易混淆概念辨析

⚠ 重点辨析

服务化原则 vs 服务化架构模式:前者是云原生7大原则之一,讲"为什么要服务化";后者是云原生7大架构模式之一,讲"如何服务化"。
微服务 vs 小服务:小服务是一组关系密切的服务的组合,可共享数据;微服务则更细粒度、数据库独立。小服务用于非常大型系统,避免微服务颗粒度太细的损耗。
SOA vs 微服务:微服务是 SOA 的扩展。SOA 集中式(ESB为核心),微服务去中心化(去 ESB)。
Mesh 化 vs 服务网格:Mesh 化是架构模式,服务网格(Service Mesh)是其具体实现技术(如 Istio)。
聚合器 vs 链式:聚合器是一对多的并行调用并聚合;链式是顺序级联调用、同步阻塞。

13.4 综合记忆口诀

★ 终极口诀

"模块为粒、契约定关、协议互通,
微服小服、典型双模,
异弹扩部组合替、复运部D测依,
聚代链分共异步、SRP-DSS-CQRS。"

涵盖:服务化定义 / 典型模式 / 7大优势 / 6大挑战 / 6种设计模式 / 3大核心约束