前言

云原生分两大部分：一部分是遵循微服务化和容器化原则的云原生应用，另一个部分是用于构建和运行云原生应用的云原生平台。云原生应用和云原生平台，共同构成了一个云原生的完整体系。在这个体系上，可以实践敏捷开发、DevOps、容器编排、微服务和容器化等理论和方法。

云原生应用架构的发展得益于以下几点原因：

• 云原生经过多年发展，已经逐渐为企业所接受。
• 随着容器技术相关应用持续深化，逐渐扩展至容器编排、微服务、DevOps、服务运维监控、应用管理的完整闭环。
• 企业核心业务的应用架构将逐步演进，充分利用公有云平台和服务的优势，获得灵活性、弹性和高可用性，满足业务快速发展、不断创新的需求。

一、企业核心业务架构演进

1.企业核心业务应用架构和集成架构发展历程

1.1 企业核心业务应用架构发展历程

企业核心业务应用架构发展历程主要有如下四个阶段：

• 单体架构
• 垂直架构
• SOA面向服务架构
• 微服务架构

1.1.1 单体架构

这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构（也叫：巨石型应用）。

1.1.1.1 特点

1、所有的功能集成在一个项目工程中。

2、所有的功能打一个war包部署到服务器。

3、应用与数据库分开部署。

4、通过部署应用集群和数据库集群来提高系统的性能。

1.1.1.2 优点

1、项目架构简单，前期开发成本低，周期短，小型项目的首选。

1.1.1.3 缺点

1、全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。

2、系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

3、技术栈受限。

1.1.2 垂直架构

垂直架构相较于单体架构而言，进行了部分解耦，但是不够彻底，在各个子系统相互依赖的代码和模块中，存在重复代码拷贝和模块功能重复开发的情况。

垂直架构按功能进行MVC划分和按职能进行前后端分离模式，通过分层来规范职责和定义边界。

1.1.2.1 特点：

1、以单体结构规模的项目为单位进行垂直划分项目即将一个大项目拆分成一个一个单体结构项目。

2、项目与项目之间的存在数据冗余，耦合性较大。

3、项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。

1.1.2.2 优点：

1、项目架构简单，前期开发成本低，周期短，小型项目的首选。

2、通过垂直拆分，原来的单体项目不至于无限扩大。

3、不同的项目可采用不同的技术。

1.1.2.3 缺点：

1、全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。

2、系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

1.1.3 SOA面向服务架构

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。

面向服务的架构主要由两种：以企业服务总线（ESB）为代表的SOA和以RPC为代表的SOA。

1.1.3.1 特点

1、基于SOA的架构思想将重复公用的功能抽取为组件，以服务的方式给各个系统提供服务。

2、各个项目（系统）与服务之间采用webservice、rpc等方式进行通信。

3、ESB企业服务总线作为项目与服务之间通信的桥梁。

1.1.3.2 优点

1、将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。

2、可以针对不同服务的特点制定集群及优化方案。

3、采用ESB减少系统中的接口耦合。

1.1.3.3 缺点

1、系统与服务的界限模糊，不利于开发及维护。

2、虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。

3、抽取的服务的粒度过大，系统与服务之间耦合性高。

1.1.4 微服务架构

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

1.1.4.1 特点

1、将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。

2、微服务遵循单一原则。

3、微服务之间采用RESTful等轻量协议传输。

1.1.4.2 优点

1、服务拆分粒度更细，有利于资源重复利用，提高开发效率。

2、可以更加精准的制定每个服务的优化方案，提高系统可维护性。

3、微服务架构采用去中心化思想，服务之间采用RESTful等轻量协议通信，相比ESB更轻量。

4、适用于互联网时代，产品迭代周期更短。

1.1.4.3 缺点

1、微服务过多，服务治理成本高，不利于系统维护。

2、分布式系统开发的技术成本高（容错、分布式事务等），对团队挑战大。

1.2 企业集成架构发展历程

“企业”是指由一整套可识别的、互为作用的业务功能构成的商业组织。企业架构是企业的基础框架，它定义和描述了企业实现经营目的和商业愿景的平台。企业架构是与企业经营战略、信息需求紧密相连的一整套原则、方针、政策、模型、标准以及流程，它结合企业未来发展方向，为企业各项解决方案的设计、选择和执行提供指导。

企业架构可以分为两大部分：业务架构和IT架构

• 业务架构：是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容。
• IT架构：指导IT投资和设计决策的IT框架，是建立企业信息系统的综合蓝图，包括数据架构、应用架构和技术架构三部分。

企业架构发展历程如图：

随着大数据、人工智能、云计算等数字技术的快速发展，技术革命进入“云时代”，企业上云（私有云或公有云）成为趋势，云平台以及企业应用上与之相关的移动应用、微服务、大数据、人工智能、物联网等若干技术手段的出现，以“云”为主要特征，具有更加开放、实时、灵活的“云架构”逐渐代替传统架构，成为新一代的企业架构。

2.应用架构演进

应用架构的演进就是：普通架构->云架构的发展历程。

常见的云服务有几种方式：

• IaaS（Infrastructure as a Service）：基础设施即服务。提供云端的基础设施为主，比如提供主机、存储、网络、CDN、域名解析等功能。
• PaaS（Platform）：平台即服务。提供云端的发布、数据库服务、文件存储、缓存服务、容器管理等基础存储和管理组件，自动化了程序的配置、发布、管理–Heroku、Google App Engine、Force.com等。
• SaaS（Software as a Service）：软件即服务。提供云端的应用服务，ERP、HR、CRM等在线系统，每个账户或者每家公司有独立的数据存储，通过账户进行权限和访问隔离，知名厂商有Salesforce、Successfactor、Zendesk等。
• BaaS（Backen as a Service）：后端即服务，起初专指针对移动端的研发提供的云服务，降低移动研发的复杂度，让开发者关注与移动端开发即可。流行的服务有几大类：综合类，Parse、Kinvey；分析类，友盟、TalkingData、神策数据；支付类，Beecloud、Ping++；IM类，环信、网易；消息类，极光、个推等。

二、华为云方案

1.应用架构演进之云服务总览

1.1 应用架构方案

华为云应用架构方案组成：客户端、前端应用、业务应用、技术平台、数据平台、混合云平台、IaaS。

1.2 让企业应用上云更简单，数字化转型更智能

华为云智能应用平台，构建在云基础设施之上，提供一个Cloud Native应用底座和三个应用创新平台，秉承了此前应用上云更简单的理念，为企业的数字化转型和智能化升级提供了系统的解决方案。将应用管理能力延伸到多云&混合云、打造更丰富的开放生态、由技术平台向行业使能平台发展。

企业应用上云有如下特性：

开放

• 中国唯一CNCF初创成员和白金会员
• K8S社区贡献度全球前三
• 微服务ServiceComb:Apache社区唯一微服务
• 源项目并已顺利毕业

智能

• 全球唯一基于K8S的GPU共享Al容器实例
• Al训练速度较自建K8S提升53%

企业级

• 安全，可靠，高性能
• 微服务框架单实例吞吐量30万TPS，时延低于1ms

1.3 ServiceStage-应用管理运维平台

华为云微服务平台ServiceStage提供应用全生命周期管理，实现业务敏捷DevOps，并通过独有的契约能力实现了微服务治理与业务代码分离，帮助企业开发者聚焦业务逻辑。

1.4 最高性能、开放开源微服务解决方案

微服务的解决方案主要有：开箱即用的微服务框架、非入侵式微服务接入、开放兼容。

备注：具体详细说明看3.6小节。

1.5 立体运维-全方位掌控系统运行状态，快速响应

华为云立体运维解决方案是为云上客户量身定制的一个解决方案，包含AOM（应用运维管理服务）、APM（应用性能管理服务）、LTS（日志服务）。覆盖IaaS层的基础设施状态，Paas层的中间件及数据库状态，应用层的各类应用状态及指标这三层，形成立体化运维分析能力。华为云立体化运维解决方案遵循DevOps标准，可以敏捷高效的获取云上应用的各类异常，并辅助运维人员快速定位。同时立体化运维解决方案以应用为中心，展示应用指标、拓扑、状态信息，提供应用视角的监控运维模式，满足日常巡检、故障排查等多种运维场景。

1.6 华为云K8S全栈容器服务

华为云全栈容器服务包含云容器引擎CCE、云容器实例CCI、服务网格Istio、应用编排服务AOS、应用运维管理AOM、容器镜像服务SWR、智能边缘平台IEF及基因容器服务GCS等一系列容器相关服务，其中CCI、IEF和GCS是全球首发，CCE和Istio属于国内首发。同时，该服务还推出了裸金属容器、GPU容器、Windows容器，丰富了客户的选择。

华为云全栈容器服务向下对接高性能IaaS资源，向上为AI、移动、区块链、边缘计算等服务提供业务运行平台，为客户提供容器应用的全生命周期管理，加速客户应用容器化上云过程，目前在互联网、AI、游戏、生信领域应用广泛。

此外，华为作为CNCF基金会的领导者，也正在将集群联邦、高级调度策略、IPVS负载均衡、容器存储快照等先进技术贡献给社区，以及开源KubeEdge和KubeGene两个项目，推动K8S生态的快速发展。

1.7 ROMA联接企业的现在与未来

ROMA联接企业的现在与未来主要分为两方面：一方面通过边缘ROMA Site配合，实现多云环境部署，完善多云、混合云集成能力。一方面通过Link打破空间鸿沟，实现IT&OT融合，真正全面的打破一切空间鸿沟。

ROMA提供的50+种主流适配器、100家行业应用资产、无缝的对接SAP、金蝶等商用软件实现了老旧系统100%接入，打破时间鸿沟，实现企业IT系统平滑演进。

ROMA方便地为企业和他的伙伴提供接入私有协议的应用与数据的能力，开放所有ROMA的经验资产给企业，打破开放鸿沟，帮助企业和伙伴快速构建新的创新业务与应用。

2.应用架构演进之高性能中间件

2.1 为什么要用云中间件服务

• 企业自己开发或使用开源中间件的弊端:
  • 硬件故障:企业需要自己保证底层硬件设施的可靠性和故障替换。
  • 软件安装部署:中间件自身的安装部署、补丁、升级等需要耗费企业大量的人力物力。
  • 中间件软件bug和安全修复:需要投入大量人力维护中间件代码和安全补丁。
• 使用云中间件服务的好处:
  • 开箱即用:完全不需要考虑软硬件安装部署，购买完毕即可使用。
  • 可靠安全:由云中间件服务保证服务可靠性和故障切换。
  • 升级和补丁:由云中间件专业团队负责代码维护和bug修复。

2.2 传统应用的挑战及应用策略

传统应用的挑战主要有两个点：非高并发、非高可用。

要解决传统应用应用的问题，可以通过分布式应用解决。解决高并发主要的技术点有：缓存、队列、分库、同步异步、处理、全局锁、线程池。解决高可用主要的技术点有：主备HA、数据多副本、限频、限流。

2.3 使用云中间件构建分布式云化应用

传统应用All in one的架构导致资源利用率低、可扩展性差、可靠性也无法得到保证。举例：一个电商系统，如果是All in one架构下，大促来临之前只能按照整系统的倍数去扩展。而不能按照缓存扩展5倍（登陆次数暴增）、数据库扩展2倍（实际的用户数据增长约2倍）比例去扩展。

这种封闭的架构，如果要做业务改动或新增业务模块都是比较困难的，因为所有的模块与数据库都是直接串行交互的。整系统的可靠性也比较差，如果数据库故障了，所有的业务流程都会受阻。增加了分布式消息队列以后，可以将各个应用模块做解耦，当某个业务模块故障时，不影响与其并行操作的其他模块。大大增强了系统的可靠性。

2.4 快速构建云上企业级分布式应用

华为云快速构建云上企业级分布式应用主要依赖于以下技术：分布式消息服务（DMS）、分布式缓存服务（DCS）、分布式数据库中间件服务（DDM）。

2.4.1 分布式消息服务(DMS)

完全托管的高性能消息队列服务，100%兼容开源Kafka&RabbitMQ，为分布式应用系统提供灵活可靠的异步通信机制。

2.4.2 分布式缓存服务(DCS)

兼容Redis、Memcached等主流缓存引擎，基于双机热备的高可用架构，提供单机、主从、集群等丰富类型的缓存类型，满足用户高读写性能及快速数据访问的业务诉求。

2.4.2 分布式数据库中间件(DDM)

专注于解决数据库分布式扩展问题，突破传统数据库的容量和性能瓶颈，通过读写分离、数据分片等实现海量数据高并发访问。

2.5 分布式缓存典型应用场景及云服务特点

DCS即一种分布式缓存数据库服务，将现在很火的几类内存数据库Redis、Memcached和内存数据网格进行包装，提供即开即用、安全可靠、弹性扩容、便捷管理的在线分布式缓存能力。DCS提供单机、主备、集群等丰富的实例类型，满足用户高并发及快速数据访问的业务诉求。

2.5.1典型应用场景一

为应用系统提供高性能的Key-Value的缓存数据库服务，支持Redis开源引擎。有效提升热点数据访问速度，并大幅降低数据库的压力。

Redis云服务特点：

• 高性能:单实例QPS10+万
• 应用0改动:支持Redis3.0/4.0/5.0开源主流版本
• 数据安全:租户间物理隔离，支持跨AZ、跨Region部署，确保数据安全可靠
• 规格灵活:可选择128MB~1TB多种缓存规格，并提供单机/主备/集群等多种实例类型，满足不同应用场景对缓存的需求
• 弹性扩展:缓存规格一键式在线扩容，无缝配合业务规模发展

2.5.2 典型应用场景二

为应用系统提供异步的消息队列服务。通过高可用的消息缓冲队列，实现应用解耦、突发流量处理及与第三方的互通和集成。

关键特性：

• 100%兼容开源:提供提供多种规格，按需使用，支持Kafka&RabbitMQ引擎
• 安全保证:VPC隔离，支持SSL通道加密和消息存储数据加密。深度修改消息引擎内核，按电信级标准修复开源安全问题
• 增强功能:一键扩容、消息查询，消息转储，消息存储加密等丰富的消息能力
• 亿级消息堆积:存储和实例规格可动态扩展，支持千万级并发支持企业级高性能应用
• 可靠消息存储:节点反亲和部署，支持跨AZ，同步落盘及多副本冗余，集群化部署确保数据和服务高可靠

2.6 DDM典型应用场景及特性

分布式数据库中间件（Distributed Database Middleware，简称DDM），专注于解决数据库分布式扩展问题，一个实现了Mysql协议栈的数据库代理服务器，通过代理服务器将底层数据库存储引擎以集群方式管理起来。DDM提供分库分表、读写分离、弹性扩容等能力，而且服务器集群管理对用户完全透明，用户通过DDM管理控制台进行数据库运维，使用JDBC等驱动服务或SQL客户端连接数据库，进行数据读写。

2.6.1 典型应用场景

作为RDS前置的分布式数据访问服务，彻底解决了数据库的扩展性问题，对应用透明地实现海量数据的高并发访问

关键特性：

• 业务不中断，自动完成水平拆分、平滑扩容
• 可承受PB级数据量、百万级并发量，十倍于单机数据库连接数
• 集群高可用，秒级故障自动恢复
• 兼容MySQL协议，业务代码零改动，透明读写分离

3.应用架构演进之微服务

3.1 微服务范围

微服务是以不断提高交付效率、缩短交付周期为核心，基于云原生的方式，对架构优化的结果。当自动化测试、持续集成、持续部署、环境管理、数据管理等都完成局部优化后，架构的优化与解耦成为缩短交付周期所不可回避的问题。演进式架构(Neal Ford，2015/Thoughtworks)的核心是提高架构应对变化的响应力，从而适应未来日益加剧的业务竞争和多元化的IT变化。

微服务范围主要包含三方面：自组织团队、技术实践、流程与工具。

3.1.1 自组织团队

• 康威定律-产品或系统的设计(架构)受到其生产组织自身沟通结构的制约
• You build it，youRuni小团队、完成服务的分析、开发、测试、部署和运维
• 不断识别交付中的瓶颈，采用精益的方式快速验证和优化，小步快跑

3.1.2 技术实践

• 通过高度成熟的自动化体系建立可靠且可重复的交付过程
• 良好的持续集成、代码review、团队内技术分享等实践
• 在满足验收标准的条件下，鼓励拥抱新技术解决业务问题，试点性验证并推广

3.1.3 流程与工具

• 积极引入外部工具，同时不断优化内部工具
• 保障持续集成、持续部署流水线的稳定且高效
• 加强基础设施的构建与管理，加快监控、告警、日志聚合等反馈效率

3.2 微服务优势

微服务优势主要有以下三点：服务模块的边界更清晰、支持独立部署、允许技术多样性。

3.2.1 服务模块的边界更清晰

微服务强调模块化结构(REST接口调用)，这对大型团队非常重要。

3.2.2 支持独立部署

单服务更易部署，由于服务是自治的出现问题之后不会引起系统崩溃。

3.2.3 允许技术多样性

有了微服务，你可以混合使用多种编程语言、开发框架和数据存储技术。

3.3 微服务带来的挑战

微服务带来的挑战主要有以下三点：

• 微服务架构复杂、依赖关系多
• 需处理分布式系统的一致性
• 增加运维复杂性

3.3.1 微服务架构复杂、依赖关系多

开发的服务数量增加，远程调用更慢且总存在失败风险。

3.3.2 需处理分布式系统的一致性

各微服务都管理自己的数据，数据不再集中保持一致性非常困难，意味着大家都要处理最终一致性。

3.3.3 增加运维复杂性

无状态、调用链长需要一个成熟的运维团队(机制)来管理大量需要频繁部署的服务。

3.4 微服务全生命周期管理

微服务开发生命周期有：创建、编码、编译、构建、部署、测试、验收、发布、删除。

微服务运维生命周期有：部署/启动、日志/监控、告警、诊断、治理/配置、扩容、缩容、回滚、停止/卸载。

3.5 微服务的价值

微服务的价值主要有以下三点：上线更快、运行更稳、成本更经济。

3.5.1 上线更快

业务上线：年>月>周>随时上线

3.5.2 运行更稳

系统SLA：3个9>4个9>5个9>永不断服

3.5.3 成本更经济

资深成本：细粒度按需伸缩

3.6 最高性能、开放开源微服务解决方案

华为微服务产品包含一套微服务开发框架、一站式微服务监控与治理平台以及一系列配套的微服务开发工具，主要功能如下：

• 基于契约(Open API)的开发模式：让微服务的开发、测试、文档、协作和管控活动标准化、自动化
• 高性能REST/RPC微服务开发框架：打包了微服务注册、发现、通信和治理等基础能力，开箱即用
• 一站式微服务治理控制台：提供微服务负载均衡、限流、降级、熔断、容错、错误注入等治理能力
• 非侵入式微服务：提供Mesher服务，可实现多语言微服务解决方案，以及遗留系统零改造微服务化
• 多样化微服务安全管控能力：提供认证鉴权、黑白名单等能力保障微服务访问安全
• 灰度发布支持业务平滑升级：支持使用接口任意参数（例如用户群组、用户类别、用户所属区域等等）定义微服务灰度发布规则
• 微服务调用追踪：提供微服务实例和接口级吞吐量、时延和成功率的实时监控及调用链分析

3.7 华为云微服务，来自华为全面云化转型成功经验

华为全面云化转型成功经验主要来源于三个方面：易用、开放、企业级。

3.8 典型场景一-以契约为中心的微服务开发模式

以契约为中心的微服务开发模式的特点：

• 设计人员通过OpenAPI或者Native APl的方式设计接口。可以通过Native APl生成Open APl，转换是双向的
• 使用“代码生成”工具，输入Open APl，生成NativeAPl。Native API可以有多种形式，一种是给开发人员实现的接口;一种是给测试人员实现的测试接口
• 使用“文档生成”工具，输入Open APl，生成PDF或者Word文档
• 管理人员/用户等使用文档对产品进行宣传、备案或者接受第三方审计
• 开发人员根据Native API实现业务逻辑
• 测试人员根据Native API实现测试逻辑
• 实施人员根据Open APl，录入接口网关，配置接口的流控、计费、开发策略等
• 开发和运维人员基于Open API定义微服务健康运行的参数，统称为服务治理
• 运维人员基于OpenAP|观察接口的监控状态，并通过配置管理平台，对具体接口进行限流、降级等

3.9 典型场景二-微服务持续交付流水线

微服务持续交付流水线有：开发->自验->集成验证->开发->上线

3.10 典型场景三-微服务治理

微服务治理分为主要有四方面：自动负载均衡、自动容错、服务降级、服务限流

3.11 典型场景四-调用链跟踪和监控

调用链跟踪的优点主要有：

1、低侵入性

监控系统应尽可能减少对业务系统的侵入，保持对使用方的透明性，减少开发人员的负担，降低接入门槛和难度。

2、低性能影响

由于全链路监控系统需要对各种应用中间件进行日志数据采集，大多都需要在业务系统内进行“埋点”或放置agent，一般都是在核心业务流程。

因此应尽可能降低对业务系统造成的性能影响，一般来说，对CPU的耗用低于2%可以作为一个参考阈值。

3、灵活全面的接入策略

为了尽可能降低接入成本，应该提供灵活的监控配置策略，让业务方决定是否接入，以及收集数据的范围和粒度，并提供对应的技术方案保障监控策略生效。

4、时效性

实时有效的监控数据展示功能，帮助相关人员理解系统行为，为流程、架构、代码优化，以及扩容缩容、服务限流降级提供正确客观的数据参考。

3.12 ServiceComb首个Apache微服务顶级项目

ServiceComb致力于帮助企业、用户和开发者将企业应用轻松微服务化上云，并实现对微服务应用的高效运维管理。其提供一站式开源微服务解决方案，融合SDK框架级、0侵入ServiceMesh场景并支持多语言。

ServiceComb的基本原则有：中立、开放、标准化、无商业Lock-in、社区健康发展

4.应用架构演进之立体运维

4.1 云上运维目标与挑战

随着企业应用的逐步上云可以享受到标准化的服务，高效、省钱、省力、安全。但对于一些有特殊要求的应用场景，还需要相关体系进一步完善。

上云后就不是传统的监、管、控的运维，面对更复杂的运维环境，需要解决以下问题。

1、实现统一运维。

上云后面临的相对复杂的环境，不是传统意义上的单个机房或者一个IDC，而是一个多云的环境，私有云、公有云，还有虚拟化平台和未来的容器平台等，不同的平台有不同的逻辑，需要用不同的技能进行运维，导致对运维人员技术要求比较高。打破不同平台之间的差异，用同一种方式对所有平台进行运维。

2、打破运维隔离。

平台的对象监控，要避免运维孤岛，有助于用户对基础监控的全面把控。

3、规避手工运维。

传统运维过程中存在非常多手工运维的操作，这会导致效率问题和安全问题。频繁地登录服务器去做一些命令操作，也存在安全隐患。平台代替人工去做此类重复劳动，避免人为的重复劳动和过多的登录服务器。

4、持续更新知识库。

知识库问题更新，故障解决方法。运维人员知识固化，个人依赖性强，干货包的分享，降低人员依赖，保证故障妥善解决。

4.2 AOP/APM架构简介

APM(Application Performance Management)即应用性能管理（应用性能监控）。

APM主要是针对企业 关键业务的IT应用性能和用户体验的监测、优化，提高企业IT应用的可靠性和质量。旨在确保最终用户获得高质量的体验，降低IT总拥有成本（TCO)。

TCO(Total Cost of Ownership)，即总拥有成本，包括产品采购到后期使用、维护的成本。这是一种公司经常采用的技术评价标准。

4.3 资源、应用、业务一站式监控与分析

通过集群与虚机、虚机与应用、应用与资源统一建模，将集群、虚机、网络、磁盘、数据库、应用、容器及业务等上百种指标监控起来，并提供各种指标智能关联分析，运维人员通过统一的告警入口即可下钻找到问题根因。

4.4 AOM应用 & 资源关联分析

应用、服务、实例、资源相关联，可以直接查看到异常影响范围。针对应用异常，可以直接查看其指标，通过指标找到原因。针对资源异常，可以查看其资源对象拓扑图及告警情况等信息来定位原因。

4.5 AOM海量日志管理

将虚机上的应用、开源组件、系统等日志集中采集起来，通过清洗、实时分析、智能聚类等处理，实现了日志的高性能搜索和业务分析。同时，支持自定义采集路径、实时刷新、上下文查看、秒级搜索、日志下载、转储等常用功能，满足日常所需。

4.6 APM全链路监控-覆盖从端侧到数据中心全链路

调用链跟踪、记录业务的调用过程，还原业务请求在分布式系统中的执行轨迹和状态，可以分钟识别异常原因。在业务方法被调用时，可自动捕获该方法的调用者、详细的堆栈以及各类参数，帮助开发人员快速锁定问题现场。

4.7 APM应用拓补

应用拓扑是对应用间调用关系和依赖关系的可视化展示，包括应用状态、时延、错误、负载、依赖关系等指标，支持数据库、缓存、消息中间件、NOSQL等各类开源组件的情况。同时可以按照时间、服务、事务、top等维度进行筛选查看。在应用拓扑中，针对异常也可直接下钻查看调用关系，定位异常根因。

4.8 APM事务监控

从运营视角，了解每个业务的运行状况，包括交易次数、时延、错误率，并通过调用链找到异常代码，同时可以帮助运营人员了解活动期间的交易体验情况。

总结

随着互联网、数据时代的不断发展，企业的发展越发趋向于智慧化经营，以信息化数字化赋能产业发展，实现企业数字化转型。云技术也在不断的更新技术创新，为企业提供着更为专业的计算、存储、数据库等综合服务，为各行业的实现数字化转型提供“云”支持。华为云强大可靠的运维能力将助力互联网企业上云无忧，更能抓住5G红利，抢先拥抱数字化和智能化时代。

本文主要讲述了:

• 企业核心业务未来架构演进路线以及基于华为云的应用架构方案
• 华为云应用服务在云基础设施之上提供覆盖端、边、云全栈的云原生应用使能平台，为企业数字化转型和智能化升级提供系统的解决方案

---

本文整理自华为云社区【内容共创】活动第14期。

查看活动详情：https://bbs.huaweicloud.cn/blogs/336904

相关任务详情：任务16.企业核心业务未来架构演进路线及华为云方案