1.2.3 智能微服务适配计算框架

本书把智能微服务适配的周期划分为设计开发和运行维护两个大的阶段：设计开发遵循“设计-开发-测试-重构”这样的周期过程，依托回路模型定义的业务功能智能匹配模型集合M_b来完成智能化的微服务设计开发任务管理和过程优化，不断推动将用户的服务需求转化为实际的微服务实现。运行维护遵循“运行时适配监控-分析-决策-执行”的回路，依托回路模型规定的智能质量保障模型集合M_s来维持微服务运行时的适配状态，并根据运行环境和用户请求的不断变化，调整整个微服务系统的运行。下面分别对这两个阶段的适配计算框架进行阐述。

1.设计开发阶段的服务适配计算框架

设计开发阶段的主要目标包括如下三点：

服务供给和需求的适配：通过构造反映服务需求的多主体模型，表达与业务相关的服务流程，同时汇聚多方面的数据来聚合所需服务的语义信息，形成服务画像和服务关联的知识图谱，比较服务需求表述和服务供给集合的差异，生成服务适配规约描述，推荐候选的服务集合。

智能的服务适配组合：根据服务供需匹配的结果，综合考虑微服务架构设计模式和服务组合模式，协助系统开发者设计微服务的整体架构，生成服务流程调用图和服务配置，并智能地动态组合微服务流程，支持面向业务流程的任务规划和可靠执行。

服务适配的检测：以服务适配质量为引导目标，基于证据和数据驱动的方式，从微服务模块代码、微服务之间的API调用、微服务架构互操作三个层次，进行微服务软件质量的分析、测试和评估。

上述三个步骤形成了服务适配设计开发的过程回路：供需适配步骤是从邮件列表、社区论坛和图形界面等收集多模态的用户需求数据，利用自然语言处理和人机交互技术生成需求模型，分析和感知用户需求的变化，成为驱动服务适配设计开发的源头；服务适配检测步骤则提供开发过程的质量综合评价，关键的质量指标将作为辅助“设计-开发-测试-重构”的基础和支撑；智能的服务适配组合是这个回路的中心决策步骤，通过汇聚用户需求、可用服务供给、质量评估指标等多方面的数据，基于多种智能工具进行开发过程辅助决策，优化组织服务模块开发、服务组合、服务功能重构等复杂的微服务软件开发活动，使得整个微服务系统向着满足用户需求、符合质量要求的目标不断演进。如图1-11所示。

（1）服务适配需求建模

服务适配需求建模的目标是形成刻画服务软件系统的需求模型，该模型描述服务系统涉及的主体和各主体之间的交互模式和业务逻辑，从而形成服务功能总体定义。本书采用BPMN（Business Process Model and Notation）语言定义用户所需要支持的业务流程集合，同时规定主要服务的QoS约束，形成业务功能约束规则KPI_b。需求建模主要有两种方式：可视化业务流程编辑是比较传统的方式，通过使用简单的图形符号将业务流程转化为可视化图形，这让业务流程建模变得简单化、图形化，比较适合专业的流程设计者使用；对于一些相对简单的流程，可以采用另一种方式，即基于自然语言处理的业务流程模型自动生成算法，这种方式允许用户通过自然语言来表达其所需的服务流程，然后从自然语言描述中提取流程信息，自动地生成业务流程BPMN模型。获得用户需求的BPMN模型后，还需要对业务流程模型的质量进行检查。一个重要的步骤就是进行流程一致性检查，将流程的自然语言描述与生成的BPMN模型进行一致性比较，分析用户所定义的服务功能要求是否达成、在维护过程中是否出现了不一致的情况，并标定存在的差异问题以便设计人员修正。

（2）服务语义建模

服务语义建模的目标就是针对大规模、多样化、关系复杂的服务元数据，精准地表示并建模服务语义，以支持智能微服务适配及应用。服务语义建模要对微服务关系图G所包含的微服务集合S形成画像描述信息，不仅刻画每个服务的静态的语法语义等信息，还包括各类动态行为属性，以刻画服务内部的复杂动态行为及其协同特点。这些服务的相关信息统一表达为针对服务API的知识图谱，把API知识图谱和领域的业务知识图谱相结合，就可以为面向用户需求的服务发现、推荐和组合提供语义融合和推理方面的支撑，为用户需求与服务供给之间的适配提供语义的引导。与传统的人工构建语义表示和知识图谱不同，服务语义建模需要采用多源数据融合、人工语义标注、基于图神经网络的语义和知识图谱表示学习等新方法，从大量的非结构化服务描述数据中，自动构建面向服务适配的服务画像和语义知识图谱。

（3）服务适配组合

服务适配组合的目标是支撑智能化的服务发现、推荐、组合和定制，以自动或半自动的方式生成复合式微服务流程，从而完成用户所需要的BPMN业务逻辑，实现用户需求与服务供给之间的功能匹配。具体包括以下研究内容：首先，构造语义驱动的服务智能组合功能，基于微服务的语义画像，进行微服务的语义聚类，根据服务需求所给出的BPMN流程的语义特征和结构特征，发现与其语义匹配的微服务集合，推荐与语义和结构特性相近的微服务组合片段，以辅助开发人员自动完成BPMN流程到微服务流程的映射实现。在流程组合过程中，具备自动插入微服务适配功能的能力，实现上下游微服务的智能衔接。其次，根据服务需求定义的业务核心指标集KPI_b，把BPMN流程的QoS规范转化为微服务流程的QoS要求，并在部署和运行当中予以保证和落实。为此，需要构造微服务流程规划与编排功能，对微服务组合方案进行动态和持续性管理，实现连续的集成和编排部署，动态维护业务流程和微服务组合的功能一致性，支持服务流程的版本管理、动态演化和自动部署，并根据流程适配的功能要求、QoS要求、成本约束要求，基于逻辑方案生成流程执行的物理方案，进行相应的流程优化。

（4）服务适配功能检测

服务适配功能检测的目标是从代码、API和软件架构三个层次来系统检查微服务系统是否存在服务功能失配的风险，找出可能存在的质量缺陷，以便辅助软件设计和开发人员改进服务适配质量。服务适配功能检测的主要任务是扫描微服务系统所包含的所有微服务的自身功能和汇聚而成的整体功能，确保其满足用户的服务需求；同时检查这些微服务的源代码和软件架构的设计风格，引导软件开发人员对代码和软件架构进行相应的优化和改进。无论微服务代码的各类功能测试和风格检查，还是微服务调用的API，服务适配功能检测的具体实现需要基于DevOps中的持续集成流水线来完成。首先是代码层面的质量检测（代码缺陷和异味），对微服务的源代码进行单元级和模块级的软件测试，找出存在的程序错误和代码缺陷；检查源代码的设计风格，扫描可能存在的设计风格和代码结构的缺陷问题（即代码异味），因为这些异味违背了基本的设计原则，妨碍代码的可理解性，并且降低代码的可维护性。其次是API层面的误用检测，核查微服务系统中各个微服务之间和微服务内部的API调用的正确性。但由于API本身的复杂性、文档资料缺失或者使用者本身的疏漏等，开发人员有时会错误地使用API，从而产生API误用缺陷，导致系统或软件在运行时产生异常或崩溃。最后是服务架构层面的质量检测，微服务系统是基于诸多微服务模块交互耦合形成的分布式系统，其架构设计事关整个系统适配的全局。近年来，许多研究提出了微服务架构设计中存在的异味或者反模式问题，即架构设计存在不好的设计模式，为服务的良性适配带来负面因素，推高微服务系统的演化和运维的技术债。为此，需要引入针对微服务架构异味的自动检查，支持软件开发人员在设计早期阶段消除不恰当的架构反模式，改进微服务系统的整体架构。

2.持续集成-持续交付/部署

持续集成-持续交付/部署是实现智能微服务系统迭代演化的关键步骤，起到支撑图1-11中演化-部署的重要作用，并成为连接智能微服务适配中设计开发和运行维护两个重要阶段的枢纽，以形成完整的服务适配回路。

（1）持续集成

持续集成的目标是把数目众多的微服务模块源代码编译汇集起来，形成可以进一步部署的云容器镜像包。持续集成工具能够有效地支撑分布式开发团队快速更新、持续集成，根据用户需求变化频繁地演化服务系统。在持续集成过程中最重要的步骤是自动化的软件质量检查任务，通过静态扫描、安全扫描、自动测试等，尽快发现和修正微服务软件错误。为此，图1-11中智能化服务适配的功能检测就成为自动化软件质量检查的重要组成部分，需要作为持续集成流水线的必备任务，以支撑开发团队进行高效的集成开发工作。

（2）持续交付/部署

持续交付/部署是持续集成的后续过程，是将集成后的容器包自动部署到实际运行环境，与持续集成相结合，实现微服务系统功能的快速上线和部署交付。持续交付和持续部署是两个相近的概念，容易产生混淆。其主要区别是，持续交付的运行环境是与实际产品线类似的内部生产环境，而持续部署更强调实际产品上线的生产环境。

当前比较流行的持续交付的实现模式是GitOps，它的核心思想是将微服务应用系统的声明性基础架构和应用程序存放在Git的版本控制库中，通过不断比较部署系统的实际状态和Git所存放的最新部署规定之间的差异，不断启动容器版本的增量式更新步骤，从而形成持续交付流程的反馈和控制回路。智能化的持续交付/部署需要“监控-决策-执行”的自适应控制回路，对于灰度发布和金丝雀部署过程中的系统状态进行实时监控，并动态进行自动调节，以保障持续部署中版本变化和升级能够无缝完成。

3.运行维护阶段的服务适配计算框架

这一阶段的核心目标是对服务系统整体效能进行评价与优化，以及实现对服务可靠性的维护与保障。基于对服务执行轨迹的自动化追踪，服务智能适配的控制系统需要实现服务适配的动态监控、效能评测、智能调度、自动恢复等一系列智能运行维护功能。这部分的开发技术是目前业界所提的AIOps[2]的重要组成部分，需要综合实时大数据处理、服务语义关联、数据驱动的机器学习和统计分析等基础工具，设计实现基于服务画像的多维度适配效能评价工具、服务任务智能调度和优化工具，以支持主动的服务质量管理和运行状态的优化。同时通过实时数据采集和日志分析，引入全景关联信息挖掘技术，设计开发服务适配运行时的监测、诊断及故障处理等服务适配保障工具，以支持快速识别故障原因并及时动态处置。如图1-12所示。

（1）适配监控

基于日志和远程数据收集等方式，对业务指标集KPI_b和系统运行指标集KPI_s的相关时间序列进行不间断的数据采集和汇聚。同时对微服务之间的动态调用关系进行监控，生成服务动态调用拓扑。基于这些服务指标数据，使用异常检测模型分析微服务系统的适配状态，对出现的服务异常情况及时发出警报。

（2）适配决策

微服务适配决策是运行维护回路的关键步骤，其涉及的自适应决策功能包括系统运行状态和负载运行动态的预测、云容器资源供给的决策、服务任务资源分配、微服务通信流量管理决策、故障诊断定位和安全访问管理决策等。

其中，资源决策和任务决策：根据运维KPI_s的QoS约束要求，基于M_s模型进行容器资源的动态分配和调度。当有新的微服务需要部署时，平台调度器会根据当前集群的节点状态及服务所需的具体资源来选择最优的节点，在微服务运行结束后会将分配给该服务的资源及时回收以便重新分配。同时通过实时数据采集和日志分析，利用全景关联信息挖掘技术对服务的运行质量进行保障，当检测到服务的容器所在节点出现故障或资源不足时，可以智能地将容器调度到其他正常节点，从而保证服务的运行质量。

流量决策：微服务平台，特别是服务网格（Service Mesh）提供了强大和灵活的流量管理功能，能非常便捷地配置服务通信的路由、控制服务之间的流量和API调用，还能在负载过大或出现故障时，实现熔断、超时和重试等机制。这些机制对于微服务系统各模块实现持续演化和可靠稳定运行，具有重要作用。传统的流量管理高度依赖运维人员的经验和直觉判断，往往无法快速和及时地应对突发性和频繁发生的流量状况。因而，需要智能化的通信流量管理，通过运行数据和微服务通信拓扑关系，自主学习生成M_s中的智能流量管理模型，实现多种场景下的流量动态自主智能决策。

故障诊断定位：一旦异常检测发出报警消息，微服务系统就需要分析异常产生的原因，确定可能发生故障的位置，以指导后续的故障恢复等运维操作，这在软件工程中通常称为故障的根因定位。由于微服务系统各服务之间存在复杂的调用关系，故障的发生具有级联式的传递性，即某个服务的故障会依照微服务关系图G的交互关系，引发多个与该服务相关的其他服务也产生故障。所以需要智能化的根因定位模型，从大量的微服务实例中实施快速而精准的定位。

（3）适配执行

上述适配决策任务需要微服务支撑平台所提供的相应管理接口才能得以实现：适配监控和系统运行状态预测需要从支撑平台上进行大量的运行时数据采集，资源供给和任务调度需要支撑平台对容器计算资源的动态扩容和分配，流量管理需要支撑平台实施动态的路由配置和负载均衡等。现代云容器平台如Kubernetes能提供这些相关的管理功能，并进一步引入服务网格的概念，让运维人员更方便和灵活地快速调整微服务系统。服务网格通过引入网络代理，实现对应用层透明的通信接管，实现微服务通信网络的虚拟化，同时构造数据平面（即微服务通信网络）与控制平面（即上层的服务管理流程）相分离的架构，从而为运维人员提供统一的运维API。这些API为适配决策任务提供了标准统一的接口，大大方便了决策算法和模型的设计与部署。