【企业架构设计实战】技术架构设计指南

时间：2024-10-26 08:05:47

 

目录

技术架构概述

技术架构的价值

技术架构设计框架

技术架构常用模式

单体模式

分层架构

事件驱动架构

微内核架构

RPC架构

SOA

微服务架构

大数据架构

上云架构

云原生架构

应用架构常用模式

集中式架构

SOA（面向服务架构）

事件驱动架构

微服务架构

云原生架构

技术架构设计原则

通用技术架构原则

技术架构标准和规范

通用非功能性原则

微服务设计原则

技术架构制图

架构制图的原则

架构制图的方法

UML

“4+1”视图模型

C4模型

技术架构视图参考

开发架构视图

部署架构视图

安全架构视图

技术基础设施上云

技术架构典型技术选型

流量调度

负载均衡

API网关

配置中心

服务治理

服务注册与发现

弹性伸缩

流量控制

灰度发布

任务调度

监控体系

监控分层

日志分析

链路追踪

应用性能监控

性能分析

消息队列

微服务技术框架

技术架构最佳实践

一致性理论

强一致性：ACID

CAP

弱一致性：BASE

提高一致性的方法

分布式集群

关注点

主备架构

主从架构

主主架构

集群架构

稳定性

容灾

可扩展性

无状态

压测

技术架构也是我们常说的软件架构、系统架构，是将业务需求和应用功能转变为技术实现的过程。技术架构在软件开发过程中应用得比较普遍，受到广大技术人员的普遍关注，它是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。技术架构可以帮助我们梳理系统边界、识别系统需求、识别系统风险和问题优先级、确定技术方案和路线，让团队之间达成共识且相互约束，并指引团队适应业务和技术的变化。

在企业架构中，技术架构是支撑整个企业架构体系的技术部分，也是企业架构中IT架构的最后架构阶段。技术架构以业务架构中的业务需求、业务能力、业务流程为指导，是从应用架构和数据架构的具体形态导出的对企业数字化系统和IT基础设施进行整体部署的一组技术标准规范、原则和最佳实践，并包含相关的技术选择标准、产品选择方案、技术实施路线等，目标是优化整个企业的IT运行环境，实现IT对业务服务高效率地交付。

从广义上来讲，技术架构涉及技术研发的方方面面，包括业务、数据、应用对应的软硬件能力，比如IT基础设施、中间件、网络、通信等。同时，技术架构从技术上指导应用系统的开发、部署、测试、交付、运维等，提出公共性、支撑性的指导，推进资源共享和系统协同，发挥现有资源和基础设施的效用，提升业务系统的互操作性。技术架构解决的问题包括技术分层、技术框架选择、开发语言选择、非功能性需求实现等。

技术架构的价值

技术架构的主要价值有以下几点。

  • 理解对齐，形成共识：软件系统是为了实现用户需求，特别是针对企业架构，不同的人有不同的视角，技术架构需要将业务架构、应用架构、数据架构的需求转换成技术人员可以理解的技术语言。需求的实现往往可以有多种途径，如何选择途径？如何拆分系统？选择技术A还是技术B？这些都需要通过技术架构描述并记录下来，让大家理解对齐，形成共识。
  • 标准规范，术语统一：软件开发的不确定因素很多，特别是大型企业的技术落地过程，往往有多种技术规范和标准，包括行业通用的和企业内部的，如开发规范、部署规范、稳定性保障规范等。同时，在技术层面有很多术语，不同的人有不同的理解，技术架构需要定义和解释清楚系统中涉及的关键概念，特别是非功能特性的选择和技术方案，并在整个架构设计和描述过程中使用标准和一致的术语。
  • 言之有物，资产沉淀：如同讨论产品交互时对照产品原型图，讨论代码Review时需要看代码一样，技术架构也有相应的实物，即架构制图（简称架构图）。架构图是软件开发的高层次抽象，是架构持续演进的具体承载，也是技术团队的核心资产，对系统开发、新人培养等具有重要的作用，是技术团队的灵魂所在。
  • 团队协同，明确分工：技术架构提供企业更有效地管理研发的流程，方便团队协同，比如通过构建企业开发平台、运维平台来协助系统的统一管理，进而结合上层应用架构、数据架构的落地，通过新技术（如云原生技术、容器化技术、敏捷交付、精益管理等软件工程管理技术）构建开发和运维一体化的平台，清楚地定义各团队的分工边界，确保业务需求和应用功能的稳定落地。

技术架构设计框架

技术架构涉及技术架构规划、技术平台、基础设施，以及技术架构标准原则、最佳实践等。

图例：技术架构设计框架总览

  • 技术架构规划：对技术架构统一规划的指导，包括架构模式、架构方法、架构制图等。
  • 技术平台：技术架构的平台组件能力，包括开发平台、数据平台、移动平台、低代码平台等，以及核心的典型技术，如服务治理、监控告警、流量调度、消息服务、缓存等。
  • 基础设施：支撑技术架构的基础设施，比如计算、存储、网络、安全及云原生基础设施等，可以充分考虑企业上云相关技术。
  • 技术架构标准原则：企业技术方向性的通用原则，如通用技术原则、技术框架原则、服务开发设计原则、架构制图原则等。
  • 技术架构最佳实践：技术架构典型的实践，如一致性、高并发、高可用、安全生产、压测、秒杀、企业上云等。

技术架构常用模式

技术架构模式基于经常出现的问题，给出通用、可复用的技术方案。技术架构常用模式既包括一些传统模式，如分层架构、事件驱动架构、SOA，也包括一些新兴模式，如微服务架构、上云架构、云原生架构等。企业需要结合自身业务和技术的实际特点，选择合适的技术架构模式。

单体模式

所有业务逻辑全部在一套系统中，是大而全的体系，没有服务化，没有分层，单机集中式数据库，存储过程复杂。这种架构适用于业务发展早期，这时产品的完善性、系统扩展性、部署规模的要求都不高。很多企业在发展初期，在技术方面的投入并不大，主要以外采系统为主，包括CRM、MES、ERP、HR、PLM、SCM等系统，各个系统各自独立，各自有单独的数据库及权限管理。单体模式的缺点是造成“烟囱式”发展，信息化协同不便，业务需求响应有限。

分层架构

分层架构是一种客户端/服务器端架构，将系统软件分成了多个层次，通过层次的抽象提供相对便捷的扩展和复用能力。每一层都是围绕一种功能的抽象，各负其责，有利于系统开发、测试、管理和维护。最常使用的分层架构是MVC三层架构，将模型、表现、控制进行分离，除此之外，后文介绍的很多架构模式本质上是分层架构的进一步演进。

事件驱动架构

事件驱动架构（EDA）是使用解耦、单一用途的事件处理组件来异步接收和处理事件的架构。一个事件驱动系统一般由事件消费者和事件产生者组成。事件驱动在分布式系统、异步处理系统、高并发削峰填谷等场景中广泛使用。事件驱动架构当然也增加了一定的复杂度，包括事务性、数据一致性、事件顺序、重复消费等方面。

微内核架构

微内核架构（Microkernel Architecture）是一种面向功能进行拆分的可扩展架构，有时也可以称作插件化架构，比如Eclipse类型的IDE、UNIX操作系统，都是参照微内核架构设计的。微内核主要分为核心系统和插件系统，核心系统拥有能使应用运行的最小功能逻辑，插件系统是独立存在的系统，包含特殊的处理逻辑、额外的功能和定制的代码，能拓展核心系统业务功能。微内核架构设计的难点是核心系统的通用性、插件系统的扩展性和灵活性。

RPC架构

RPC架构是远程过程调用架构。当时，很多企业采购了ESB和数据交换工具，将不同的流程打通，做到信息拉通、数据集成、协同管理。RPC框架主要包括网络通信、序列化或反序列化、传输协议和服务调用等组件。远程服务提供者以某种形式提供服务，调用相关信息，远程代理对象通过动态代理拦截机制生成远程服务的本地代理，让远程调用在使用上和本地调用一样。网络通信通过序列化或反序列化方式对网络传输数据进行有效的传输。服务调用可以分为同步调用、异步调用等方式。传输协议可以使用TCP和HTTP。Dubbo是RPC架构典型的分布式框架代表。

SOA

SOA通过服务化技术进行系统的拆分，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通信，是面向服务的设计模式，最终需要总线集成服务。过程中引入中间件、消息、分布式数据库等技术组件，通过ESB与企业系统进行集成和交互。这种架构适用于业务发展中期，这时企业对产品的完善性和精细性有了一定的需求，团队也越来越大，扩展性主要依赖服务化的能力。

微服务架构

微服务架构本质上是SOA的演进，在被Martin Fowler等人推广后，由于其实用性，越来越受到大家的重视。微服务由一组小型自治服务组成，每个服务实现单个业务功能，每个服务是小型的、独立的、松耦合的，每个服务代码库都是独立的，每个服务负责持久化自己的数据或者外部状态，通过使用定义良好的API进行通信。微服务架构的好处很多，比如提高研发效率、支持更专注的团队、提高可扩展性、隔离业务和数据、有更小的代码基线；同时带来一些挑战，比如复杂度高、部署和运维困难、数据一致性问题、版本控制问题、组织文化考验等。

大数据架构

大数据架构是数据架构的一种，其主要进行大数据的技术处理和分析海量数据。该架构是大数据解决方案的蓝图，处理的工作包括批量处理大数据源、实时处理数据、预测分析及机器学习。大数据架构的优势是应对大规模数据处理，通过并行度提升性能，弹性伸缩，与现有方案（如物联网、BI等）互通；其挑战在于相关大数据技术、团队技能储备及数据安全等问题。

上云架构

云计算已成为社会的公共的基础设施，企业上云也被人们广泛接受。在企业数字化转型过程中，首先应使用云作为企业的技术基础设施，并逐步应用云计算的红利，逐步将应用迁移到云上，这就诞生了上云架构。上云架构有很多优势，比如极致的弹性、降本增效、加速IT设施发展、提升系统稳定性、加强资源整合等；其挑战是对企业的技术团队能力要求高、整体架构与企业的对接和整合不容易等。

云原生架构

云原生是云计算的“下一站”，云原生的代表技术有容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。运行在其上的应用被称作云原生应用，云原生架构是依赖云产品和云原生技术构建的IT架构，生于云、长于云并最大化运用云的能力，让开发者聚焦于业务本身。云原生的设计理念是面向分布式（Distribution）、配置（Configuration）、韧性（Resistancy）、弹性（Elasticity）、交付（Delivery）、性能（Performance）、自动化（Automation）、诊断性（Diagnosability）及安全性（Security）等方面。

应用架构常用模式

应用架构常用模式主要有以下几种。

集中式架构

集中式架构又称单体架构，传统企业根据各个业务部门的需求，开发了多个“烟囱式”系统，这种架构模式有很多弊端，在一些传统企业中还存在。

SOA（面向服务架构）

企业采用企业服务总线（ESB）来解决多系统之间复杂的接口交互模式，也就是传统的SOA模式。而随着互联网企业的发展，采用去中心化、去IOE的分布式服务架构，不需要ESB作为中心节点，而是进行直接发现和调用，以解决中心化服务扩展难、不适合互联网大流量要求快速响应的痛点。

The Open Group的面向服务架构 (SOA) 工作组提出了一个SOA架构的参考模型，主要包括：

图例：SOA参考应用架构

SOA参考应用架构，具体包括以下几个层面。

  • 基础设施服务：由操作系统和后台的应用系统组成，能够被系统组件调用，实现IT系统服务功能，并确保服务的质量，为各层次的系统提供数据支持。
  • 服务总线：：通常由ESB系统提供路由、多协议、转换等,服务在这里注册和发现，也可以通过组合形成组合服务,并且通过对服务的服务组合和编排实现业务流程。
  • 关键服务组件：由服务使用者组成，构建前台的访问应用。
  • 开发工具：提供SOA的相关开工具，如WSDL等
  • 管理工具：提供服务质量（QoS）服务，包括安全、管理和基础设施监控等。

SOA并不是推倒重建企业的系统，而是在现有的系统之上进行包装服务，建立标准结构，方便互通和调用。SOA也使得架构设计的过程从面向对象、面向组件的设计方法过渡到面向服务的设计方法，其强调以服务为中心的设计理念，接口和实现分离、服务提供和服务使用分层的设计思想。

事件驱动架构

事件驱动架构（Event Driven Architecture，EDA）以SOA为基础，以事件为单位进行各种处理。事件驱动的核心是事件，事件是历史，是事实，是已经发生的事。

图例：事件驱动架构示意

事件由事件源生成，并通过事件管理器进行发布，各种事件的订阅方根据需要进行订阅消费，可以直接处理该事件，或者即时转给其他订阅方，同时事件作为一种业务数据的载体，可以进行存储，从而在以后进行处理。

图例：事件驱动概念示意

事件驱动系统通常是异步的，事件生产者向事件管理器发布事件，如果事件消费者不可用，事件管理器将保留这个事件，之后再次转给事件消费者。

事件生产者与事件消费者相对独立且解耦，事件生产者不需要知道哪个消费者会接收消息。事件消费者彼此之间也互相解耦，每个消费者都可以接收全部或者部分消息。因此，事件驱动架构的系统更适用于包含较多未知因素的环境或者异步的环境，通过构建分布式高可用架构，提供事件生产者和事件消费者相对灵活解耦的能力。事件驱动架构适用于多种场景，比如有多个子应用且处理相同事件，需要实时处理大量数据，有复杂的事件处理等。

图例: EDA领域事件

从领域设计角度，事件驱动架构也有广泛应用，比如基于事件风暴的分析方法。其中，事件源和订阅者都是具体的领域实体，事件管理器可以作为基础设施的一部分技术组件，这个过程会借助消息中间件来进行能力提供。

微服务架构

随着互联网技术的发展，SOA技术进一步进化为以微服务为主流的分布式服务架构。微服务是一种分布式架构模式，微服务架构凭借其简单清晰、灵活可扩展、独立部署等优势，逐渐成为分布式架构的主流。微服务将大型复杂软件应用拆分成多个微小的服务，服务之间是松耦合的，每个服务描述一个小业务，可以独立地进行升级、部署、扩展和重新启动等流程，并通过接口契约、标准协议等保持彼此互通。

微服务架构由SOA演化而来，是SOA的一种特殊实现方式，突出将服务划分为更细粒度的微服务，按照业务领域划分，强调服务编排、服务治理、自动化运维，并具备高可用、性能要求、分布式事务一致等特点。

关于微服务是什么，转述Martin Flower 大神的系统阐述：

  • 微服务是一种架构风格，也是一种服务
  • 微服务的颗粒比较小，一个大型复杂软件应用由多个微服务组成，比如Netflix目前由500多个的微服务组成
  • 微服务采用UNIX设计的哲学，每种服务只做一件事，是一种松耦合的能够被独立开发和部署的无状态化服务（独立扩展、升级和可替换）。

图例：微服务架构示例

与集中式架构相比，微服务有降低系统复杂度、提高迭代效率、促进团队沟通、弹性扩展、容错能力、独立部署、可扩展性、跨语言编程等很多优点，这里挑选几个进行说明。

  • 提高迭代效率：支持细粒度的独立迭代和发布，速度快。由于微服务架构中的每个小型服务是独立部署的，可以单个服务进行缺陷修复或者特性变更，无须重新部署整个应用程序，一旦发现缺陷，就立刻回滚服务。
  • 促进团队沟通：单个小型服务仅需要一个小的开发团队就可以完成开发、测试和部署工作。相比之下，更大的团队通常意味着更低的沟通效率、更高的管理开销。
  • 容错能力：当系统出现问题时，将仅影响单个小型服务，不一定导致整个应用程序中断；同时对应的数据也将会进行隔离，风险明显降低。
  • 可扩展性：每个小型服务都支持独立水平扩展，无须扩展整个应用程序，资源的利用率高，扩展快速。每个小型服务都可以独立进行服务升级，并且结合持续集成工具可以进行持续发布，快速完成服务升级和发布流程。

微服务架构有很多好处，不过也存在以下一些挑战。

  • 设计的复杂性：与传统架构的应用程序相比，微服务架构的组件更多。服务数量多意味着部署和管理的工作量更大，还需要考虑分布式系统的复杂性和分布式事务的处理难度。
  • 开发、测试、部署难度：当服务拆分后，几乎所有功能都会涉及多个服务，所依赖的其他独立服务增多，此时处理好服务间的依赖关系成为关键。原本单个程序的测试会变为服务间调用的测试。测试变得更加复杂。
  • 运维难度：由于可能采用不同的语言和框架，应用程序可能变得难以维护。整个应用分散成多个小型服务，这导致问题定位更加困难，同时可能增加服务间的通信量。
  • 数据一致性：每个小型服务都仅负责各自相关的数据持久性，因此不同服务间的数据一致性很难达到。

云原生架构

分布式架构的出现是为了解决应用难以开发和维护的问题。

  • 垂直拆分：把按业务领域拆分为多个松耦合的独立应用，各自独立部署和维护。
  • 水平拆分：把通用的、共性的应用进行分层沉淀，形成共享的服务能力，这样可以对性能稳定性等问题进行统一处理和优化，防止重复开发。

如今，架构朝着越来越轻量化、能力越来越下沉、应用越来越灵活的方向发展，到云原生时代达到了新的高度。

云原生将云应用中的非业务代码进行最大化的剥离，关注点分离，让云来负责原有的大量非功能特性需求，如可靠性、扩展性、可观测性、弹性、轻量、敏捷、自动化等。

同时，有很多企业也在尝试“双IT架构”，即以云原生架构来应对敏态业务的快速变化，以及传统的基于ESB方式的架构应对稳态内部系统的管理，二者相互结合并互补。

技术架构设计原则

下面从不同维度给出技术架构的设计原则。

通用技术架构原则

  • 业务需求导向原则：企业业务战略计划决定了企业架构的发展方向，同时决定了企业的整体IT架构。技术的首要任务是支撑业务发展，技术需要结合业务需求及业务架构、应用架构、数据架构的要求输入，从而快速实现IT投资的回报。
  • 实用性原则：IT需要以实用为原则，不能一味地追求市场上最先进的技术平台，需要结合企业实际的业务发展。
  • 复用原则：遗留的系统和数据都是宝贵的资产，在技术改造过程中，要最大限度地保护现有IT资产，并充分结合新一代技术架构的技术特点，在复用的基础上进行创新。
  • 开放与标准化原则：尽量采用国际上通用的技术标准体系，充分考虑主流的开源及商业化选择。统一且成熟的技术标准可以保证系统的一致性和兼容性，同时减少企业在非功能性技术方面的投入。
  • 分布式架构参考设计原则：一个良好的分布式系统需要充分综合考虑相关的能力，比如应用服务能力的线性扩展、高并发下的高性能响应、服务治理能力、数据化运营能力、全链路监控跟踪等。
  • 尽可能应用无状态：仅当业务需要时才呈现使用状态，尽量保持应用无状态，这样更易于扩展。
  • 尽可能异步设计：仅当无法异步时，才进行同步调用，尽量考虑异步设计。

技术架构标准和规范

  • 架构模式标准化：包括应用平台的架构模式选型标准、微服务架构设计标准、应用平台开发标准等，通过统一的应用平台架构来规范应用的整体结构，并涵盖未来应用系统、遗留系统及需要集成与整合的系统。
  • 技术选型标准：需要从企业实际角度提出技术选型管理标准，结合市场上主流开源和商业技术组件，以及企业技术的发展趋势，综合考虑技术的架构、功能、性能、集成难度、实施难度等因素。
  • 基础设施选型标准：针对企业的服务器、存储、数据、网络等综合基础设施，比如采用云原生基础设施能力，充分考虑企业上云过程的利与弊。
  • 系统非功能性能力管理：充分考虑系统的非功能性能力，权衡投入产出比，评估IT系统管理的复杂度，确定是否采用一系列开源或商业化产品加以辅助管理。

通用非功能性原则

提到非功能性，技术架构可能涉及多个方面，如稳定性、可扩展性、一致性、可移植性、兼容性、可配置性、可降级性、可部署性、可发现性、故障透明性、容错性、可检验性、可安装性、完整性、可维护性、可管理性、模块性、可操作性、可恢复性、可靠性、重现性、弹性、可复用性、稳健性、安全性、可服务性、合规性、可持续性、可测试性、可追溯性等。当然这些特性可能并不会在一个系统中全部满足，需要结合企业实际需求进行针对性的开展。下面是ISO/IEC 25010标准定义的系统软件产品质量中所考虑的非功能性，包括以下八大类别。

  • 功能适合性：功能完整度、功能正确性和功能恰当性。
  • 性能效率：响应时间、资源利用率和容量。
  • 兼容性：多版本共存和互操作性。
  • 易用性：可学习性、可运维性、自动纠错、UI美观度、可访问性。
  • 可靠性：成熟度、容错性、可恢复性。
  • 安全性：机密性、完整性、不可伪造性、权威性和可审计性。
  • 可维护性：模块度、可复用性、可分析性、可修改性、可测试性。
  • 可移植性：可适配性、可安装性、可替代性。

微服务设计原则

微服务设计原则如下所示，有的前文已提到过。

  • 稳定性原则：以稳定为中心，设计得尽可能简单和清晰，不过度设计。
  • 依赖和分离原则：需要把稳定的服务部分与易变的服务部分进行分离，把核心业务微服务与非核心业务微服务分离，应用与数据分离，服务接口与实现细节分离。
  • 异步松耦合原则：不同业务域间尽量异步解耦；核心业务和非核心业务间尽量异步解耦。
  • 垂直划分优先原则：尽可能根据业务领域进行服务的垂直划分，这样更加关注业务实现，端到端负责，便于持续改进，减少调用次数。水平划分需要充分从总体考虑。
  • 持续演进原则：应逐步划分、持续演进，避免服务数量的“爆炸性”增长。当服务数量增加时，需要考虑持续交付、微服务监控与治理等环节。
  • 服务自治原则：服务需要提供SLA，保持稳定性，可以独立开发、测试、部署和运行，避免发生连锁反应。
  • 自动化驱动原则：可以结合DevOps和CI/CD等自动化工具，以及成熟的微服务治理框架，提高微服务生命周期的自动化效率。
  • 微服务拆分原则：优先拆分比较独立的服务、通用服务、边界明显的服务、核心服务。
  • 提前准备原则：开展微服务前需要做一些准备，比如研发环境和流程上的转变、构建自动化工具链、服务注册与发现、流量调度、监控等。

技术架构制图

在架构设计领域，架构制图是针对系统架构某一个方面的一种描述，将系统的技术方案、技术选型通过视图的方式进行展现。架构制图可以帮助团队内部和团队之间消除沟通歧义，提升协作效率。一图胜千言，无图无真相。图是直观而形象的，顺应了人类与生俱来的视觉识别本能，一张图所能传达的信息非常多。常见的技术架构制图有功能架构制图、系统分层架构制图、系统链路架构制图、部署架构制图、开发架构制图等。

架构制图的原则

国际上对架构描述设立了专门的标准（ISO/IEC/IEEE 42010:2011），架构制图是架构的载体，从制图本身角度，架构制图需要关注以下几个方面。

  • 深刻理解制图目标：架构制图需要有明确的目标，需要准确、完整、清晰、一致、简洁。
  • 明确受众及关注点：比如业务、产品、开发、测试、运维、外部客户、行业专家等。
  • 考虑全面，有所侧重：架构制图需要跳出图本身，全面展示涉及的内容，避免“只见树木，不见森林”；同时需要针对受众和关注点有所侧重，略去与当前视图无关的细节。
  • 充分采用设计方法：建议采用结构化思维，比如金字塔原理、结论先行、以上统下、归纳分组、逻辑递进。
  • 采用多种架构视图：可以采用不同的视图来进行描述，比如从工程制图角度，有主视图、俯视图、左视图等。
  • 遵守统一的图例规范：比如UML中泛化、聚合、组合、依赖等关系的表达，以及各种方框、虚实线、箭头的含义，特别是组件之间的交互方式，比如同步或异步。
  • 持续优化迭代：与软件一样，架构制图也有版本，核心是表达清楚图的内容，突出最重要的地方，架构制图的粒度、类别、内容等可以逐步完善。

架构制图的方法

UML

UML（Unified Modeling Language）是统一建模语言的简称，它是一种由一整套图表组成的标准化建模语言。UML用于帮助系统开发人员记录软件系统的产出。UML主要使用图形符号来表示软件项目的设计，帮助项目团队沟通和进行软件设计。

UML总共包含十几种不同类型的图，可以覆盖软件设计领域各种制图需求，主要分为如下两大类图。

图例: UML分类

  • 结构图（Structural Diagrams）：通过对象、属性、操作和关系等，强调系统的静态结构，包括类图（Class Diagram）、组件图（Component Diagram）、部署图（Deployment Diagram）、对象图（Object Diagram）、包图（Package Diagram）、组合结构图（Composite Structure Diagram）。
  • 行为图（Behavioral Diagrams）：通过展示对象之间的协作关系及对象内部的状态改变，强调系统的动态行为，包括用例图（Use Case Diagram）、活动图（Activity Diagram）、序列图（Sequence Diagram）、状态机图（State Machine Diagram）、通信图（Communication Diagram）、交互概述图（Interaction Overview Diagram）、时序图（Timing Diagram）。

下面简单介绍几种常用的UML制图。

  • 类图（Class Diagram）：类图是一切面向对象的核心建模工具，描述系统中对象的类型及它们之间存在的各种静态关系。
  • 组件图（Component Diagram）：组件图描述组件如何连接在一起以形成更大的组件或软件系统。它展示了软件组件的体系结构及它们之间的依赖关系。
  • 用例图（Use Case Diagram）：用例图从用例的角度描述系统的功能需求，它是系统预期功能（用例）及其环境（参与者）的模型。
  • 活动图（Activity Diagram）：活动图用于展示工作流程，它支持选择 （Choice）、迭代（Iteration）和并发（Concurrency）。活动图描述目标系统的业务流程。
  • 状态机图（State Machine Diagram）：状态机图描绘允许的状态和转换，以及影响这些转换的事件，有助于可视化对象的生命周期管理。
  • 序列图（Sequence Diagram）：序列图根据时间序列展示对象如何进行协作。它展示了在用例的特定场景中，对象如何与其他对象进行交互。

对于通用的一些UML原则，《码出高效：Java开发手册》给出了比较详细的介绍，这里挑选并提炼其中几条。

  • 在需求分析阶段，如果与系统交互的对象超过一类并且相关的用例超过5个，则使用用例图来表达更加清晰的结构化需求。
  • 如果某个业务对象的状态超过3个，则使用状态机图来表达并且明确状态变化的各个触发条件。
  • 如果系统中某个功能的调用链路上涉及的对象超过3个，则使用时序图来表达并且明确各调用环节的输入与输出。
  • 如果系统中模型类超过5个，并且存在复杂的依赖关系，则使用类图来表达并且明确各类之间的关系。
  • 如果系统中超过2个对象之间存在协作关系，并且需要表示复杂的处理流程，则用活动图来表示。
  • 谨慎使用继承的方式进行扩展，优先使用聚合或组合的方式。
  • 在进行系统设计时，根据依赖倒置原则，尽量依赖抽象类与接口，这样有利于扩展与维护，需要注意的是，应对扩展开放，对修改闭合。
  • 在系统设计阶段，共性业务或公共行为抽取出来公共模块、公共配置、公共类、公共方法等，避免出现重复代码或重复配置的情况。

“4+1”视图模型

1995年，Philippe Kruchten发表了题为“The 4+1 View Model of Architecture”的论文，引起了业界的关注。此论文提出了一种用来描述软件系统体系架构的模型，以架构为中心场景驱动和迭代开发等方式实现设计。“4+1”视图模型基于不同项目干系人，从4种基础视图和场景方面来描述软件需求。

图例：“4+1”视图模型

  • 场景（Scenarios）：场景用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计，通常用用例图表示。
  • 逻辑视图（Logical View）：逻辑视图用于描述系统软件功能拆解后的组件关系，反映系统整体组成与系统构建过程，通常用组件图和类图表示。
  • 物理视图（Physical View）：物理视图用于描述系统软件到物理硬件的映射关系，反映系统的组件部署关系，通常用部署图表示。
  • 流程视图（Process View）：流程视图用于描述系统软件组件之间的通信时序、数据的输入和输出，反映系统的功能流程与数据流程，通常用时序图和活动图表示。
  • 开发视图（Development View）：开发视图用于描述系统的模块划分和组成，以及细化到内部包的组成设计，反映系统开发实施过程，通常用组件图和包图表示。

C4模型

C4模型来自《程序员必读之软件架构》（Software Architecture for Developers）一书，C4模型是一种“抽象优先”的架构制图方法，它是受UML的启发而开发出来的，但相对而言，C4模型更加简单和轻量，只包含少量的一组抽象和图表，易于学习和使用，如图7-4所示。

图例：C4模型示意图

C4代表上下文（Context）、容器（Container）、组件（Component） 和 代码（Code） 分层的图表，可以用这些图表来描述不同缩放级别的软件架构，每种图表适用于不同的受众。

C4模型最关键的思想就是自上而下对系统的静态结构进行逐级拆分，依次描述各层次对象的职责、关系和外部依赖。此外，它还可以包含动态视图、部署视图等补充视图。举个例子，一个软件系统由多个容器（如数据库、应用）组成，一个容器由多个组件组成（如微服务和技术组件），一个组件由多个代码（如接口类、实现类、领域对象类）结构组成。

技术架构视图参考

技术架构视图可分为多种类型，比如系统功能架构、开发架构、测试架构、部署架构、运维架构、安全架构、集成架构、数据交互架构等视图，下面简要介绍几种技术架构视图。

开发架构视图

开发架构视图提供软件系统各模块的组织结构，涉及系统的各个层面，包含软件复用技术应用、设计和测试的标准化、代码组织管理等。开发架构主要面向技术开发人员，一方面强调软件开发生命周期的各阶段，另一方面重视对已有资产的封装、管理和重用，强调统一建模和设计的重要性。  

图例：开发架构视图

上图展示了一个例子，从分层角度，开发架构包括网关层、应用层、服务层、技术底座层、基础设施层等。

整个框架体现一个目标：以基础设施层为依托，以技术底座层为开发准则，以应用层和服务层为核心，通过网关层，全面为各层次提供高质量的服务。

  • 网关层更体现不同用户和终端的接入
  • 应用层和服务层承接应用架构的部分能力
  • 技术底座层更体现统一的技术与开发管理能力，如应用管理、项目管理、集群管理，这一层提供统一的资源分配及调度，并提供完整的CI/CD、DevOps、代码托管等能力，打通业务开发与基础设施，屏蔽基础设施中复杂的技术细节，并提供对接其他系统的能力
  • 基础设施层提供基础资源，比如计算资源、数据存储资源、服务资源等

部署架构视图

部署架构视图主要面向运维人员，维持系统运行的各种服务，包括运维安全管理、网络设施管理、基础服务管理、配置管理、基础设施和环境管理，以及相关的规章制度和管理流程等。

部署架构有时也叫作物理架构，需要考虑一些因素，比如网络情况、流量调度、隔离的环境、运行时功能或数据迁移、状态性能监控、系统配置、数据和系统备份及还原等，还要考虑如何保障系统的稳定性，在出现运行故障时能够进行容错和快速恢复，包括安装、迁移、管理和支持活动，同时这些活动需要尽可能自动化。

图例：部署架构视图

上图展示了一个基于Spring Cloud体系的部署架构，包括服务注册集群、服务配置中心、业务服务容器、服务监控和保护、流量控制和负载均衡、认证鉴权等集群组件的部署。

安全架构视图

安全架构视图定义了企业向业务部门提供的安全范围和功能，贯穿整个企业架构的安全环节，是业务安全运行的基础架构。

图例：安全架构视图

安全架构包括身份和访问管理、开发安全管理、运维安全管理和集成架构安全等，以及合规等安全运营管理等。

安全架构对企业非常重要，涉及的面很广。比如，从系统数据安全角度，需要敏感数据保护、数据传输加密、数据存储加密等；从系统应用安全角度，涉及应用防火墙保护、应用配置安全、代码安全、漏洞扫描等；从系统账号安全角度，需要进行身份认证、访问授权、账号管理、操作审计等；从系统安全监控运营角度，需要进行威胁检测、配置检查、日志审计、备份恢复等。

技术基础设施上云

从技术架构基础设施角度，越来越多的企业选择使用云计算，逐步将企业的应用搬到云上。这里我们来看看企业上云的好处和通用方法。

什么是上云？上云指的是企业以云计算的服务能力为基础，进行信息化系统及相关业务应用的建设并对外连接的过程。上云可以帮助企业解决技术统一、业务统一的问题；可以支持敏捷开发，加速业务快速创新；还可以帮助企业降本增效。云计算通过资源池和虚拟化技术，让应用和底层基础设施解耦，进而提高资源的利用率，并通过资源弹性使得云基础设施和传统IDC（互联网数据中心）对比具有明显优势。

企业上云一般可分为三种类型。

图例：企业上云的三种类型

  • 第一类是新托管（Rehost），通过迁移的方式，将线下物理机替换为云上虚拟机，比如计算、存储、网络的云资源；
  • 第二类是新平台（Re-platform），用托管的云服务替换线下自建应用基础设施，并越来越渗透到PaaS层，比如数据库、中间件、监控、应用生命周期等，从而具备更好的弹性、稳定性和自治运维能力；
  • 第三类是重构/新架构（Refactor/Re-architect），进行深层次的微服务或云原生应用架构改造，以及对应的DevOps整体研发流程改造。

可以看出，上云不仅是简单地使用一些计算、网络、存储等云资源，更重要的是从Rehost向Re-platform，进而向Re-architect升级。

在此过程中，虽然上云的成本和复杂性逐步增加，但是在其他方面（比如敏捷性、弹性、可用性、容错性等）的收益也在持续增加，因此企业上云需要综合考虑自身的业务和技术特点，选择适合自己的上云节奏。

在上云过程中，企业需要遵从以下原则。

  1. 选择好架构模式：要充分结合各种架构模式的优缺点，根据具体的应用场景进行选择，比如N层架构、微服务架构、事件驱动架构、大数据架构及高性能计算架构等。
  2. 单一还是多云：企业需要结合实际现状，一般多个供应商对接的成本更高，但如果企业一定要与多个供应商合作，则建议将相对独立的应用模块放在同一个云中，将其他应用模块放在另外的云，而不是将单个应用模块部署到多个云中。
  3. 充分评估转化成本：当选择云供应商或者云服务时，需要充分评估转化成本，不同的云及云产品在功能、性能、成本、可靠性等多方面都有差异，因此要进行综合评估。
  4. 重视非功能性：一个设计良好的上云架构在满足功能性需求的同时，需要充分考虑非功能性需求，尽可能利用云服务来简化这些非功能性需求的实现，需要重点考虑性能效率、可靠性、兼容性、可执行性和可维护性。

企业应用上云需要紧密结合自身的业务和技术特点，可以采用以下通用的几个步骤。

  1. 确认上云需求：首先需要收集和确认应用上云的需求。此过程需要结合其他架构（如业务架构、应用架构），并与不同的人员交流和讨论，收集各方的痛点。从上云的视角来看，需要重点考虑工作负载（工作负载对高可用及容灾的需求）、业务增长（如大促峰值的增长）、成本管理（如资源消耗等）、时间目标（如恢复时间目标等）、安全合规（如数据隐私等）等。
  2. 考虑架构原则：在确认了上云需求之后，需要综合考虑架构模式和原则，明确上云的非功能性需求，比如比较多种架构模式，以及确定是使用单一还是多云提供商，同时评估上云的转化成本和风险，并重点考虑性能效率、可靠性、兼容性、可移植性、可维护性等原则，确定上云的核心架构原则与相应指标。
  3. 选择云上服务:使用标准云产品是上云的关键路径，可以帮助我们全面解耦应用与云资源，充分利用云计算带给我们的技术红利，让云服务最大限度地解决企业的非功能性需求。云上服务也有非常多的种类，涉及基础设施、接入层、中间件、消息、数据存储、大数据、安全、产品研发等多个方面。
  4. 制订上云方案:进而，企业可以基于需求、架构原则及云服务选型制订整体的上云方案，建议从全局视角进行总体规划，并对核心的架构原则及云服务选型进行充分阐述，并制订出具体的分步实施计划，并请企业高层（如CTO/CIO）及架构委员会进行评审。
  5. 实施上云项目:企业可以通过项目进行推进，包括上云的项目管理、组织流程、质量保障、风险识别等，特别是相关的进度和上云前的各种压测，以及一些上云过程中的预案处理。

云计算的“下一站”是云原生，企业上云的趋势也是云原生基础设施。

Gartner将云原生基础设施划分成四大类，主要分为IaaS、CaaS（Container as a Service）、Serverless Containers（如ASI）、FaaS（如函数计算）。可以看出，从下往上，计算单元的粒度越来越细，越来越体现云原生的特质，体现在模块化程度、自动化运维程度、弹性效率、故障恢复能力等方面。

可以说，云原生基础设施是应用研发和运维的最佳实践的组合（如容器化、持续集成和交付、不可变基础设施等），使分布式系统更加可靠、易管理和易观测，提升研发运维的效率；同时使云原生的优势和云厂商的传统优势（如规模、稳定性和弹性）完美结合，并通过开放的社区标准与各大云提供商的商业化服务能力，极大地改变了用户的心智。可以预计，云原生基础设施将大大简化企业上云的过程，并结合新一代计算单元、Serverless Containers、函数计算、分布式云环境等更加灵活地适配企业多种上云诉求。

技术架构典型技术选型

技术架构由多种技术组成，过程中可能涉及非常多的具体技术

图例：技术架构核心技术

下面我们就技术架构中核心的流量调度、服务治理、监控体系、消息列队、微服务技术框架等进一步展开介绍。

流量调度

流量调度是技术架构中的核心技术，包括负载均衡、API网关、配置中心，以及一些高级特性，如容灾。

负载均衡

负载均衡（Load Balance）是将请求分摊到多个操作单元上执行。

来自客户端的请求通过负载均衡被分发到各个服务器，根据分发策略的不同产生不同的分发结果。

  • 负载均衡不仅对流量进行了再次分配，还可以起到类似队列的作用，作为请求和服务之间的缓冲区，来缓解请求的压力，进而实现削峰填谷。
  • 负载均衡可以帮助扩展服务器的处理能力、增加吞吐量、提高系统的灵活性。
  • 负载均衡的本质是对流量的管理，在系统可容纳的前提下，把资源留给最优质的流量使用，在节省成本的同时确保系统不会被冲击崩溃。

负载均衡解决方案已经是业界比较成熟的方案，通常分为硬件负载均衡和软件负载均衡。

  • 硬件负载均衡需要在服务器节点之间安装专门的负载均衡设备，常见的有交换机、F5等。
  • 软件负载均衡的解决方案很多，常见的有LVS、Nginx等，我们通常会针对特定业务在不同环境中进行优化。

以Nginx为例，它提供一个成熟的、可扩展的、高性能Web服务器和反向代理，Nginx便于部署、配置和二次开发，并可管理授权、权限控制、负载均衡、缓存及提供应用健康检查和监控。

负载均衡的网络消息转发一般集中在传输层和应用层。

  • 传输层在OSI七层模型中位于第四层，业界也常称之为四层负载均衡，它是基于IP地址和端口号进行负载均衡的，常见的有F5和LVS等产品。
  • 应用层在OSI七层模型中位于第七层，因此集中在应用层的负载均衡是基于URL和请求头等应用层信息进行负载均衡的，常见的有Nginx，过程中还会包括SSL、Web应用防火墙等特性。

在云服务广泛使用的今天，还有一种负载均衡的策略是把资源尽可能向消费者侧分布，这里的典型代表是内容分发网络（Content Delivery Network，CDN），这是一种用于内容分发的虚拟网络。依靠部署在各地的边缘服务器，CDN通过负载均衡、内容分发、调度，可以让用户就近获取所需内容，从而缓解网络拥塞，提高访问速度和命中率。

负载均衡算法有很多，大体上分为静态的和动态的两大类。

  1. 静态负载均衡算法：随机算法、轮询算法、加权轮询算法。
  2. 动态负载均衡算法：最少连接数算法、服务调用时延算法、源地址哈希算法。

API网关

API网关一般作为后台服务的入口，企业需要特别关注，API网关主要具有以下作用。

  • 门户功能：提供统一服务入口。
  • 隔离作用：作为服务的应用边界，防止腐化。
  • 解耦作用：使微服务各方独立、*、高效、灵活。
  • 路由功能：应对外部应用，提供前端应用的路由能力。
  • 封装功能：封装服务内部结构，为各个客户端提供API。
  • 脚手架功能：提供便于扩展的注入点，包括授权、过滤、流量控制、监控、负载均衡等。

在进行API网关设计时需要考虑如下能力。

  1. 需要考虑流量调度的问题，比如如何将入口的流量路由到后段，如何从后段服务中进行负载均衡，如何将流量在多个实例间按比例或者按其他策略分发。
  2. 需要考虑调用轨迹与调用监控，这样可以及时发现问题。
  3. 需要考虑安全问题，要有良好的安全策略，从而把非法访问拦截在外，比如采取认证鉴权、黑白名单等。
  4. 需要考虑一些流量控制手段，比如限流机制、熔断机制、流量染色等。基于此，一个良好设计的API网关内部可能由多种能力组件构成，比如服务路由组件、协议转换组件、流量控制组件、负载均衡组件、认证监控组件、数据缓存组件、超时熔断组件、自动告警组件、API网关管理台等。
  5. 需要关注高可用、安全性、高性能、扩展性、服务目录管理、API全生命周期管理。

API目前设计是将RESTful作为约定规范，RESTful主要基于HTTP定义API，有以下常见的HTTP请求方法。

  • Get：用于检索并获取位于指定URI处的资源。
  • Post：用于在指定的URI处更新资源。
  • Put：用于在指定的URI处创建或更新资源。
  • Delete：用于删除指定URI处的资源。
  • Patch（Update）：对资源局部进行更新。
  • Head：获取资源的元数据。

其中，Post、Put和Patch很容易弄混。Post请求用于创建资源，Put请求用于创建资源或更新现有资源，Patch请求用于对现有资源的局部进行更新。Put请求必须是幂等的，如果客户端多次提交同一个Put请求，那么结果应始终相同，而Post和Patch请求没有这样的要求。

常用的API网关产品如下所示。

  • Apigee：提供API管理软件，包括API平台管理、API分析、开发者工具、数据分析等。
  • Amazon API Gateway：Amazon托管式服务，提供二次开发平台，让开发者创建、发布、维护、监控和保护任意规模的API。
  • 阿里云API网关：提供API托管服务，覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等API各个生命周期阶段。
  • Zuul：Spring Cloud体系中的API网关。
  • Mashape Kong：可扩展的开源API层工具。

配置中心

一般在系统的配置管理中，会有以下几个问题。

  • 在分布式系统中，应用和机器的数目众多，单个应用的不同配置需要分发在多台机器上，各应用之间存在复杂的配置依赖，如系统启动时所需要的启动数据和预加载信息、数据库连接信息、连接池信息、权限管理数据、用户信息等。
  • 各种配置的存储方式和版本不同，比如XML、YML、Property文件，注册表，数据库等。
  • 在传统架构的应用发布过程中，修改一个应用配置需要将整个应用重新打包发布，过程烦琐且容易出错。

配置中心的目的就是解决上述问题，统一集中管理系统和服务的配置。

图例：配置中心

配置的三要素：

  • 快速传播
  • 变更不频繁
  • 与环境相关

在配置管理的过程中，为了优化配置中心的质量，可以考虑以下方案

  • 为了增加读的性能，有时使用本地缓存或者集中式缓存，不过需要注意数据的一致性；
  • 为了提高实时性，企业可以使用心跳监听和定时同步的机制；
  • 为了提高可用性，可以使用冗余服务、缓存等机制。

配置中心的非功能性需求是配置的安全性、实时性、动态管理、版本管理、环境与应用解耦、高可用、灵活性、可靠性、可用性、审计功能。

配置中心一般包含以下组件。

  • 配置中心端：提供配置获取、更新接口，以及动态异步推送接口，支持配置更新的实时化通知。
  • 客户端：管理客户端配置响应，比如自动Reload、动态上报等。
  • 配置管理界面：提供配置管理界面，包括配置的修改、发布等，配置存储，响应的上传、下载、更新等，以及实时通知客户端等。

常用的配置中心技术产品如下所示。

  • Nacos：开源技术，致力于打造一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。目前，Nacos主要包含分布式配置中心、服务注册与发现能力。
  • 应用配置管理（ACM）：Nacos的商业化版本，是一款在分布式架构环境中对应用配置进行集中管理和推送的产品。与Nacos相比，其具备高可用与高性能、敏感配置的安全保障、支持灰度发布等。

服务治理

服务治理主要包括服务注册与发现、弹性伸缩、流量控制、灰度发布、任务调度等。

服务注册与发现

服务注册与发现指的是使用一个注册中心来记录分布式系统的全部服务信息，以便让其他服务能够快速找到这些已注册的服务。

服务注册与发现的本质是服务路由。服务路由可以分为直接路由和间接路由。

  • 直接路由需要服务消费者感知服务提供者的地址信息，比如基于配置中心或者数据库来存储目标服务的具体地址。直接路由的缺点是消费者直接依赖提供者的地址，增加了彼此的耦合度，同时配置中心或者数据库本身需要额外的维护成本。
  • 间接路由体现了解耦的思想，本质是一种发布-订阅模式。

图例：服务注册与发现示意图

  • 在服务注册的过程中，服务实例将自己的服务信息（如端口、服务名等）注册到服务注册中心，服务注册中心将服务信息及服务健康状态通过API暴露出来。
  • 服务消费者通过服务注册中心获取到服务实例信息，去请求服务提供者提供服务。当服务地址发生变化时，服务注册中心将服务变化推送给服务消费者，同时服务消费者会配置缓存机制以加速服务路由，特别是当服务注册中心不可用时通过本地缓存实现服务的可靠调用。
  • 此外，服务注册与发现还需要对服务实例的健康状态进行实时监控，当服务实例不可用时，将通知各服务消费者移除无效服务实例。
  • 另外，一个服务可能存在多个服务实例，需要根据不同的负载均衡算法来保持均衡。

服务发现主要包括以下组件。

  • 服务注册中心：进行服务注册、销毁等。
  • 服务发现组件：服务目录查询、服务地址查询。
  • 本地服务缓存库：一般在客户端，暂时缓存获取的服务信息。
  • 注册中心服务存储库：存储服务信息，如KV存储服务配置信息。
  • 服务管理平台：后台管理服务集群的状态，监控服务异常，检查服务注册信息，进行统计分析等。

服务注册与发现需要考虑以下因素。

  • 高可用问题：服务注册中心需要保持7×24小时的稳定运行，特别是当新增、移除服务时应避免对其他服务造成影响，同时需要消除单点故障，采用数据库持久化和服务集群方式。
  • 数据一致性：注册中心的节点维护已注册的服务列表，同一份数据不能出现读写数据不一致的情况。
  • 实时性：对注册的服务进行心跳检测，确保在注册中心的服务信息是实时的、准确的，如有数据变更及时通知服务消费者。
  • 高性能：服务提供者根据不同的算法来平衡负载。
  • 监控性：提供监控负载能力，监听注册中心服务器的状态、资源情况、负载程度。
  • 兼容性：比如与其他组件的兼容能力，提供统一的注册中心，如Dubbo、Spring Cloud、Kubernetes、Service Mesh等。

对于常见的服务注册与发现技术组件，业界已经有了很多成熟的方案。

  • DNS：最早的服务发现实现，适用于小规模单体应用，如Spotify(中文链接)。
  • Eureka：Spring Cloud体系，自定义构建，具有最终一致性，Java体系。
  • Nacos：除了具备配置中心能力，也提供服务注册与发现的能力。
  • Zookeeper：通用注册中心能力，配置存储方案，Java体系。
  • Consul：支持跨数据中心，具备KV模型存储和健康检查能力。

弹性伸缩

弹性伸缩指的是在分布式集群中，通过服务探针、监控应用、服务状态，以及一些系统的指标，根据指定的规则自动调整服务实例的数量。

在传统的方式中，如果需要增加机器资源，需要找运维人员申请机器，然后部署好软件服务接入集群，整个过程依赖的是运维人员的自身经验，容易出错。比较理想的方式是通过一定的机制和工具，辅助我们自动进行弹性伸缩。

在弹性伸缩中，有两个核心，即扩容和缩容。

  • 扩容指的是在监控到服务容器出现瓶颈，包括负载、CPU、RT指标紧张时，能够自动将服务实例增加到集群中。
  • 缩容指的是在监控到服务容器负载减少，出现资源浪费时，自动释放服务实例，从而降低成本。

在扩容和缩容的过程中，需要结合很多服务的信息，充分结合应用的入口流量进行控制，让系统的入口流量和系统的负载达到一个平衡，一些扩容和缩容的指标参考如下。

  • Load：当系统Load超过阈值，并且系统当前的并发线程数超过预计的系统容量时触发。
  • CPU使用率：当系统CPU使用率超过阈值时触发。
  • RT：当单台机器上所有入口流量的平均RT达到阈值时触发。
  • 线程数：当单台机器上所有入口流量的并发线程数达到阈值时触发。
  • 入口QPS：当单台机器上所有入口流量的QPS达到阈值时触发。

在弹性伸缩的过程中，需要密切关注系统的稳定性，系统能够稳定地处理潜在的故障并从故障中恢复。在分布式系统中，瞬态和更永久性故障都是有可能的。为了保持弹性，必须快速、有效地检测故障并进行恢复，比如隔离、重试、限流降级、故障恢复等。

流量控制

流量控制（Flow Control）简称流控，根据流量、并发线程数、响应时间等指标，把随机到来的流量调整成合适的形状（流量塑形），从而提高系统的高可用防护能力。流控可能包括系统的不同层次，比如对网关入口、应用级别、服务依赖、系统资源等各个方面加以控制。

流控的根本目的是高可用，大型分布式系统对高可用有很高的要求，客户始终希望系统能提供7×24小时不间断服务。高可用（Availability）的计算公式如下所示。

Availability = MTTF/(MTTF + MTTR)

影响系统可用性的指标主要有两个：

  • MTTF（Mean Time to Failure，不出故障的时间）
  • MTTR（Mean Time to Recovery，出故障后的恢复时间）

因此要提高系统的可用性，可以从两个方面入手：

  1. 尽量增加无故障时间
  2. 尽量缩短出故障后的恢复时间

业界通常用N个9来量化可用性，如“4个9（也就是99.99%）”的可用性，也就是，一年下来网站不可用时间约为53分钟（也就是不足1小时）。

可用性(通俗叫法) 可用性比率 年度停机时间
2个9 99% 87.6小时
3个9 99.9% 8.76小时
4个9 99.99% 53.6分钟
5个9 99.999% 5.36分钟

分布式系统是由不同组件构成的，包括复杂均衡、应用、缓存、消息、配置、数据库、存储、基础设施等；每个组件又有不同的技术，比如分布式应用可以使用SpringCloud、Dubbo或者HSF；每种技术又有自己的特点，如性能、自动扩展、恢复、容灾。

总体来说，从流量控制角度，提高高可用的方法可以大致分为冗余、自愈、限流、降级等。

  1. 冗余。提升高可用最主要的方法是冗余，增加机器，分担压力，降低风险。同一服务部署在多台服务器上；同一数据存储在多台服务器上互相备份。当任何一台服务器宕机或出现不可预期的问题时，就将相应的服务切换到其他可用的服务器上。这样，即使单个机器出现问题，也不影响系统的整体可用性，从而保证业务数据不丢失。

    • 冗余的方式可以是双机或集群。
      • 双机有主备、主从和双主模式
      • 集群在双机的基础上，增加了备机、从机或其他主机的个数（比如一主多从、一主多备、多主等）
    • 冗余高可用的关键点是考虑多机器之间的数据复制、状态检测、调度分配、选主切换等。

  2. 自愈。自愈主要体现在系统出现问题时，系统快速恢复，不影响业务的可用性。自愈通用的方式是超时、重试、回滚、数据恢复等。

    • 超时：当调用服务时，调用方不可能无限制地等待提供者接口的返回，一般会设置一个时间阈值，如果超过了时间阈值，就不再继续等待。
    • 重试：超时时间的配置是为了保护调用方，避免因为服务提供者不可用而导致调用方也不可用。但也有可能提供者只是偶尔“失灵”，在这种场景下，我们可以在超时后重试一下，保证服务的正常调用。重试需要考虑两个方面：一方面，可以采取一些策略，比如考虑切换一台机器来调用，避免原机器出现性能问题；另一方面，需要考虑幂等，即同一个请求被客户多次调用，对“失灵”产生的影响（这里的影响一般指某些与写入相关的操作）是一致的，而且这个幂等应该是服务级别的，而不应是某台机器层面的，重试调用任何一台机器，都应该做到幂等。
    • 回滚：通过版本控制进行稳定版本的回滚恢复，包括应用回滚、基线回滚、版本回滚等。在应用回滚之前需要保护好故障现场，以便排查原因；在应用回滚后，代码基线也需要回到前一版本。整体回滚需要服务编排，通过大版本号对集群进行回滚。
    • 数据恢复：在故障发生后，系统保证数据不丢失。比如数据节点从一台机器切换到另一台，需要保证节点之间的数据一致。当然根据实际业务高可用的SLA，可以保证最终一致，比如在主备数据复制过程中，允许短暂的主备数据不一致，但最终保证一致性。数据恢复有时对机器磁盘有要求，比如尽量做RAID（磁盘阵列），使用SSD/SAS，保证容量充足，避免因硬件因素造成数据丢失。

  3. 限流。限流类似于我们日常生活中的排队，比如在上下班高峰期的地铁站，上班族通过“蚊香”式排队等待地铁。限流的策略可分为限制访问的绝对数量和控制流速。限制总数可通过设置规则来实现，目前常见的限流算法有计数器限流算法、漏桶算法和令牌桶算法。在分布式系统中，限流可通过服务限流和资源隔离等方式实现。

    • 服务限流：为了保护系统应用提供者，监控入口流量的QPS或线程数，当达到阈值时立即拦截流量，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。在限流后可以采取以下方式：直接给调用方返回缓存、固定数据或直接拒绝；需要实时写入数据库的，先缓存到队列里，后续或异步写入数据库。
    • 资源隔离：隔离是对问题故障的有效控制，可以防止故障恶意扩散。类似于病毒隔离，在分布式系统中，可以通过不同角度进行隔离，可以是机器角度，分为线程、进程、容器、单机、集群、分区等；也可以是功能角度，比如读写隔离等。

  4. 降级。限流主要从应用服务提供者的角度进行保护，而降级主要从应用服务调用者的角度进行保护，因为调用者可能依赖后端很多服务，但有可能某一个服务经常异常、超时或出现数据错误，为了保护调用者，则对有异常的提供者进行降级。降级的具体实施既可以是代码自动判断，也可以是人工根据突发情况切换，一般可采用关闭非核心服务、降低一致性约束、简化功能等方式。具体地，降级可分为依赖降级和熔断降级。

    • 依赖降级：调用者监控到下游依赖异常（如响应时间、错误率），并且达到指定的阈值，立即降低下游依赖的优先级，采用备用逻辑（如错误页面、固定返回值），避免应用受到影响，从而保障应用的高可用性。在此过程中，建议集中管理降级开关，并尽量前置化。
    • 熔断降级：熔断降级是在依赖降级的基础上执行的，当服务提供者调用大量服务超时或失败时，应该熔断该服务的所有调用，并且将后续调用服务直接返回，从而快速释放资源，确保在目标服务不可用的这段时间内，所有对它的调用都为立即返回。熔断降级可以理解为依赖降级的升级，是系统可用性的“保险丝”。
      • 熔断可分为三个状态：
        • 第一，Closed（闭合）状态，这是正常状态，系统需要一个基于时间线的错误计数器，如果错误累计达到阈值则切换至Open状态
        • 第二，Open（断开）状态，对所有服务请求立即返回错误，不用调用后端服务进行计算
        • 第三，Half-Open（半开）状态，允许部分请求流量进入并进行处理，如果请求成功则按照某种策略切换到Closed状态。
      • 熔断的设计要点是需要定义错误类型、有标准的日志输出、有服务诊断及自动恢复能力、设置开关（用于三种状态的切换）、做到业务隔离。

在流量控制的过程中，需要把握一个总体原则，即“恢复业务优先原则”。线上业务故障，需要优先恢复业务，再分析问题。如果系统不能自动恢复，则应想尽一切办法进行限流、隔离或降级，比如下线有问题机器，对问题业务进行降级或资源隔离，在恢复业务后，再进行信息搜集（如日志、堆栈、抓包、截屏等），后续分析根因并优化系统。

为了更自动化地进行流量控制，可以构建统一的服务治理平台，一般包含以下几个部分。

  • 服务管理平台：比如管理服务依赖，通过关系图的形式展现，涉及相关的负责人，服务上下线的审批管理，服务的SLA管理，调用统计，白名单管理等。
  • 服务稳定性平台：比如冗余、自愈、限流、降级等相应的配置，流量控制的分流管理，请求堆积的处理，通过熔断配置防止服务雪崩等。
  • 稳定性故障演练：比如全链路压测、大促秒杀活动、稳定性预案处理，在特殊情况下，还需要做一些故障演练、快速恢复等稳定性综合能力建设。故障大概可以分为依赖服务故障（如依赖的中间件、数据库、缓存等实施一些网络丢包、网络延时）、应用层故障（应用本身故障，如宕机、假死、重启等）、系统层故障（如系统CPU、内存、磁盘、网络）等。

流量控制常用的一些技术如下所示。

  • Sentinel：开源限流系统，基于QPS限流，支持多种降级策略和数据源类型，系统自适应保护，支持控制台。
  • Hystrix：Spring Cloud体系，基于线程池和信号量隔离，提供简单的控制台能力。
  • Resilience4j：基于信号量隔离，通过Rate Limiter模型限流，不提供控制台能力。
  • AHAS：Sentinel的商业化版本，专注于提高应用及业务高可用的工具平台，提供应用架构探测感知、故障注入式高可用能力评测和流控降级高可用防护三大核心能力。

灰度发布

在分布式系统中，发布非常频繁，其中灰度发布是一种发布策略，其让我们的发布按照一定的策略和节奏进行。灰度发布技术适用于两个不同版本同时在线上并行的场景，既可用于业务试错，也可用于版本发布。

灰度发布需要解决两个方面的问题：

  • 一是多版本部署，分为客户端部署和服务端部署
  • 二是流量切分，包括入口流量切分（服务器权重、IP地址段或用户标签）和服务流量切分（服务发现机制、植入流量切分规则、控制流量方向） 

图例：灰度发布示意

灰度发布是一种部署策略，从不同版本发布节奏及流量状态方面，我们也常用一些其他的术语来表达，比如停机部署、滚动发布、蓝绿部署、A/B测试等，这些术语有所不同，这里不做详细说明，但本质都是对不同版本应用服务升级的部署策略。

任务调度

任务调度是分布式系统不可缺少的一个环节，传统的方式是在Linux机器上配置定时任务或者直接在业务代码里面完成调度业务，现在多用成熟的中间件来代替。

任务调度需要支持灵活的任务处理能力，定时的调度器，比如Cron规则、固定延迟、时区、日历等；支持可视化的任务编排，解决任务有前后依赖的情况；支持多种语言（如Java、Python），同时支持静态分片，提供Java动态分片，支持失败自动重试，还可以在控制台手动原地重试，并且具备丰富的报警功能，比如任务失败报警、超时报警、服务缺失报警。

一些通用的任务调度中间件如下所示。

  • Spring Batch：Spring体系的轻量级批处理框架，支持记录/跟踪、事务管理、作业处理统计、作业重启和资源管理。
  • SchedulerX：阿里巴巴自研的基于Akka架构的新一代分布式任务调度平台，具有高可靠、秒级调度及可运维等能力。

监控体系

监控分层

分布式系统是由多个机器共同协作的，同时网络无法保证时刻可用，因此需要建设一套能够监控的系统，从底层到业务各个层面进行监控，并基于监控及时修复故障。监控一般包括收集、处理和汇总，并且显示关于某个系统的实时量化数据，如请求的数量和类型、错误的数量和类型，以及处理用时、应用服务器的存活时间等。

从监控能力层次上，一般我们可以从以下方面对系统进行监控。

  • 基础监控：基础监控是对容器资源的监控，包含各个硬件指标的负载情况，比如CPU、I/O、内存、线程、吞吐量等。
  • 中间件监控：如中间件、缓存、数据库等组件的相关QPS、RT、成功率等。
  • 服务监控：比如应用的性能监控，对核心应用服务的实时指标（QPS、RT、成功率、异常数）、上下游依赖等进行监控，以及监控服务画像、服务拓扑关系、服务调用链、版本信息、服务组件内部状态等。
  • 业务监控：除了应用本身的监控程度，业务监控也是保证系统正常的关键。企业可以根据业务规则对异常情况做报警设置，基于日志、异常、错误码Top N等统计和告警；或者进行业务层面的统计，比如分钟级下单数量。
  • 数据监控：基于数据查询、数据一致性和稳定性的监控，包括超时、积压、资损对账等方面，确保业务和应用数据层面的稳定和一致。

日志（Logging）、指标（Metrics）、追踪（Tracing）是监控体系的核心元素。

  • 日志：描述的是一些不连续的离散事件，包括日志采集、日志分析和告警通知。例如，有些业务系统采用ELK（Elasticsearch+Logstash+Kibana）或类似技术栈的日志收集系统，它们是分布式监控系统的早期形态，借鉴了传统的解决问题方式。
  • 指标：可以累加，具有原子性，包括指标监控、健康检查和告警通知。每个指标都有一个逻辑计量单元，体现了一段时间内相关指标的状态。
  • 追踪：也就是分布式调用链路，指在单次请求范围内处理信息，数据和信息都被绑定到系统的单次链路上，包括分布式调用和告警通知。调用链路近年来格外受人们关注。

日志、指标、追踪的关系如图7-15所示。这三个概念并不是相互独立的，往往一个监控体系都会涉及一些。APM（应用性能管理）系统便是三者一体化的解决方案，充分理解三者的关系，可以更好地理解监控的本质，以及更好地定位开源和商业化监控工具。

监控系统的一些通用原则如下所示。

  1. 关注业务黄金指标：比如延迟、流量、错误、饱和度，以及相关的QPS、成功率、RT。
  2. 留意系统基础指标：系统基础指标包括CPU、Load、内存、流量、网络丢包、重传率、磁盘I/O等，以及JVM的GC次数和时间、Java线程数、Java堆内存使用情况等。
  3. 告警阈值设计合理：监控系统信噪比高，发出紧急警报的组件简单且可靠，可以防止大量无效告警。
  4. 简化监控告警：监控规则应该越简单越好，可预测性强，非常可靠。
  5. 监控系统长期优化：随着业务系统和架构的升级，需要对监控系统进行相应的优化。

基础监控常用的技术工具如下。

  • Zabbix：基于Web界面的分布式系统监视及网络监视功能，提供企业级开源解决方案。
  • Newrilic：提供功能Rails性能检测服务的网站，提供不同级别的监测功能。
  • Tsar：系统信息跟踪工具，主要用来收集服务器的系统信息（如CPU、I/O等）及应用数据（如Squid、Haproxy、Nginx等）。

日志分析

企业系统每天会产生海量日志，日志信息增长迅速。为了解决信息存储容量、数据安全、日志搜索分析等问题，需要分布式日志监控系统来进行发掘、分析、判断并形成定性或定量描述。

日志系统一般需要包含以下组成部分。

  • 日志收集：收集各类日志，发送到日志中心，并形成不同类型的日志。
  • 日志缓冲：不同类型的日志需要有不同的目录空间，形成不同的主题。
  • 日志处理：对从原始数据到检索格式进行转化，从日志中抓取关键字，判断并写入索引中。
  • 日志存储：存储到数据库中，并对存储结构进行定义。
  • 日志展示：UI展示日志统计、查询结果等。

一些常用的日志分析工具如下。

  • Elasticsearch：ELK组成之一，是基于Lucene的搜索服务器，提供一个分布式多用户的全文搜索引擎，基于RESTful Web接口。
  • Logstash：ELK组成之一，是一个应用程序日志和事件传输、处理、管理和搜索的平台，可以统一对应用程序日志进行收集和管理，并提供统一接口查询。
  • Kibana：ELK组成之一，是一个开源的分析和可视化平台，提供搜索、查看，并与存储在ES中数据进行交互，以及提供各种图标、表格和地图等工具。

链路追踪

针对分布式系统复杂的调用链路，如何快速、准确地定位服务异常位置？如何跟踪处理结果？如何将技术与业务异常高效结合？这需要分布式调用链路的监控。

分布式调用链路把调用过程记录下来，关注各个调用的性能指标，比如吞吐量、响应时间及错误记录等。调用链路从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，方便度量整体和局部性能，找到故障产生的原因，缩短故障排查时间。

在链路追踪的历史中，关键事件是2010年Google Dapper论文的发表，之后各个厂商依据Dapper纷纷研发了自己的调用链监控工具，比如携程的CTrace，韩国公司Naver的PinPoint，Twitter的Zipkin，阿里巴巴的Eagleye，京东的Hydra。接着产生了调用链监控的标准规范Open Tracing，目的是通过兼容、统一的API来进行链路追踪，Uber的Jaeger、Apache SkyWalking也均符合Open Tracing规范。

调用链每个请求生成一个全局TraceID，通过TraceID可以连接起整个调用链。此外，SpanID用于记录调用复杂关系，整个调用过程中每个请求都要透传TraceID和SpanID。所有这些ID可用全局唯一的64位整数表示。每个服务将该次请求附带的TraceID和附带的SpanID作为Parent ID，并且记录自己生成的SpanID。要查看某次完整的调用只要根据TraceID查出所有调用记录即可。

图例: 调用链示意图

一个通用的链路处理，一般采用这样的架构和技术组件。整个过程是对调用链数据定义、生成、采集、计算、存储的过程。

图例: 通用的调用链组件架构

比如采用ELK和HBase，通过Agent生成调用链日志，通过Logstash采集日志到MQ；MQ负责提供数据给下游消费，Storm计算汇聚指标交给Elasticsearch，Logstash将MQ的数据明细给到HBase中，根据TraceID作为行键进行快速查询。  常用的链路最终方案如下所示。

  • Zipkin：Twitter公司的Zipkin是Google Dapper的开源实现，采用Scala编写，集成到Twitter的分布式服务Finagle中，涵盖信息的收集、处理和展现。
  • Pinpoint：Naver开源的Pinpoint是一款用Java编写的大规模分布式调用链系统，追踪每个请求的完整调用链路，收集性能数据，支持大规模服务器集群。

应用性能监控

APM的全称是Application Performance Management，指的是对应用程序的性能和可用性的监控管理。

  • 狭义上的APM单指应用程序的监控，如应用的各接口性能和错误监控，分布式调用链路跟踪，以及其他各类用于诊断（内存、线程等）的监控信息等
  • 广义上的APM除了包括应用程序的监控，还包括移动端App监控，页面端监控，容器、服务器监控，以及其他平台组件（如数据库）等层面的监控

APM是伴随着云技术、微服务架构发展起来的一个新兴监控领域。

在国内外，无论是开源的Apache SkyWalking、云厂商（如AWS、Azure等），还是独立的公司（Dynatrace、Appdynamics等），都有着非常优秀的APM产品，比如阿里云的ARMS。

目前，人们对APM的要求越来越高，比如分布式追踪、非侵入式的语言探针、轻量化、低延时分析，这些是对APM提出的进一步要求。

展示了APM的主要能力，一般包括以下几项。

  • 应用一般对外提供两种客户端访问模式：移动端App访问，基于浏览器的页面访问。
  • 部署相应的业务探针，通过API来直接测试服务性能或进行健康检测。
  • 对客户端直接提供服务的为后端应用服务程序。
  • 后端应用一般运行在容器里，进一步使用容器技术来优化开发和运维。
  • 应用还会直接依赖各类的PaaS/SaaS云服务，对应用提供相应平台服务，从而简化应用的运维成本。

性能分析

分布式系统的性能指标，一般包括以下几个方面。

  • 从广义上来讲，可能有多个方面，比如QPS、高可用（如99.99%）、响应时间、客户体验、数据一致性、可扩展性、容错性等；
  • 从狭义上来讲，我们常用业务QPS来表达系统性能，即在满足一定客户体验的前提下，在一定机器资源环境下，系统所能够承载的最大业务处理能力，通常用每秒处理的事务数QPS来表示。

性能优化是一个系统工程，是无止境的，需要有明确的目的和思路，并结合实际的业务来进行，这里给出一些通用的参考。

  • 梳理业务目标：重点分析核心的业务流程和应用功能，比如秒杀大促、交易链路等的GMV（商品交易总额）、DAU（日活跃用户数量）、订单数等。不同的业务目标，系统所承载的压力不同。
  • 梳理系统架构：总体把控系统架构，比如产品、组件、组网、技术选型等多方面架构。
  • 确定性能问题：明确要优化的问题及其指标，比如QPS、RT。
  • 确定优化目标：明确现状和目标。
  • 确定解决方案：方案可能有多种，需要综合分析各方案的优缺点，多方评审和讨论并选择一个，比如可以有如下的优化思路：
    • 从拆分角度，可以有垂直拆分、水平拆分、分库分表、读写分离；
    • 从QPS角度，可以有异步化、批量化、拆分；
    • 从高并发角度，可以有伸缩扩容、拆分、异步、缓存、限流降级；
    • 从可扩展角度，可以有无状态设计、伸缩、拆分等。
  • 测试解决方案：综合测试方案，为整个应用程序创建性能测试套件。
  • 分析调优结果：综合分析，调优也是个循环过程，逐步优化，达到目标。

从技术角度，性能问题可能发生在系统的网络、服务端（基础设施、操作系统、中间件、数据库）、客户端，可以采用如图7-19所示的方法。

  • 网络：一般指的是防火墙、动态负载均衡器、交换机等设备。很多情况是因为网络不同，比如SLB、WAF、CDN加速，VPN等配置问题，或者更为粗暴的网络光缆切断。
  • 客户端：主要是客户应用与服务端的版本或通信问题。
  • 服务端：分布式系统大部分问题发生在服务端。
    • 在硬件层面，比如基础设施中常见的CPU满、内存满、磁盘满，操作系统的参数配置等。
    • 在软件层面，
      • 一是业务应用问题，主要是业务逻辑（多数情况是程序本身设计问题，比如大对象调用、多层嵌套循环、串行处理、请求的处理线程不够、无缓冲、无缓存）和应用配置问题（JVM、线程池、连接池配置不足）；
      • 二是系统平台问题，比如中间件方面的服务框架、消息异步设计、服务注册与发现性能、日志采集异常等，以及数据库的缓存、SQL等配置优化（如JDBC）。

图例：性能优化分析方法

性能优化的一些通用工具如下。

  1. 压力测试工具JMeter。JMeter是Apache组织开发的基于Java的压力测试工具。它可以用于测试静态和动态资源，如静态文件、Java服务程序、CGI脚本、Java对象、数据库、FTP服务器等。JMeter可用于对服务器、网络或对象模拟巨大的负载，在来自不同压力类别下测试它们的强度和分析整体性能。另外，还可以尝试阿里云的SaaS性能测试平台PTS，简化业务场景的构建，为性能问题定位、容量最佳配比、全链路压测的流量构造提供帮助。
  2. Dapper调用链分析。分布式系统中的服务很多，也有很多跨进程、跨线程的场景，汇总收集并分析海量日志尤为重要。分布式调用链分析的目的是追踪每个请求的完整调用链路，收集调用链路上每个服务的性能数据，计算性能数据并比对性能指标，甚至在更远的未来能够反馈到服务治理中。相关的调用链分析可参考前文，比如EagleEye工具。
  3. Arthas应用在线诊断工具。Arthas是阿里巴巴中间件团队基于Greys开发的全新在线诊断工具，采用命令行交互模式，使得在定位、分析、诊断问题时看每一个操作都非常便捷，可以跟踪到每一行代码的执行时间，有助于查找定位系统的性能瓶颈。
    • Dashboard——当前系统的实时数据面板。
    • Monitor——方法执行监控。
    • Trace——方法内部调用路径，并输出方法路径上的每个节点上耗时。
    • Stack——输出当前方法被调用的路径。
    • tt——方法执行数据的时空隧道，记录下指定方法每次调用的入参和返回信息，并能对这些不同的时间下调用进行观测。

消息队列

分布式消息队列系统是消除异步带来一系列复杂步骤的一大利器，通过消息队列既可以解耦系统，又可以削峰填谷等。在消息服务中，消息是由生产者创建的数据，并且会被分发出去，由消费者接收并进行进一步处理。

生产者和消费者之间通过消息代理（又称消息传递中间件）进行通信。

图例：消息服务示意图

消息队列使用的应用场景如下所示。

  • 削峰填谷：诸如秒杀、抢红包、企业开门红等大型活动时皆会带来较高的流量脉冲。
  • 异步解耦：交易系统中每笔交易订单数据的产生会引起数十个或者上百个下游业务系统的关注，包括物流、购物车、积分、流计算分析等，整体业务系统庞大且复杂，通过消息服务实现异步通信和应用解耦，确保主站业务的连续性。
  • 顺序收发：企业中需要保证顺序的应用场景非常多，例如证券交易过程的时间优先原则，交易系统中的订单创建、支付、退款等流程，航班中的旅客登机消息处理等。顺序收发与先进先出（First In First Out，FIFO）原理类似。
  • 分布式事务一致性：交易系统、支付红包等场景需要确保数据的最终一致性，大量引入消息队列的分布式事务，既可以实现系统之间的解耦，又可以保证数据的最终一致性。
  • 大数据分析：数据在“流动”中产生价值，传统数据分析大多基于批量计算模型，而无法做到实时的数据分析，将消息队列与流式计算引擎相结合，可以实现业务数据的实时分析。

从技术角度，消息服务具备高性能、高可用、高可靠等特点。

  1. 高性能：消息发送方将耗时较长且无须实时处理的操作封装为消息，并将消息发送给消息队列服务。发送方无须等待消息被消费方处理完，就可以继续做其他事情，从而提高性能。
  2. 高可用：消息队列服务及集群的方式部署，常见的有一主多备或双主双备等。当一台消息队列服务“挂掉”后，另一台消息备份服务可以及时对外提供服务。
  3. 高可靠：消息队列服务提供了极高的可靠性，保证消息集群可靠和稳定，同时可以通过进一步的服务幂等性，进一步提高整体的可靠性。此外，消息队列服务会执行消息的持久化，包括同步双写和异步复制，保证了数据的高可靠性。

一些常见的消息队列技术或产品如下。

  • Kafka：由Scala编写的分布式、分区的、多副本的、多订阅者的分布式MQ系统，可用于Web/Ngnix日志、搜索日志、监控日志、访问日志等，具备提供消息的持久化、高吞吐量等特点。
  • RabbitMQ：由Erlang开发的高级消息队列协议（AMQP）的开源实现，具备可靠性、灵活路由、消息集群、高可用、多种协议等特点。
  • RocketMQ：基于Apache RocketMQ构建的低延迟、高并发、高可用、高可靠的分布式消息中间件，支撑千万级并发、万亿级数据洪峰。
  • ActiveMQ：Apache下开源项目，支持多语言Client，支持JMS和J2EE规范、支持多种传输协议，支持Spring、Ajax、Axis等的整合。
  • IBM MQ Series：广泛应用在硬件和软件平台，提供确定、异步、一次性数据发送的通信系统。
  • Microsoft MQ：微软消息队列，提供应用间互相通信的异步传输服务。
  • ZeroMQ：一个开源的高性能、异步、分布式的消息队列，支持多种语言，具备高性能、可靠性、可扩展性等特点。

微服务技术框架

微服务框架本身是一个体系的框架，包括负载均衡、配置管理、服务注册与发现、服务安全、分布式监控、流量调度与容错、弹性伸缩、任务调度等多方面，一个稳定的微服务框架可以简化开发管理和技术选型，一些常用的微服务框架如下。

  • Spring Cloud：基于Spring Boot实现的应用开发工具，提供微服务开发所需的配置管理、服务发现、断路器、路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件，是微服务框架的标准。它由很多子项目组合而成，应用开发者可以根据自己的需求灵活地将各种组件搭配使用。Spring Cloud遵循如下设计理念：约定优于配置，建议在熟悉的约定前提下，简单、标准化地构建应用；提供声明式的元注解配置方式，屏蔽组件具体的实现复杂度；提供丰富的组件，比如与大量的服务治理相关的组件，同时相对中立，有不同的实现方案；灵活的解耦。各种服务组件完全解耦，企业可根据需要灵活组合和替换。
  • Netflix：是对Spring Cloud框架的一种实现，包括服务注册与发现框架Eureka、API网关Zuul、服务端框架Karyon、客户端框架Ribbon、服务容错组件Hystrix、配置中心Config/Vault、服务容错Hystris、分布式追踪Sleuth等。
  • Spring Cloud Alibaba：也是对Spring Cloud框架的一种实现，比如服务发现与配置管理Nacos、限流降级Sentinel、分布式消息系统RocketMQ、分布式事务Seata、动态追踪工具Arthas等。
  • Dubbo：Alibaba开源的分布式服务框架，基于RPC方式，基于分布式服务调用简化服务提供方和调用方的开发，同时具有注册中心、协议支持、服务监控等能力。
  • 企业级分布式应用服务（Enterprise Distributed Application Service，EDAS）：是一个应用托管和微服务管理的云原生PaaS，提供应用开发、部署、监控、运维等全栈式解决方案，同时支持Spring Cloud和Dubbo等微服务运行环境。

技术架构最佳实践

下面从最佳实践角度，介绍技术架构中一般需要考虑的设计点。

一致性理论

一致性在分布式架构，特别在微服务架构中特别重要。我们先来看看一致性的通用理论，再看看一些常见的一致性方案。

强一致性：ACID

强一致性的保障，比如传统单机数据库内的事务一致性，强一致性的模型有Paxos、Raft、Zab等。强一致性主要由四部分特性组成。

  • Atomicity：原子性，一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。
  • Consistency：一致性，在事务开始之前和事务结束以后，数据库的完整性没有被破坏。
  • Isolation：隔离性，数据库允许多个并发事务同时对其数据进行读写和修改，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据不一致。
  • Durability：持久性，在事务处理结束后，对数据的修改就是持久的，即便系统故障不会消失。

CAP

CAP指的是在一个分布式系统下，包含三个要素。

  • C：一致性（Consistency），在分布式系统中的所有数据备份，在同一时刻一致（等同于所有节点访问同一份最新的数据副本）。
  • A：可用性（Availability），在集群中一部分节点出现故障后，集群整体还能响应客户端的读写请求（对数据更新具备高可用性）。
  • P：分区容错性（Partition Tolerance），对实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

在分布式系统中，CAP不能完全兼容，P一般是客观存在的（如果没有分区，也就不是分布式系统），因此需要在AP和CP中进行取舍。

  • 若选择AP，继续让系统正常运行，提供服务，但不能确保整个系统所有节点的数据都是最新的，故舍弃了C
  • 若选择CP，系统暂停服务，等待通信恢复并同步数据，暂停服务期间系统不可用，故舍弃了A

弱一致性：BASE

BASE理论主要是解决CAP理论中分布式系统的可用性和一致性不可兼得的问题。BASE理论包含以下三个要素。

  • 基本可用（Basically Available）：基本可用指的是分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
  • 软状态（Soft State）：软状态指的是允许系统存在中间状态，而该中间状态不会影响系统的整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。
  • 最终一致性（Eventual Consistency）：最终一致性指的是系统中的所有数据副本在经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

BASE理论与ACID不同，满足CAP理论，通过牺牲强一致性来保证系统的可用性。由于牺牲了强一致性，系统在处理请求的过程中，数据可以存在短时的不一致。系统在处理业务时，记录每一步的临时状态。当出现异常时，根据状态判断是否继续处理请求或者退回原始状态，从而达到数据的最终一致。

弱一致性的模型有DNS和Gossip协议。

提高一致性的方法

在分析了通用的一致性理论后，这里介绍几种提高一致性的方法。

  1. 尽量避免数据一致性问题。在设计上做将需要同时成功的数据放到一个服务中心内，同一个操作人的数据分布在同一个物理分片上，通过单机事务来保证，避免分布式事务。
  2. 二阶段提交协议X/Open DTP。X/Open DTP（Distributed Transaction Process）是一个分布式事务模型，此模型主要使用二阶段提交（Two-Phase-Commit，2PC）来保证分布式事务的完整性。在这个模型中，有三个角色，即AP（应用程序协议）、RM（资源管理器）及TM（事务管理器，负责各个RM的提交和回滚）。二阶段提交的优点是提供了一套完整的分布式事务解决方案，遵循事务严格的ACID特性**。二阶段提交的缺点是TM通过XA接口与各个RM进行数据交互，从第一阶段的准备阶段，业务所涉及的数据就被锁定，并且锁定跨越整个提交流程。在高并发和涉及业务模块较多的情况下，对数据库的性能影响较大，同时不支持特大型的系统规模，同时存储组件有很多不支持XA协议。
  3. TCC（Try-Confirm-Cancel）。TCC方案是二阶段提交的另一种实现方式，它涉及三个模块，即主业务、从业务和活动管理器。第一阶段主业务服务分别调用所有从业务服务的Try操作，并在活动管理器中记录所有从业务服务。当所有从业务服务Try成功或者某个从业务服务Try失败时，进入第二阶段。在第二阶段中，活动管理器根据第一阶段从业务服务的Try结果来执行Confirm或Cancel操作。如果第一阶段所有从业务服务都Try成功，则协作者调用所有从业务服务的Confirm操作，否则调用所有从业务服务的Cancel操作。在第二阶段中，Confirm和Cancel同样存在失败的情况，所以需要对这两种情况做异常处理，以保证数据的一致性。
  4. 基于消息的最终一致性。使用半消息技术，保证只要一个事件发生后，关联的结果事件一定会发生。半消息技术解决了如下问题：事件发生后，消息发送却失败；消息发送成功后，消息代理推送给消费方却失败；消费方重复消费此消息。使用半消息技术，在事件发生前，先发送一个半消息，这样可以保证事件发生的消息一定能够发送成功。消息代理增加了事件结果查询功能，保证在事件触发成功后一定将消息推送给消费方。消息代理保证消息至少推送一次，但要求消费方自己实现幂等性，避免出现异常。 

图例：基于消息的最终一致性

这里解释一下幂等（Idempotence），幂等是一个数学与计算机学概念，常出现于抽象代数中，公式为f(x)=f(f(x))。

一个幂等方法指的是在其入参相同时执行1次与执行N次的影响相同，返回结果相同，也就是说重复执行该方法不会影响系统状态，也不用担心重复执行会对系统造成改变。

幂等的方案可以通过发送方创建唯一ID，或者放入业务ID来实现；消费方增加一个过滤服务，每处理一个事件都会通过存储这个事件ID来实现，看是否已经消费过。

分布式集群

分布式系统指的是多个机器之间通过网络进行交互，实现一个共同目标。

分布式集群指的是一个特定领域的软件部署在多台服务器上，并作为一个整体提供一类服务，这里简称集群。

图例：分布式集群

关注点

在分布式系统中，需要我们关注以下几个方面的内容。

  1. 高性能：衡量性能的重要质量属性，如RT、QPS、资源利用率。提高性能可以从单机和集群两个角度考虑。
    • 单机需要考虑进程和线程，或者硬件指标（比如SSD提升I/O访问速度、提高处理器核数）
    • 集群需要考虑任务分配（如CDN、F5、LVS、Nginx）、任务调度、功能分解、多实例副本、数据分割等
  2. 稳定性：衡量系统在故障发生时仍稳定可用的程度。硬件可能出现问题（比如机器宕机、网络断网），高可用通过技术手段（如服务和数据的冗余备份、失效转移），使得系统继续可用。
  3. 高并发：本质是有限的资源应对大量的请求，过程中需要考虑如下方面，比如:
    • 无状态（便于水平扩展，有状态配置可通过配置中心实现无状态）
    • 拆分（业务维度、功能维度、读写分离、模块维度等）
    • 服务化（需要进行服务化等多层次的建设，比如RPC、集群、服务注册与发现、服务分组/隔离/路由、限流降级、服务治理、故障补偿等）、异步处理（比如通过消息队列，对服务进行解耦，处理削峰缓冲、应对大流量缓冲、数据校对等）、缓存（比如用户侧、代理层、接入层、应用层、服务层、数据层等）。
  4. 可扩展：整个系统对系统变化的适应能力。这种变化可以是系统环境的变化，或者业务需求带来的软件变化。企业可使用分布式服务框架来构建可扩展、复用的平台，或分布式消息队列来降低业务模块的耦合性。
  5. 低成本：系统架构需要考虑成本因素，低成本本质上与高性能和高可用冲突。架构的优化伴随着成本的增加，比如机器扩容，使用先进技术和高性能硬件。成本也需要考虑实施的人力、时间及预期目标等因素。
  6. 安全：安全是系统的根基。比如功能方面（防小偷）的XSS攻击、CSRF攻击、SQL注入、Windows漏洞；或者架构方面（防强盗）的访问控制等。
  7. 规模：“量变引起质变”，当规模数量超过一定的阈值后，系统复杂度会发生质的变化。比如业务功能越来越多，调用逻辑越来越复杂，或者数据容量、类型、关联关系越来越多。在规模质变后需要对整体架构进行升级，整体考虑性能、可用性、可扩展性、成本等因素。

在分布式集群中，最基本的是双机架构和集群架构，而双机架构又分为主备架构、主从架构和主主架构。

主备架构

在主备架构中，备机起到备份作用，不承担实际的业务读写。在故障发生后，需要人工把备机改为主机。

  • 主备架构的优点：简单。客户端不需要感知备机的具体状态，在故障发生时，感觉服务器地址变化了，所以需要知道备机的地址。主机和备机之间只需要对数据负责，无须状态判断和进行主备自动切换。
  • 主备架构的缺点：备机只是备份，当故障发生时才可用，资源有浪费，并且故障切换需要人工干预。

主从架构

主从架构与主备架构类似，区别在于从机一般可以提供读操作。

  • 主从架构的优点：当发生故障时，从机可继续提供读操作，提高了机器利用率。
  • 主从架构的缺点：Client需要感知主从关系，将不同读操作发给不同机器；另外，由于数据复制延迟，有数据不一致风险；当发生故障时需要人工干预。

可以看出，主备架构和主从架构在机器发生故障后，无法提供写操作，并且需要人工干预来恢复主机角色。这就需要“双机切换”，工程中需要考虑什么时候备/从机需要升级为主机（如RT过高、重启次数过多），如何切换（如自动、白屏、后台），如何通知Client主机的变化（如手动更改）等问题。其中，主机和备/从机的状态传递和判断尤为重要，一般来说，可以由第三方执行，有时也会由机器自己进行状态传递和判断。

主主架构

主主架构又称双主架构，两台机器同时提供读和写操作。

  • 主主架构的优点：都是主机，不用切换；客户端也不用区分，随机选择一台机器执行操作请求。
  • 主主架构的缺点：主机如果是无状态的，则使用哪台机器都可以，但主机可能有状态（如Server1处理前半部分数据，Server2处理后半部分数据，各自的压力比较大，相对独立），或者不能进行双向复制（比如库存，两个Server的库存数据不同，进行复制会造成冲突）。另外，如果全量复制，则可能由于数据延迟、数据量过大而造成数据不一致的情况。

集群架构

集群架构主要是在双机架构的基础上，增加了备机、从机或其他主机的个数，大体可以分为一主一从、一主一备、一主多从、一主多备、多主等情况。在集群架构中，重点需要考虑以下几个方面。

  • 主机与备机的数据复制：需要数据复制通道。
  • 主机和备机的状态检测：可能引入中介。
  • 主机切换的选主：典型的为Zookeeper的ZAB算法。
  • 如果存在从机或多个主机：任务的调度和分配需要引入调度器。

图例：集群架构

稳定性

如今，稳定性越来越受到各个企业的重视，稳定性在业界又称可靠性，网站可靠性工程的英文是SRE（Site Reliability Engineering）。一些互联网公司习惯用“安全生产”来进行稳定性保障。SRE最早由Google提出并应用，近几年逐步被国内外互联网公司广泛应用。我们先来看看Google的SRE，根据其Site Reliability Engineering一书提及的内容来看，SRE核心是通过监控、应急响应、复盘、压测、容量评估，综合指导系统的研发及最终产品交付的稳定性。

图例：SRE金字塔

稳定性保障过程与研发过程有所区别，强调快速定位问题，协调相关人投入排查，评估影响面，快速决策恢复手段。过程中需要重点关注基础设施容量规划、全链路压测、生产系统的监控告警和负载均衡、发布和变更管理、On-Call（轮值）与Firefighting（紧急故障救火），以及与业务团队和开发团队协作，共同完成疑难问题的紧急处理。

康维定律指出“设计系统的架构受制于产生这些设计组织的沟通结构”，在实践过程中，建议构建独立的SRE团队。

在一些重要节点（比如大促保障过程）中，需要关注以下方面。

  • 关键链路梳理：需要重点梳理关键链路，包括输入流量和单量，梳理上下游流量压力，并绘制总体链路图，以及关键的业务指标，评估限流阈值和资源缺口。
  • 压测阶段：需要关注压测模型，以及进行关键的流量预估，并按照计划进行压测，过程中要关注限流降级及相关瓶颈点。
  • 预案演练：需要充分分析稳定性风险，并指定预案体系，比如问题场景、定位表现、止血措施、预案执行、上下游风险，同时要敢于执行相应预案，并做好相应的回滚等止血准备。
  • 监控告警：需要指定细致的监控体系，包括基础、应用、服务等层面，保证关键业务和技术环节都有合理的监控。
  • 作战手册：可以指定相应的Checklist，并做好检查和宣讲，明确时间点和责任人，以及相应的操作红线等。
  • On-call：建立好相应的On-call体系，包括线上报警、团队协同、故障响应机制等。
  • 故障复盘：故障复盘不是为了指责或者惩罚，而是为了发现背后深层次的技术与管理问题，需要确定相关的方式及优化改进机制。
  • 知识库：可以建设相应的稳定性知识库，对保障过程中的通用问题进行沉淀。

容灾

容灾系统指的是在不同的地方建立两套或多套功能相同的系统，互相之间可以进行功能切换，以在发生意外时，整个应用系统可以切换到另一处，使得该系统可以继续正常工作。容灾技术是系统的高可用性技术的一部分，容灾系统更强调节点级别的恢复功能。

从对系统的保护程度角度，可以将容灾系统分为以下几种。

  1. 数据级容灾：指通过建立异地容灾中心，对数据进行远程备份。数据级容灾的恢复时间比较长，但是其费用比较低，而且构建和实施相对简单。
  2. 应用级容灾：指在数据级容灾的基础之上，在备份站点同样构建一套相同的应用系统，尽可能减少灾难带来的损失，让用户基本感受不到灾难的发生，过程中需要对应用涉及的技术组件进行容灾，比如中间件、缓存、接入层等方面。
  3. 业务级容灾：指全业务的灾备，除了数据和应用的恢复，更需要从整体业务角度开展业务，并包括用户侧的一些切流、业务异常处理、业务恢复等内容。

衡量容灾系统的两项技术指标如下。

  • RPO（Recovery Point Objective）：恢复点目标，是业务系统所能容忍的数据丢失量。
  • RTO（Recovery Time Objective）：恢复时间目标，是所能容忍的业务停止服务的最长时间。

RPO针对的是数据丢失，而RTO针对的是服务丢失，二者没有必然的关联性。RPO和RTO必须在进行风险分析和业务影响分析后根据不同的业务需求确定。

从容灾系统的物理分布角度，可以将容灾系统分为同城容灾、异地容灾，生产数据中心、同城灾备中心、异地灾备中心（三中心）等多种容灾处理方式，这需要结合成本性能、业务场景、技术演进等进行选择。

可扩展性

可扩展性（Scalability）是技术架构中需要考虑的典型非功能性需求，是用来描述系统应对负载增长能力的术语，设计良好的代码允许更多的功能在必要时可以被插入到适当的位置中。这样做的目的是应对未来可能需要进行的修改，但这造成代码被过度工程化地开发。

可扩展性可以采用不同的开发方式，比如动态加载的插件SPI方式、抽象接口的类层次结构、回调函数构造、可塑性强的代码结构、基于服务的API方式、基于组件的开发方式、基于配置的开发模式。 目前，低代码（Low-Code）开发也是一种趋势，它提供了一种可视化的高可扩展性的框架能力。

Low-Code为开发者提供了一个创建应用软件的开发环境，与传统代码集成开发环境不同的是，Low-Code开发平台提供的是更高维和易用的可视化集成开发环境。在大多数情况下，开发者并不需要使用传统的手写代码方式进行编程，而是可以通过图形化拖曳、参数配置等更高效的方式完成开发工作。

在Low-Code的指导思想下，这里推荐其中比较理想的提高可扩展性的方法。

  • 模型扩展：通过元数据等能力的定义，对模型存储服务托管和模型映射能力提供相应的扩展能力，比如增加一个字段。
  • 服务扩展：通过定义核心的服务接口，通过Interface的多态实现，实现相关能力的扩展，比如增加一个参数。
  • 流程扩展：通过定义服务流程的能力，基于流程的继承、组合和编排来实现。
  • 配置扩展：通过高度抽象的扩展，在前台基于可视化的调整，可以到达相应的页面搭建、流程、服务、模型的综合扩张管理。

无状态

无状态（Statelessness）指的是服务内部变量值的存储。有状态的服务伸缩起来非常复杂，因此可以通过将服务的状态外置到数据库、分布式缓存中，使服务变得无状态。有状态的应用会带来很多不便，比如在弹性扩展、配置变更、节点宕机重启、更换负载节点等过程中，可能导致数据不一致、不可维护等多方面问题。

无状态不代表状态消失，只是尽量减少或者把状态转移到分布式场景中。那么，我们通过什么方式来做到无状态？这里推荐几种方式。

  1. 会话改造：尽可能少使用会话，坚持HTTP无状态处理；或者处理好Cookie、Session、Token存储及同步问题，比如使用Sticky Session、共享Session等方式减少会话的状态。
  2. 本地存储：尽量禁止本地存储，不根据本地存储进行业务判断，可以通过分布式存储，以及NoSQL形式来存储，比如OSS、MongoDB等。
  3. 本地日志：尽可能使用分布式日志系统，同时日志系统要保障在本地落盘的日志丢失时，系统仍能够正常工作。
  4. 本地配置：不建议将可变配置放在应用服务器上，建议配置与应用本身进行分离，以实现配置统一管理的目的，防止出现配置漂移。
  5. 本地缓存：不建议使用本地缓存，本地缓存只适用于变更频率极低且即使数据不一致也可以自愈的场景。
  6. 去触发器、存储过程：尽量避免触发器和存储过程。
  7. 定时任务：建议使用分布式任务系统，并处理好对应的状态存储。
  8. 考虑程序的兼容性：比如应用的重新启动、版本管理、兼容性升级，从接口上、数据库设计上及中间件支持的优雅上下线，从应用和技术架构层面提高系统的无状态处理能力。

压测

为了测试系统的性能，我们往往需要进行压测，特别是以下场景。

  • 新系统上线：准确探知站点能力，防止系统一上线就被用户流量打垮。
  • 技术升级验证：大的技术架构升级后进行性能评估，验证新技术场景的站点性能状态。
  • 业务峰值稳定性：大促活动等峰值业务稳定性考验，保障峰值业务不受损。
  • 站点容量规划：对站点进行精细化的容量规划，分布式系统机器资源分配。
  • 性能瓶颈探测：探测系统中的性能瓶颈点，进行针对性优化。

压测过程涉及以下概念。

  • 系统环境：分为生产环境、测试环境等，理想的测试环境配置是生产环境的1/2或1/4。
  • 测试指标：包括业务指标（如并发用户数、QPS、成功率、响应时间）、资源指标（如CPU利用率、内存利用率、I/O、内核参数等）、应用指标（如空闲线程数、数据库连接数、函数耗时等）、前端指标（如页面加载时间、DNS、连接时间、传输时间等）。
  • 数据量级：数据量主要包括基础数据量（或者叫历史数据量、垫底数据量、数据库中已有的数据量）和参数化数据量。
  • 测试模型：分为已上线系统和未上线系统，以电商场景为例，不同的促销形式和主推的类目决定了不同的容量整体配比。
  • 测试类型：比如单交易基准测试、负载测试、压力测试、容量测试、业务突变测试、混合交易稳定性测试等。
  • 测试场景：场景是若干服务、API的组合，完成某种业务功能，包括订单下单场景、库存扣减场景。
  • 流量来源：系统中需要区分出真实流量及测试流量，并有响应的路由和处理逻辑，比如测试服务、影子表数据库等。
  • 监控：需要针对操作系统、中间件、数据库、应用等进行监控，每种类型的监控尽量全面。
  • 分析调优：对系统中存在的瓶颈点进行分析，并进行性能优化，比如操作系统、中间件、数据库、应用等。
  • 压测工具：比如JMeter、LoadRunner等。

为了反映真实的业务承接能力，压测的过程中需要特别关注线上环境、用户规模、测试场景、数据量级、流量来源等，尽量做到压测和真实环境一致或等比例。

PTS压测流程，主要流程如下。

  • 在控制台上，准备压测API数据，构造压测场景，定义压测模式、量级等；支持随时启停压测，压测过程中可调速。
  • 压测启动后，PTS后台的压测控制中心将自动调度压测数据、压测任务和压测引擎。
  • 通过随机调度全国多个城市和运营商的内容分发网络（CDN）节点，发起压测流量，保证从虚拟用户并发量、压测流量的分散度等维度都接近真正的用户行为，压测结果更加全面和真实可信。
  • 通过压测引擎向指定的业务站点发起压测。
  • 在压测过程中，通过集成云监控、ARMS产品，结合PTS自有监控指标，实时采集压测数据。
  • 在控制台，实时展现压测数据，进行过程监控；在压测结束后，生成压测报告。基于整个压测场景的性能表现，定位性能问题、发现系统瓶颈。

相关文章