【20210909】架构师究竟是干嘛的？！

时间：2021年09月09日

作者：小蒋聊技术

大家好，欢迎来到小蒋聊技术。小蒋准备和大家一起聊聊技术的那些事。

最近小蒋身边的一位架构师朋友在参加面试。参加了好几轮面试后终于通过了，那个公司决定录用。那家公司的HR也已经和我那个架构师朋友谈好了薪水与公司福利待遇。我那个朋友收到Offer的时候一看根本就不是那家公司HR说得那样，薪水福利远没有HR说得那么美好，我那个朋友就一脸不高兴的找到我，并问我：“接受还是拒绝？”

那小蒋得问问呀，究竟是什么原因导致最终公司的官方Offer和那家公司HR说得不一样呢？我朋友告诉我，那个HR说，最近公司的领导非常忙天天开会，没时间签字授权。

我滴天呀，小蒋开始意识到一个问题。其实不做技术的朋友们，大部分弄不清楚构师究竟是做什么的，既然不知道那肯定也不会对架构师岗位的招聘有多么重视。所以，今天小蒋就准备和大家聊聊看，架构师究竟是做什么的？那如果你是一名开发者又如何能够顺利的晋升成为一名架构师呢？

既然咱想知道架构师是做什么的，那咱先来看看国内知名的架构师都有谁，看看他们究竟都做了什么。这样我们就可以有一个感性的理解。

那国内知名的架构师有：张小龙、丁磊、张建锋、陈天桥、李开复等等，这些人估计做技术的朋友大家都不陌生。即便不是做技术的，提起他们做的产品大家也一定能耳熟能详。

咱先说张小龙，他做的这个产品我们几乎每天都在用，那就是“微信”。对，张小龙是“微信”的创始人，曾担任腾讯微信事业群首席架构师。

再说网易公司的创始人丁磊，他是网易公司的创始人，也曾担任网易公司的首席架构师。当时与张朝阳、王志东并称为网络三剑客。反正对小蒋80年代这群技术人，有很大的影响。小蒋的E-mail一直是网易163的。

最后咱说张建锋，他是2004年加入的淘宝，曾经担任过淘宝的首席架构师。是阿里巴巴集团合伙人之一，现在担任阿里云智能总裁，达摩院院长。张建锋带领团队攻克了超大规模互联网高并发难题，解决了双十一、12306春运购买火车票、央视春晚等背景下的流量突变型云计算系统难题。

这些人都曾经担任过架构师，当然，我那个朋友肯定没法和他们比。他们在架构师名头前还有一个首席的头衔。^_^

小蒋就更没法和他们比了，但至少小蒋也在朝着他们的方向努力前进。小蒋不求能达到他们的水平，但求每天都能比昨天得自己进步一点。

大家是不是对架构师开始有了一点点感性的认识了。

小蒋在工作当中，也曾参与过架构师的招聘工作。架构师的招聘非常不容易，公司架构师这个职位挂出去了半年，愣是一个合适的也招到。后来不得不联系猎头，从其他公司挖了一个过来。

这是一个典型的宁缺毋滥的职位。就好比驾驶员，没有驾驶员顶多咱这个车不开了呗，大不了咱花点时间内部培养一个呗。但你随意招聘一个不合格的驾驶员进来，那后果可能是车毁人亡，赔了夫人又折兵。

小蒋你废话说了一大堆，我还是不明白架构师究竟是做什么的。别着急，别着急，小蒋马上就说。

在企业中，数量最多的肯定是一线工作人员。就像在BAT这些大厂，研发人员就好比流水线上的操作人员，数量是最多的。

除了一线工作人员外，其实在企业中还有两类人员非常重要。

一个是 管理 人员。

一个是 领导 人员。

什么领导，什么管理，云里雾里的，乱七八糟的？！

简单来说，每天催你按时上下班，上下班按时打卡，上班不要迟到的那个人就是在管理着你，这个就是管理人员。

另外还有一类人，总拉着你开会，一开会就在白板上画来画去的，不停地给你谈指标，不停地和你谈战略。这类人通常就是领导人员。

还是不明白，怎么区分管理人员和领导人员？

小蒋的理解是这样的，一般管理人员是站在团队后面，推动团队往前走的人。领导人员是站在团队前面，摇旗呐喊，为团队设定目标，拉团队不断向目标靠近的人。你看这样，是不是不就好区分了。

咱说完了管理和领导。那架构师呢，架构师属于什么呢？

架构师这个岗位就比较有意思了，架构师是同时兼了技术岗位和管理岗位。一手托技术，一手托业务。

也就是说，架构师他这个职位中，既要进行技术相关的工作，也要进行管理相关的工作。公司里的架构师一般情况下会直接代表技术团队和整个公司中的其他部门进行沟通。也就是说其他部门有需求，直接会把需求提报到架构师那里，然后架构师就得马上开始做需求分析，把需求进行分解，然后进行模块划分，再把这些整理完的内容整理成相关研发工程师能看得懂的文档。这些工作做完了，还要把整个需求中的内容拆分成一个一个具体的小任务，分配给相关的研发工程师，让每个工程师知道该怎么样开展自己的工作。

到这呢，还不能算完。因为架构师紧接着，赶紧得去做进度追踪，开发日程的调度。中途遇到问题，必须马上根据具体情况进行方案调整。如果碰到疑难杂症，那必须要参与核心模块的设计。在项目实施过程中对突发的状况，要做出合理且恰当的计划变更，以确保解决方案可以保质保量顺利的完成。

所以，对架构师来说，架构师必须得具有驱动整个团队的能力。

好像对架构师做的事有点理解了，但是听着感觉还是云里雾里的！

小蒋，拿点具体工作中的事出来。公司市场部为了提升用户体验，想要收集一下双十一活动中，哪些产品最受欢迎，哪些产品用户浏览的次数最多。针对这个事提出需求，希望技术团队可以统计出TOP前100的产品，以及这些产品的具体用户访问量。

一般来说公司里的其他部门，只需要把具体的业务需求告诉架构师，然后就可以了。

这时候，架构师第一反应，是开始做需求分析和抽象，可能业务部门这个需求得依赖一个“用户行为反馈系统”，还得依赖一个“数据统计系统”。

为什么要依赖两个系统呢？

因为，一般来说“用户行为反馈系统”通常都是实时的，或者说是在线的。用户划一下页面，点一下屏幕，马上就得记录一下。而“数据统计系统”，一般都是非实时，或者说是离线的。每4个小时做一次也行，每12个小时做一次也行，这个得看具体需求。通常是积攒了一大批数据后，统一做一次。

另外一个是，“用户行为反馈系统”一般要求高吞吐量，高并发。“数据统计系统”一般要求海量存储，高计算能力。就像一个人愿意白天干活，另外一个人愿意晚上干活。你非让他们俩人一起干活，可能谁都干不好。与其谁都干不好，那还不如各干各的。

这个时候就会有人说了，那“数据统计系统”有没有实时的，把“数据统计系统”变成实时的不就完了，他们不就能在一起了？

实时的“数据统计系统”？！好像还真有，不过应该不叫这个名字。实时的“数据统计系统”，一般叫“估值系统”。也就说这个系统一 般是用来做预测的，要依赖“用户行为反馈系统”实时的数据情况做基准，再根据“数据统计系统”的同比数据、环比数据、历史数据等。通过AI模型，预测未来数据走势。通常金融领域有很多这种系统，就比如股票行情预测系统。这样来看，不但没把原来的两个系统放在一起，反倒又多出来一个系统。

架构师，架构师，那到底要架构什么呢？所谓的架构又是什么呢？

关于这个词，有一段时间网上是吵得挺激烈的。

有人说架构是算法。

有人说架构是数据结构。

有人说架构是负载扩展。

有人说架构是产品选型。

小蒋的理解是，他们说得都对。关于架构每个人有每个人的理解，的的确确这些点都是要考虑的。其实架构师就是要对整个项目进行一个宏观的规划设计。架构师要从业务部门发现或者获得需求，再通过技术手段帮助业务部门解决问题。架构师需要带领整个技术团队选择合适的开发方案，在不停的解决整个方案在开发过程中遇到的各种问题。

那究竟什么是开发过程中遇到的问题呢？

小蒋认为其中最严重的问题就是人、时间、资源不平衡的问题。用大白话说就是人、时间、金钱不平衡的问题。解决任何一个业务问题，完成任何一个软件项目都需要大量的时间，大量的金钱，和很多的人力。

小蒋就经常和身边的架构师朋友们聊天的时候问他们。哎你说，你现在负责的项目，时间、金钱、人力哪一个是充足的。我那帮架构师朋友们一般都会黑着脸，满脸郁闷的和我说：“没一个是充足的”。那么在钱也不足，时间也不足，人力也不足的情况下，怎么才能让这个项目继续做下去，又如何保质保量的完成，这就非常考验一个架构师了。

架构师必须对整个团队有非常强的管理能力，能够有效的调度现有的时间，金钱，人力资源，去解决实际开发过程中的问题。

接下来，咱们再来说一个开发中会遇到的问题，那就是“需求不明确”的问题。

研发工程师最怕的就是，不明确的需求。如果一个架构师把太笼统的问题交给一个研发工程师。那么这个研发工程师通常都会很迷糊，你到底是想要什么呢？就比如直接把“用户行为反馈系统”交给研发工程师。那研发工程师肯定会问，用户的什么行为要反馈？往哪反馈？怎么反馈？这种情况下，研发工程师是是有权利拒绝这个任务的，并且告诉架构师这个任务描述的不明确。

所以，对于架构师来说必须还得有强大的沟通能力与文档能力。架构师通常要代表整个技术团队与企业中其他团队进行交流的。所以架构师必须得能听得懂那些不懂技术的业务人员们他们说的各种业务场景与期望要解决的问题。然后把这些一个一个的业务问题，翻译成研发工程师们能看得懂的软件开发需求，把这些软件开发需求编写成文档，再把这些文档交给他的技术团队。

这个工作可不是每个人都能做得了的。因为你一边得懂业务，得能听懂的业务人员们讲的业务场景和问题，还得要懂技术知识，能把这些业务问题通过技术手段进行解决。另外必须要有强大的文档能力与沟通能力，必须要善于与技术人员沟通，让技术人员能够确切的明白到底要开发什么，怎么去开发。

对于架构师在需求开发的过程中会遇到的问题，其实是非常多的。小蒋可以顺着整个软件的开发周期，从开始到结束，来一个一个的慢慢谈。但是花费的这个时间，我恐怕大多数人撑不住。

所以，小蒋，最后再分享一个。

网上有好多文章，他们跟你推荐各种各样的技术，而且他们宣称这个技术特别好。于是圣战就开始了。

他说Java语言好，我说PHP好，他说Node.js好。

他说阿里云好，我说腾讯云好，他说亚马逊云好。

他说微软的东西好，我说Google的东西好。

他说大括号应该换行，我说大括号不应该换行。

他说应该用Tab设计，我说应该用空格设计。

在开发过程中，这种无穷无尽的争论充斥着开发的各个角落。朋友们还记得架构师是干什么的么？架构师是那个带着团队把项目保质保量干下去的那个人。所以架构师在一个项目里经常会遇到这种类型的争吵。

那我们坐下来，研究一下。这种争论真的答案嘛？其实是没有答案的。架构师是不会参加这种圣战的，因为这类问题是架构师在进行第一步产品选型的时候所要做的决策的部分。当架构师面临我们团队到底是用Java还是PHP的时候，架构师要考虑绝对不是Java和PHP哪个更好的问题。架构师他要具体分析目前团队所面临的问题。我们现在时间不足，金钱不足，人力也不足。他要分析团队背景，分析公司的人员配比情况，分析人员的能力情况。分析CTO给他们制定的技术愿景，甚至还要分析他们开发的产品和整个团队的气质符不符合。也就是说他要考虑的问题实在是太多了。

你说，一个公司里维护了好多个已经使用了将近20多年的核心系统，当时系统是用BASIC写的。在网上有好多人评论说，BASIC这个语言一点都不好用，存在各种各样的问题。但是，松下公司就是这样的，它是一个日企。在松下公司他们使用最普遍的语言仍然是BASIC，他们已经使用了20多年的BASIC了，重构几乎已经不可能了，招聘新的开发人员也几乎不可能了。如果你是松下公司的架构师，难到你会选择用JAVA语言进行整个系统的重构吗？

总结来说，整天在公司里吵架这个语言和那个语言好不好的人，其实都是非常弱智的人。真正在决策的时候，要考虑的事情其实远远超过技术好坏的本身。换句话说，对于整个开发团队来讲，其实没有最好用的技术，也没有最难用的技术，只有最合适于现在团队的技术和不合适团队现在情况的技术。

假如，我们团队招聘了10个Java开发工程师，架构师却坚持使用PHP，不管你PHP设计的再好，开发效率再高，对于团队来讲也未必合适。

在后续开发实践的过程中，要做产品选型的地方其实非常多。例如我们团队依赖了一个模块，那架构师就要决定是自建，还是采用开源社区的解决方案，亦或者是使用第三方机构的解决方案等。如果要使用第三方机构的解决方案，那究竟要选择哪个第三方，和他们的哪个方案等等。如果要选择开源社区的解决方案，那究竟要选择哪个开源社区，和他们的哪个解决方案。

在衡量评估这些问题的时候，架构师要衡量和评估的问题，绝对不是这些方案本身技术的好坏与否。而是，是否与当前团队情况相匹配。如果不匹配，那究竟有多大偏离度，是否有可能通过什么办法弥补呢。

举个例子，几乎所有公司都会面临给用户发送手机验证码这个功能，面对这个功能，一般来说有三种方案，第一种方案是自己搭建短信服务器，自己写算法，公司直接对接电信运营商 ，直接向用户的手机号码发送短信。第二种方案是，采用开源社区的方案，在Github上有很多手机验证码发送方案。第三种是采用第三方公司他们的解决方案，直接和第三方公司谈合作，直接调用他们的API接口，就可以完成手机验证码的发送了。

决策用哪个方案中的哪个具体的解决方案，都需要架构师衡量很多问题，随着项目开发进程的继续，架构师还要合理的分配时间资源，人力资源等，来协调各个工作上要投入的精力。是否需要花大量的时间进行上线前测试，是否要花大量时间写文档，是否需要花大量时间写测试，这都是架构师要面临的挑战。

如果，你未来希望成为一名架构师，最好的办法就是参与大量的实践项目。有些人肯定会问，我都已经参加了20多个项目了，为什么感觉什么东西都没有学习到，为什么也没能成为架构师？

这个肯定也是和自己的悟性有一定关系的，另外一个就是你参与的项目中是否存在挑战。就比如在公司的运营过程中，用户数量与访问量是否在呈几何级别的增长，服务器是否经常面临负载无法承受的问题，业务部门是否经常提出各种各样的棘手的需求。面对这些问题，公司里的架构师肯定需要不停的思考如何提高开发效率，如何引入新技术，如何进行负载扩展，哪些模块要进行功能拆分，哪些模块要合并，并统一管理。哪些部分要拆分成无状态服务，哪些部分又要拆分成有状态服务。如何处理服务的注册与发现，是否要采用API网关，是否要引入反向代理。消息队列是自建，还是直接引入第三方的。是要用第三方的方案，还是选择一个开源的方案。天呐，要决策的事情实在是太多了。

可以看到，架构师这个职位对人的要求是很高的，你不但要对技术本身有非常深刻的理解，你还要有很好的沟通能力，文档能力，还要有很强的管理能力。

小蒋一般把项目分为三类：

第一类是unreachable：无论如何努力都难以达成的项目。比如你让我带领团队造个卫星出来。我觉得无论多努力，我也很难完成这个项目。

第二类是reachable：可能现在自己能力还达不到，但是努努力，使使劲，用用功就能够完成的项目。这种项目对个人能力的成长是非常棒👍🏻的。比如说小蒋以前并没有接触过AI，但是我跟着我的团队要做一个股票行情预测系统，这个项目对于小蒋来说肯定有非常大的收获。

第三类是reached：这类项目是你现在的能力已经达成的了。就比如，你现在再让我写个MVC架构的企业管理系统。这样的系统我在再写10个，对我个人的能力的提升也非常有限。这样的项目你参与的越多，其实就是再浪费你个人的职业发展空间。

写在最后

1. 记住没有人天生就是架构师，所有的架构都是在积累了大量开发项目经验后，慢慢积累而来的。而且，千万不要只学习与技术相关的知识，也千万不要参与技术哪个更好这类无意义的争吵。
2. 一定要多参加reachable这类的项目，那种有挑战，但努努力能达到的项目。
3. 多去参与跨行业的项目。这样你很快就会成为一名架构师了。

如果在听的你已经是一名架构师了，那非常高兴的祝贺你。希望你有一天能够登上CTO的位置，小蒋暂时呢也给不了你什么有建设的意见 ，因为小蒋自己也不是一个很成功的架构师，也还在不断地学习和成长。

但是，小蒋一直坚定的认为：年龄的增长不可怕，可怕的是从未成长！

感谢大家支持小蒋，小蒋希望和大家共同成长，谢谢。

音频地址：https://www.ximalaya.com/keji/51588599/452647491