获得国家科技奖是一种什么体验？
这是一个颇为凡尔赛的话题，但这位华为Fellow确实有话语权。9年前，因在通信技术创新和产业化上做出突出贡献，顾炯炯获得了国家科学技术进步奖，他也是华为为数不多的最高技术等级专家，代表着华为的最强技术战力。
如今的顾炯炯，作为华为云的首席架构师，全局操盘着云服务的整体架构，从架构层面带领华为云实现技术和商业上的突破。
揭开架构师的“神秘面纱”
在谈架构前，顾炯炯讲了一个故事。
任何一座建筑拔地而起前，都要由建筑师规划好顶层的蓝图设计，确定建筑的整体设计美学风格。土木工程师结合力学、材料学等专业知识形成可指导施工的设计图纸，最后交由施工队伍完成具体的建造工作。
整个流程和云服务产品的构建类似，架构师在其中扮演的角色相当于其中的建筑师，以及土木建筑工程师的角色。
这也是顾炯炯给出他对自己的定位，在华为云，他既要负责架构竞争力的规划工作、架构创新方案设计及落地开发，还要协调各个云服务产品下的技术方案评审和争议仲裁，以及公共治理架构的制定维护。
看似宏观又抽象的工作背后，也许会有人疑惑，为什么架构师要去承担这些工作，云服务架构的目的又是什么？
在公有云领域，除底层的计算存储等基础实施之外，上面还有包罗万象的产品线，比如PaaS平台、AI、IoT、音视频等等，它们彼此之间的依赖关系错综复杂，并涉及到不同业务领域、软件技术组件与生态，运维管理工具的选型等，所以要构建一个类似线上互联网业务一样可运营、可持续敏捷低代的架构体系。
当建立了这种全栈云的体系后，就需要一个既能掌控整体又洞悉局部瓶颈，并依据具体业务场景给出解决方案的团队领导型人物，这也是顾炯炯要承担的角色定位。
他形容，“如果将每个云服务都看作一个积木，架构师就要完成积木搭建过程，定义每个积木的形状大小、积木之间的接口、协同及组合，从而进一步形成更大的可以满足特定功能的‘积木’。”
那么，宏观的架构设计背后，是否有极具价值的方法论，让后来者得以遵循这样的规律，避开一些坑，少走一些弯路？
设计架构前，需要明白的重要规律
康威定律里提到，最合适的软件架构，永远是与该软件架构所解决或服务的领域业务架构，甚至组织与流程架构最匹配的。
所以在着手设计架构前，首先对业务有深入的理解，明确云服务是线上可消费的数字化产品，而架构要解决产品的成本投入和产出问题，并服务好使用资源的用户、云服务运维人员等相关利益人。
这其中的挑战在于当架构师进行顶层架构设计时，会出现跨服务领域的冲突。此时架构师并不需要深入每一个服务领域里面，对所有技术了如指掌，但至少得清楚这些服务的业务层面要解决的核心技术挑战。
基于自身经验，顾炯炯提出，一个系统架构首先必须确保其所承载的商业目标可以达成， 也即从商用成功的目标“以终为始”反推，可以大体描摹出一个优秀的架构。
首先架构必须是完整的，它能满足基本的业务功能需求；其次是对诸如可靠性、可用性、可运维、安全性等非功能性需求有合适的权衡取舍；最后要确保整个结构设计是可实现的。
如顾炯炯所说，“没有一个完美的架构可以解决所有问题，也没有一个架构是长期不‘腐烂’的，蓝图画的再美，如果不能交付都是不切实际。”
在此基础之上，一个优秀的架构往往具备以下五个关键特性：
架构是容易被理解、简单的；
架构是稳定的，能对未来的发展趋势做出足够的前瞻性判断，适应需求的变化；
架构考虑同类产品的需求，易于其他产品复用；
架构和现有人力、物力、资金、交付时间等条件匹配；
架构不能是一锤子买卖，它必须是容易维护和管理。
为了更具象地呈现架构设计的逻辑，顾炯炯以华为云的架构为例做了细分拆解，解读这种分而治之、层层分解细化的架构是如何一点点搭建起来的。
经验之谈，揭开华为云架构设计的奥秘
一个完整的架构设计落地，必然存在一个将其自顶向下、分而治之的架构逐步分解细化、反馈修正的过程。
顾炯炯会从两个维度来考虑具体的架构设计：业务功能，以及非业务功能的质量属性（可靠/可用性、安全性、性能）。
业务功能方面
以华为云的公有云为例，整体是云服务商通过互联网或企业物理专线，在自建或租用的数据中心内搭建资源池，并开发部署多样化的平台层、业务层的软件。
再通过Web UI或API，以云服务产品的形式提供给企业使用。 这些全栈云服务产品又可进一步细分为：云平台、云服务、云运营与计费系统、云运维监控与故障管理系统等，通过定义它们之间的API接口，并依此类推，将云服务、云运营计费，云运维工具等子系统进一步进行架构拆解与细分。
非业务功能方面
诸如架构的解耦、韧性、安全性、可用性都至关重要。以华为云的微服务解耦为例，它支持无数据库及表对象的直接共享；对外API符合自声明、自包含特征的同时做到不对外暴内部的实现细节；各云服务既鼓励共享开发组件与平台，也不排斥解耦云服务选择最适合的开发语言与技术组件。
顾炯炯强调，云架构一定要运行态解耦，因此在做整体架构规划的时候，更需要明确好顶层架构的边界和交互关系。 在这样的框架下，各个产品服务一方面能够保持自己松耦合的灵活性，另一方面也必须遵从统一的治理架构开展各自竞争力的构建。
在这其中，架构师既要从“为什么要这样做”、“要做哪些功能”、“能构建什么样的差异化竞争力”等偏服务产品的宏观视角收集架构规划与设计的原始输入，又要防止一头扎进技术实现与开发细节的讨论上，“只顾埋头拉车，不顾抬头看路”。与此同时，架构师还要从偏研发的开发实现视角判断如何进行领域服务架构的设计与划分。
所以，架构师既要有全局掌控能力，又能洞悉局部的技术实现细节。
在确定满足业务功能的逻辑架构后，下一步再考虑底层可以选用何种技术支撑该架构， 到这一阶段才涉及到具体开发语言、组件、工具的实施选择。整个架构设计的展开则可以参考业界通用方法论：4+1架构视图。
当然，架构设计的重点不仅聚焦于复杂软件系统的内部构成设计。需要注意的是，API串联了整个架构和外部世界：云服务可以通过API被调用，也可用API支撑开发更复杂的应用，更高效地构建行业应用解决方案。所以云服务API本身的开放性、易用性显得极为关键， 而且考虑到使用API的是普通开发者，在开放架构设计时更要慎重思考如何让他们更容易且高效的使用、组合API能力。
架构设计做到开放易用的同时，也要把握住其中的边界，比如“API是否做到各云服务及其内部各微服务解耦所要求的自声明式，不包含内部实现状态信息；是否在屏蔽架构内部实现细节的同时，完整覆盖必要的输入与输出参数。”
顾炯炯强调，“如今云计算、互联网领域对开源软件、生态的开放性及快速迭代演进能力更为看重，因此决定了部分服务API不一定完全基于业务领域驱动的架构设计模型，有时架构边界与API设计也会打上开源生态的烙印。”
比如计算、存储、网络服务层的Openstack、K8S，大数据/AI层的Hadoop/Spark, Tensoflow/Caffex/MXnet等，都是华为云坚持架构开放性、易用性的同时保持与开源生态的兼容并蓄。
敢为人先的架构创新：Regionless和柔性计算
从一个普通的技术工程师到首席架构师，顾炯炯经历了架构迭代演进的黄金时期，他回忆道：
架构的迭代总是与技术的演进齐头并进，从大型机时代的单体架构到PC时代逐渐形成的分布式架构“雏形”，如今越来越多的企业开始采用开放的分布式架构，也通过借鉴互联网的成功经验，将传统单体软件架构拆分为运行态充分解耦的微服务架构。
当一切应用都生于云，长于云，云架构的迭代也会进入一个新的阶段。新的故事，自然有新的叙事方法。围绕云原生2.0，顾炯炯提出了八个关键趋势：分布式云，混合调度，应用驱动基础设施，存算分离与数据治理自动化，可信、平民化DevOps，基于软总线的异构集成，多模态可迭代AI模型，全方位立体式云安全。
当然，架构师不仅要有洞察整体技术趋势的敏锐力和全局视角，还得具备一点大胆的想象力，敢于向一成不变的模式提出挑战，打破既有格局，找到驱动新一轮成长的重要机会点。
这是顾炯炯在架构师岗位这么多年来的心得感悟，他也一直探索能够构建华为云差异化竞争力的机会路径。
Regionless：引入全域调度能力，挑战传统资源调度模式
以当下数据中心资源池分配不均衡的问题为例，为积极落实碳达峰碳中和要求，发改委提出了“东数西算”工程。对于公有云厂商来说，资源的均衡分配在架构层面提出了难题：如何解决东西地区的平滑引流， 让用户在几乎无感知的情况下，将业务负载从东部城市平滑地迁移到西北部，比如华为云刚刚建好的乌兰察布数据中心。这其中涉及到地区层面的架构分层以及全域调度，乃至东部和西部资源的定价差别等等。
顾炯炯认为，由于当前很多服务分层理念的设计都沿袭传统方式，一以贯之的模式让资源的调度难以做到真正的平衡。这种时候，如果架构师“没有独立思考和质疑的能力，是很危险的。”
“每个云服务厂商面临的实际挑战不一样，唯传统是瞻不一定正确。”顾炯炯举例，通常情况下，用户购买资源前都是先选Region（地区），而他们对云服务的全球部署、网络拓扑的连接并没有整体概念，所以云厂商需要为用户揭开迷雾，将资源的分布、价格、使用现状一一呈现出来。在架构设计上打破Region级服务的约束，引入全域调度能力，基于对算力成本最优化、特定云服务及业务负载接入时延，以及应用/应用群之间的通信耦合关系，为用户提供最佳选择。至于具体云服务的资源实例发放到哪一个地理区域，完全由云的智能调度系统动态确定。
“这个过程我们称之为Regionless化。”顾炯炯进一步解释道，“把困难留给自己，我们来完成调度策略，屏蔽底层资源调度的复杂性，用户不再需要自己选择地理Region，得以享受全局服务的全球部署能力。”
柔性计算：真正如用水、电一样使用云资源
如前所述，架构师要具备一点点反叛的勇气，并能另辟蹊径提出更好的解决方案，顾炯炯从架构出发提出了Regionless，试图解决地区资源分配不均衡的痼疾。同时，他将目光瞄向了大多数人会忽略的一个问题：提高服务器的CPU利用率问题。
“业界大部分公有云厂家都存在一个通病：有上百万台服务器，但每台服务器的平均CPU利用率可能只有2成左右。”这个数据可能出乎很多人的意料，但现实就是如此。之前华为云在许多数学家的帮助下，将资源分配率已普遍提高到80%甚至达到90%。然而分配率并不等于利用率：大量的计算资源虽然售卖并分配给用户，但这些售出的计算资源中有效使用率只有1/4左右，近3/4的计算资源其实并未转化为租户可消费、可使用的“云资源”。
顾炯炯表示，虽然弹性计算是主流，但并不代表它是最好的模式。用户购买虚拟机和容器不是最终目的，关键在于其中的资源能否支撑上层的应用负载，至于具体使用了多少则需要动态度量的。为此，他提出了一个概念：柔性计算。
顾炯炯打了个比方，“目前的弹性计算的计费模式，就像按照家用电器的额定最大功率乘以使用时长来计算电费，柔性计算则是按照家里电表的实际用电量度量收费。”
柔性计算不仅仅具备弹性的特征，保证了横向的资源扩展，而且它也能实现纵向资源规格的可大可小。目前，消费者云已经在内部验证了柔性计算的能力，可以在不改变上层业务的前提下提高利用率，实现性能的倍增。
“不过未来我们想实现像用水、电一样的精细化计量计费和动态调度云资源，还需要引入AI、大数据等技术形成闭环。”
顾炯炯强调这不仅是形式上的引入，它们会改变现在资源分配的基本逻辑：不再用资源去匹配资源，而是用动态负载匹配底层的物理\虚拟的资源。 使资源分配的依据从静态固定的虚拟机、容器规格，转变为可在一定范围内时刻动态改变CPU、内存利用率的“应用负载实例”。
从云原生2.0下的八大架构趋势，到Regionless和弹性计算的架构创新，这些都是顾炯炯身为首席架构师最常思考的问题：如何通过架构创新给用户带来差异化的价值。他也始终坚信 “即便既有模式已经很好，也不妨对它们提出一些质疑，也许会发现新的机会点。”
总结：
云与IT领域的技术可谓一日千里，因此架构师在这个行当里就好比“逆水行舟，不进则退”。架构师肩上的担子也很重，他要做好一个大系统的架构规划及各项重大方案设计权衡与最终落地，同时又能不囿于一些技术的细枝末节，有所取舍。这种全局性的视野和敏锐的洞察力，再加上开阔的创造力和想象力，也是顾炯炯从一个普通技术工程师走上首席架构师的关键。
