本文作者：何文强 — CODING 高级解决方案架构师 具有一线互联网、物联网独角兽、全国股份制银行、新型智慧交通等跨行业从业经历，历任 Java 开发高级工程师、DevOps 技术专家、高级研发经理等职，对微服务、敏捷、DevOps、容器技术有深刻的理解和丰富的实践。
微服务架构
在 2010s 进入移动互联网（web3.0）时代，互联网用户规模再次迎来井喷式增长，面向服务的技术架构在服务海量规模用户时显得力不从心。SOA 架构中 ESB 存在单点以及 RPC 中缺少服务的治理能力，ESB 和 RPC 架构都很难满足移动互联网海量用户的要求，微服务开始出现，并成为今天技术架构的主流。
定义
微服务是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的 API 集相互通信。
微服务架构实现了系统解耦和持续集成，有清晰的服务边界，粒度相对 ESB 架构和传统 SOA 架构来说更小，使用轻量级的通讯机制交互，具备更强的扩展性和弹性，能够更灵活、更快响应业务变化。
微服务架构演进过程
微服务架构：
有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。
SOA（Service Oriented Architecture）“面向服务的架构”：
他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。
微服务架构与 SOA 架构类似，微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过旁路注册中心而非企业总线完成交互和集成。
NFRs（非功能性需求）
是指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求。和非功能性需求相对的是功能需求，后者会定义系统特定的行为或功能。非功能性需求也可以视为为了满足客户业务需求而需要符合，但又不在功能性需求以内的特性。
常见的非公能性需求按角色关注可分为：
- 开发侧
熔断、限流、降级、链路追踪、路由鉴权、安全加密。
- 平台侧
高可用、高并发。
- 运维侧
灰度发布、蓝绿发布、金丝雀发布、弹性伸缩、快速回滚。
分布式中间件
中间件（英语：Middleware），又译中介层，是一类提供系统软件和应用软件之间连接、便于软件各部件之间的沟通的软件，应用软件可以借助中间件在不同的技术架构之间共享信息与资源。中间件位于客户机服务器的操作系统之上，管理着计算资源和网络通信。
分布式中间件大致可分为：
- 服务调用框架
服务调用框架是微服务间进行通信的桥梁，管理东西流量。常见的服务框架如 Dubbo、gRPC、Thrift 等。
- 服务注册与发现
服务注册与发现主要为服务提供方和服务调用方提供服务地址动态寻址的能力，通过 DNS 或者 restful 接口的方式来注册服务和发现服务。服务可根据实际情况自行选择。常见的服务注册与发现中间件有 Zookeeper、Etcd、Consul、Eureka 等。
- 分布式网关
网关是流量的入口，负责服务路由转发和过滤，管理南北流量。常见的网关有 Nginx、Zuul、SpringCloud Gateway 等。
- 分布式消息队列
消息队列是一种异步的服务间通信方式，适用于无服务器和微服务架构。消息队列可为这些分布式应用程序提供通信和协调。常见的分布式消息队列中间件有 ActiveMQ、Kafka、RabbitMQ、RocketMQ、Pulsar 等。
- 分布式配置
应用程序在启动和运行的时候往往需要读取一些配置信息，配置基本上伴随着应用程序的整个生命周期。分布式配置是将配置信息存储到远端，对配置进行统一管理，在应用启动或运行时会将配置从远端下发到应用。常见的分布式配置中心中间件有 Apollo、Nacos、ConfigServer 等。
- 分布式事务
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单理解跨系统的事务成为分布式事务。常见的分布式事务中间件有 Seata、JDTX、LCN 等。
- 分布式数据库中间件
分布式数据库中间件，使用云数据库（RDS）作为存储引擎，具备自动部署、分库分表、弹性伸缩、高可用等全生命周期运维管控能力。专注于解决数据库分布式扩展问题，突破了传统数据库的容量和性能瓶颈，实现海量数据高并发访问。常见的分布式数据库访问有 ShardingSphere、Vitess 等。
- 分布式数据库
分布式数据库是指利用高速计算机网络将物理上分散的多个数据存储单元连接起来组成一个逻辑上统一的数据库。分布式数据库的基本思想是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量。常见的分布式数据库有 Spanner、TiDB、TDSQL、OceanBase 等。
- 分布式缓存
分布式缓存是传统单机缓存概念的一个延伸，用于表示能跨越多台服务器，同时具有可扩展性的缓存。常见的分布式缓存中间件有 Redis、Memcached 等。
- 分布式任务调度
任务调度是指系统为了自动完成特定任务，在约定的特定时刻去执行任务的过程。分布式任务调度是在分布式环境下高性能、高可用、可扩展的分布式任务调度框架。常见的分布式任务调度中间件有 Elastic-job、Xxl-job、Saturn、Schedule X 等。
- 分布式追踪
分布式跟踪是一种由跟踪工具实现的方法，用于跟踪、分析和调试跨多个软件组件的事务。通常情况下，分布式跟踪会游历多个服务，这要求它是唯一可识别的。跟踪上下文的传播依托于这个唯一标识。常见的分布式追踪中间件有 Zipkin、Jaeger、Opentracing 等。
微服务架构模型
应用主要包含业务逻辑，非功能性需求（NFR）和三方库依赖（如数据库、缓存、消息等中间件）。
在 SOA 架构中，应用除了需要实现业务逻辑之外，还需要自行解决上下游寻址、通讯，以及容错等问题。随着微服务规模扩大，服务寻址逻辑的处理变得越来越复杂，非功能性需求（NFR）和三方库等基础能力无法复用，存在大量的重复能力建设。
在微服务架构中，引入了旁路服务注册中心作为协调者来完成服务的自动注册和发现。服务之间的通讯以 及容错机制开始模块化，形成独立服务框架。
微服务架构开始具备部分 NFR 和三方依赖的能力，框架本身开始提供部分能力，其余部分有框架进行集成，通常是通过 lib 库和 SDK 的方式进行集成。
微服务技术架构
微服务是典型的分布式应用，当一个应用微服务化后，就具有分布式应用的特点和挑战。当应用被微服务化后，首先需要解决的是服务间的通信问题（图中的 ①），目前业界主流的通信方式有两种，一种是通过 RPC 进行通信（如 Dubbo）；一种是通过 Http 协议的 Restful API 进行通信（如 SpringCloud），服务间通信解决应用东西流量（从左往右）问题。
为了应对海量的用户和并发，应用单实例无法满足系统要求，每个应用都会运行多个实例（副本），因此应用需要具备负载均衡的策略（图中的 ②），通过负载算法将流量负载到不不同的实例上，常见的负载均衡算法有轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接数法、权重法等。
通常微服务中的每个应用都有自己的数据库，在进行跨应用间的通信时，可能会对不同应用的数据库同时进行事务操作，出现跨库事务操作，这里面就涉及到分布式事务（图中的 ③），解决分布式事务的解决方案有两阶段提交（2 PC）、三阶段提交（3 PC）、TCC（Try、Confirm、Cancel）、Saga 等。在分布式事务开发过程中，为提升效率和降低难度，通常会引入分布式事务中间件（框架）来解决，例如 Seata、LCN 等。
每个应用的可提供服务的实例数量会动态变化（服务器节点故障实例不可用、实例上下线等），一个应用（应用 A）调用另一个应用（应用 B）时，需要能够正确感知到被调用应用（应用 B）的可提供调用的实例，这时就需要机制来保障服务能够被动态的发现和调整实例数，这就需要服务注册与发现（图中的 ④），通过服务注册与发现，调用方（消费者）能够动态获取被调用方（生产者）的可用的复杂实例地址。
微服务包含一组应用，当我们需要对多个服务进行统一的流量管理、路由和过滤时，需要引入网关（图中的 ⑤），网关解决应用的南北流量（从上到下）问题，可通过网关进行微服务应用的流量管理、鉴权、服务路由。
分布式应用带来了分布式日志。分布式应用多个实例分布在还不同的服务器上，每个实例都会产生日志，需要对分布在不同服务器的实例日志进行统一的收集、存储和展示，这就需要分布式日志收集工具（图中的 ⑥）。常见的分布式日志收集工具有 logstash、fluentd、loki 等，常见解决方案有 ELK、EFK 等。除了日志外，应用间调用性能和调用链成为微服务开发中的一个痛点，因此需要对应用的调用链和性能进行可视化追踪，还需要一些 APM（应用性能）工具对服务间的调用进行可视化和性能分析，常见的 APM 工具有 Zipkin、Jaeger、Skywalking 等。
随着应用安全意识和能力的增强，满足安全合规的要求，加强配置信息的统一维护和管理，需要将存储在应用配置文件中的敏感信息（例如数据库配置信息等）与代码分离（云原生应用 12 特征之一），并且存储在远端，进行统一的管理和权限设置，分布式配置中心可以很好的解决这个问题（图中的 ⑦），常见的分布式配置中间件有 Apollo、Nacos、Etcd、Config Server 等。
伴随着系统的长期服务和用户的稳定增长，应用产生和积累的数据越来越多，单个数据库不能满足海量数据存储的需求，业界主流的方案采用分而存之（图中的 ⑧），分而存之有两种方式，一种是在 DDL 层做分库分表操作，将一个大的数据库拆分成多个数据库，通过数据库链接代理来进行分库和路由，典型的中间件有 ShardingSphere、Vittes 等；另一种方案是采用采用分布式数据库，分布式数据库封装所有分布式细节，用户不需要在数据库访问层做代理或添加路由逻辑，像使用传统数据库一样使用分布式数据库，典型的中间有 TiDB、Spanner 等。分布式数据库属于新型数据库，目前还处于快速发展期，有着广阔的前景。
微服务框架与能力
Java 是目前最流行的服务端语言，Java 现阶段主流的服务框架是 Dubbo 和 SpringCloud。接下来将对 Dubbo 和 SpringCloud 两个 Java 微服务框架做介绍。
Dubbo
Apache Dubbo 是一款高性能、轻量级的开源服务框架。Dubbo 提供六大核心功能：
- 面向接口代理的高性能RPC调用；
- 智能容错和负载均衡；
- 服务自动注册与发现；
- 高度可扩展能力；
- 运行期流量调度；
- 可视化的服务治理与运维。
Dubbo 架构
- Provider：暴露服务的服务提供方
- Consumer：调用远程服务的服务消费方
- Registry：服务注册与发现的注册中心
- Monitor：统计服务的调用次数和调用时间的监控中心
- Container：服务运行容器
Dubbo 能力
在 Dubbo 框架中，Dubbo 具有服务自动注册与发现、服务间的通信等中间件能力，具有路由鉴权、负载均衡、灰度发布、蓝绿部署（服务器节点级别）、以及服务治理等非功能性需求（NFRs）能力。但是大部分的中间件能力和 NFR 能力是缺失的，需要用户通过 lib 或 SDK 的方式在业务代码中进行集成。如下图：
SpringCloud
Spring Cloud 为开发者提供了快速构建分布式系统中一些常用模式的工具（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态）。分布式系统的协调导致了样板模式，使用 Spring Cloud 开发人员可以快速建立实现这些模式的服务和应用程序。
SpringCloud 架构
核心组件：
- API Gateway（服务网关）
- breaker dashboard（熔断监控）
- config dashboard（配置中心）
- service registry（注册中心）
- distributed tracing（链路追踪）
- message brokers（消息队列）
SpringCloud 能力
在 SpringCloud 框架中，SpringCloud 自身提供了一系列的中间件和 NFRs 的能力。SpringCloud 除了具备 Dubbo 的能力，例如服务调用框架、服务注册与发现、负载均衡等能力外（能力虽然都有，但是实现原理和模型是不一样的，例如在 Dubbo2.x 中，服务注册与发现是接口级别的，服务间的通信是 RPC。SpringCloud 的服务注册与发现是应用实例级别的，服务间的通信是 REST API），还具备分布式网关（zuul、SpringCloud Gateway）、分布式消息、分布式配置（config server）、链路追踪（zipkin）等中间件能力和熔断、限流（hystrix）等 NFR 能力。但是分布式事务、分布式数据库访问、分布式日志等能力依然缺失，需要独立集成地方放的 lib 库和 SDK。
SpringCloud Alibaba
Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。
SpringCloud Alibaba 架构
核心开源组件：
Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。
Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架。
Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
核心商业化组件：
Alibaba Cloud OSS：阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。
Alibaba Cloud SchedulerX：阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。
Alibaba Cloud SMS：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。
SpringCloud Alibaba 能力
SpringCloud Alibaba 提供的能力与 SpringCloud 基本类似，但是与 Springcloud 对比，有以下区别：
能力替换：Nacos 替换 eureka、Sentinel 替换 hystrix；
能力新增：分布式事务（Seata）。
SpringCloud Alibaba 应用
特点
- 去中心化；
- 引入旁路注册中心；
- 三方组件模块化；
- 部分三方依赖和NFR能力下沉。
微服务优势与不足
优势
- 模块化：模块化的结构，业务充分分离解耦；
- 独立部署：简单的服务易于部署，且单个服务出问题不会影响整个系统；
- 扩展性好：可根据每个模块的负荷进行单独的弹性扩展和部署；
- 复用性高：每个模块之间的自由组合达到服务复用。
不足
- 开发测试复杂性：分布式系统的编程难度更大、测试更复杂；
- 运维复杂性：需要成熟的运维团队来管理和组织众多的微服务；
- 中间件管理复杂性：需要成熟度高的开发团队来构建和管理分布式中间件；
- 影响性能：微服务采用rest/rpc等形式进行交互，通信的时延对导致性能不如本地调用；
- 业务逻辑、三方库依赖、NFR耦合严重，缺少关注点分离；
- 侵入性:Dubbo、SpringCloud、SpringCloud Alibaba都是侵入性微服务框架；
- 异构支持不足：对非Java语言的集成不友好。
微服务发展趋势
- 跨语言；
- 容器化；
- Mesh化；
- 无服务器架构化；
- 多运行时架构。
《数字化 IT 从业者知识体系》背景
数字化和可持续发展是中国企业未来发展的两大主题，掌握数字化知识，具备数字化能力，应用数字化技术是我们 IT 从业者未来核心竞争力所在。《数字化 IT 从业者知识体系》的初衷是为 IT 从业者提供的系统性的数字化知识体系，内容涵盖管理实践、工程实践、技术实践三个层次，涉及软件开发方法、应用技术架构、应用部署与管理、软件交付与协作四大方面。
在接下来的《数字化 IT 从业者知识体系》系列文章，何文强将从软件开发方法、应用技术架构、应用部署与管理、软件交付与协作四个方面，为大家进行逐一分享介绍：
1. 软件开发方法主要包括瀑布、敏捷、精益等；
2. 应用技术架构主要包括微服务架构、服务网格架构、无服务器架构、分布式多运行架构等；
3. 应用部署与管理主要包括但不限于虚拟化技术、容器技术与容器编排等；
4. 软件交付与协作主要包括但不限于 CMMI、ITIL、DevOps 等。
相信该知识体系有利于 IT 从业者构建丰富的技术体系、全面的技术视野和系统的能力建设。欢迎大家前往《数字化 IT 从业者知识体系》话题进行详细阅读。
