一位大牛架构师的经验总结

架构师是一个既能掌控整体又能洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。看似完美的“人格模型”背后，是艰辛的探索。今天，阿里巴巴技术专家九摩将多年经验，进行系统性地总结，帮助更多架构师在进阶这条路上走得更“顺畅”，姿态更“优雅”。

架构师职责

架构师不是一个人，他需要建立高效卓越的体系，带领团队去攻城略地，在规定的时间内完成项目。

架构师需要能够识别定义并确认需求，能够进行系统分解形成整体架构，能够正确地技术选型，能够制定技术规格说明并有效推动实施落地。

按 TOGAF 的定义，架构师的职责是了解并关注实际上关系重大但未变得过载的一些关键细节和界面，架构师的角色有：理解并解析需求，创建有用的模型，确认、细化并扩展模型，管理架构。

从业界来看对于架构师的理解可以大概区分为：

• 企业架构师：专注于企业总体 IT 架构的设计。

• IT 架构师-软件产品架构师：专注于软件产品的研发。

• IT 架构师-应用架构师：专注于结合企业需求，定制化 IT 解决方案；大部分需要交付的工作包括总体架构、应用架构、数据架构，甚至部署架构。

• IT 架构师-技术架构师：专注于基础设施，某种软硬件体系，甚至云平台，提交：产品建议、产品选型、部署架构、网络方案，甚至数据中心建设方案等。

阿里内部没有在职位 title 上专门设置架构师，架构师更多是以角色而存在，现在还留下可见的 title 有两个：首席架构师和解决方案架构师，其中解决方案架构师目前在大部分 BU 都有设置，特别是在阿里云和电商体系。

解决方案架构师

工作方式理解：

• 了解和挖掘客户痛点，项目定义，现有环境管理；

• 梳理明确高阶需求和非功能性需求；

• 客户有什么资产，星环（阿里电商操作系统）／阿里云等有什么解决方案；

• 沟通，方案建议，多次迭代，交付总体架构；

• 架构决策。

职责：

1、从客户视图来看

• 坚定客户高层信心：利用架构和解决方案能力，帮忙客户选择星环／阿里云平台的信心；

• 解决客户中层问题：利用星环／阿里云平台服务+结合应用架构设计/解决方案能力，帮忙客户解决业务问题，获得业务价值；

• 引领客户 IT 员工和阿里生态同学：技术引领、方法引领、产品引领。

2、从项目视图看

• 对接管理部门：汇报技术方案，进度；技术沟通；

• 对接客户 PM，项目 PM：协助项目计划，人员管理等。负责所有技术交付物的指导；

• 对接业务部门和需求人员：了解和挖掘痛点，帮忙梳理高级业务需求，指导需求工艺；

• 对接开发：产品支持、技术指导、架构指导；

• 对接测试：配合测试计划和工艺制定。配合性能测试或者非功能性测试；

• 对接运维：产品支持，运维支持；

• 对接配置&环境：产品支持；

• 其他：阿里技术资源聚合。

3、从阿里内部看

• 销售方案支持；

• 市场宣贯；

• 客户需求Facade；

• 解决方案沉淀。

架构师职责明确了，那么有什么架构思维可以指导架构设计呢？请看下述的架构思维。

架构思维1、自顶向下构建架构

要点主要如下：

1）首先定义问题，而定义问题中最重要的是定义客户的问题。定义问题，特别是识别出关键问题，关键问题是对客户有体感，能够解决客户痛点，通过一定的数据化来衡量识别出来，关键问题要优先给出解决方案。

2）问题定义务必加入时间维度，把手段/方案和问题定义区分开来。

3）问题定义中，需要对问题进行升层思考后再进行升维思考，从而真正抓到问题的本质，理清和挖掘清楚需求；要善用第一性原理思维进行分析思考问题。

4）问题解决原则：先解决客户的问题（使命），然后才能解决自己的问题（愿景）；务必记住不是强调我们怎么样，而是我们能为客户具体解决什么问题，然后才是我们变成什么，从而怎么样去更好得服务客户。

5）善用多种方法对客户问题进行分析，转换成我们产品或者平台需要提供的能力，比如仓储系统 WMS 可以提供哪些商业能力。

6）对我们的现有的流程和能力模型进行梳理，找到需要提升的地方，升层思考和升维思考真正明确提升部分。

7）定义指标，并能够对指标进行拆解，然后进行数学建模。

8）将抽象出来的能力诉求转换成技术挑战，此步对于技术人员来说相当于找到了靶子，可以进行方案的设计了，需要结合自底向上的架构推导方式。

9）创新可以是业务创新，也可以是产品创新，也可以是技术创新，也可以是运营创新，升层思考、升维思考，使用第一性原理思维、生物学（进化论--进化=变异+选择+隔离、熵增定律、分形和涌现）思维等哲科思维可以帮助我们在业务，产品，技术上发现不同的创新可能。可以说哲科思维是架构师的灵魂思维。

image

2、自底向上推导应用架构

先根据业务流程，分解出系统时序图，根据时序图开始对模块进行归纳，从而得到粒度更大的模块，模块的组合／聚合构建整个系统架构。

基本上应用逻辑架构的推导有4个子路径，他们分别是：

• 业务概念架构：业务概念架构来自于业务概念模型和业务流程；

• 系统模型：来自于业务概念模型；

• 系统流程：来自业务流程；

• 非功能性的系统支撑：来自对性能、稳定性、成本的需要。

效率、稳定性、性能是最影响逻辑架构落地成物理架构的三大主要因素，所以从逻辑架构到物理架构，一定需要先对效率、稳定性和性能做出明确的量化要求。

自底向上重度依赖于演绎和归纳。

如果是产品方案已经明确，程序员需要理解这个业务需求，并根据产品方案推导出架构，此时一般使用自底向上的方法，而领域建模就是这种自底向上的分析方法。

对于自底向上的分析方法，如果提炼一下关键词，会得到如下两个关键词：

1）演绎：演绎就是逻辑推导，越是底层的，越需要演绎：

• 从用例到业务模型就属于演绎；

• 从业务模型到系统模型也属于演绎；

• 根据目前的问题，推导出要实施某种稳定性措施，这是也是演绎。

2）归纳：这里的归纳是根据事物的某个维度来进行归类，越是高层的，越需要归纳：

• 问题空间模块划分属于归纳；

• 逻辑架构中有部分也属于归纳；

• 根据一堆稳定性问题，归纳出，事前，事中，事后都需要做对应的操作，是就是根据时间维度来进行归纳。

image

3、领域驱动设计架构

大部分传统架构都是基于领域模型分析架构，典型的领域实现模型设计可以参考DDD（领域驱动设计），详细可以参考《实现领域驱动设计》这本书，另外《UML和模式应用》在领域建模实操方面比较好，前者偏理论了解，后者便于落地实践。

领域划分设计步骤：

1、对用户需求场景分析，识别出业务全维度 Use Case。

2、分析模型鲁棒图，识别出业务场景中所有的实体对象。鲁棒图 —— 是需求设计过程中使用的一种方法（鲁棒性分析），通过鲁棒分析法可以让设计人员更清晰，更全面地了解需求。它通常使用在需求分析后及需求设计前做软件架构分析之用，它主要注重于功能需求的设计分析工作。需求规格说明书为其输入信息，设计模型为其输出信息。它是从功能需求向设计方案过渡的第一步，重点是识别组成软件系统的高级职责模块、规划模块之间的关系。鲁棒图包含三种图形：边界、控制、实体，三个图形如下：