如何成为顶尖架构师？

在每一个程序员的心里，估计都想成为顶级架构师，这一点是毋庸置疑的，这里我先给大家介绍一下架构师的成长路径。

架构师成长路径

第一个阶段，工作的前三年一定要培养自己扎实的代码落地能力。

（1）架构师总是从优秀的工程师中脱颖而出的；

（2）只有具备代码堆积的量变，才能让自己具备质变的可能性；

（3）这个阶段也是培养自己快速学习新技术的能力；

（4）熟悉各种比较牛逼的分布式中间件的玩法，可以停留在用的阶段。

第二个阶段，工作三年之后一定要培养自己独立带和落地项目的能力。

（1）架构的需求永远是来源于业务，那么要接触业务就必须要做项目；

（2）从业务项目的视角去做架构，才能真正的去验证程序员的设计能力和落地能力；

（3）用最简单的技术方案去解决复杂项目中的技术问题；

（4）只有具备独立带项目的能力，你才能够主导业务项目的架构，包括业务、技术架构等；

（5）只有具备落地项目的能力，才能够去验证你的架构思路的正确性；

（6）解决沟通歧义的能力，具体包括开发人员、管理人员、产品以及需求方对业务的理解程度是不一致的，开发人员、管理人员、产品以及需求方对技术的理解程度是不一致的。

第三个阶段，工作五年之后你就应该考虑如何利用自己的技术硬实力和软实力，去做有价值的事情。

如果你的兴趣是去沉淀业务，做一个业务专家，那么你可以走业务架构的路线。

如果你的兴趣是去沉淀技术，做一个技术解决方案专家，那么你可以走技术架构的路线。

如果你的兴趣爱好是去做技术研究和落地，就可以走我们常说的基础架构的路线，也就是我们常说的Paas和Iaas架构路线。

这里给大家介绍一个阿里的哥们的事迹，以下就是采访内容，大家可以耐心去看，你总会从别人的事迹当中寻找到自己的影子，并找出一条自己成长的路径。

好的，废话不多说，我们就来来具体的采访内容。

我叫道延， 2014年进入阿里，在阿里通信呆了接近两年。2016年底到了业务平台，当时玄难找我的第一件事就是要解决大促的问题，第二件事就是解决安全生产的问题。

我带着这个命题进入业务平台，来做后续一系列的事。今天趁这个机会，和大家分享一下，关于这件事和这件事背后的一些想法，以及我对架构师的一些思考。

对技术的理解

顶层设计

国家每5年有五年计划，这其实就是在国家整个层面的一个非常清晰的顶层架构设计，这里面对国民经济重大建设项目和生产力进行宏观的架构设计，它也是一种架构设计。在这里面，要做什么事要定义的非常清楚，要达到什么样的结果也要定义的非常清楚。

双11的保障也是需要设计的。双11本身是一个业务的活动事件，因为规模比较大，所以需要很多的技术来支撑这个东西。技术里面我们可能要考虑低成本、高效率、高稳定，并且还要引入一些更多的新技术来支撑，也要把这些东西整合好，架构设计好，让它很润滑、很流畅地保证我们的业务。

在阿里巴巴双十一的顶层设计就非常关键了，这个种体量的业务场景估计很多程序员这一辈子都碰不到。

当然就算是你在阿里巴巴，也很难有机会去参与双十一的顶层设计，毕竟大部分人都是在做螺丝钉。

物理架构

大家在阿里可能都听说过，我们有一个比较有名的单元化架构，其实不光阿里有单元化架构，很多公司都有类似的架构。比如微信。阿里和他们的单元化架构其实有一些本质的区别。

阿里目前单元化架构达到一个什么目标呢？通过部署异地单元将生产流量完整运行在千里之外的独立机房，连续性的运行业务。这几句话里面包含了非常多的关键点，一个是异地，第二个是千里之外，第三个是独立，第四个是连续性。

单元化架构的总设计师是老毕，因为我们这块业务跟单元化的架构是非常相关的，所以要对它完成的掌握和吃透才能往下走。

应用架构

目前我们中台里面做的比较多的叫星环，星环说白了，它想达到架构的本质目的就是将单纯的代码共建模式，抽象成横向和纵向的业务包模式，做到业务与业务隔离，业务与平台隔离。

这背后带来的问题是什么？我们原来产生用共建的方式支撑了50多个BU的会员、商品、交易、营销、资金、支付、库存逆向等等业务，其实每个里面都是遍地开花的if else。然后代码的合并也难，开发也难，测试也难，上线也难，整个过程都很痛苦。所以我们当时在2015年开始一直在做星环的架构，就是让这些东西不那么痛苦，慢慢的解决这个问题。当然了现在我们又用了新的痛苦点。

应用架构也是非常重要的，这个也是很多刚入门的架构师最容易犯的错误，你如果能够结合现有的基础架构，做出一套非常合理的应用架构技术解决方案，那说明你非常牛，并且这套应用架构的技术解决方案是建立在你对业务的理解的前提之上的。

架构师的角色

形散而神不散

架构其实是每个应用线每个业务线都有。有些技术同学本身就是有架构师的这种角色。阿里很早以前是专门有架构师岗位，专门的去做架构，但是做着做着架构师就做没了。因为很不接地气，它没有解决具体、真实、实际的问题。但现在可能更多的看到了，其实很多平台很多应用里面都会有一些架构师的角色，他们是在抽象这些技术问题，解决这些问题。所以第一点是行散神不散。优秀的技术同学一直在用架构的意识，解决实际的技术和业务问题，这就跟普通的技术同学有本质的区别。他不光是解决这一个问题，他可能解决这一类问题，用架构的思想去解决问题。

前瞻性

为什么你能解决这个问题，并且能解决这一类问题？一定是你要看的多，你要想的多，这需要大量的实践和知识的积累，并且是站在过去的肩膀上。

阿里电商系统很早就开始建立了，我们这一代一代人在里面去做架构，都是站在前一代人的肩膀上。要去看前一代人为什么要这么设计，去想或跟他去聊，吸取他好的地方。现在可能遇到新的问题，通过其他的方法来解决一些新的问题，需要有实践和知识的积累。

接触更多的人和事，用新方法解决新问题。这个很关键。不能只看代码看一个月，要找真实的业务方，你的上游，你的下游，你的合作伙伴。比如说做双11，我是2016年12月份到业务平台，我花了整整三个月，跟每年双11的大队长、重要人去聊双11。他们是怎么理解，怎么来思考的，他们认为什么地方有问题。我再找他们要一些建议：我应该怎么去做。跟他们聊的过程中才知道我们需要做什么样大促，要把握什么是关键点，这都是一些宝贵的财富。

解决复杂问题

好的架构师都在解决复杂的问题。只有复杂的问题，它才需要更多不一样的技术或更新的技术彻底解决。高并发高可用是我们阿里电商面临的基本面问题，但是架构师要有不一样的高并发和高稳定性的解决思路。

当前最紧急的问题，比如说用户体验、提升效率、低成本。这些问题其实是非常复杂的。很多同学都想解决这个问题，很多种方法都在解决，但是整体来说效果不是特别明显。因为它链路太长了，链路长代表影响的业务和影响的人更多，你必须得换一种新的思路来考虑这个问题。同时用户分层，内部的技术人员增多，其实我们最终要化为一句话：要把解决复杂问题定义为架构师的一个典型角色。

架构师需要什么样的能力

发现问题

对局部和全局的问题需要有发现的眼光，更应该有发现未发生问题的能力，哪些是需要治标，哪些需要治本，这个是发现问题的基本判断力。现在系统可能没什么大问题，但你要有发现的眼光，这些问题如果不解决，未来业务可能遇到更严重的问题。架构师看问题的眼光和别人不一样，不要只看见这一个问题，还要看见这个问题背后是什么，这一类问题背后是什么，我怎么能用抽象的方法解决一类问题。想好了以后，我就把当前的这个问题先解决掉，其他的问题用抽象的方式去解决它。

定义和分析问题

阿里不缺解决问题的同学，但是缺定义问题的同学。你怎么知道这是个问题，并且把这个问题定义清楚。需要将发现的问题进行抽象和归纳，定义出问题的基本要素，同时定义出问题的短期和长期方案，推进技术整体的进步。

定义问题这个要求非常高。你们平时在解决业务技术问题的时候，也要去分析和定义问题的一些能力，把一个问题定义清楚了，可以真正的能推动业务往前进。

解决问题是制定问题的实施路径和解决方案，协同团队和上下游，推进问题的解决。架构要解决的问题一定不是一个局部问题，一定是一个全局问题。架构师一定会碰到各种各样的角色和链路，他要有这个能力去定义问题的解决方案和实施路径，同时要协同团队。他不能闷头做事，真的要抬头，并且是要有良好的沟通能力，跟所有的同学达成共识才能往前进。

第一点就是沟通能力非常关键。你怎么把这个问题说清楚，切中问题的点，同时也能帮助上下游带来实际的效果。

第二点是架构需要能救火，但不仅仅是救眼前的火，应该救未来的火，架构师救火能力要很强。

我来阿里之前在做一个CRM的系统。刚开始前几年一直在做CRM系统的业务，后来我要解决很多业务的问题，要把它抽象出来，去做业务问题下面基础的平台。再后来发现基础平台的要解决更彻底，还要做下面的中间件。来阿里之前我做过业务，做过业务的开发平台，也做过开发平台下面的中间件。

从2017年到业务平台以后能学到系统它的链路是什么样的，数据链路是怎么样的，整个调用链路是怎么样的，它和底层的关系是什么样的，可能遇到什么样的问题了？现在可能出现这个问题，再往后运行是不是会出现其他的问题。通过救火的过程中积累对系统的了解。

也许我对当前系统也不是很清楚，但有很多以前技术的积累，现在的问题还是能非常快地解决掉，帮助团队解决当下问题的同时，也能让自己对全局有所了解。

架构师的挑战有哪些呢？

全局视角

比如看到一个会员，你不能仅仅只看到会员，你要看到会员上面的业务是什么，谁在用会员，这叫全局。同时，会员用的最多的是导购和交易，登录仅仅是会员本身一个很小的业务功能而已。基于会员，我们有导购有交易，把这些东西要串起来看明白，就能完整的认识到会员到底提供了什么，一定要有一个全局视角。

技术广度

阿里的技术特别复杂，能入职到阿里来，把阿里的整个技术栈完整摸一遍的同学真的是很了不起。以单元化架构为例，我们可能需要了解端，有iOS、安卓端，有PC端，还要了解CDN、网络、接入层、服务发现、服务路由、HSF等的。数据库的储存同步、多点写，还有消息。这些东西其实平时同学们都在用，但架构师不仅在用，架构师真的是要去把玩，彻底了解透彻这些东西，这是关键点。

给大家举个例子，像数据库组成的强同步，对我们后续技术架构进和业务的改进都是有极大影响的。这个时候大家要对数据库有一个全局的认识。

2009年用Oracle数据库用的非常多。。我当时不是做数据库相关的，但是为了把Oracle数据库研究透，去学了非常多Oracle数据库相关的内容。了解里面的逻辑，知道它是什么开发态，是什么运行态，什么管理态，知识都是延续的，后来到了阿里，可能花很短的几个小时就能把现在阿里所有的数据库吃透。

技术的广度非常依赖于积累。你一定要带着问题去想，这个时候你才有记忆力、有了积累，慢慢的你技术的广度就会越来越深。你要了解数据库，你必须对下层的网络了解，所以我们要对网络，CDN可能要更进一步的认识。

2009年以后我花了两年时间学习网络，对交换机、路由器、骨干网、城域网，运营商怎么建网的，我们的IDC是怎么建网的，除了实践以外，已经基本了解了。大家每天都跟网络有交互，为什么重传高？为什么延时高，TCP/IP第4层的下面IP第3层是怎么操作的，IP下面的MAC层是怎么操作的，大家都要深入了解一下。

救火很多时候就考验你这个能力。我去救火时根本不会用现在那些平台化的工具，直接上手用TCP代码抓原始发文，马上能分析出很多问题。这就是平时的积累，慢慢的你就会对全局有认知。

2019年整个核心系统上云的时候，同样跟技术的广度有关系，我们上云发生了什么变化？整个底座到云上去了，计算、存储、网络全到云上去了，那要了解云啊。我2018年在阿里云注册了个账号，基本把阿里云的云产品全摸了一遍，这时就会对阿里云的网络、技术有本质的了解。

架构师一定要有技术的广度。大家一定要学会积累，积累到一定程度以后，你会做到无师自通。比如你了解网络、数据库，然后你又了解了磁盘30%，当这些知识逐渐成体系了，你是有能力去消化和打通不同技术点背后的相关性，对于你的个人能力的提升和认知层面的提升有巨大的帮助。

持续性的学习

每时每刻都在发生技术的升级和变革，只有持续不断的学习，才能对老的架构有新的认识，对于老的问题产生新的解法，要了解业界最近在发生什么变化，这个领域最关键的项目和人在做什么，学习他们的技术，学习他们的论文。我以前每天大概2到3个小时是用来学习。这几个小时的学习时间是我最放松的时间，不用去想太多事。

学习也不是说去瞎学，一定要有体系化的。首先跟你工作相关的，要体系化的去学习，从最下到最上体系化的去学习，学习完了以后你会有新的不一样的认识。把你的想法可以向你的团队说出来，向你的主管说出来。

还有就是要去看论文。跟数据相关的，OLTP和OLAP都有非常好的论文。看了论文以后再看其他人对论文的理解。一定要去看一些比较好的东西，跟工作相关的都可以去看，每天去学习。每天花2到3个小时去学习，三年以后你就知道自己跟别人完全不一样。有人说过：在一个行业你能付出1万个小时，你会跟别人形成本质的区别。但是在我们这个领域，1000个小时就形成差别。

业务理解

这个一定要到实践中去，不是业务离不开架构，而是架构离不开业务，业务、架构、技术要三位一体才能达到最佳的效果。我们平时学习、实践的过程就在磨刀，但你不能说你天天在磨刀，总得要用这个刀。这就是跟业务结合起来，用不一样的思路解决实际的业务问题，会带来更低的成本、更高的效率。

结果

要将技术的先进性转化为业务的先进性，忘掉屁股。这个“忘掉屁股”就是你做很多事情不是你一个人能搞定的，复杂、越大的事情是要协同更多的人。如果你就是为了你自己，比如说KPI去做事，我告诉你，这个事情做一次两次可以，但后面就没人跟你配合。你一定要忘掉屁股，才能慢慢的把这个事情做成，真正做到你想要的结果。

遇山开道、遇水架桥，这讲的是决心。很多时候问题确实很难解决，也需要协调更多的人。很多人可能会放弃。我们最近在做架构的升级，用国产化芯片，从底到上全链路的。如果有一方配合不到位，这事情就很难推进了。从 4 月份一直到 7 月底被阻碍了两次，第三次如果再没办法开展下去，这个事情就彻底的结束了。我们当时把整个团队召集到一起，互相打气：一定要干成。遇山开道、遇水架桥，有什么问题抛出来，大家一起来解决，要有决心，更要果断。

如何成为一个顶级架构师呢？

要想成为一名顶级的架构师，你一定要具备很强的技术深度和广度，也就是你相关的技能越强，那么你架构师的职业生涯就会越久，那么你成为顶级架构师的机会就会越多。

下面我结合阿里的那位哥们的采访内容，我来给大家做一次总结。

（1）架构师不是一个岗位，它只是一个角色，也就是说架构师是从项目中训练出来的。

（2）架构师是通过项目去拿人，但是架构师也要具备一定的管理能力，也就是说架构师要能够落地技术解决方案，并且为了确保技术解决方案不会出现大的偏差，那么架构师要能够输出核心代码，并给开发人员定好基础框架，

（3）一个顶级的架构师不光只会做顶层设计，也会从具体的子系统去反推顶层架构设计的正确性。

（4）架构师不是一个团队中技术深度最牛的技术专家，但必须是技术广度最广的那位，这一点是毋庸置疑的。一个好的架构师需要具备很强的规划能力，无论是技术规划，还是业务规划，都需要架构师的技术的广度和业务的广度达到一定的程度，你才能做出方向正确的架构设计。

（5）一个顶级的架构师不是靠代码给喂出来的，一定是要靠核心项目的顶层设计给带出来的。也就是说，代码细节书锻炼一个初级或者高级架构师的落地能力，但是顶级架构师已经过了这个阶段，那么它应该更加关注如何从顶层设计的角度去思考架构方法论，并逐一去论证。

（6）一般情况下，在一个公司很少有顶级架构师，一般是这样的，公司的框架和业务一旦定下来就很难再改动了，比如你从单体架构升级为微服务架构，或者是云原生架构，对于一次比较全面的顶级架构方案来说，顶级架构师可以快速的做出来，但是这个要动原有的框架，就需要花费很多时间。那么这个时候，顶级架构师应该更加要关注成本和收益了。

一旦大家走上架构师的道路，大家一定时刻想着用架构的思维去解决问题，这个非常重要，而不是一味的用技术思维，去转死胡同，从而将复杂的问题更加复杂话，从而不能跳出来去解决问题。

架构师一定要先高屋建瓴的去想问题，然后再按照既有的方法论去一步一步的设计方案，并推演出解决问题的最佳解决方案。

另外我的新书RocketMQ消息中间件实战派上下册，在京东已经上架啦，目前都是5折，非常的实惠。

https://item.jd.com/14337086.html?编辑https://item.jd.com/14337086.html

“RocketMQ消息中间件实战派上下册”是我既“Spring Cloud Alibaba微服务架构实战派上下册”之后，又一本历时超过1年半的巨无霸技术实战类型的书籍。

为了提高读者阅读本书的体验性，本书总共设计了十个特色，下面我一一的给技术小伙伴阐述一下。?

【特色一】由浅到深

本书将RocketMQ的技术原理和最佳实践体系化，按照由浅到深的顺序呈现给读者，使读者可以按照章节顺序按部就班地学习。当学习完全书内容之后，读者不仅能熟悉RocketMQ的核心原理，还能充分理解RocketMQ的“根”。

【特色二】技术新

本书不仅包括RocketMQ4.x（4.9.2版本）的核心原理分析和最佳实践，还包括RocketMQ5.x（5.1. 0版本）的新特性分析和最佳实践。

【特色三】精心设计的主线：零基础入门，循序渐进，直至彻底掌握RocketMQ

本书精心研究了程序类、架构类知识的认知规律，全书共分为6篇：①基础；②进阶；③高级；④高并发、高可用和高性能；⑤应用；⑥新特性，是一条相对科学的主线，让读者快速从“菜鸟”向“RocketMQ分布式架构实战高手”迈进。

【特色四】绘制了大量的图，便于读者理解RocketMQ的原理、架构、流程?

一图胜于文，书中在涉及原理、架构、流程的地方配有插图，以便读者更加直观地理解。

【特色五】从架构师和技术专家的视角分析RocketMQ?

本书创造性地分析了RocketMQ具备高并发、高可用和高性能的功能及原理，并从架构的视角展开分析，这些也是程序员进阶为技术专家或架构师必备的技能。

以下为从架构师和技术专家的视角分析RocketMQ典型案例，读者阅读完本书之后，也能够达到这样的水准。

【特色六】不仅有原理分析，还有大量的实战案例?

本书介绍了大量的实战案例，能让读者“动起来”，在实践中体会功能，而不只是一种概念上的理解。

在讲解每一个知识模块时，我在思考：在这个知识模块中，哪些是读者必须实现的“标准动作”（实例）；哪些“标准动作”是可以先完成的，以求读者能快速有一个感知；哪些“标准动作”具有一定难度， 需要放到后面完成。读者在实践完书中的案例之后，就能更容易理解那些抽象的概念和原理了。

本书的目标之一是，让读者在动手中学习，而不是“看书时好像全明白了，一动手却发现什么都不会”。通过体系化的理论和实战案例去培养读者的主动学习能力，这样本书的价值就会被最大化。?

本书相信“知行合一”的理念，而不是“只知，而不行”，避免开发人员出现眼高手低的现象。尤其是在技术面试过程中，面试官更加看重的是既懂原理，又能够主动是实践技术的技术人。

【特色七】深入剖析原理?

?本书以系统思维的方式，从业务功能视角剖析?RocketMQ?底层的技术原理，使读者具备快速阅读?RocketMQ?框架源码的能力。读者只有具备了这种能力，才能举一反三，实现更复杂的功能，应对更复杂的应用场景。

?【特色八】从运维的视角分析?RocketMQ?的最佳实践

【特色九】参与开源?

?本书向读者展示了如何修改?RocketMQ?源码，并快速验证案例分析。这样，读者可以从中学到参与开源的技能，并为后续自己能够参与开源做准备。

【特色十】双色印刷，读者体验会更好?

为了提高读者阅读本书的体验，在有上下两册的前提下（巨无霸，超过800页），出版社不吝啬印刷成本，依然采用双色印刷。

【推荐】本书的最佳学习路径?

?为了提高读者学习RocketMQ的效率，我这边结合我自身从RocketMQ小白到RocketMQ专家的经历，为读者汇总了一条最佳学习路径。

【寄语】作者寄语?

RocketMQ是我深度参与研究的一款开源消息中间件，无论是从源码，还是架构场景，我都提炼了很多最佳实践。

在开源领域，技术小伙伴可以使用的开源消息中间件非常的多，比如Kafka、Pulsar等，我之所以选择研究RocketMQ，除了工作内容和角色需要之外，更多的还是自己感兴趣，因此我建议技术小伙伴一定要先培养自己的兴趣，兴趣才是提升技术硬实力的第1要素。

当然我并不止研究了RocketMQ，还研究了Pulsar和Kafka等（包括开源消息中间件生态中的主流框架），只是本书作为一本关于RocketMQ实战派的书籍，我必须要以RocketMQ为主。

假如技术小伙伴想成为Java领域的架构师或者技术专家，我强烈建议你去研究RocketMQ，它会给你带来很多意想不到的技术和架构方法论的收获，这个也是我写本书的主要目的之一。

建议技术小伙伴按照本书设计的学习路线，逐章的去阅读和实战，这样学习效果会更好。

如果技术小伙伴有技术交流的，可以通过博文视点官方的读者群找到我的联系方式，并与我沟通，我会实时的解答读者的疑问。

本文公众号“架构随笔录”

本人视频号“架构随笔录”

【博文视点】2021年度优秀作者

2021年我和博文视点合作了一本技术类型的书籍“Spring Cloud Alibaba微服务架构实战派上下册”，它是我涉足知识输出领域以来的第一本书，同时它也是我自己积累的技术池中部分技术的产出。

为了写好那本书，我几乎花费了所有的休息时间，并主动的承担了书的售后技术辅导和咨询的职责（几乎是有问必答，坚持了整整两年）。

所谓有付出总会有回报，Alibaba这本书的销量还不错，我也因此获得了博文视点颁发的2021年度优秀作者。

我很清楚，这个是博文视点为了鼓励我继续去用心写书，因此我又花了接近1年半的时间去写了RocketMQ消息中间件实战派上下册这本书。

所谓一分耕耘一份收获，我将我对RocketMQ的理解体系化的输出给喜欢技术的技术人，希望真的对大家有帮助。

?【博文视点】2023技术成长领路人

2022年，我开始涉足技术直播和技术讲师领域，并和博文视点合作几次技术直播，直播效果还不错，再加上我孜孜不倦的布道“Spring Cloud Alibaba微服务架构实战派上下册”这本书相关的技术，并且这些技术都是有助于“技术人”快速成长的，因此也获得了博文视点颁发的“2023技术成长领路人”这个技术奖项，这个奖项也是为了鼓励我继续通过技术直播的方式给技术人去布道技术，因此只要我有时间，我就会孜孜不倦的去讲和聊技术。

【四维口袋】2022 KVP最具价值技术专家?

2022年，我开始涉足企业培训和相关技术直播，并和“四维口袋”合作了几次技术直播，并荣获了2022 KVP最具价值技术专家的技术奖项。