架构师 ###### 定义 ==== * 所谓架构师，就是掌握大量设计理念和原则、落地到各种语言及附带工具链（生态）下的实践方法、垂直行业模型理解，定制系统模型设计和工程实践规范细则，进而控制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. 迭代能力的修炼，学会反思，学会在自我否定中不断成长 学会否定自己 .. note:: 架构师需要有自己的信仰。我们需要坚持对业务进行正交分解的信念，要坚持不断地探索各类需求的架构分解方法。“一个个业务只读、接口稳定、易于组合的模块 + 组合的方法论” .. note:: 作为架构师，事情优先级的排列是第一位的，有太多重要的事情值得去做。 其他 ==== * 架构师一定要负责整个系统中最核心和最难的地方编写，并且设计好团队合作开发方式，能根据编程经验看到未来的变化 * 如果一个团队里需要一个架构师，一定是一位代码能力最好的，能够负责核心业务的开发，并且不能脱离实际业务 架构师职责:: 架构师需要建立高效卓越的体系，在规定的时间内完成项目 架构师需要: 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 可以提供哪些商业能力 梳理现有流程和能力模型:: 找到需要提升的地方，升层思考和升维思考真正明确提升的部分 定义指标:: 定义指标并能够对指标进行拆解，然后进行数学建模 能力诉求转化为技术挑战:: 将能力诉求转换为技术人员的方案设计，需要结合自底向上的架构推导方式 创新:: 创新可以是业务创新，也可以是产品创新，也可以是技术创新，也可以是运营创新 升层思考，升维思考，使用第一性原理思维帮助自己在业务，产品，技术上发现不同的创新可能 哲科思维是架构师的灵魂思维 .. figure:: https://img.zhaoweiguo.com/uPic/2022/04/OxVldU.jpg caption 自底向上推导应用架构 ^^^^^^^^^^^^^^^^^^^^ 先根据业务流程，分解出系统时序图，根据时序图对模块进行归纳，从而得到粒度更大的模块，通过模块的组合或者聚合构建整个系统架构 应用逻辑架构的推导有 4 个子路径:: 1. 业务概念架构: 来源于业务概念模型和业务流程 2. 系统模型: 来源于业务概念模型 3. 系统流程: 来源于业务流程 4. 非功能性的系统支撑: 来源于对性能，稳定性，成本的需求 最影响逻辑结构落地成物理架构的三大主要因素:: 1. 效率 2. 稳定性 3. 性能 从逻辑架构到物理架构，一定需要先对效率，稳定性和性能做出明确的量化要求 自底向上依赖于演绎和归纳:: 如果产品方案已经明确，程序员需要理解这个业务需求，并根据产品方案推导出架构， 一般使用自底向上的方法。领域建模就是这种自底向上的分析方法 演绎: 演绎就是逻辑推导，越是底层，越需要演绎:: 1. 从用例到业务模型就属于演绎 2. 从业务模型到系统模型也属于演绎 3. 根据目前的问题，推导出需要实施某种稳定性措施也是演绎 归纳: 归纳是根据事物的某个维度来进行归类，越是高层的，越需要归类:: 1. 问题空间模块划分属于归纳 2. 逻辑架构也有的属于归纳 3. 根据一堆稳定性问题来归纳出事前，事中，事后都需要的对应的操作，是就时间维度来进行归纳 .. figure:: https://img.zhaoweiguo.com/uPic/2022/04/1YLQBS.jpg caption 必备技能 -------- 设计 ^^^^ 理论层面:: 1. 了解基本的设计模式 2. 研究一下模式与反模式 3. 了解质量度量 实践层面:: 1. 尝试理解不同的技术栈 2. 分析和理解应用模式: 查看当前流行的框架 在实践中学习很多模式 理解如何在框架中应用模式，为什么要这样做 深入地研究代码并了解如何实现的 决策 ^^^^ 架构师需要制定决策，指引项目甚至整个公司的正确方向:: 1. 分清主次: 概念完整性 一致性 2. 优先级 3. 认清自己的能力，明确自己的职责 4. 评估多种选择 成长方式 -------- 广度 ^^^^ 广度: 架构师应该对所在领域的主流技术体系有一个全面清晰的认识，每一种技术不需要深入的了解，但必须指导每个技术的三个层面 每种技术的由来，为什么会出现这种技术？这种技术是用来解决什么问题的？ 每种技术是什么？技术的基本组成是什么？ 解决同一个问题的相同技术各自优缺点是什么？更适合哪种场景？只有清晰认识同一类型技术的优缺点，才能在技术选型能够使用更加合理的技术 广度学习方法：对各主流技术一一通过搜索引擎了解三个层面的内容 高度 ^^^^ 高度: 架构师应该具备能够从纷繁杂乱的信息中建立抽象的能力 业务抽象: 能够从软件和产品的复杂需求中抽象出核心业务实体，并给业务实体建立合理的关系 技术抽象: 能够对复杂的技术架构进行分层抽象，服务抽象或者微服务抽象，组件抽象，并为各层和各层服务之间调用建立合理关系 高度学习方法：深入理解和学习面向对象，设计模式，琢磨优秀开源框架的设计原理和设计思想 深度 ^^^^ 深度: 架构师对主流技术有深入理解 对主流技术的原理，运作机理有基本全面的理解 至少要对一种技术有深入的认识，是这种技术的专家，熟悉源代码 宽度 ^^^^ 宽度: 架构师要熟知当前的技术前沿和热点，能够使用新的技术解决问题。比如微服务，大数据，云计算，人工智能 宽度学习方法：订阅相关的技术咨询，定期了解，对于和所负责工作相关的技术进一步了解