阿里云原生应用平台架构师田伟：应用架构的规划、治理与演进_开发态 运行态 运维态

2022 年 6 月 17 日，阿里云用户组（AUG）第七期活动在合肥成功举办。现场，阿里云云原生中间件架构师田伟分享了应用架构的规划、治理与演进。从云原生的生产背景切入，详细讲解了如何构建一个好的应用程序，并通过 3 个场景深入浅出地分享了应用架构的治理要点。本文根据演讲内容整理而成。

云原生（Cloud Native）产生背景

随着 IT 技术持续不断演进，业务应用从传统的单体架构，转变为分布式 SOA 架构，直至当前主流的微服务架构。与此同时，由于云平台技术 IaaS/PaaS/SaaS 的不断成熟以及分布式框架的普及，企业上云已成为必然趋势。

从长远来看，未来应用主要分为两类：第一类是用于构建云的应用，第二类是基于云来构建的应用。对于第二类应用，基于云构建的应用可以理解为云原生应用。

根据 CNCF 官方的描述，云原生应用具备五大技术特征：不可变的基础设施、容器、服务网格、微服务、声明式 API。用于帮助企业在公共云、私有云、混合云上快速构建具备可伸缩、可扩展的，可移植的业务应用。

虽然 CNCF 对于云原生业务应用的定义比较抽象，但是翻译成大白话就是云原生能够最大程度的利用云计算技术优势、降低 IT 建设成本、提高研发效率，使业务系统加稳定更具韧性。

应用架构的规划与演进

从广义角度来说，一个好的应用程序包含两个维度：

• 一个是功能性维度，与此相关是应用程序的业务逻辑，也就是产生业务价值的部分；
• 另一个就是非功能性维度，保障应用高效稳定运行，应用架构与此紧密联系。

功能性维度

功能性维度包含完整性、正确性以及恰当性等。功能的完整性、正确性很好理解，而恰当性则表现为功能设计的合理性。例如疫情刚出现时候，健康码最初是三个颜色：红码、绿码与黄码。但随着今年疫情形势的复杂和变化，新增加灰码标识，以适应不同阶段的场景要求，这就是功能恰当性的一个体现。

非功能性维度

非功能性维度则是指除功能需求以外的、应用为满足业务需求而必须具有的特性，包括业务应用的性能（例如响应时间快）、可靠性、易用性、兼容性、可移植性，可维护性、安全性等。事实上，决定一个程序的架构，往往是根据非功能性因素来进行考虑的。以数据库高可用设计为例，在传统模式下可以采用主从方式，或者双主互备，而在云计算的基础上，则可以直接使用云原生数据库，同样实现高可用的要求。

架构演进

相对于传统架构而言，云原生架构就是最大化地利用云平台的组件来实现这些非功能性要求，这样自然具备云原生带来的特性和收益。与此同时，将更多的精力聚焦在业务功能代码的实现，而把非功能性代码交由云原生组件的实现，例如应用高可用、流量防护、容灾切换、安全防护等，以此提升研发效率并保障系统稳定。

应用治理的范围

相对应用架构而言，应用治理是一个更高级的话题，其内涵和外延更加宽泛，从功能层面看，应用治理覆盖了设计、开发、测试、运行、运维等各个阶段，其中每个阶段都具有相应的治理措施。

设计态

一个好的设计离不开治理，它将影响从开发到上线的各个方面。

在复杂业务场景下划分业务域实现业务系统高内聚低耦合，引入新技术组件用以实现高性能等，这些行为都会对应用治理产生影响，因此需要有方法论进行指导。以阿里的业务中台建设为例，通过 AEPM (Alibaba Enabling Platform Methodology) 方法论，保障业务中台的设计合理落地。在设计阶段，正确指导业务调研、用例分析、领域划分，抽象共享服务中心、领域建模，数据建模、接口设计规范等。

开发态

开发态需要考虑开发调试便捷，提升研发效率。

端云互联的方式，实现本地应用和云端资源双向访问，方便调试。

环境隔离则保障多环境下资源隔离，为每一个正在开发的功能特性隔离出一个独立的环境， 提升开发迭代的效率。

服务契约、服务 mock 及服务调试则包括规范定义接口名称及参数，让开发快速调试、服务使用者者快速上手。

测试态

测试态需要考虑方便测试人员压测、回归、验证功能，提升测试效率，让测试更快更准更全面。

对于压测阶段而言，需要快速发起压测，迅速了解微服务的容量是否偏离基线，确保应用性能。

通过自动化的方式进行回归测试，自动发起测试并自动比对结果进行验证，无需人工重复测试，保障业务代码逻辑的正确性。

流量的录制与回放，以真实的请求丰富测试用例保障业务逻辑的正确性。

运行态

运行态需要保障应用运行稳定、流量控制及安全保障。

• 发布态：解决业务发布时的流量治理问题，让应用发布流程顺畅。

以无损下线的方式确保应用在发布、停止、扩容时，所有请求都不会被影响。

金丝雀发布用来满足特定流量特征的请求才会进入微服务的灰度节点，通过小流量验证微服务新版的逻辑是否符合预期。

全链路灰度则是面对一个迭代的多个应用同时发布，希望经过灰度的上游流量只能达到下游的灰度节点，确保灰度流量只在灰度环境中流转。

• 安全态：需要保护敏感业务、提供零信任能力，结合云平台能力保障应用安全。

通过服务鉴权，确保敏感服务只能被已授权的应用访问和调用，保护敏感微服务。

通过升级应用框架、流量拦截、动态程序修改等技术来修复方式实现漏洞的防护。

对于敏感配置，不希望任何微服务都有权限访问，控制只有受限的微服务才能访问。

• 高可用：应对洪峰或者脉冲流量需要提供限流、降级、熔断等能力，保障业务稳定。

限流、熔断与降级是针对访问流量进行控制，防止雪崩效应，保障机器和整体业务的稳定性。

离群实例摘除则是在单个服务提供者节点持续不可用的情况下，在消费者侧摘除这个异常节点，保障业务的高可用。

临近路由可以在微服务多可用区部署的情况下，确保流量优先在同一个可用区内流转，降低业务的整体时延。

就近容灾路由则是当某个可用区发生故障，可以把流量尽快的切到正常的可用区，让业务以最快速度恢复。

运维态

运维态是关注应用运行状态、监控报警和应急处理，让应用可视可管。

以架构可视化的方式，将设计态的应用架构与运行态的真实架构进行对比，以确保设计的一致性，发现潜在问题。

将基础资源设施、应用、前端的监控全覆盖，以全景视角方式了解系统资源的全部情况。

海量存储日志信息，快速检索上下文信息，发现问题，快速定位。

根因定位可以根据暴露出的问题，及时给出问题原因的定位判断，以辅助运维人员快速发现解决问题。

应用治理关键点

架构治理

架构决定应用的并发性、伸缩性、扩展性、可维护性等。一般需要全局分析，从业务架构、应用架构、技术架构到部署架构进行整体考虑。在面向复杂的业务场景下，需要领域专家的帮助以便对业务领域进行合理的划分，同时对架构设计完善优化，避免应用重复开发、库表拆分不合理等。

链路分析

在复杂业务场景下，业务的链路往往较长，例如淘宝的下单操作，就涉及用户中心、商品中心、交易中心、营销中心、库存中心等。因此对于业务链路，需要清晰展示不同层次间的调用时序关系、业务链路调用情况、错误信息和这条链路请求的响应时间、QPS、TPS 等。

调用关系分析

应用的调用关系有多种：单向调用或者双向调用，平层调用或者跨层调用。以业务中台为例，存在前台、中台、后台三个层次，通常情况下，前台应用与中台进行交互，而中台与后台进行集成。如果出现前台直接调用后台的情况，就需要评估该调用的合理性。

应用分析

应用分析是从多维度考量应用构建和使用，包括对外部依赖组件的使用情况，如数据库、缓存、消息等，到自身业务功能代码实现，以及提供对外的接口服务。基于这些信息可以评估应用是否稳定、业务是否正常、交互是否友好，同时也是应用需要改造或升级的重要依据。

服务列表分析

服务列表是应用对外提供服务能力的界面，不管是 SOA 架构还是微服务架构，都是通过应用服务接口来暴露系统的全部功能。以接口定义、接口数量、版本信息、接口复用度、接口相似度等特征，可以对服务接口的合理性及复用性进行很好的判定。

指标池

大型系统由众多应用组成，针对单应用的指标不足以全面了解系统的真实状态，因此还需要全局维度的指标分析。可以将错误接口 top10、高复用接口 top10、关联度分析、复用度分析、RT 分析、QPS 分析等指标组成指标池，通过大盘方式清晰进行展现。

场景下应用治理

场景一：应用架构分析

基于应用真实运行的拓扑图对架构进行分析。可以从分层体系到依赖关系、从调用链路到异常请求，将系统白盒化展示，同时具备了多种不同视角观测系统的能力。例如，可以通过性能测试的视角来发现系统瓶颈，以资源使用率视角来实现成本优化，以流量分布视角来判定核心应用。

场景二：全链路追踪

端到端的全链路追踪为分布式应用提供了完整的调用链路还原、调用请求量统计、链路拓扑和应用依赖分析等信息，可提高开发诊断效率。通过 TraceId 标识某一次具体的请求 ID，将该请求在系统中调用的路径串联起来，组成完整的调用链路。

场景三：基础设施监控

应用依赖硬件、网络、数据库、中间件等各种基础设施资源，需要对全局 IT 基础设施资源进行监控接入、管理与分析和可见性，以保障应用的正常运行，与此同时要建立报警及时预警和对应的应急处置流程。

结语

应用治理是一个长期建设的过程，针对不同的应用架构，其治理的能力和方法也不同，在此基于云原生架构的视角对应用治理的提出方法建议，以期为企业 IT 治理带来长远收益。

阿里云原生应用平台架构师田伟：应用架构的规划、治理与演进