架构的本质是什么？

最近总是有小伙伴问我，如何成长为一名优秀的架构师，我也不知道该如何去回答，但是我想聊一下架构的本质。

架构不是互联网行业独有的

架构及对应的架构师职位并不是互联网行业独有的，只要存在组织的地方就存在架构。

比如一个木工，在开始制作家具之前是不是要做好图纸，就算没有图纸，人家也会在脑海中勾兑出一张家具图，这样木工才会参照这张家具图去做家具。

架构的理念是无处不在的，只要有人活动的地方都会存在，只是说职位名称不一样而已。

就算是古代的行政机构，比如皇帝，他设计了一套完整的中央集权的组织，并利用这个组织中的成员去管理这个国家，比如明朝的中书省，它就是皇帝作为国家的首席架构师去搭建的，并希望这个机构去高效的管理这个国家。

也就是皇帝希望官员执行这个机构的架构理念，并高效的去工作，皇帝最终的目的就是要官员执行它的架构思想。

那么互联网领域的架构其实也是一样的，架构师要做的事情就是如何让开发人员理解自己的架构思想，并严格的执行自己的方案，最终高效的完成产品研发工作，最终的落脚点都是要能够高效的成事，而不是虚无缥缈的概念。

假如皇帝制定了一大堆关于管理国家的架构理念，比如建文帝，要执行削藩，那么朱棣就不满了，坚决不执行且还造反，那么最终建文帝是很难成事的，最终就灭亡了。

同样架构师也一样，假如你底下的技术开发都不买你的账，且一致的抵制你的技术方案，那么你这个架构师大概率是要被撸走的。

 架构的目的是解决问题

架构的目的就是为了解决问题，假如违背了这个初衷，那么架构就没必要存在了。

还是拿木工做家具这个例子来分析，假如木工事先不设计图纸，只是漫无目的的做家具，那么出错了怎么办呢？木工只能不断的返工，甚至最后直接推倒重来，这样家具的容错率太低了。

如果他有图纸，就可以事先设计好，并反复的推演家具的模型，最终确定家具的模型，并生成图纸，就算是生产出现错误，木工也是有图纸作为依据，再去重新制定一张新的图纸，而不是靠记忆和经验去重新开始设计，那样效率太低且不能真正的解决问题。

互联网行业的架构师也是为了解决问题而存在的，假如你的产品团队中的架构师不能为团队分担问题（无论是业务还是技术问题），那么这架构师就是不合格的，或者是团队根本不需要专职的架构师。

我也见过很多刚开始做架构师的小伙伴，非常的努力，总是冲在业务的第一线且收集了很多业务痛点，并制定了很多技术方案，花费了大量的时间去给技术开发人员去宣讲自己的架构理念。

初步一看，这样也是没错的，也是架构师的工作内容，但是这位架构师小伙伴的群众反馈并不高，甚至在绩效考核的时候，KPI还不如那些一线的技术开发小伙伴。

其实这个也是刚开始做架构师的技术人都会犯的一个通病，那就是没有抓住架构师的目的，那就是解决问题。

诚然这个架构师小伙伴很努力，针对调研的问题输出了很多技术方案，也一一的宣讲了这些架构方案，技术小伙伴也都参加了，但是最终人家就像看电影一样，匆匆看完，匆匆离场，也就是对于他们而言，这个不是他们该考虑的事情，也不是他们的责任，这个是你架构师该考虑的。

哈哈，说到这里我想小伙伴应该很清楚了吧，这个架构师就是犯了这样的错误，没有将自己输出的技术方案转换为责任，并分担给技术开发人员。

更加直白的说那就是没有将技术方案转换为技术开发人员的KPI，导致你的技术方案永远只停留在你的PPT和图纸上。这样领导肯定会绝对你的技术方案根本不能帮他去解决问题，只是过了一下嘴瘾而已。

以上这个例子是做架构师的时候经常会犯的一个错误，只是不会将技术方案转换为KPI，那么接下来这个小伙伴犯的错误，就更好玩了。

同样也是一个非常努力的架构师，调研了很多技术和业务问题，并输出了很多技术方案，但是这个架构师输出的方案太大了，几乎每一个方案都是要将之前的产品规划推倒重来，并在宣讲的过程中一五一十的将这些方案全部讲了出来，参与的技术开发人员刚开始会觉得这个架构师非常的牛逼，非常的专业，但是慢慢的人家会感觉到“工作量太大了”，这个饼画的也太大了。

这个架构师小伙伴也没有给人家一一拆解，而是一股脑的将这些技术方案下放给需要配合改造的业务产品负责人，并将相关责任也关联给人家，以为这样就可以大功告成了。

那么人家肯定是一脸懵逼，嘴上肯定答应我会配合你的，但是人家手上也有很多紧急的任务和需求要做，只会将你这个改造任务的优先级降到最低。

事实上你的技术方案等于还是没有落脚点，还是虚的，虽然了下放给了相关责任人，也或多或少放到了KPI中，但是优先级太低了。

当然以上问题也是想做架构师的技术小伙伴经常会犯的一个错误，其实这个错误的本质也是没有真正的理解架构师就是要解决问题的

这些技术方案，架构师需要将它拆解为一个个小的里程碑任务，并和相关责任人一起穿插到技术开发人员的开发规划中。

至于如何穿插，这个就要考量你架构师的功底了，不仅仅需要你要有很强的技术硬实力和业务理解能力，也需要你有很强的软实力，并说服人家去改造。

我可以列举一个简单的例子，假如你需要技术开发人员配合你完成微服务框架的升级，比如统一使用Spring Cloud Alibaba，那么你调研了公司目前的微服务框架，并做了详细的对比，但是你不能单单去给技术开发人员去讲解Spring Cloud Alibaba的技术原理和使用方式，而是要去讲解如何将现有的服务从旧的微服务框架升级为Spring Cloud Alibaba，一定要细节到开发、测试和发布上线，以及如何回滚等。

当然除了技术层次的开发流程，你还要考虑业务层次的流程，比如优先改造哪一批服务的技术风险和工作量最小，落地的可能性最大等。

也就是前面常说的，你要学会将一个大饼拆解为可以落地和度量的小的子任务，让技术开发人员不被吓到，从非常乐意的帮你去落地。

其实架构师是否优秀，就是基于这一点去评判的，你要能够让技术开发人员参与到你的技术方案中，并非常快乐的一起去做有意义和有价值的事情，而不是带着情绪去做事情。

架构的本质就是用最优解去解决问题 

一个资深架构师总是时刻让自己奔跑在寻找问题最优解的路上，这个是区分架构师水平的唯一标准。

在产品研发的过程中，问题太多了，且能够解决问题的方法有很多，有些是拿来主义，有些是需要自己去加工一下，有些需要自己花费很多时间去研究并转化为工具，但是它们都将作为一种方法去解决问题，但是是否是最优解，这个就会考量一个架构师的水平了。

寻找问题的最优解是非常难的，就算是工作多年的我，在解决一个非常棘手的问题且非常紧急时，也都是把优先解决问题放在第一位，这个也是你领导经常和技术开发人员说的话，只要能够解决问题就行，要的就是速度。

当然这种说法也是没问题的，毕竟没有那么多时间让你去折腾和研究技术，解决问题效率是最重要的。

但是作为一个架构师，你不能这样就放弃了最优解，就算是当下没时间去研究，你一定要事后去复盘，并找到问题的最优解，从而将这个转换为经验和可以参考的架构方案，方便以后可以借鉴，这个就是你作为架构师的技术和架构经验的沉淀。

我可以再列举一个技术问题，那就是你在业务开发过程中经常会碰到线程安全的问题，当然你可以图省事，直接使用Java的同步字段（同步锁），直接放在方法上，但是你有没有想过，你的方法中所有的代码都需要用同步锁去确保线程安全吗？是否锁的粒度太大呢？

因此你就需要考虑锁的粒度和范围的问题，是否可以将部分代码用同步锁，这样可以减少一些性能损耗。

也就是你作为架构师，你要考虑解决线程安全的最优解，这样你的技术视野和抓细节的能力才会越来越强。

好吧，比较零散的和大家聊了这么多，希望对想要成为架构师的技术人有帮助吧。

 

 另外我的新书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最具价值技术专家的技术奖项。