架构的本质是什么？
最近总是有小伙伴问我，如何成长为一名优秀的架构师，我也不知道该如何去回答，但是我想聊一下架构的本质。
架构不是互联网行业独有的
架构及对应的架构师职位并不是互联网行业独有的，只要存在组织的地方就存在架构。
比如一个木工，在开始制作家具之前是不是要做好图纸，就算没有图纸，人家也会在脑海中勾兑出一张家具图，这样木工才会参照这张家具图去做家具。
架构的理念是无处不在的，只要有人活动的地方都会存在，只是说职位名称不一样而已。
就算是古代的行政机构，比如皇帝，他设计了一套完整的中央集权的组织，并利用这个组织中的成员去管理这个国家，比如明朝的中书省，它就是皇帝作为国家的首席架构师去搭建的，并希望这个机构去高效的管理这个国家。
也就是皇帝希望官员执行这个机构的架构理念，并高效的去工作，皇帝最终的目的就是要官员执行它的架构思想。
那么互联网领域的架构其实也是一样的，架构师要做的事情就是如何让开发人员理解自己的架构思想，并严格的执行自己的方案，最终高效的完成产品研发工作，最终的落脚点都是要能够高效的成事，而不是虚无缥缈的概念。
假如皇帝制定了一大堆关于管理国家的架构理念，比如建文帝，要执行削藩，那么朱棣就不满了，坚决不执行且还造反，那么最终建文帝是很难成事的，最终就灭亡了。
同样架构师也一样，假如你底下的技术开发都不买你的账，且一致的抵制你的技术方案，那么你这个架构师大概率是要被撸走的。
架构的目的是解决问题
架构的目的就是为了解决问题，假如违背了这个初衷，那么架构就没必要存在了。
还是拿木工做家具这个例子来分析，假如木工事先不设计图纸，只是漫无目的的做家具，那么出错了怎么办呢？木工只能不断的返工，甚至最后直接推倒重来，这样家具的容错率太低了。
如果他有图纸，就可以事先设计好，并反复的推演家具的模型，最终确定家具的模型，并生成图纸，就算是生产出现错误，木工也是有图纸作为依据，再去重新制定一张新的图纸，而不是靠记忆和经验去重新开始设计，那样效率太低且不能真正的解决问题。
互联网行业的架构师也是为了解决问题而存在的，假如你的产品团队中的架构师不能为团队分担问题（无论是业务还是技术问题），那么这架构师就是不合格的，或者是团队根本不需要专职的架构师。
我也见过很多刚开始做架构师的小伙伴，非常的努力，总是冲在业务的第一线且收集了很多业务痛点，并制定了很多技术方案，花费了大量的时间去给技术开发人员去宣讲自己的架构理念。
初步一看，这样也是没错的，也是架构师的工作内容，但是这位架构师小伙伴的群众反馈并不高，甚至在绩效考核的时候，KPI还不如那些一线的技术开发小伙伴。
其实这个也是刚开始做架构师的技术人都会犯的一个通病，那就是没有抓住架构师的目的，那就是解决问题。
诚然这个架构师小伙伴很努力，针对调研的问题输出了很多技术方案，也一一的宣讲了这些架构方案，技术小伙伴也都参加了，但是最终人家就像看电影一样，匆匆看完，匆匆离场，也就是对于他们而言，这个不是他们该考虑的事情，也不是他们的责任，这个是你架构师该考虑的。
哈哈，说到这里我想小伙伴应该很清楚了吧，这个架构师就是犯了这样的错误，没有将自己输出的技术方案转换为责任，并分担给技术开发人员。
更加直白的说那就是没有将技术方案转换为技术开发人员的KPI，导致你的技术方案永远只停留在你的PPT和图纸上。这样领导肯定会绝对你的技术方案根本不能帮他去解决问题，只是过了一下嘴瘾而已。
以上这个例子是做架构师的时候经常会犯的一个错误，只是不会将技术方案转换为KPI，那么接下来这个小伙伴犯的错误，就更好玩了。
同样也是一个非常努力的架构师，调研了很多技术和业务问题，并输出了很多技术方案，但是这个架构师输出的方案太大了，几乎每一个方案都是要将之前的产品规划推倒重来，并在宣讲的过程中一五一十的将这些方案全部讲了出来，参与的技术开发人员刚开始会觉得这个架构师非常的牛逼，非常的专业，但是慢慢的人家会感觉到“工作量太大了”，这个饼画的也太大了。
这个架构师小伙伴也没有给人家一一拆解，而是一股脑的将这些技术方案下放给需要配合改造的业务产品负责人，并将相关责任也关联给人家，以为这样就可以大功告成了。
那么人家肯定是一脸懵逼，嘴上肯定答应我会配合你的，但是人家手上也有很多紧急的任务和需求要做，只会将你这个改造任务的优先级降到最低。
事实上你的技术方案等于还是没有落脚点，还是虚的，虽然了下放给了相关责任人，也或多或少放到了KPI中，但是优先级太低了。
当然以上问题也是想做架构师的技术小伙伴经常会犯的一个错误，其实这个错误的本质也是没有真正的理解架构师就是要解决问题的。
这些技术方案，架构师需要将它拆解为一个个小的里程碑任务，并和相关责任人一起穿插到技术开发人员的开发规划中。
至于如何穿插，这个就要考量你架构师的功底了，不仅仅需要你要有很强的技术硬实力和业务理解能力，也需要你有很强的软实力，并说服人家去改造。
我可以列举一个简单的例子，假如你需要技术开发人员配合你完成微服务框架的升级，比如统一使用Spring Cloud Alibaba，那么你调研了公司目前的微服务框架，并做了详细的对比，但是你不能单单去给技术开发人员去讲解Spring Cloud Alibaba的技术原理和使用方式，而是要去讲解如何将现有的服务从旧的微服务框架升级为Spring Cloud Alibaba，一定要细节到开发、测试和发布上线，以及如何回滚等。
当然除了技术层次的开发流程，你还要考虑业务层次的流程，比如优先改造哪一批服务的技术风险和工作量最小，落地的可能性最大等。
也就是前面常说的，你要学会将一个大饼拆解为可以落地和度量的小的子任务，让技术开发人员不被吓到，从非常乐意的帮你去落地。
其实架构师是否优秀，就是基于这一点去评判的，你要能够让技术开发人员参与到你的技术方案中，并非常快乐的一起去做有意义和有价值的事情，而不是带着情绪去做事情。
架构的本质就是用最优解去解决问题
一个资深架构师总是时刻让自己奔跑在寻找问题最优解的路上，这个是区分架构师水平的唯一标准。
在产品研发的过程中，问题太多了，且能够解决问题的方法有很多，有些是拿来主义，有些是需要自己去加工一下，有些需要自己花费很多时间去研究并转化为工具，但是它们都将作为一种方法去解决问题，但是是否是最优解，这个就会考量一个架构师的水平了。
寻找问题的最优解是非常难的，就算是工作多年的我，在解决一个非常棘手的问题且非常紧急时，也都是把优先解决问题放在第一位，这个也是你领导经常和技术开发人员说的话，只要能够解决问题就行，要的就是速度。
当然这种说法也是没问题的，毕竟没有那么多时间让你去折腾和研究技术，解决问题效率是最重要的。
但是作为一个架构师，你不能这样就放弃了最优解，就算是当下没时间去研究，你一定要事后去复盘，并找到问题的最优解，从而将这个转换为经验和可以参考的架构方案，方便以后可以借鉴，这个就是你作为架构师的技术和架构经验的沉淀。
我可以再列举一个技术问题，那就是你在业务开发过程中经常会碰到线程安全的问题，当然你可以图省事，直接使用Java的同步字段（同步锁），直接放在方法上，但是你有没有想过，你的方法中所有的代码都需要用同步锁去确保线程安全吗？是否锁的粒度太大呢？
因此你就需要考虑锁的粒度和范围的问题，是否可以将部分代码用同步锁，这样可以减少一些性能损耗。
也就是你作为架构师，你要考虑解决线程安全的最优解，这样你的技术视野和抓细节的能力才会越来越强。
好吧，比较零散的和大家聊了这么多，希望对想要成为架构师的技术人有帮助吧。