1. 大厂架构师的JD

一般从招聘网站上的JD可以归纳出两类信息，岗位的工作内容和应聘者的要求。

1.1 职位职责

架构师的工作内容一般会归纳出以下几类：产品业务设计和讨论、架构设计、核心组件的开发编码、架构系统的缺陷分析和trouble shooting、提高系统的可靠性和可扩展性等。

1.2 职位要求

为了应对上面的工作内容，应聘单位会给出一定的准入门槛给应聘者来衡量自己，总体也可以大致分为以下几类：对学历的要求、对工作年限（经验）的要求，对技术深度的要求、对技术广度的要求、对交流协作以及沟通表达能力的要求。

1.3 如何针对JD锻炼自己的架构师训练之路

按照对于上面的职责和要求的剖析，要成为架构师需要先训练自己以下几个方面的能力

架构设计

作为一名架构师，最基本的能力就是对一个新系统或现存系统的新模块进行一个整体设计，这里需要我们掌握对于涉及的业务领域有一个充分的了解，因为架构设计时，需要架构师对业务领域进行抽象与关联，如果对业务掌握得一知半解，是很难做出正确的业务抽象。要获得对业务的理解，没有太多捷径，只能多看、多听、多写、多总结归纳，重点针对自己要应聘的单位的业务或相似的业务。

架构设计输出

上面提到了设计，这里还要再提出设计输出，因为光有设计还不能完成项目，因为项目一般都是要多人协作，需要产品、开发、测试乃至运维都知道我们将有实现的一套系统是如何运作的。这就需要架构师能把这些脑子里设计的东西输出到文字和图上，面对不同的协作团队，我们需要输出不同的架构设计视图，一般使用UML来做架构设计输出。

技术能力

上面提到的更多是顶层设计能力，更多是宏观的层面，但是到了真正要实现和落地，如果架构师没有实际编码的能力，那做出架构可能最终会被推倒，这里的架构关乎系统性能、安全性、可靠性、可扩展性、团队的上手门槛以及成本，而成本往往是最容易被忽视的一点。架构师在全盘考虑后，要选择最适合自己公司的一套架构来应对需求，在不同阶段架构，也是要有不同的设计。架构师如果不具备分布式、高并发、海量数据存储等技术知识储备，那设计出来的架构很容易出现局部甚至全局的问题，导致无法落地，最后成一名PPT架构师。要想做好这一点，需要我们长期的投入精力去学习，巩固自己的知识，建议先做深度、再做广度。

软技能

当技术能力具备后，架构师还需要具备不少软技能，团队协作、语言表达能力和学习能力。

架构师还是要对项目最终落地负责，需要在多个团队中协调资源，中间往往少不了各种协调会议、各种评审，架构师如果没有很好的团队意识和交流能力以及文档表述能力，会对自己设计的输出造成障碍，使得交流双方在理解上出现偏差。所以，一定要善用合理的表达视图，例如UML的用例图、部署图、时序图，来降低沟通双发理解的难度。同时也要有一颗强大的内心，接收外部的压力，平时一定要多运动，保持良好的状态，也可以用运动来发泄压力（笑）。此外还需要掌握适合自己的学习方法，抓住问题的本质，例如一些底层的数据结构，算法，操作系统等基础知识必须要牢固掌握，这样遇到了新知识才能解构这些表象的东西，让自己快速吸收新的知识。



成为架构师远不是上面那么简单，需要耐得住寂寞，占用个人时间投入大量的精力去学习、去思考、去总结。



2. 架构视图

上面提到了架构师的架构能力，如何表现架构能力，第一要素就是输出一个架构视图。为了表述出整体架构，为了抽象我们的设计，视图中分别有对象和关系两大类元素，针对这两大类元素，我们一般有以下几种视图：

• 逻辑视图

• 过程视图

• 物理视图

• 开发视图

• 场景视图

这些前4个视图最终都是围绕着场景视图服务，所以我们通常说4+1架构视图。

2.1 逻辑视图

逻辑视图是是表述架构设计中元素有哪些，元素和元素之间的关系。这些元素可以是一个系统，一个模块，一个类，一个实例对象等，而关系则表示这些元素之间的关系，例如依赖关系，包含关系等。该视图面向最终用户、产品经理和相关开发Leader。

2.2 过程视图

过程视图表示的是在系统运行过程，各个运行单位之间的运行情况，例如我们的数据流如何在各个组件之间流转，我们的线程调度过程等。该视图面向开发和性能优化人员。

2.3 物理视图

物理视图表示系统中使用到的物理资源以及拓扑情况，例如使用了多少服务器，服务器与服务器之间的通信模式，网络组网情况等。该视图面向系统集成商和系统运维。

2.4 开发视图

开发视图表示系统在编码层面如何划分功能模块组成，如何抽象出合理的接口、类以及相应的集成关系。该视图主要面向开发人员和测试人员，用于规范开发使用的类和分层结构。

2.5 场景视图

场景视图则是在特定场景下，把前面用到的视图有机结合起来表述这个场景下，有哪些元素，这些元素的关系以及运作方式。

3. UML(统一建模语言）

为了规范我们输出上面的视图，计算机领域在长时间过程中，最终提炼出了使用UML来表述我们在软件架构设计中的建模过程。

这里列举一些常用的UML图：

3.1 用例图

用例图用于表述系统存在的功能模块，以及模块与模块间的关系。



3.2 时序图

时序图，用于表示某些场景下，元素间按照时间顺序的交互流程以及相应元素在场景上的作用范围。



3.3 组件图

组件图表述了元素和元素之间的关联关系，这和用例图有些相似，但具体不是以用户使用功能角度出发去表示关系，而是系统本身的依赖或聚合关系来表示。



3.4 类图

类图用于在编码前，划分类、接口、实现功能的模块之间的关系和边界，让开发人员能够直观在架构师的意图下，按照框架约束进行开发。



4. 架构设计文档

作为架构师在架构设计最终输出的文档，其内容主要是经过需求分析后做出的概要设计，主要还是描述系统有哪些功能，其元素和元素间组成关系。通过UML图来把整个软件架构描述出来。文档的目的是为了统一设计人员和开发人员的理解，同时也是让架构师本人在编写过程中，逐步细化自己的设计，发现之前没有考虑到的漏洞和细节。