大咖们如何评判优秀架构师？

点击视频，查看完整直播回放

01

优秀架构师的成长故事

李力：我成为架构师从某种程度上是一件机缘巧合的事情，腾讯没有架构师这样一个实际存在只去做架构规划的岗位，我们技术人员都统称为工程师。腾讯云在2012-13年刚开始研究做云服务器产品的时候，我深入研究了OpenStack这个当时业界最知名的架构，思考我们的云服务器应该怎样去设计才能很好支撑起海量业务。最终在选用开源的OpenStack方案还是自研之间，我们选择了后者。于是我自己设计出了腾讯自研的大规模任务调度系统VStation，从这个项目后我开始觉得自己从工程师变成架构师了，因为我需要去规划一些技术方案和未来的产品走向。再后来，我成为了腾讯云服务器和区块链业务的负责人。

孙玄：我在浙大毕业以后就去了百度，选择百度的原因很简单，校招时的技术总监说三年内可以实现年薪百万的突破，我就签了offer。在百度第一年结束的时候离百万年薪还差很远，第二年依旧差很远，于是我忍不住跑去问当时的技术总监，结果他竟然说自己其实只是个例。为了实现百万年薪的梦想，我觉得代码基础上做得不错还不够，还要在深度和广度上有提升，2011年我加入了一个神奇的网站——58同城。加入58以后主要负责IM平台，这是我职业生涯的一个转折点。因为工作要求我必须从需求分析到架构设计、选型，都要很好地hold住。慢慢地在这个过程里我开始主导一些事情，逐渐成长为一名架构师。

再后来，我个人成长上除了负责IM相关的技术，也开始涉足其他业务方向，比如房产、招聘等业务线。在这个过程中，我觉得收获最大的是掌握了架构设计的本质。于是我逐渐成长为58集团的最高级别架构师、技术委员会主席、转转首席架构师，主要负责中后台、大数据、运维、安全、交易等技术建设。再后来，我有了更高的发展诉求，于是出来创办了奈学教育。

史海峰：2001年，我从北京化工大学计算机专业毕业。到今天已经有19年从业历史，历经四家公司，目前供职于贝壳金服。之前在当当架构部，对架构领域一直很关注，也写了一些架构领域相关的文章。

我记忆中有一件小事对我后来的影响很深：2006年，我当时在亚信工作，9月份的时候，有一个系统要求十月一日上线，到月底了还有一个模块没做。当时的项目经理找过来问我能不能搞定，我也没多想，觉得可以就去做了，最后成功上线了。好几年后，当时的项目经理跟我说起，就是因为这件事让他觉得我是一个靠谱的人。当时这个模块是另外一个同事负责，紧要关头掉了链子，交给我时不仅二话不说就做了，还做得很好，于是建立了对我的信任。回过头来再看，我觉得这是对我职业生涯影响很大的一件事，虽然在当时并不起眼。

信任的积累很重要，因为我们最终都要靠一件件小事，或者一个个成果来证明自己，可能自己都不觉得这些事情到底有多重要，但是人民的眼睛是雪亮的。所以我一直强调我们要踏实靠谱，要建立信任感。用金融的思维来说，这就是信用，因为你做任何一个决策的时候都要考虑风险、成本、收益，但是你的信用是能够影响决策的关键因素，这一点很重要。

02

怎么成为一名架构师？从普通程序员到架构师，只差一个机会怎么办？

李力：我成为架构师算是机缘巧合，而我本人其实还算是一个半路出家的工程师，大学期间学的并不完全跟计算机相关专业。早期的时候没想过自己会成为程序员、架构师甚至去管业务，当时只觉得写代码太难，架构太复杂。有一天一位前辈跟我这样说：“做程序员，是一件非常好的工作，它是把真实世界的需求映射到计算机的虚拟世界中，让机器帮你实现”。我听了之后觉得很科幻，逼格很高，于是决定投身于这个行业。

在这期间，我学了很多技术，也走了很多弯路，一直以来我都对自己早期的技术水平没有信心。有一天，又一位前辈告诉我：“程序开发这条路，技术本身变化非常快，如果追求新潮技术永远追不过来，技术的本质都是一些最基本的东西”。我听了以后大受启发，于是把大一、大二的书拿出来重新看。在这期间我培养出了一个技能，能把一本书从第一页看到最后一页。可能有人会觉得这不算什么，但你工作了以后就会发现人容易变得很浮躁，能完整看完一本计算机相关的书籍并不是那么容易。

类似《编译原理》、《计算机的组成原理》、《算法导论》等等经典书籍，一共看了七八本。一年时间，把书上的习题都做了，代码都写了。我自己定了一个小目标，花5年时间成为一个程序员。

工作以后发现，把基础打牢了，遇到的各种形式的问题其实都在已有的框架内。不论是微服务、无服务计算、大数据还是云服务，核心本质都在我学过的基础范围内。后来我明白了，做技术最重要的是对基础原理的研究，比如有一本书叫《C++的设计与演进》，当你了解原理以后就会理解表象的东西，API、UI是怎么来的。

腾讯云要做云服务的时候，我在想该怎么解决OpenStack的选型问题，到底是选择开源还是自己做。这背后的核心是：我要想清楚解决一个什么问题。最终我们决定，依靠一部分高级别工程师的力量，支持上百万核的调度，而OpenStack大概只能支持1万核不到的调度能力。这个过程其实仍旧是在基础原理里找到一些方法，看似完全不一样的东西，在原理上其实是相通的。所以我后来觉得，我之所以能成为一名架构师，是偶然也是必然。我比较幸运的是在早期花了很多时间把计算机的基础知识恶补和推演一遍，于是能在云领域做好架构师的保障。所以我的建议大家：如果想成为架构师，就不要过分追求新潮的技术，专注于基础的原理。

孙玄：我们从需求方来看，你最终做项目也好还是其他工作也好，本质上都是面对需求，把需求落地到线上的代码、服务。所以我认为，架构师首先要清楚从需求到代码之间的gap，需要做什么去解决这个问题。

架构师需要怎么做，我觉得具体而言有以下几个部分。

第一，需求分析。需求分析的核心看你能否得到最本质的东西。

第二，架构设计。架构模式应该用微服务还是单体？如何针对业务场景、针对公司的时间、运维、研发能力做出选择；

第三，架构选型。微服务架构用什么框架做，性能如何规划等等？

另外一方面，思维的转化很重要，不能光闷头写代码。架构师应该清楚地认识到所在岗位需要什么能力，针对性拆解，去获取。我的经验是，当你不知道怎么办的时候，不断提升输入，参考同类产品的架构，周末去参加技术分享与人交流，只有不断输入才能保证输出。你得有清晰认知，从程序员到架构师的能力。第二，每个认知里都需要持续输入，交流。

史海峰：李力和孙玄两位老师的分享我总结了两点，第一，是不是专业出身不重要。第二，要做出来合适的东西满足需求，不管是用时尚的技术还是古早的技术。

我把架构师的定义总结为了以下七句话：

以工程思维全面理解业务需求；

基于模型和基础模式抽象简化；

提出恰当可行的整体解决方案；

在限定资源范围完成明确目标；

满足业务需求且保证系统质量；

在可预见的周期内具备扩展性；

并在系统生命周期内持续演进。

架构师就是一个代号，它是一个职位还是一个title并不重要，重要的是你在团队或者项目中是否做到了以上的这七句话。做架构师专业度很重要，要有理论的基础，同时还要有项目经验的积累和成果，所以这是一个不断迭代、自我突破的过程。

03

如何定义优秀架构师？什么样的人注定成不了优秀架构师？

李力：我认为成为架构师就挺难的，成为优秀架构师反而没那么复杂了。工作以后我发现了一条规律叫求仁得仁，你把时间花到哪里去了就一定会有所回响。如果把写代码做架构当成养家糊口的本事，以为糊弄完老板就结束了，这样的人难以成为优秀的架构师。

刚毕业到工作的前几年，我每天最开心的就是中午熄灯的时候，我当时觉得好像灯关了世界就是我的，于是我会花很多时间去看书、看别人分享的文章，技术大会视频，了解大家怎么写代码做架构。这背后主要还是兴趣驱动，当你阅遍了各种架构，虽然不能保证成为优秀的架构师，但至少不会去选择一些冷门奇怪，不怎么令人喜欢的架构做实现。

举个例子，以前我在面试时有遇到过一个做实时交易系统的架构师团队负责人，在公司内的级别非常高，他们希望能找到一个更现代化的语言来代替解决C语言实现实时框架，用Go语言去做这个工作，整个团队大概有100来人参与，花了一年时间。后来发现，Go语言本身自带垃圾回收机制，很难干涉具体时间点进行垃圾回收，就容易导致系统实时性不足的问题。

为了解决这个问题，团队做了很多方案，最后都没法上线，最终决定把Go语言的垃圾回收机制关掉。这样导致的内存泄漏，团队负责人竟然不把它算作泄漏，而是对上级重新“定义”为“内存增长”，交易关闭的时候重启就好了。

在这个例子中，我认为他也许是一名优秀的工程师，但却不是一名优秀的架构师，因为他没有解决一个实际的问题。很多时候我们要想清楚，是否非要在某个方向里去解决一个无法解决的问题？

想变得优秀，就要在保持热情的同时去解决实际的问题，拆解业务所面临的问题，为什么要设计这个架构？别人不解决的问题可能本身就不需要解决！我在工作中，时常会对架构设计得非常复杂的方案提出质疑，是否必须这样设计才能解决问题？我认为优秀的架构师要把复杂变得简单，而不是把简单变得复杂。优秀的架构师要让工程师团队都能看得懂，参与进来。你需要扎到业务场景中去，再抽象出来，解决实际问题，让其变成一个可复制、抽象层次上的问题。

孙玄：我个人认为，最好的架构师不是具备了多丰富的知识点，他最需要的特质是折中，他可以在任何场景下都给出优雅的设计方案。举个例子，像腾讯这样的大公司，架构设计上要关注于高并发，但对小型团队来说，架构设计更应满足快速迭代、持续交付的特性。

从本质上看，优秀的架构应该满足的关键就是降本增效。你所做的架构设计是增加了人力和其他成本，还是让人力、运维等降低了，或者让效率提高了？这些才是最关键的。前面提到的折中，再进一步，架构设计的真实本质，就如李力老师说的那样，就是看你能不能把复杂问题简单化。

我也遇到过类似的案例，当我在做企业内训的时候，我问技术团队的同学，你们怎么做微服务架构的拆分。他告诉我说，技术总监设置的标准是按照代码行数拆分微服务架构，标准是1000行。那我问他，假如这个服务需要1001行才能完整实现怎么办，他回答说去把前面的注释删掉，就可以精简到1000行。这个解决方案在我看来就不是优雅的架构设计，做一个优秀架构师，一切脱离场景谈结果，都是耍流氓。优秀架构师要做到百万年薪很难，但朝着目标去努力总会实现。

史海峰：两位老师的分享给我印象很深的有两点。第一，重启大法好。第二，化繁为简，复杂问题简单化。微服务拆分的例子我也遇到过，根本原因在于没有深刻理解代码到底是怎么产生的，系统是怎么产生的，康威定律是什么？我推荐一本叫《聊聊架构》的书，大家可以看看，里面没有一行代码，却把康威定律讲得很清楚。

优秀的架构师还需要有大局观，全局视野，并且少不了责任感，能把事情在更横向的层面去驱动和解决。另外一点还需要有影响力，要让别人对你认可。你是不是优秀的架构师，自己说了不算，要看大家是否认可。所以一位优秀的架构师，一是要能够在全局上看问题，二要有足够强的责任心，三是要有影响力，能够去驱动事情，最终要能把你的理想变成现实，而且变成大家的共识，最终落地成大家的成果。

04

优秀架构师的技能地图到底是什么样？必备硬技能和软实力究竟有哪些？

李力：我认为技能地图、技能点只能是参考指标，并不是所有东西都准备好了才能上。对我这种半路出家的人来说，一开始我可能大部分要求都不能满足。做架构也是一样，并不需要对所有技术了如指掌才能去做。

对架构师也是同理，你要看你做的架构到底做了哪些取舍，做平衡的时候考虑是否完善。你能不能把你做的架构设计以一种简单的方式讲给别人听，并能让别人听懂，那么这或许就是一种比较优秀的架构设计了。

如果要推荐一本书，我推荐《社会性动物》。这本书是社会心理学相关的著作，因为我始终认为我们解决的问题其实都是一些真实世界的投影，这世界上许多问题本身是比较简单的，跟人关联才会显得复杂，反映到架构设计上就是，这许多人机之间产生的问题变成代码之后要怎么去处理？这个问题产生的原因是什么？我们可以在人类几百万年的进化过程当中，找到人解决这类问题的思路或者途径，再把这样的能力赋予到你的架构当中去。所以我倾向于大家把看待问题的洞察力提高一点，然后再反馈到你自身非常精通的领域当中把它对应起来，用代码实现。

孙玄：我跟李力老师的观点非常统一，在这里根据自身经验补充几个方面。第一，我觉得想成为一名架构师，除了硬技能的具备，另外一个重要的软技能就是内驱力。你要想清楚自己未来人生设置的目标是什么，你也许在工作的8个小时中满足业务需求，但在工作以外的时间里就单纯享乐去了，这可能就会影响你的后续发展。

第二，如果已经成为一名架构师了，变得更优秀的诀窍是什么？我认为，诀窍是不管做任何事情，都能透过现象看到本质。你要知道业界现在比较热门的技术是什么，以及技术发展的趋势怎么样？并且你需要判断：这些发展趋势、热门技术是不是真的能够用在我们公司里面？

我认为差距不在于你具备多少知识点，而是在于你到底具不具备一个良好的架构认知的思维模型。因为如果你在一个比较低级的思维模型里面，你即使学了再多的知识，在我看来也仅仅是低水平的重复。你需要的是更高维度的认知，更高维度的架构设计能力，能够把某个点打穿打透。

史海峰：对于架构师的技能维度，我认为具体可以分成6个维度。首先是硬技能，包括技术能力、业务能力；然后是软技能：自驱力是核心发动机，此外还包括高效的学习能力，可以帮助你快速掌握技能。另外一点，良好的心态同样非常重要；最后一个是沟通协作的能力，单枪匹马做出杀手级应用的时代已经一去不复返了。

我之前开玩笑说，架构是一门艺术，架构师就是架构的承载者或者说实现者，应该掌握四门功课，这四门功课是什么？当然不是说学逗唱，而是能多打酱油、能和稀泥、肯背黑锅、敢拉仇恨。因为很多事情架构师如果不扛起来，这个事情就未必能做好，一定需要克服很多困难，这些并不都是简单的技术问题。

到了leader或者是架构师的位置，工作可能更多由面向机器编程层面转向面向人编程的层面。如何把人组织好，让大家达成共识，能够把一个设计、方案，或者说一些架构原则变成每一个人都理解并且能够执行到位，这样的话才能说你的架构不只是你脑子里面的空中楼阁。

互联网时代，绝大部分技术人的寿命会比互联网公司更长，更比自己的代码长，所以我们技术人一定要看当下，能不能把当下的事情做好，体现出自身的价值，这样才能在飞速迭代的互联网世界里走得更长久。

Q&A

Q：老师对现在变态的招聘要求怎么看

李力：我也做了很多年面试官，我觉得要求越多，越是对大家的保护。不要被岗位要求吓到，你只要证明自己在一个点上有所突破，证明自己有拆解问题的能力，其实就足够满足岗位需求。招聘方心里有数，这样全能的人绝对凤毛麟角。实际上真正面试中什么都会的人，反而大多是为了面试而做的准备，一问细节就露馅了。所以我建议，不要花太多时间去研究最新的技术却又不精通，而是要在兴趣点上有所突破。我在面试的过程喜欢让面试者在一分钟的时间讲清楚他们到底解决了什么样的问题，怎么解决的？如果他们回答得清晰明了，一般来说架构都能做的比较好。求职者不要看自己是否全部符合岗位要求，而是重点关注自己符合哪些要求。架构师说到底，最终解决的问题还是有限，面试的时候讲明白一两个问题就行了。

Q：什么是好的架构？

孙玄：大家可以思考一下，能够满足海量高并发需求的架构就一定是好的架构吗？我认为不是。好的架构一定是有它的特定场景的，脱离场景就很难说了。在我看来，作为架构师，首先要对公司当前阶段、业务规模有清晰的认知，知道在当前阶段如何选择技术，不要去过度设计。比如说当前阶段用微服务1.0就可以的话，不用再去强行上微服务2.0，只要架构能够满足当下的业务需求，同时具备未来一段时间的可扩展性就可以了。没有最好的架构，只有最合适的架构。

Q：当现有架构勉强满足业务需求时，架构师怎么办？

史海峰：这个问题非常经典。常规思路，首先看业务规模后面还会有多大增长，然后把它转化为技术指标，了解清楚系统的瓶颈在哪里。如果不能确定就压测，来判断最终要解决的问题在哪里。如果只是勉强满足业务需求，我认为还是比较危险的，因为互联网业务，很有可能会出现流量波动，或者在某个时段访问突增，这样的话系统就容易被击穿，所以需要做冗余，否则流量波动下很容易出现问题。对架构师来说，满足业务需求只是第一步，体现架构师的水准在非功能性需求，要想清楚自己应该干什么。

Q：任务急，时间短，怎么做架构？

李力：这是架构师经常遇见的状况，也才体现出架构师的能力。孙玄老师提到的要做balance（折中），在这种情况下仍旧是一个怎么做的问题。说到底还是抽象层次不一样，如果时间充裕，架构过程应该在建模、分层、耦合、调用等环节上做到充分论证讨论。时间紧任务重，横向比较的点，一定要想明白最重要的事情是什么，最重要的目标是什么，可能会有哪些变化？其实做面向变化的设计挺困难，要搞明白什么地方是重要的，还需要跟上面反馈做不到的可能性，反馈到决策端。架构师也是一个决策环节，不一定要去做所有不可能完成的任务。

Q：在没有碰到大规模，高并发的架构设计项目，没有对应的环境（软硬件条件都没有）的背景下，怎么提升这方面的能力呢？

孙玄：在我看来，第一，应该秉持这样一个信念：因为相信，所以看见。建立足够的自信心，不断告诉自己可以做到这样的架构设计。第二，没见过猪肉总见过猪跑，你可以看看同类产品怎么做的，在脑海里构建一个印象。比如，假设我要做一个高并发的架构设计，我可以看看腾讯的相关分享，抽象出核心关注的点比如尽量提升吞吐量等。

Q：架构设计合格，代码落地能力差怎么办？看源码能提高吗？

史海峰：这个问题我存在疑议，如果是个人而不是团队的话，逻辑上我不认可。代码写不好，大概率架构设计也不行，因为架构设计的本质还是结构，如果你代码写得好，那么必然具备能做好拆解的前提条件，不然很难说代码写不好的人架构设计能做好。另外一点，看源码是很好的一点，一些最火的开源项目的源码，社区讨论的issue，要多去看多去交流，了解别人是怎么做的。另一方面，可以多看看相关的经典书籍比如《重构》、《代码整洁之道》等。

Q：腾讯云有没有相关课程推荐？

李力：腾讯云相关的入门课程，都可以在腾讯云的官网找到。除此以外，对有志于成为高端程序员或者架构师的同学，我有一个经验可以供大家参考一下。我个人在入门云计算的时候，花了很多时间去看不同的云厂商的产品介绍文档，其实这些产品介绍文档都写得挺好的，为什么？因为它是要卖钱的，所以它可能跟课程不一样，是从另外一个角度上阐述这个产品。

而回到今天的架构师主题，我觉得云是一个特别好的切入点。你可以去尝试想一下云服务器，应该提供什么样的接口？应该提供什么功能？在控制台应该怎么去方便用户使用？它跟驾驭公司的日常架构师工作很像，而你去了解这些东西之后，对你的架构师的职业生涯也有帮助。

你未来去做架构设计的时候，会发现原来已经有很多云的产品，云的中间件可以直接用在这个架构设计当中。现在这个时代真的是最好的时代，有了云之后，很多东西都不需要你重复造轮子，只需要付费购买相应的服务，甚至还有很多云产品本身就是免费的。

如果说大家有志于成为架构师，可以从腾讯云的云加社区、腾讯云大学去学一些技术，然后反向地在云的产品介绍文档、云的控制台和API文档里面去找到一些感觉，了解了云的产品之后，可能对你的整个架构设计有更大的帮助，我们在架构设计当中，已经有很多通用的组件可以直接使用了。

Q：如何看待产品经理与架构师的关系？

孙玄：从本质上说，其实不仅仅是产品经理与架构师之间的关系，拓展开为人和人之间关系。最主要的特质是要坦诚、要开放，要平等地去对待这个事。尤其在技术选型、方案上出现争论时，对事不对人。千万不要去猜别人的动机，而是把讨论聚焦在技术实现上，这样也才能保证良好的工作关系与人际氛围。