自2009年加入百度至今，已经走过了11年职业历程。我从一线研发工程师起步，逐步成长为负责复杂技术方向的技术负责人。十余年的工作经历，让我有机会亲历大规模技术演进，尤其是云计算与云原生技术从萌芽走向普及的全过程。随着技术环境变化，软件工程师和软件架构师所需要具备的核心能力也在不断升级。借着入职11周年这个时间点，结合我在百度的成长经验，总结一下我认为在云计算，尤其是云原生时代，软件架构师必须具备的关键能力，希望能帮助正在成长为架构师的同学少走一些弯路。
初出茅庐 |从工程师变成子系统的技术骨干
读书时我对搜索引擎其实并不了解，但一直希望自己能够投身一个足够有技术深度的方向。当时听说 Google 三驾马车相关论文非常经典，就第一时间找来学习。但受限于当时的技术积累，我对 MapReduce 的设计理念几乎无法真正理解。后来偶然读到一本搜索引擎入门书籍，立刻被搜索引擎技术体系所吸引。我意识到，搜索引擎同时覆盖工程与算法两大领域：从底层 Linux 内核到分布式系统，从基础压缩算法到复杂的 PageRank，这是一条足以长期深耕、持续学习一生的技术路线。于是，带着做搜索引擎的信念，我开启了求职之路。后来有幸同时拿到了百度和阿里的 offer，考虑到百度在搜索技术领域的领先优势，我最终放弃了后来成长为“阿里云”的机会，选择加入百度。
刚入职时，我被分配到搜索工程团队，参与的第一个项目是基于 Hadoop 重构原有伪分布式架构下的建库系统，解决伪分布式架构无法线性扩展的问题。当时百度的索引数据量增长极快，急需借助 MapReduce 这类具有时代意义的分布式架构来支撑业务发展。我也正是在这个阶段加入团队。经过3年多时间，我和团队伙伴一起将建库系统从伪分布式架构升级为 MapReduce 架构，又在此基础上进一步优化为流批一体、流批结合的流式建库架构，使建库效率提升了数十倍以上。我自己也从一线研发工程师逐渐成长为小方向的核心技术骨干。回顾这个阶段，我认为主要锻炼了以下3项核心能力：
（一）软件工程的持续改进能力
软件研发本质上是团队协作，每一位工程师都是研发链路中的关键一环。在软件工程领域，决定团队研发效率的核心因素，往往不是单点技术能力，而是研发流程与协作机制的效率。互联网行业变化快、不确定性高，而云原生时代更强调 DevOps 理念与敏捷研发模式，通过快速迭代、持续交付和及时试错来应对复杂环境。我们团队从2011年开始尝试由传统瀑布式研发转向敏捷研发，并引入 DevOps 工具体系来支撑整个敏捷流程的落地。
下面是我总结的几点核心能力：
把握关键流程：需求分析、产品设计、软件研发、产品验收等关键环节，都需要明确责任角色并建立审查机制。例如，需求分析和产品设计必须经过产品负责人评审，软件设计、编码和测试则必须经过技术负责人及对应模块负责人的审查。只有把关键流程控制住，软件研发质量和交付效率才能真正稳定下来。
使用工具自动化：为了提升研发效率，要尽可能把大量重复性高、标准化程度高的工作自动化，包括文档管理工具、需求卡片自动状态流转、IDE 和代码审查工具、代码搜索系统、构建与自动化测试流水线以及基础设施平台等。通过自动化减少低价值重复劳动，本质上就是工程师文化的重要体现，也是现代软件开发和云原生研发体系中非常关键的一环。
重视代码审查：代码是软件研发过程中最核心的交付成果，也是工程师协作的核心媒介之一。作为架构师或技术骨干，需要能够识别代码审查流程中的问题，并持续优化相关机制。Google 在代码审查方面的实践，为业界提供了非常有价值的参考，也值得软件架构师和研发团队长期借鉴。
无论是架构师还是技术骨干，都需要对研发流程中的每个环节保持高度敏感，及时发现问题并提出有效改进方案。很多人常讨论架构师要不要写代码，其实无论写不写代码，能够持续洞察研发流程、优化协作方式，才是真正推动软件项目高效、高质量落地的关键。
（二）业务需求分析和理解能力
深入理解业务，能够让架构设计更快落地，也能让架构师与业务研发团队之间的沟通更加顺畅高效。因此，架构师切忌脱离业务，尤其是业务线架构师，更要持续保持对业务场景、业务目标和业务变化的理解能力。以我们搜索架构团队为例，就需要经常和算法团队沟通，讨论他们当前的技术痛点以及未来的发展预期，从而提前在工程架构层面做好规划和准备。
理解业务：技术的根本目标是帮助业务成功，架构设计作为技术体系的核心组成部分，也必须服务于业务目标。因此，软件架构师一定要加强对业务的深入理解，洞察业务痛点。更偏业务型的架构师，甚至需要具备一定的前瞻性，能够预测业务发展趋势，并提前在关键技术方向上完成准备。例如，当年我们之所以决定迁移到 MapReduce 架构，就是因为预判到原有架构已经无法承载未来持续增长的数据规模，必须提前布局。
提炼需求：很多时候，用户或业务方提出的“需求”并不一定是真正的需求。面对需求，架构师要养成多追问、多思考的习惯，分析需求对应的业务场景是什么，真正要解决的问题是什么，从而识别并还原真实需求。作为架构团队，算法和运维同学经常会向我们提需求，但这些需求往往已经带有他们自己的加工与假设，把某种解决方案当成了需求本身。只有通过深入讨论业务场景，才能准确把握真实诉求，进而设计出更优的技术方案。
（三）技术折中和持续优化能力
随着业务发展和技术演进，我相信任何公司、任何系统，乃至任何代码模块，都会存在一定程度的技术债务，或者说存在一些并不理想的实现方式与架构设计。软件架构师需要具备识别真正技术债务和技术折中的能力，这要求架构师能够判断这些问题的影响范围与严重程度，并推动技术体系朝着持续优化、持续演进的方向发展。
所谓合适的时机，核心在于把握真正的目标。解决技术债务本身不是目标，而是实现业务目标和提升研发效率的手段。只有明确目标，技术优化才能更有针对性。比如某些高频迭代模块，由于结构耦合严重，已经明显影响研发效率、新功能发布速度，或者因质量较低而频繁出现线上问题，这时就需要优先治理。再比如，优秀的架构师还需要在一定程度上预判未来趋势，推动技术向更先进、更适配的方式演进。我经常会遇到一种情况：面对多种技术选型时，架构师容易执着于所谓“统一架构”，并把统一本身当成目标，却忽略了背后真正的业务诉求，最终并不能有效解决问题。
迭代式演进通常能够有效降低技术风险，但在实践过程中需要避免两个极端。一个极端是动辄发起大规模重构，一个项目耗费数人年甚至更长时间才能上线，这不仅项目风险极高，也大幅降低了试错机会。另一个极端则是持续“打补丁”、不断添砖加瓦，只关注新功能设计与研发节奏，却完全不做技术债务治理。时间一长，系统会越来越难维护，类似的失败案例在行业里并不少见。
游刃有余 |从技术骨干成长为架构师
到2012年前后，我对分布式建库系统已经非常熟悉，大大小小的相关项目处理起来都比较从容。但我自己并不完全满足：一方面，我觉得自己主要集中在建库环节，对搜索引擎中的检索和抓取链路几乎没有接触；另一方面，很多已有成果更多是在前人积累基础上的延伸，自己真正原创且具有前瞻性的技术实践还不够多。所以，我希望参与一些更具开创性、此前没有系统做过的新技术方向。从2013年开始，我跟着师傅一起探索新的技术体系。我们当时观察到，无论是离线服务还是在线服务，微服务框架与中间件能力都还比较初级，开源生态中也缺少足够成熟的解决方案，于是决定自研一套更先进的微服务系统。现在回头看，它大致相当于 K8S + ServiceMesh + SpringBoot（C++版）的组合体。这个技术方向一方面让我对 C++ 底层技术有了更深刻的理解，另一方面也让我更早接触并理解了微服务架构背后的思想与技术趋势。在整个技术方向的研发和业务落地过程中，我的能力也得到了更加全面的锻炼，从技术骨干逐步成长为负责一个技术方向的软件架构师。与此同时，这也恰好是以 Spring 为核心的微服务技术快速发展的时期。
（四）归纳抽象和技术泛化能力
我认为，架构设计的本质就是抽象与泛化。在设计微服务框架的过程中，无论是对外接口设计，还是内部组件划分，我都经历了大量关于抽象思维的训练。所谓抽象，就是把共性与差异分离出来，将共性部分抽象为独立接口、功能模块或服务能力；所谓泛化，就是把已有技术能力推广到更多相似场景中，解决更广泛的同类问题。抽象与泛化相辅相成，都要求架构师对问题进行反复深入思考与对比分析，抓住问题背后最本质的部分，并优先解决本质问题。日常写代码时，如果能够遵循 SOLID 等代码设计原则，并在合适时机对代码或架构做局部重构，这些过程本身就是锻炼抽象能力的最佳方式。有了代码级抽象与泛化能力作为基础，才能进一步参与模块级、子系统级甚至平台级的架构设计，不断提升架构设计能力。
抽象和泛化能力的培养，前提是能够看清事物本质。对此，我特别推荐大家刻意训练结构化思维。《金字塔原理》以及《系统化思维导论》等书籍，都是训练结构化思维的经典读物，对思维方法、分析框架和表达逻辑都有非常系统的阐述，值得认真阅读，并结合日常研发、技术设计和架构思考反复实践。
历史是一面镜子，日常工作中及时总结和复盘同样非常重要。每当完成一个阶段性目标后，及时对自己的工作过程、设计思路和最终结果进行复盘，能够帮助我们站在更高视角重新审视问题，也更容易发现不足并持续改进。这对软件架构师成长尤其重要。
（五）项目管理和技术领导能力
随着个人能力不断提升，我开始逐步承担技术方向负责人的角色，同时并行推进多个项目。一方面，需要带领整个研发团队完成多个项目的落地；另一方面，还要规划团队未来的发展方向。这就要求架构师不仅要具备扎实的项目管理能力，还需要拥有一定程度的技术领导力，才能带领团队持续产出结果。项目管理的核心，主要包括项目工作的合理拆解、研发任务的有效分配以及项目进度的持续跟踪。在项目推进过程中，还需要结合实际情况做出必要的技术判断与管理决策，例如调整研发优先级和依赖关系、重新分配人力、梳理并协调上下游合作环节等，最终确保项目在既定时间内实现最优结果。
我认为，技术领导力的核心有三个要素：定义目标，结果导向，组织能力。首先是定义目标，目标决定团队前进方向，合理清晰的目标是团队成功的前提。其次是结果导向，团队最终要对结果负责，而不是只对技术本身负责，只有真正创造业务价值，团队才具备持续发展的基础。最后是组织能力，良好的组织能力是团队高效达成目标的重要保障。这包括充分理解团队成员特点，做到知人善用；合理设计协作流程和组织结构，提升整体协同效率；识别核心岗位和关键人才，实现人岗匹配等。管理本身是一门专业学问，软件架构师也需要适当补充管理知识，才能更好地带领团队达成目标。
本文是云原生时代架构师的十大核心能力上篇，后续还会继续推出下篇内容，请扫码关注下方公众号二维码持续关注我们！获取更多微服务、云原生架构、软件架构设计相关的技术内容！
