3.2.2. 架构师¶
定义¶
所谓架构师，就是掌握大量设计理念和原则、落地到各种语言及附带工具链（生态）下的实践方法、垂直行业模型理解，定制系统模型设计和工程实践规范细则，进而控制30万+行代码项目的开发便利性、可维护性、可测试性、运营质量的资深研发群体。
如何成为好的架构师¶
职责:
1. 确保团队有个共同的技术愿景
* 帮助团队向客户交付他们想要的系统
2. 只和一个团队工作
* 技术引领者
3. 负责整个项目组的技术愿景
* 协调多个团队间的工作
难做好的原因:
响应客户的需求变更
放弃一开始设计出完美系统的想法
设计一个可以不断演化的框架
新知识可以很容易的应用到系统中
架构师设计¶
如何进行性能测试，性能测试的流程是什么？性能测试的主要关注指标有哪些？
怎么理解领域驱动设计DDD? DDD的优缺点是什么？
导致系统故障无法正常访问的原因有哪些？保障系统稳定高可用的方案有哪些？ 如何保护数据库中存储的用户密码，用时序图展示「用户密码」加密存储与登录验证的过程
架构师的主要能力:
1. 编程
2. 基础技术掌握能力
3. 常用技术产品的理解与应用能力
4. 性能优化与分析故障的能力
5. 常用架构模式和框架的理解 与应用能力
6. 建模以及设计文档的方法和能力
7. 业务理解与功能模块及非功能模块拆解能力
8. 快速学习能力
9. 沟通与领导能力
Shawn：“PPT 架构师”的口头禅是“细节不讨论”，一个优秀的架构师，需要对细节有多少考虑呢:
华仔：这是一个非常好的问题，也是很多同学困惑的问题，我分享一下我的做法，以我学习 Elasticsearch 为例，具体的做法是：
1. 搭建一个单机伪集群，搭建完成后看看安装路径下的文件和目录，看看配置文件有哪些配置项，不同的配置项会有什么样的影响。
2. 执行常用的操作，例如创建索引，插入、删除、查询文档，查看一下各种输出。
3. 研究其基本原理，例如索引、分片、副本等，研究的时候要多思考，例如索引应该如何建，分片数量等
4. 和其他类似系统对比，例如 Solr、Sphinx，研究其优点、缺点、适用场景。
5. 模拟一个案例看看怎么应用。例如，假设我用 Elasticsearch 来存储淘宝的商品信息，我应该如何设计索引和分片。
6. 查看业界使用的案例，思考一下别人为何这么用；看看别人测试的结果，大概了解性能范围。
7. 如果某部分特别有兴趣或者很关键，可能去看源码，例如 Elasticsearch 的选举算法
8. 如果确定要引入，会进行性能和可用性测试。
不建议拿到一个系统一开始就去读源码，效率太低，而且效果也不好
架构师沟通能力:
架构师是业务和技术之间的桥梁，同时通常情况下还会确定整体项目的步骤。
因此，架构师的沟通能力非常重要，
既要说得动老板，让老板支持自己的设计决定；
又要镇得住技术人员，让技术人员信服自己的设计选择；
同时还要能够理解业务，结合业务不同发展阶段设计合适的架构，所以也要参与产品和项目决策。
由于架构设计过程中存在很多判断和选择，而且不一定都有明确量化的标准，因此不同的人有不同的看法是普遍情况。
这种情况下架构师既需要专业能力过硬，又需要具备良好的沟通技巧，才能促使业务、项目、技术三方达成一致。
当然，架构师的核心能力还是技术能力，过硬的技术才是良好沟通的基础，
否则单纯靠沟通技巧甚至花言巧语，一次两次可能奏效，但后面被打脸打多了，也就没人信任了。
架构师的职责:
制定规范 + 指导落地
架构师根据业务需求所制定的合理且可落地的技术规范，我们将这样的规范称为架构。
微服务架构师需要具备以下基本职责:
1. 分析业务需求并切分微服务边界
2. 定义架构规范与文档标准
3. 确保微服务架构顺利落地
4. 改善微服务架构并提高开发效率
微服务架构师必须面对并克服这些挑战:
1. 架构需要适应不断变化的业务需求
2. 架构具备稳定性、扩展性、安全性、容错性等
3. 使技术团队深刻理解微服务思想
4. 展现微服务架构的价值
架构师的内功主要包含三部分:
1. 判断力
能够准确判断系统的复杂度在哪里
2. 执行力
能够使用合适的方案解决复杂度问题
3. 创新力
能够创造新的解决方案解决复杂度问题
提升内功方法:
1. 经验
设计过的系统越多、系统越复杂，架构师的内功也就越强，
不管是成功的架构，还是失败的架构，
不管是踩坑的经验，还是填坑的经验，都将成为架构师内功的一部分。
2. 视野
掌握的知识和技能越多、越深，架构师的内功也就越强，
他山之石可以攻玉，站在巨人的肩膀上会看的更高更远。
3. 思考
经验和视野都是外部输入，还要消化，将其变为我们自己的营养，这就是思考的作用。
思考能够将经验和视野中的模式、判断、选择、技巧等提炼出来为我所用，思考也能促使我们产生新的创意和灵感。
总的指导原则是：积累经验，拓宽视野，深度思考
其他¶
架构师核心是把知识串起来，构建一个完整的认知，不留疑惑:
大部分知识是不需要深入细节的，只在你需要的时候深入，但深入的时候要很深。
架构师绝对不是要把自己打造为全才。
架构师掌控全局的核心思想是打通经络，让自己的内力在全身自然流通，浑然一体。
在不影响理解的情况下，你需要放弃很多实现细节的专研，
但有一天你需要细节的时候，你能够知道存在这些细节，并且快速钻研进去。
架构师并不是一个纯技术岗位。我们从软件工程的视角来看，架构师的职责就是要对软件工程的执行结果负责，这包括：按时按质进行软件的迭代和发布、敏捷地响应需求变更、防范软件质量风险（避免发生软件质量事故）、降低迭代维护成本。
从技能来说，我们可能把架构师能力去归结为:
1. 理需求的能力
2. 读代码的能力
3. 抽象系统的能力
架构师修炼之道，更难的是在心性上，这包括:
1. 同理心的修炼，认同他人的能力
2. 全局观的修炼，保持好奇心和学习的韧性
并不是所有的技术都值得深耕。我们也都没有这个精力去这么做
要做到的是，随时想深入耕耘就能深入
3. 迭代能力的修炼，学会反思，学会在自我否定中不断成长
学会否定自己
备注
架构师需要有自己的信仰。我们需要坚持对业务进行正交分解的信念，要坚持不断地探索各类需求的架构分解方法。“一个个业务只读、接口稳定、易于组合的模块 + 组合的方法论”
备注
作为架构师，事情优先级的排列是第一位的，有太多重要的事情值得去做。
其他¶
架构师一定要负责整个系统中最核心和最难的地方编写，并且设计好团队合作开发方式，能根据编程经验看到未来的变化
如果一个团队里需要一个架构师，一定是一位代码能力最好的，能够负责核心业务的开发，并且不能脱离实际业务
架构师职责:
架构师需要建立高效卓越的体系，在规定的时间内完成项目
架构师需要:
1. 识别定义并确认需求
2. 进行系统分解形成整体架构
3. 正确地技术选型
4. 制定技术规格说明并有效推动落地
架构师的角色:
1. 理解并解析需求
2. 创建有用的模型
3. 确认并细化扩展模型
4. 管理架构
软件架构层级¶
应用级:
1. 最低层级的架构
2. 层级低，但是很详细
3. 这种层级的交流一般是在一个开发团队内展开
解决方案级:
1. 架构的中间层
2. 关注一个或多个满足业务需求的应用，即商业方案
3. 这之中有些设计是高层次的，但大部分还是低层次的设计
4. 这种层级的交流开始涉及多个开发团队
企业级架构:
1. 架构的最高层级
2. 关注多个设计方案
3. 这种架构的设计层次高且抽象，因此也需要方案级和应用级的架构师对此进行细化
4. 这种层级的架构需要多个组织进行沟通
架构师可以被看作是不同工作组之间的粘合剂:
1. 横向: 在业务部和开发人员或者不同的开发团队之间架起沟通的桥梁
2. 纵向: 在管理者和开发人员之间架起桥梁
3. 技术: 将不同的技术或应用整合在一起
解决方案架构师¶
工作方式理解:
1. 了解和挖掘客户痛点，项目定义，现有环境管理
2. 梳理明确高阶需求和非功能性需求
3. 对客户问题已经存在什么解决方案
4. 沟通，方案建议，多次迭代，交付总体架构
5. 架构决策
职责:
从客户视图看:
1. 坚定客户高层信心: 利用架构和解决方案能力，帮助客户选择相关解决方案
2. 解决客户中层问题: 利用相关解决方案，帮助客户解决业务问题，获得业务价值
3. 引领客户 IT 员工: 技术引领，方法引领，产品引领
从项目视图看:
1. 对接管理部门: 汇报技术方案，进度，技术沟通
2. 对接 PM, 项目 PM: 协助项目计划，人员管理等。负责所有技术交付物的指导
3. 对接业务部门和需求人员: 了解和挖掘痛点，帮忙梳理高级业务需求，指导需求工艺
4. 对接开发: 产品支持，技术指导，架构指导
5. 对接测试: 配合测试计划和工艺制定。配合性能测试或者非功能性测试
6. 对接运维: 产品支持，运维支持
7. 对接配置和环境: 产品支持
8. 其余资源整合
软件架构师职责¶
定义和确定所需的开发技术和平台
定义开发标准，如编程标准，工具，审核流程，测试方法等
对确定和理解业务需求提供技术支持
设计系统并根据需求作出决策
对架构定义，设计和决策进行讨论记录
检查并审核架构和代码，比如检查前期确定的模式与编程标准是否被正确实施
与其他部门和架构师合作
对开发人员的引导和咨询
将高级设计细化，并转化为较低级的设计
按照系统设计实现过程:
1. 支持售前或需求阶段，提供概念架构或技术咨询
2. 系统分析，架构设计，技术选型，产出架构解决方案
3. 指导项目团队成员，按照架构设计完成，开发，测试和发布
4. 开发或设计开发框架，制定编码或者编程规范，设计架构原型，验证架构原型
5. 组织技术或架构培训，把我技术或者架构方向
6. 实现与成本的方案平衡，干系人沟通，技术风险管理，技术领袖
按照项目阶段:
1. 售前阶段: 给予商务支持，提供系统解决方案和架构咨询
2. 需求阶段: 与需求分析师一起，参与项目沟通，协助完成技术或者业务咨询和需求模型，兼顾业务专家身份
3. 架构阶段: 进行系统分析与设计，进行系统抽象，设计系统模型，进行技术原型，开发架构原型等
4. 设计阶段: 指导设计人员完成详细设计
5. 开发阶段: 指导开发人员按设计实现，解决技术难题
6. 测试阶段: 指导测试人员工作，特别是非功能需求测试
7. 发布阶段: 指导部署人员按照部署架构进行部署，及时解答或反馈运行期间架构问题
8. 其他工作: 技术选型，人员培训，技术指导
软件架构师工作流程¶
架构的工作流程是一个系统如何从需求，架构到实现的的过程和方法
良好的架构:
需要架构师具备技术和架构设计能力之外，还需要具有良好丰富的业务知识
从软件工程角度，架构师不仅要参与系统架构和设计阶段外，还要参与需求分析阶段，开发，测试，发布，试运行阶段
需求分析主要包括需求模型，架构模型，设计模型和解决方案模型:
1. 需求模型: 参与需求分析和需求模型设计，提供技术建议或引导需求定义，提供解决方案指导
主要参与者：需求分析师，业务分析师
辅助参与者：架构师，设计师
2. 架构模型: 根据需求模型，产出架构模型
选择架构对象: 关键流程，核心用例和非功能需求
流程建模: 梳理需求关键流程，分析业务对象，子系统，模块，设计出系统的交互流程
领域建模: 梳理业务流程中设计的对象，子系统模块，划分子系统，模块，核心对象，通信机制，事务模型等
输出总体架构: 根据领域模型和业务流程模型，结合组件架构，部署架构，通信机制，输出系统体架构方案
架构验证: 验证架构可用性，可以用评审或架构原型的方式，进行评审或实际测试验证
主要参与者：架构师，架构委员会
辅助参与者：系统设计师，开发人员，测试人员
3. 设计模型: 在架构师的指导下，根据系统架构，完成各子系统，模块，功能，接口的概要或详细设计
主要参与者：系统设计师，高级工程师
辅助参与者：架构师
解决方案模型: 架构模型，设计模型，架构原型等统一组成架构解决方案
一个完整的系统架构包括:
1. 整体架构
2. 子系统
3. 模块
4. 功能概要或详细设计
5. 通信机制
6. 事务机制
7. 接口定义，包括内部和外部
8. 领域模型
9. 业务流程
10. 数据库设计
11. 中间件
12. 组件架构
13. 部署架构
系统解决方案标准:
1. 满足功能和非功能性需求
2. 符合项目要求的规模和成本
3. 满足开发，测试和发布要求
架构思维¶
自顶向下构建架构¶
定义问题:
定义问题中最重要的是定义客户的问题
定义问题，特别是识别出关键问题.
关键问题是对客户有体感，能够解决客户痛点，
通过一定的数据化来衡量识别出来，关键问题要优先给出解决方案
问题定义加入时间维度:
将方案和问题定义区分开来
分析问题定义:
需要对问题进行升层思考后再进行升维思考，从而真正抓到问题的本质，
理清和挖掘清楚需求
要善用第一性原理思维进行分析思考问题
问题解决原则:
使命: 先解决客户的问题
愿景: 然后才能解决自己的问题
强调的是能够为客户具体解决什么问题，然后才是我们能变成什么，从而怎样去更好地服务客户
善用多种方法对客户问题进行分析:
将客户问题转换成产品和平台需要提供的能力
比如仓储系统 WMS 可以提供哪些商业能力
梳理现有流程和能力模型:
找到需要提升的地方，升层思考和升维思考真正明确提升的部分
定义指标:
定义指标并能够对指标进行拆解，然后进行数学建模
能力诉求转化为技术挑战:
将能力诉求转换为技术人员的方案设计，需要结合自底向上的架构推导方式
创新:
创新可以是业务创新，也可以是产品创新，也可以是技术创新，也可以是运营创新
升层思考，升维思考，使用第一性原理思维帮助自己在业务，产品，技术上发现不同的创新可能
哲科思维是架构师的灵魂思维
caption¶
自底向上推导应用架构¶
先根据业务流程，分解出系统时序图，根据时序图对模块进行归纳，从而得到粒度更大的模块，通过模块的组合或者聚合构建整个系统架构
应用逻辑架构的推导有 4 个子路径:
1. 业务概念架构: 来源于业务概念模型和业务流程
2. 系统模型: 来源于业务概念模型
3. 系统流程: 来源于业务流程
4. 非功能性的系统支撑: 来源于对性能，稳定性，成本的需求
最影响逻辑结构落地成物理架构的三大主要因素:
1. 效率
2. 稳定性
3. 性能
从逻辑架构到物理架构，一定需要先对效率，稳定性和性能做出明确的量化要求
自底向上依赖于演绎和归纳:
如果产品方案已经明确，程序员需要理解这个业务需求，并根据产品方案推导出架构，
一般使用自底向上的方法。领域建模就是这种自底向上的分析方法
演绎: 演绎就是逻辑推导，越是底层，越需要演绎:
1. 从用例到业务模型就属于演绎
2. 从业务模型到系统模型也属于演绎
3. 根据目前的问题，推导出需要实施某种稳定性措施也是演绎
归纳: 归纳是根据事物的某个维度来进行归类，越是高层的，越需要归类:
1. 问题空间模块划分属于归纳
2. 逻辑架构也有的属于归纳
3. 根据一堆稳定性问题来归纳出事前，事中，事后都需要的对应的操作，是就时间维度来进行归纳
caption¶
必备技能¶
设计¶
理论层面:
1. 了解基本的设计模式
2. 研究一下模式与反模式
3. 了解质量度量
实践层面:
1. 尝试理解不同的技术栈
2. 分析和理解应用模式:
查看当前流行的框架
在实践中学习很多模式
理解如何在框架中应用模式，为什么要这样做
深入地研究代码并了解如何实现的
决策¶
架构师需要制定决策，指引项目甚至整个公司的正确方向:
1. 分清主次:
概念完整性
一致性
2. 优先级
3. 认清自己的能力，明确自己的职责
4. 评估多种选择
成长方式¶
广度¶
广度: 架构师应该对所在领域的主流技术体系有一个全面清晰的认识，每一种技术不需要深入的了解，但必须指导每个技术的三个层面 每种技术的由来，为什么会出现这种技术？这种技术是用来解决什么问题的？ 每种技术是什么？技术的基本组成是什么？ 解决同一个问题的相同技术各自优缺点是什么？更适合哪种场景？只有清晰认识同一类型技术的优缺点，才能在技术选型能够使用更加合理的技术 广度学习方法：对各主流技术一一通过搜索引擎了解三个层面的内容
高度¶
高度: 架构师应该具备能够从纷繁杂乱的信息中建立抽象的能力 业务抽象: 能够从软件和产品的复杂需求中抽象出核心业务实体，并给业务实体建立合理的关系 技术抽象: 能够对复杂的技术架构进行分层抽象，服务抽象或者微服务抽象，组件抽象，并为各层和各层服务之间调用建立合理关系 高度学习方法：深入理解和学习面向对象，设计模式，琢磨优秀开源框架的设计原理和设计思想
深度¶
深度: 架构师对主流技术有深入理解 对主流技术的原理，运作机理有基本全面的理解 至少要对一种技术有深入的认识，是这种技术的专家，熟悉源代码
宽度¶
宽度: 架构师要熟知当前的技术前沿和热点，能够使用新的技术解决问题。比如微服务，大数据，云计算，人工智能 宽度学习方法：订阅相关的技术咨询，定期了解，对于和所负责工作相关的技术进一步了解