企业云原生之微服务全面解析

微服务与服务网格

1 、单体应用

传统应用系统多为单体应用、经典三层架构部署：“应用 - 数据库 - 中间件”，关于该业务领域的功能实现全部在一个软件工程中进行开发，集成发布打成一个程序包更新，其主要优点为：

（ 1 ）系统整体架构简洁清晰，测试、部署及运维比较简便，中小型项目开发快捷；

（ 2 ）资源占用较低，不需要分布式开销；

单体由于将所有功能模块耦合在一起，导致其存在如下缺点：

（ 1 ）系统耦合度高，容错能力低，小的问题可能导致整体的不可用；

（ 2 ）开发周期长、程序代码冗肿，调试复杂、启动时间慢；

（ 3 ） Bug 修复成本高，每一次线上 Bug 修复需要全局替换、发布；

（ 4 ）扩展性差，应对高并发、高吞吐能力差；

（ 5 ）交付周期长，所有功能一起构建、一起部署、一起发布，代码集成复杂，出错率高；

（ 6 ）对于大型项目以及需求变化频次高的系统，重构是必然。

综合单体应用的优缺点，其比较适合变化频次较低的中小型系统，具体表现为用户量稳定、需求变化不大以及整体开发工程量微小的项目，比较经典的系统有：资产管理系统、资质管理系统、财务系统、人事系统等。

2 、微服务

2.1 微服务基础设施组件

微服务是云原生的主要技术内容之一，是云上应用的主流架构，同时也是应用系统及数据适应云平台的最佳选择。移动互联时代，用户体量及访问量几何式倍增，同时用户需求和行业环境等皆处于快速变化的状态，传统的单体应用受限于其耦合度高、扩展性差、迭代缓慢等缺点已基本不适用与主流应用系统，微服务应运而生。微服务本质上是对传统的单体应用根据业务领域和模块进行划分、解耦，拆分成一个一个单独部署、运行的微小应用。

例：单体销售系统重构微服务商城系统

通过拆分单体应用为微服务，实现对业务系统的充分解耦，可以收获以下优势：

（ 1 ）系统松耦合、服务高内聚，代码聚焦指定业务功能或需求，专注度高；

（ 2 ）系统容错率高，单服务的故障基本不影响整体系统运行，用户体验度高；

（ 3 ）易扩展、可前后端分离，应对高并发、大流量的场景下可以快速扩容服务节点增大吞吐；

（ 4 ）快速迭代、试错成本低，可以实现对业务的快速响应。

微服务技术架构包括网关、注册中心、配置中心、链路监控、流量控制等内容，整体如下：

图：微服务框架

（ 1 ）服务集群， 根据业务功能模块拆分成一个个独自的项目，每个项目完成独自的功能，每个项目又称为独自的服务，每个服务构成了一个服务集群；

（ 2 ）注册中心，应用系统 拆分成多个服务之后，每个服务都有独立的服务信息（ IP 地址、端口以及功能等），如何让对方知悉服务信息，需要注册中心模块对服务进行整体管理。每个服务在注册中心中注册，当用户进行调用服务，它首先到注册中心拉取服务信息再去调用相对于的服务。

（ 3 ）负载均衡，多个服务组成服务集群，在进行服务调用是通过负载均衡分担服务调用流量，实现服务高可用的同时也增加服务的并发吞吐。

（ 4 ）网关，拆分成多个服务之后，涉及到服务之间的调用吧，一个服务调用了三个服务的模块，那在这个服务里，配置三个调用地址，看起来是不是很麻烦呀，所以就出现了网关，所有的服务调用都调用到网关，然后在网关里配置路由，进行服务的转发，类似于代理的作用。当然网关需要配合注册中心进行使用，去发现转发到哪个服务上去。

是为了校验身份和请求路由，负载均衡

（ 5 ）配置中心， 每个服务都会有各自的配置信息，便于统一管理，使用到配置中心，如果想更改服务的配置中心，就在配置中心上进行更改，配置中心会通知相关的服务实现配置的日更新。

除上述 5 大基础组件外，微服务还包括链路监控、流量控制（限流、熔断、降级）、日志管理、以及常用的中间件服务（文件、缓存、消 息队列等）和服务网格等。

链路监控 是实现云原生可观测性的方式之一，应用系统微服务拆分后，服务之间相互调用，前台页面的一个请求往往涉及后端多个服务的调用实现，复杂的调用及实现方式造就了一些列的问题，如：问题定位缓慢、故障影响范围不清以及服务依赖不合理等问题，同时服务调用的性能和实时容量也存在不清晰的地方，相关指标如服务吞吐量 TPS 、服务响应时间、服务调用失败率等难以量化。通过全链路监控从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。有了全链路监控工具，我们能够达到：请求链路追踪，故障快速定位：可以通过调用链结合业务日志快速定位错误信息；可视化：各个阶段耗时，进行性能分析；依赖优化：各个调用环节的可用性、梳理服务依赖关系以及优化。数据分析，优化链路：可以得到用户的行为路径，汇总分析应用在很多业务场景。

流量控制 主要包括流量熔断、限流、降级，是服务实现高性能、高并发、高可用的关键手段之一。熔断是指在服务的依赖调用中， 在服务的依赖调用中，被调用方出现故障时，出于自我保护的目的，调用方会主动停止调用，并根据业务需要进行相应处理。之所以需要熔断，是因为假定服务 A 依赖服务 B ，当服务 B 处于正常状态，整个调用是健康的，服务 A 可以得到服务 B 的正常响应，当服务 B 出现故障时，比如响应缓慢、超时或是直接宕机，如果服务 A 继续请求服务 B ，那么服务 A 的响应时间也会增加，进而导致服务 A 响应缓慢，如果服务 A 不进行熔断处理，服务 B 的故障会传导至服务 A ，最终导致服务 A 也不可用。限流是针对服务请求数量的一种自我保护机制，当请求数量超出服务的处理能力时，会自动丢弃新来的请求。之所以需要限流是因为任何一个系统的处理能力都是有极限的，假定服务 A 的处理能力为 QPS=1000 ，当 QPS<1000 时服务 A 可以提供正常的服务。当 QPS>1000 时，由于请求量增大，会出现争抢服务资源的情况（数据库连接、 CPU 、内存等），导致服务 A 处理缓慢；当 QPS 继续增大时，可能会造成服务 A 响应更加缓慢甚至奔溃，如果不进行限流控制，服务 A 始终会面临着被大流量冲击的风险，做好系统请求流量的评估，制定合理的限流策略，是我们进行系统高可用保护的重要一步。降级是通过开关配置将某些不重要的业务功能屏蔽掉，以提高服务处理能力。在大促场景中经常会对某些服务进行降级处理，大促结束之后再进行复原。之所以需要降级是在不影响业务核心链路的情况下，屏蔽某些不重要的业务功能，可以节省系统的处理时间，提供系统的响应能力，在服务器资源固定的前提下处理更多的请求。

日志管理 也属于可观测性实现方式之一，应用系统服务拆分后，服务、数据库以及中间件等增多，缺乏统一的日志管理将导致问题故障定位复杂、处理时间缓慢等，同时日志缺失、不完整也不符合响应的监管要求。日志管理包括两个方面，一是统一的日志标准，包括日志级别、日志存储位置、日志存储周期等，另一个就是统一的技术架构实现日志采集、日志存储、日志分析、日志展示等。分布式的微服务架构，统一的日志管理平台是必不可少的组件，同时也是提高运维效率和缩短故障定位时间的最佳有效方法之一。

从架构的完整性来说，不管是单体应用还是微服务都需要对中间件进展集中管控的，常用的中间件类型有：消息队列服务、缓存服务、分布式文件服务、任务调度服务、流程引擎服务、搜索服务等。对于中间件的管理主要包括标准统一的高可用部署、性能优化和安全加固、调用与被调用的依赖关系以及配置管理等。

图：微服务组件全家桶

2.2 服务网格

服务网格是用于处理服务间通信的专用基础设施层，负责在微服务间进行可靠地请求传递。服务网格通常通过一组轻量级网络代理来实现，这些代理与应用程序代码一起部署，而不需要感知应用程序本身。随着规模和复杂性的增长，服务网格包含的实现的功能越来越多，它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。其部署结构如下图所示：

图：服务网格部署图

服务网格有如下几个特点：

• 应用程序间通讯的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试 / 超时、监控、追踪和服务发现

如果用一句话来解释什么是服务网格，可以将它比作是应用程序或者说微服务间的 TCP/IP ，负责服务之间的网络访问、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用服务网格也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud 、 OSS ，现在只要交给服务网格就可以了，从而极大地方便了微服务应用的开发。

2.3 微服务技术框架

微服务基础设施组件众多，其实现的技术框架主要有： Dubbo 、 SpringCloud 、 SpringCloudAlibaba 等。

● Dubbo

Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官方提供了 Java 、 Golang 等多语言 SDK 实现。使用 Dubbo 开发的微服务原生具备相互之间的远程地址发现与通信能力，利用 Dubbo 提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。 Dubbo 被设计为高度可扩展，用户可以方便的实现流量拦截、选址的各种定制逻辑。

在国内， Dubbo 实质上算是第一代微服务的经典框架，但自 2014 年暂停更新后，长期止步于 Dubbo2 版本直至 2017 年开源重启、 2021 年推出 3.0 ，至此 Dubbo3 被定义为面向云原生的下一代 RPC 服务框架。 3.0 基于 Dubbo 2.x 演进而来，在保持原有核心功能特性的同时， Dubbo3 在易用性、超大规模微服务实践、云原生基础设施适配、安全性等几大方向上进行了全面升级。 Apache Dubbo 总体架构能很好的满足企业的大规模微服务实践，因为它从设计之初就是为了解决超大规模微服务集群实践问题，不论是阿里巴巴还是工商银行、中国平安、携程等社区用户，它们都通过多年的大规模生产环境流量对 Dubbo 的稳定性与性能进行了充分验证，因此， Dubbo 在解决业务落地与规模化实践方面有以下优势：

开箱即用： 易用性高，如 Java 版本的面向接口代理特性能实现本地透明调用；功能丰富，基于原生库或轻量扩展即可实现绝大多数的微服务治理能力

面向超大规模微服务集群设计： 极致性能，高性能的 RPC 通信协议设计与实现；横向可扩展，轻松支持百万规模集群实例的地址发现与流量治理

高度可扩展： 调用过程中对流量及协议的拦截扩展，如 Filter 、 Router 、 LB 等；微服务治理组件扩展，如 Registry 、 Config Center 、 Metadata Center 等

企业级微服务治理能力： 国内公有云厂商支持的事实标准服务框架；多年企业实践经验考验，参考用户实践案例

Dubbo 核心特性主要有高性能 RPC 通信协议、自动服务（地址）发现 、运行态流量管控、丰富的扩展组件及生态 、面向云原生设计等。

● Spring Cloud

从个人工作经历来看，由于 Dubbo 的多年停更，给了 Spring Cloud 在国内的快速发展期，最起码我所熟悉的 3 家公司在进行系统重构时，皆受限于 Dubbo 的停更转为使用 SpringBoot 并逐渐发展为全套的 Spring Cloud ，当然 Spring Cloud 也是非常优秀的框架组合。

Spring Cloud 是分布式微服务架构的一站式解决方案，它提供了一套简单易用的编程模型，使我们能在 Spring Boot 的基础上轻松地实现微服务系统的构建。 Spring Cloud 被称为构建分布式微服务系统的 “ 全家桶 ” ，它并不是某一门技术，而是一系列微服务解决方案或框架的有序集合。它将市面上成熟的、经过验证的微服务框架整合起来，并通过 Spring Boot 的思想进行再封装，屏蔽调其中复杂的配置和实现原理，最终为开发人员提供了一套简单易懂、易部署和易维护的分布式系统开发工具包。 Spring Cloud 中包含了 spring-cloud-config 、 spring-cloud-bus 等近 20 个子项目，提供了服务治理、服务网关、智能路由、负载均衡、断路器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。 Spring Cloud 本身并不是一个拿来即可用的框架，它是一套微服务规范，共有两代实现：

Spring Cloud Netflix 是 Spring Cloud 的第一代实现，主要由 Eureka 、 Ribbon 、 Feign 、 Hystrix 等组件组成；

Spring Cloud Alibaba 是 Spring Cloud 的第二代实现，主要由 Nacos 、 Sentinel 、 Seata 等组件组成。

Spring Cloud 的常用组件如下表所示：

● Spring Cloud Alibaba

Spring Cloud Alibaba 是阿里巴巴结合自身丰富的微服务实践而推出的微服务开发的一站式解决方案，是 Spring Cloud 第二代实现的主要组成部分。 Spring Cloud Alibaba 吸收了 Spring Cloud Netflix 的核心架构思想，并进行了高性能改进。自 Spring Cloud Netflix 进入停更维护后， Spring Cloud Alibaba 逐渐代替它成为主流的微服务框架。

Spring Cloud Alibaba 包含了多种开发分布式微服务系统的必需组件：

通过 Spring Cloud Alibaba 的这些组件，我们只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。 Spring Cloud Alibaba 的应用场景如下：大型复杂的系统，例如大型电商系统；高并发系统，例如大型门户网站、商品秒杀系统；需求不明确，且变更很快的系统，例如创业公司业务系统等。

Spring Cloud 两代实现组件对比如下：

● 微服务工作流程

以 SpringCloud 为例，参考 CSDN 博主（小陈在这儿、 weixin_55758948 ）的一幅图，简述微服务的工作流程，具体如下：

各个组件的功能作用如下：

Eureka ：各个服务启动时， Eureka Client 都会将服务注册到 Eureka Server ，并且 Eureka Client 还可以反过来从 Eureka Server 拉取注册表，从而知道其他服务在哪里

Ribbon ：服务间发起请求的时候，基于 Ribbon 做负载均衡，从一个服务的多台机器中选择一台

Feign ：基于 Feign 的动态代理机制，根据注解和选择的机器，拼接请求 URL 地址，发起请求

Hystrix ：发起请求是通过 Hystrix 的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题

Zuul ：如果前端、移动端要调用后端系统，统一从 Zuul 网关进入，由 Zuul 网关转发请求给对应的服务

其大致步骤为：

（ 1 ）步骤一：服务注册，每个微服务部署有注册中心的客户端，将该服务的信息注册到注册中心，包括服务名称、地址、端口号等内容；

（ 2 ）步骤二：服务发现，在注册中心完成服务注册后，其他服务即可发现该服务并且根据需要进行调用；

（ 3 ）步骤三：负载均衡，多个服务组成服务集群，其他服务在进行调用的时候需要通过负载均衡调用集群而非单个服务，服务均衡负责同一集群内多个服务的调用策略；

（ 4 ）步骤四：服务调用，即服务在相互间进行调用；

（ 5 ）步骤五：流量控制，服务间调用存在服务不可用、服务达到瓶颈等问题，需要通过熔断、限流、降级等措施处理，确保应用整体可用。

（ 6 ）步骤六：网关路由，系外部应用调用微服务时，通过网关策略路由至具体服务进行响应。

2.4 框架选择建议

关于微服务的框架、组件的选择，建议技术团队内部进行头脑风暴式的讨论，结合各种框架、组件的优劣势以及社区发展趋势，选择最熟悉、最适用的框架及组件。从个人工作经历来看，大致由如下几个小建议：

（ 1 ）配置中心的选择，建议 Nacos Config ，一方面是由于 SpringCloudConfig 过于庞大、复杂，不适用，另一方面 Apollo 处于停更，相比而言 Nacos 更好用、更实用；

（ 2 ）不选择停更的组件，如 Eureka 、 Zuul 、 Hystrix 等；

（ 3 ）分布式任务调度建议 XXL-Job ，比较简便、稳定；

（ 4 ）微服务的基础设施一定要全，链路监控、流量管控、服务网格、任务调度、分布式文件、日志、缓存、消息队列等，并且集群化高可用部署，预置扩容方案及脚本，确保可随时扩展。

由于微服务涉及框架、组件众多，且多为开源社区产品，安全问题需要提前考虑，主要有如下几个方面：

（ 1 ）所用组件类型及版本要有清晰的台账记录，一方面用于根据版本主动查询、监控高危漏洞的情况，另一方面爆出高危漏洞时能够及时判断影响范围；

（ 2 ）建立好漏洞管理机制和补丁修复流程，针对不同漏洞制定不同补丁修复策略（修高危、补中危、观低危）。

2.5 微服务的缺点及难题

微服务提高了应用系统高性能、高并发的能力，并且大幅提高系统吞吐量，也在一定程度上缩短系统开发周期、提高开发效率，但其也增加了应用系统的整体复杂度，为开发、测试、运维及安全等多方面带来一定的难度，相比单体集中式应用，其缺点主要有如下内容：

（ 1 ）架构层面，增加系统架构的复杂度，引入更多的中间件解耦服务之间的共通部分，其服务与中间件以及数据库等的高可用架构变得庞大、复杂；从用户访问到结果返回之间的调用链路变长、节点呈几何级倍增，虽说微服务提高并发、提高性能，但是从访问及调用链路来看，经过节点数量的增加是为性能带了了副作用的。

（ 2 ）开发层面，相比单体集中式应用，开发微服务需要面对复杂的分布式系统，其分布式事务设计以及数据一致性考量需要结合业务实际情况进行充分评估。服务之间的调用需要在开发层面实现基于消息传递或 RPC 的进程间通信机制，同时需要在代码层面增加一定的容错性处理，特别需要考虑有不可靠的网络传输网络延迟、上下游服务延期或不可达类容错性处理、消息序列化、同步以及异步机制选择、服务版本化管理、服务差异化的工作负载等内容。

（ 3 ）测试层面，增加测试的复杂度以及重复测试率，特别是一个服务的修改涉及相关依赖服务的集成测试、回归测试，工作量较大，需要自动化测试支持，同时服务量增加、线上 Bug 增多，测试质量需要被高度重视。

（ 4 ）运维层面，一是大幅增加部署资源来支持服务、中间件以及数据库等高可用集群运行，资源需求量显著增加；二是运维复杂度及难度提升，一方面是运维对象倍增管理复杂，容易失控，另一方面是故障定位迟缓，故障解决时间拉长；三是更新发布量增加，同时发布失败率增加。

（ 5 ）安全层面，微服务及前后端分离增大网络安全攻击面，同时引入的微服务框架、中间件等多基于开源社区，风险隐患较高，设计补丁修复及安全防护成本大幅增加。

总体来说，微服务架构一方面给应用系统高并发、弹性扩展带来便利可以快速支持业务变现，另一方面其复杂度增加了技术及管理成本，需要更多、更专业的人来使用和维护，对开发到运维全流程的自动化、智能化高效工作方法提出急迫的新要求

微服务典型适用于复杂、多变的中大型系统，特别是面向激烈市场竞争的业务场景，而用户稳定、业务流程标准清晰、变化甚微的场景下，简单的单体应用应该更适合。一旦接受微服务，还需要面对如下难点：

（ 1 ）服务拆分颗粒度，如何拆分服务是微服务第一难度，过粗或过细的拆分粒度都将导致一系列的问题，所以微服务的第一步需要明确服务拆分的标准及颗粒度。这在实际工作中，一般会按照业务板块、业务线以及业务模块进行划分并且讨论、确认，另外服务的拆分标准也并非一成不变，根据实际业务变化，服务的拆分及合并也需要动态跟进。这对架构师的业务理解和业务规划有较高的要求。

（ 2 ）微服务基础设施，配置中心、链路监控、容器云平台以及 DevOps 工具链等，通过微服务基础设施推动微服务高效开发、测试以及运维等，提高微服务管理效率，降低复杂度。

（ 3 ）服务依赖，服务内高内聚、服务之间低耦合是微服务拆分的关键目标，但服务之间的调用、依赖不可避免，服务之间的调用及依赖关系如何管理及展现，某一服务的不可用，其上下游影响如何对全局影响如何，是服务管理难点之一。微服务的全链路跟踪监控和云原生可观测性解决方案可以呈现微服务的全调研及依赖关系。

（ 4 ）服务标准及服务治理，随着微服务的开展，服务数量进一步增加、规模进一步扩大，为防止服务管理失控产生不可预测的影响，服务标准与服务治理需提前介入，服务标准及治理覆盖服务全生命周期，包括设计、开发、测试、运维、安全等，同时借助统一架构和服务基础设施进行约束，确保服务安全、可控，并且助力自动化服务管理过程，提高效率和质量。

总之，微服务是企业应用及数据变革升级的利器，也是数字化转型及运营不可或缺的助产工具，企业云原生更离不开微服务，同时云原生的既要最大化发挥微服务的价值，也要最大化弥补微服务的缺陷。