作为一名工程师，我的目标一直都是成为一名架构师，从最开始对架构师盲目的崇拜以及对架构朦胧片面的认知，到现在对架构有一个初步的认知，并对成为架构师有了自己的规划，工作 4 年半，虽然没有太多的实践与过厚的沉淀积累，但是自己算是有了清晰的方向，所以写下来，和大家一起探讨下，这篇文章没有干货，丢一个话题出来，并记录下此刻自己的认识。请各位看官，轻喷慢拍 ~~

架构这种东西本身就很虚，不像某个具体的框架，有实实在在的 API 与使用姿势，而且也与自己的工作经历与追求有关，窥不得系统全貌聊何架构，没有资深的业务实战经验，又怎么谈得上架构实现。

什么是架构

聊架构当然要先说清楚什么是架构？

这个问题的标准答案在知乎上有更权威更专业的回答。这里我只说说我自己的理解。

往大了说，架构是为了满足具体的业务的发展而做出的一整套的解决方案。

太抽象了，那就掰开了说，架构是一套解决方案，是能够满足所承载的业务可以持续发展的解决方案，即包含软件层面的框架链，当然包含硬件层面（目前不熟，暂时略过）。

软件层面又区分出了大前端架构，后端架构，这些算是整个公司总的技术架构的子架构，为了能流畅的进行协同，这些子架构又必须遵守某一规范进行设计以及实现，只有这样，才能在最终子架构之间进行集成的时候足够的流畅，参与其中的开发同学才能足够的轻松，个人感觉目前的很多公司都缺乏这么一个拥有上帝视觉的总架构师来制定以及监督执行这一规范，导致的很多成立 N 年的公司依旧没有太深的技术积累，每每有新需求，都是重头开始进行前后端的技术选型，项目搭建，甚至每次集成发布都要解决一遍之前遇到的问题 ~~

啰嗦一大堆，我要表达的核心思想就是：架构就是为了实现业务而为技术实现设计的蓝图，这张蓝图就是上述所说的解决方案和规范。

其实依旧很抽象，这就是源于自己积累不够，不足以解释的更加通俗，好在自己能理解到这里，所以知道了自己缺什么，也明白了下一步自己要往哪个方向走。

架构要做什么

说了自己对架构的理解，这里再说说自己对架构要做什么的理解，这里我从两个方向进行表述：

业务方向

既然架构是为业务服务的，所以架构首要的功能就是为线上业务提供稳定的环境，不管你是直接使用了 N 多开源的框架集成后搭建的框架，还是辅以自研的框架，首先就是要能够提供稳定环境。否则三天一小挂，五天一大瘫，哪个业务能正常运营 ~~

所以架构首要的基础就是: 稳

其次业务是由市场决定的，所以业务的变化是在所难免的，所以架构要做到的另外一个基本的点就是可扩展，甚至，最开始我们可以提供一个稳定但简单的架构，只要这套架构拥有一定的扩展能力，那么这套框架就可以随着业务的发展而以一种渐进式的方式进行稳步的增强，满足更多的业务场景，甚至提供更加强大灵活的扩展能力。

所以架构的另外一个基础就是：可扩展

使用者方向

接下来是面向使用者了，任何一套架构完成搭建后，要真正的完成业务的承载还是离不开这我们这些长期奋战在一线的开发同学们。所以架构设计与实现不可忽略的一点就是面向一线工程师友好，否则再牛批的架构也无法快速的响应市场的变化，快速的完成业务的布局。

要达到面向一线工程师友好，第一点要做到新概念足够少，这样就需要做更多更高层级的封装，其次逐步的提供更多围绕架构核心提高开发部署效率的周边系统平台，框架，工具链，甚至是便于二次开发的 API.

所以在架构设计初期我们就需要把这些点都考虑进来，尽管不可能一步到位，至少要在规划之内，拆分为若干季度的目标，一步步实现。

所以好架构基础就必须能做到使用 高效、简洁

如何成为架构师

说完了自己对架构的认识，我在聊聊自己对成为架构师的一些粗浅的想法：

第一步：既然架构是为了支撑业务的，那边有必要在某一业务上（当然是自己感兴趣的方向喽）深入学习了解，不仅仅是为了更好的实现业务功能，更重要的是为了积累足够多的样本数据，这样才能做到更加合理有价值的抽象，才有可能设计出好的框架，搭建更加强壮的架构，所以没错，好的架构师离不开对业务的积累！像我这个 level 的同学还是需要安心在自己的业务线上认真踏实的工作。

第二步：继续深入学习技术基础，多多阅读各种设计规范，只有对使用的技术有更基础的认知，才能做更出更合理的设计与封装。同时在深入自己擅长的领域的同时，也要积极的扩展自己的知识边界，建立更加完备的知识体系，这样才能设计出拓展性足够好的框架，搭建更加高效的架构。

第三步：虚心学习，业内已经有了足够多优秀的框架了（业务型，工具型），虽然不一定能够 100% 满足各自公司的需求，但是依旧有很多值得借鉴的思想（设计模式），所以在深入业务领域的同时我们要想成为架构师，就要阅读足够多的框架源码，加油！

上面说的计划那么多，平时工作又那么忙，怎么办？根据自己的节奏，保证本职工作的前提下，不放弃，持续学习，时间长了，终有所成。

切勿抱着一技之长而停止学习 ~~