不想当将军的士兵不是好士兵，闲话如何成为一个架构师

类比到IT行业

不想当架构师的程序员不是好程序员。

虽然此种类比不一定恰当。也许你就想简简单单、安安静静写写代码，这种想法没错。国外，就有很多老程序员，与世无争的写代码，把代码写漂亮，没有那么功利非要给自己挂一个架构师的头衔。相比较而言，国内就要现实太多。工作N多年后，如果还是在一线码农，多数时候也会被鄙视，也许还会被BOSS扣上此人发展潜力不行。还有N多人，换工作的时候，非架构师职位不来。

年前和团队人开会，有个同事的给他的定位是渐渐可以做更多架构规划相关的工作。他说，对于如何做架构还有很多迷茫。有些人也许不会选着这条路；有些人正在这条路上，但是很迷茫：我该如何成为一个架构师呢？

说到这里，也给大家推荐一个架构交流学习群：835544715，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，相信对于已经工作和遇到技术瓶颈的码友，在这个群里会有你需要的内容。

视野

记得有个架构师讲过

“视野决定格局”

自己还是比较认同这句话，架构师首先要重构的是自己的视野。视野不是装逼。视野可以作为一个看问题、积累专业领域知识的内在驱动力。

仅仅说视野，未免太虚，如何把视野坐实是很重要。由内在（思维、心态、方法）驱动外在（专业知识）是需要扎扎实实去积淀。

常常听到这样的观点

“做架构师，一定要有全局的视野或关注”

如何理解全局？负责几百个应用就是全局？负责单个系统就不是全局？

个人对全局有如下理解：

单点、模块、链路

由点到面去积累知识，从全局和细节两条路逼近学习；不仅仅关注自我，还超越自我。要做一个架构师，不仅仅需要知道自己能做什么，还需要知道别人能做什么，还需要自己不能做什么。所以要做好，需要超越自我，积累更为全局的知识，首先是你的上游需要理解，进一步是上游的上游需要了解。

过去、现在、未来

从过去看为什么来；从现在看缺什么；从未来来看走向哪里。架构师需要看的更远，比如半年，一年，三年。预知未来的能力。

抽象归纳

从全局、多样性信息中去抽象归纳。案例推演越多，越能找到本质，更能经得住推敲。分离关注点，识别关键内容。

视野会决定你获取信息的宽度和广度。

假比架构师负责的系统是一个圈，架构师的的视野，不仅仅是站在圈内看圈内，还要站在圈内看圈外。进一步，还可以站在圈外看圈内。进一步，你还可以飞起来，鸟瞰。

架构方法论

对于架构相关的工作不是无方法可循，相反对于企业级架构是有一整套方法论。

1、企业级建模方法ArchiMate

没有听过的可以自行搜索查看。

业务架构、应用架构、技术架构、信息架构是常见的划分视角。技术为业务服务，技术驱动业务。

不同层次/定位的架构师的关注点会有不同：

业务架构对接业务愿景，业务架构师不一定需要完全懂技术，或者有很强的技术能力。 如果是强业务型平台，这类平台一般会直接面对业务场景，业务分析、建模能力需要更强；共享型平台，这类平台一般在各个业务平台的下层，提供统一的业务支撑和高可用的服务支撑，此类架构师，既需要领域建模，有需要很强的技术能力，一般没有技术功底的PD也很难规划、掌控此类平台；技术型平台，诸如基础技术平台、中间件等架构师，需要对技术的深入度，对于技术栈的深度和广度需要很高的要求，此类架构师对于业务的理解可能不会太强，而且此类架构师可能不喜欢关注业务。

应用架构对标业务架构，应用架构支撑业务架构。两者关系是相互促进循环。应用架构师考虑如何基于当前的技术架构，对业务架构提出的业务模型进行系统支撑。

技术架构是企业的基础技术栈。消息中间件，服务框架等等都可以纳入这一体系。技术架构不是一味的堆砌高大上的概念。业务发展/愿景，应用架构遇到的问题会驱动技术架构完善；技术架构的扩展能力确保能快速支撑业务爆发增长（比如亿级访问量），或者业务复杂度（比如服务框架或者分布式事务框架）。

信息架构最难，此部分最容易忽略，最容易被取舍。如果要建立完全的信息架构也比较困难，第一个困难就是建设成本太高，第二就是可能当前解决还想不清楚，比如业务领域的变化性很大，在模糊阶段建立信息标准存在悖论。一般前期需要业务先行，所以信息架构，信息标准会缺失；待系统发展到一定规模后，各个系统信息交互存在困难时，再来重构的成本也会很高。

2、业务建模模式

业务功能域拆分，自顶向下的分解功能域。抽象建模是每个层次都需要的能力，不同的业务复杂度级别采取的方案可能不同。

比较简单的业务，建设初期可能就是单系统。可以采用模块化拆分（包结构也算一种模块化，多工程也是一种模块化）；可以使用GoF设计模式，进行复杂功能的拆分，提供可读性、可维护性；可以使用OOP面向对象变成进行业务建模等等。

稍微复杂一点的业务，可以使用DDD进行领域分析建模。对于业务领域进行业务实体，领域服务等合理的拆分，确定业务领域的职责范围。

更复杂的业务综合体，可以使用基于SOA的架构进行更大范围的业务功能域的拆分，此部分的拆分模式其实可以理解为更大范围的DDD拆分，然后使用技术（SOA）的方式，让各个业务域进行协作。本质上，建模的方式没有太大的区别，把相同的业务服务划分到特定职责的业务域。

3、架构与组织

一般架构师不需要关注这个点，但是架构和组织是配套对齐。只有得到组织的强有力支撑，架构实施才能得到有力实施。相对大型的业务实体会划分为多个一级业务域，这些域会对应架构师，同时也会配比一定的研发团队；一级业务域可能划分为多个二级架构域，二级架构域也会有对应的架构师，组织一般也是配套。

有的架构师是纯架构师，不带团队，这种架构师需要有加强的架构沟通能力，和各个TL协调资源和架构目标。有的架构师兼容TL，这类架构师得到的支撑力度会更顺畅。

对于大型的架构团队，基本上会有架构委员会。一级业务域形成公司级别的架构委员会，对于一级域的重要职责负责；二级业务域也可以形成架构师团队，便于二级业务域内职责确定和协作。

一个好的架构师需要理解自己，同时理解周边。一级业务域架构师，需要清楚自己负责的一级业务域，同时也需要很熟悉周边的一级业务域。架构越大的域，信息量越大，很考验架构师的信息接收、抽象、建模能力。

4、架构规划闭环

架构规划、架构实施、架构评估是一个架构闭环。

架构是动态的，在平衡、取舍、演进的架构迭代中不断演进。

没有完美的架构，如果你觉得当前的架构是完美的架构，那么你的业务可能是“死业务”。充满生命力的业务会带来业务变化，业务愿景/目标也会有调整。业务愿景可以直接带来架构目标（比如要支撑国际化）；缺失的平台能力也带来架构目标（比如平台故障频出）。

对于架构目标的内容进行合理的人员、优先级、里程碑排布，然后付诸于实施。架构实施的过程一般都是充满挑战，实施过程中会有对架构目标的修正，会有和你负责的上下游进行游说、PK，会有基于当前的困难做的取舍。

达到里程碑点后对于架构目标和实施情况进行评估，反馈，进行架构治理相关工作。

架构师的价值

个人把程序员进阶分为如下几个阶段

任务明确型阶段

多见于初入门的程序员，需要在别人指导下完成编码工作。部分仅仅完成开发工作，不追求甚解的人可能停留在这个阶段。

业务明确型阶段

对于一个系统/业务的熟悉后，你已经可以完全掌控这个系统的职责。这个时候给你一个应该你做的需求，你会很容易进行系统的功能分解，设计，然后把这个需求完成。这个时候你知道自己该做什么，不该做什么。

业务模糊型阶段

这个阶段，你会遇到很多需求，这些需求可以在你这里做，也可以不在你这里做。会面对很多模糊领域的问题，解决模糊领域的能力，考验架构师的能力，在信息中抽丝剥茧，归纳抽象能力。这个时候，你不仅仅知道自己不该做什么，还能知道这个不该做的应该放到哪里去做，比如应该放到哪个系统里。

创造进阶阶段

这个阶段更复杂，带有更多创造性，视野可能不仅仅局限在现状里，比如现状划分了5个功能域。但是这个阶段的架构师，也许可以创造出第6个功能域。一种方式是通过业务域重组；一种方式是对未来的识别。

架构师的挑战和价值在于处理模糊领域的问题，让模糊的变得不模糊，清晰可触摸。

架构师的软能力

架构师很爱写PPT，架构师写PPT也很爱被一线的工程师诟病，说不干实事。

但是，架构师很需要沟通表达能力，如何把架构目标清晰的进行表达，对架构职责进行表述，和相关关系人进行沟通，这些都很重要，关乎架构目标是否能达成。

同时，架构师对于信息的处理能力很重要，对信息的理解能力会决定架构师走的多远，能多快、多准的找出架构关键点。

架构师也需要协调能力，比如架构师之间的沟通协调，架构师和实施团队的沟通协调。

架构师该不该写代码

一个好的架构师应该是从实战中的真知，从实战和细节中走来；但是，成长为一个架构师后，关注太多细节，会消耗较多的经历，会影响从更宏观看问题。技术型架构师这方面一般会好点。

架构师的工作，也是从编码，架构规划等工作中的取舍。如果需要关注到很细，架构师需要深入下去；如果不需要深入太细，可以从更宏观来看问题，比如从功能层面。