顾大师：云服务是一种什么体验？(图)

获得国家科学技术奖是一种怎样的体验？

这倒是个凡尔赛的话题，但这个华为确实有话语权。九年前，顾炯炯因其在通信技术创新和产业化方面的突出贡献而获得国家科技进步奖。他也是华为为数不多的技术水平最高的专家之一，代表着华为最强的技术力量。

今天的顾炯炯作为华为云的首席架构师，掌控着云服务的整体架构，从架构层面带领华为云实现技术和商业的突破。

从软件工程师到高级架构师，顾炯炯一路走来积累了丰富的架构经验。本期华为云社区“云享人面对面”专访了这位华为内部员工眼中的“顾大师”。让我们了解顶级架构师如何思考问题，如何打破常规，不断创新，如何带领团队打造“向上刺天，向下扎根”的竞争力。

揭开建筑师的“谜团”

在说结构之前，顾炯炯讲了一个故事。

在任何建筑物从地面升起之前，建筑师必须规划顶层的蓝图设计，以确定建筑物的整体设计美学风格。土木工程师结合力学、材料学等专业知识，形成可以指导施工的设计图纸，最后交由施工队完成具体的施工工作。

整个过程类似于云服务产品的搭建，架构师扮演了建筑师和土木工程师的角色。

这也是顾炯炯对自己的立场。在华为云架构师，他不仅负责架构竞争力的规划、创新架构解决方案的设计和实施，还负责协调各种云服务产品下的技术方案审查和争议仲裁。，以及公共治理结构的制定和维护。

在看似宏观抽象的工作背后，可能有人会疑惑架构师为什么要承担这些任务，云服务架构的目的是什么？

在公有云领域，除了底层计算存储等基础实现外，还有包罗万象的产品线，如PaaS平台、AI、IoT、音视频等，它们之间的依赖关系错综复杂，涉及不同的业务领域、软件技术组件和生态、运维管理工具的选择等，因此需要构建一个类似于在线互联网业务的可操作的、可持续的、敏捷的、低代的架构体系。

当这样一个全栈的云系统建立起来时，需要一个既能控制整体瓶颈又能控制局部瓶颈并针对具体业务场景提供解决方案的团队负责人。这也是顾炯炯必须承担的角色。

他描述，“如果把每一个云服务看成一个积木，架构师必须完成积木的构建过程，定义好每一个积木的形状和大小、积木之间的接口、协同与组合，从而进一步形成一个更大的可能实现特定功能的‘积木’。”

那么，在宏观架构设计的背后，有没有有价值的方法论，让后来者能够遵循这样的规则，避免一些坑，少走弯路？

在设计架构之前要了解的重要规则

康威定律指出，最合适的软件架构始终是与软件架构解决或服务的领域业务架构，甚至组织和流程架构最匹配的架构。

所以，在开始设计架构之前，首先要对业务有深刻的理解，明确云服务是可以在线消费的数字化产品，架构要解决产品的成本投入和产出问题，为用户服务谁使用资源和云服务。运维人员和其他利益相关者。

这里的挑战是，当架构师在设计顶层架构时，会出现跨服务域的冲突。这时候架构师不需要深入到每一个服务领域，把所有的技术都了如指掌，但至少要知道这些服务在业务层面要解决的核心技术挑战。

顾炯炯根据自己的经验提出，一个系统架构首先要保证它所承载的业务目标能够实现。

一是架构必须完整，能够满足基本的业务功能需求；其次，必须对可靠性、可用性、运维、安全等非功能性需求进行适当的权衡；最后，确保整个架构设计是可行的实现。

正如顾炯炯所说，“没有完美的建筑可以解决所有问题，也没有不‘腐烂’很久的建筑。蓝图再美，交付不出来也是不现实的。” "

在此基础上，一个优秀的架构往往具有以下五个关键特征：

为了更形象地呈现架构设计的逻辑，顾炯炯以华为云的架构为例进行了细分拆解，阐述了这种分而治之、层层分解、细化的架构是如何实现的。一点一滴建成。

谈经验，揭秘华为云架构设计

一个完整的架构设计在实施时架构师，必然有一个自上而下、分而治之的架构逐步分解、细化和反馈修正的过程。

顾炯炯会从业务功能和非业务功能的质量属性（可靠性/可用性、安全性、性能）两个维度考虑具体的架构设计。

以华为云的公有云为例，云服务商作为一个整体，通过互联网或企业物理专线在自建或租用的数据中心构建资源池，开发部署多样化的平台层和业务层软件。

然后通过Web UI或API，以云服务产品的形式提供给企业。这些全栈云服务产品又可以进一步细分为：云平台、云服务、云运维计费系统、云运维监控和故障管理系统等，通过定义它们之间的API接口等等，子系统云服务、云运营计费、云运维工具等进一步拆解和细分。

架构的解耦、弹性、安全性和可用性等因素至关重要。以华为云的微服务解耦为例，支持无数据库和表对象的直接共享；外部API符合自声明自包含特性，不暴露内部实现细节；每个云服务不仅鼓励共享开发组件和平台，也不排斥将云服务解耦以选择最合适的开发语言和技术组件。

顾炯炯强调，云架构必须与运营状态解耦。因此，在规划整体架构时，更需要明确顶层架构的边界和交互。在这样的框架下，一方面每个产品服务都可以保持自己松耦合的灵活性，另一方面必须遵循统一的治理结构来构建自己的竞争力。

在这方面，建筑师不仅要从“为什么做这个”、“做什么功能”、“能打造什么样的差异化竞争力”等服务产品的宏观角度去收集建筑规划设计的原始投入。还要防止一头扎进技术实现和开发细节的讨论中，“埋头拉车，不管抬头看路”。同时，架构师还必须从偏向于研发的开发和实现的角度来判断如何设计和划分领域服务架构。

因此，架构师不仅要具备驾驭全局的能力，还要洞察局部技术实现的细节。

在确定了满足业务功能的逻辑架构之后，下一步就是考虑在底层可以使用哪些技术来支持该架构。只有在这个阶段才涉及到具体的开发语言、组件和工具的实现选择。对于整个架构设计的开发，可以参考业界通用的方法论：4+1 View。

当然，架构设计的重点不仅仅在于复杂软件系统的内部组成设计。需要注意的是，API 连接了整个架构和外部世界：可以通过 API 调用云服务，也可以通过 API 支持更复杂的应用开发，更高效地构建行业应用解决方案。因此，云服务API本身的开放性和易用性是极其关键的，而且考虑到API是普通开发者使用的，需要仔细考虑如何让他们更容易、更高效地使用和组合API设计开放式架构时的能力。

在架构设计为开放易用的同时，也需要把握边界，比如“API是否按照每个云服务与其内部微服务解耦的要求进行自我声明，不包括内部实现状态信息；完整覆盖必要的输入和输出参数，同时屏蔽架构的内部实现细节。”

顾炯炯强调，“如今，云计算和互联网领域更加注重软件开源、生态开放和快速迭代演进能力。因此，确定了一些服务API不一定基于业务领域驱动的架构设计模型。” . API 设计也将被打上开源生态系统的烙印。”

比如计算、存储、网络服务层、K8S、大数据/AI层/Spark、//MXnet等，都是华为云在坚持开放架构和易用性的同时，保持与开源的兼容性生态系统。

开创性的架构创新：和灵活的计算

从普通技术工程师到首席架构师，顾炯炯经历了架构迭代演进的黄金时期，他回忆道：

架构的迭代总是与技术的演进齐头并进。从大型机时代的单体架构到PC时代逐渐形成的“初级”分布式架构，越来越多的企业开始采用开放的分布式架构。互联网的成功经验将传统的单体软件架构拆分为运行状态下完全解耦的微服务架构。

当所有的应用都诞生在云中，并且比云长，云架构的迭代也将进入一个新的阶段。新故事自然有新的叙述方式。顾炯炯聚焦云原生2.0，提出了分布式云、混合调度、应用驱动基础设施、存储计算分离和数据治理自动化、可信、平民化、基于软总线的8个关键趋势异质性。架构一体化，多模态可迭代AI模型，全方位立体云安全。趋势解读详见：华为云首席架构师独家分享：云原生8大趋势2.0架构设计-云社区-华为云

当然，架构师不仅要对整体技术趋势有敏锐的洞察力和全球视野，还要有一点大胆的想象，敢于挑战一成不变的模式，打破现有格局，找到驱动新一轮的重要契机的增长。.

这是顾炯炯这么多年当建筑师的心得。他也一直在探索构建华为云差异化竞争力的机会。

：引入全局调度能力，挑战传统资源调度模型

以当前数据中心资源池分布不均衡的问题为例，为积极落实碳中和要求，国家发改委提出“东西部”工程。对于公有云厂商来说，资源的均衡分配在架构层面提出了一个难题：如何解决东西部区域的畅通引流，让用户可以将业务负载从东部城市平滑迁移到西北，而不至于被意识到这一点。比如华为云刚刚建成的乌兰察布数据中心。这涉及区域层面的结构分层、全球调度，甚至东西方资源的定价差异。

顾炯炯认为，由于当前很多服务分层概念的设计沿用了传统方式，很难以一致的模型实现资源调度的真正平衡。在这种时候，如果建筑师“没有独立思考和质疑的能力”，那是非常危险的。

“每个云服务商所面临的实际挑战各不相同，传统的看法未必正确。” 以顾炯炯为例，通常情况下，用户在购买资源之前先选择（地区），而且他们有全球部署的云服务。, 网络拓扑的连接没有一个整体的概念，所以云厂商需要为用户揭开迷雾，将资源的分布、价格、使用状况一一呈现。架构设计打破了高层服务的约束，引入了全局调度能力。基于对算力成本、特定云服务和业务负载的访问延迟、应用/应用组之间的通信耦合关系的优化，为用户提供最优的解决方案。最好的选择。至于具体云服务的资源实例下发到哪个地理区域，完全由云端的智能调度系统动态决定。

“我们称之为过程转换。” 顾炯炯进一步解释，“把困难留给自己，我们会完成调度策略，屏蔽底层资源调度的复杂性。用户不再需要选择自己的地理位置，可以享受全球服务的全球部署能力。”

弹性计算：真正使用水电等云资源

如上所述，架构师应该有一点反抗的勇气，能够想出更好的解决方案。顾炯炯从架构上提出，试图解决长期存在的区域资源分布不均的问题。同时，他把目光投向了一个大多数人会忽略的问题：提高服务器的 CPU 利用率。

“业内大部分公有云厂商都有一个共同的问题：有数百万台服务器，但每台服务器的平均CPU利用率可能只有20%左右。” 这个数据可能会让很多人感到惊讶，但这就是现实。在众多数学家的帮助下，华为云普遍将资源分配率提升到了80%甚至90%。但是分配率不等于利用率：虽然大量的计算资源被出售并分配给用户，但这些出售的计算资源的有效利用率只有1/4左右，接近3/4计算资源实际上并没有转化为租户可消耗的、可用的“云资源”。

顾炯炯表示，弹性计算虽然是主流，但并不代表就是最好的模型。用户购买虚拟机和容器并不是最终目的。关键是其中的资源能否支撑上层的应用负载。至于具体用法，需要动态衡量。为此，他提出了一个概念：灵活计算。

顾炯炯打了个比方，“目前的弹性计算计费模式，就像是按照家电的额定最大功率乘以使用时长来计算电费，而弹性计算是按照家庭实际用电量计费。电表。”

柔性计算不仅具有弹性的特点，既保证了横向资源扩展，又使纵向资源规格可大可小。目前消费云内部已经验证了柔性计算的能力，在不改变上层业务的情况下，可以提高利用率，性能翻倍。

“但是，未来我们要实现水电等云资源的精细化计量计费和动态调度，还需要引入人工智能、大数据等技术，形成闭环。”

顾炯炯强调，这不仅仅是一个正式的介绍，而是他们将改变当前资源分配的基本逻辑：不再使用资源来匹配资源，而是使用动态负载来匹配底层的物理/虚拟资源。资源分配的基础从静态固定的虚拟机和容器规格转变为可以在一定范围内动态改变CPU和内存利用率的“应用负载实例”。

从云原生2.0下的八大架构趋势到弹性计算的架构创新，这些都是顾炯炯作为首席架构师最常思考的问题：如何通过架构创新价值为用户带来差异化服务。他也始终认为，“即使现有的模式已经很好，你不妨质疑一下，说不定你会发现新的机会。”

总结：

云和IT领域的技术可谓是突飞猛进，所以这个行业的架构师就像是“逆水行舟，不进则退”。建筑师肩上的担子也很重。他要做好大型系统的架构规划和各种重大方案设计的取舍和最终实施。这种整体的眼光和敏锐的洞察力，加上广阔的创造力和想象力，也是顾炯炯从一个普通的技术工程师到首席架构师的关键。

最后附上顾炯炯总结的架构师能力清单，与开发者分享：总结10年经验，华为教你如何成为优秀架构师？-云社区-华为云