学点架构师思维和技能总是有益的。
架构是关于软件系统的一系列重大设计决策的有机整体，实现期望的质量属性和业务目标。
架构的实质是站在系统全局视角思考和构建软件，解决问题。
《架构师修炼之道》清晰简明地阐述了架构师的职责、思维、技能和工具箱。全书内容更侧重沟通维度的技能，适合作为手册，放在桌边边读边学边练边用，一个小技能一个小技能地落实。
职责与影响力
软件架构师做什么
从系统全局出发，指导开发团队一起实现系统的短中长期业务目标，推进项目成功。
- 挖掘和确定关键架构需求。需要与主要利益相关方、最终用户深入交谈。
- 从工程角度定义问题。关注软件的上下文语境，定义质量属性。
- 分解系统，分配职责。确定构成软件的主要模块（子系统）及模块（子系统）之间的关联。
- 确定系统关键质量属性。需要在质量属性之间权衡取舍。
- 关注核心功能实现。确定系统所面临的核心技术难题，并推进确定对应的技术决策和方案。
- 展示和评估系统的关键决策。通过各种视图、图表从多个视角展示软件的全景图和主要组成部分。
- 管理技术债务。
- 提升团队成员的设计技能。
针对每个项目提问
- 利益相关方是谁，主要业务目标是什么？
- 整体解决方案是什么？
- 涉及哪些技术？
- 最大风险是什么？如何克服？
- 有机会重做，如何改进？
架构对软件开发的作用
- 将大问题分解为容易处理的小问题。
- 为协同工作提供总体指导和方向。
- 为讨论复杂设计提供基本词汇。
- 重点解决系统质量属性。
- 兼顾考虑成本、约束、进度、风险、交付。
- 避免犯重大错误。
- 让软件更加灵活。
架构不做什么：有所为有所不为
- 不做过于细节的具体决策，除非细节与系统关键质量属性相关。
- 不涉及非核心功能的实现，除非影响系统核心功能。
- 不关注功能需求的实现，但关注关键架构需求。
架构目标与衡量
从“质量-效率-成本”铁三角维度来说，架构的目标就是站在系统整体看待和解决问题，提升研发效率和关键质量，降低长期维护成本。
架构思维
基本思维
- 系统全局：始终坚持站在系统和全局的视角看待和解决问题。
- 以人为本：理解利益方需求，关心最终用户，考虑程序员、测试人员、项目经理、运维等。
- 推迟决策：不到成熟一刻，不着急做出最终决策；低优先级的事情，推迟决策。
- 善于借鉴：研究和借鉴已有的设计成果和设计模式。
- 化虚为实：让想法具体化形象化，将架构展现出来。
- 极简主义： 只关注高优先级的质量属性，提升这些质量属性同时降低风险。
实践方法
- 理解问题 => 清晰描述问题 => 探索想法 => 展示想法 => 评估可行性和适用性
- TDC循环：思考、动手、检查。
专业知识
架构师拥有架构模式与质量属性映射的丰富知识。架构师知道如何在质量属性之间取舍权衡，选择合适的架构模式。
技术架构模式
- 分层模式：应用通常分为多层（控制层、服务层、领域层、数据层、基础设施层），是常见的技术架构模式。
- 端口适配模式：系统通过各种端口适配器将输入转换为系统能够处理的输入，或者将系统输出转换为外部能够接收的输出。通常也称为接口模式，用于子系统交互或消息适配。
- 插件模式：系统支持加载不同的插件来完善自身功能。微内核是一种插件模式，其自身只包含最核心的模块，其它模块通过插件机制动态加载进来。
- 管道过滤器模式：由一系列过滤器通过管道连接，构成一个处理流水线。linux 管道就是典范。
- SOA：应用分解为多个分布式的服务组件，通过 RPC 和标准服务对象格式来通信。
- 微服务模式：应用分解为多个分布式的微服务组件，通过 RPC 或消息队列来通信。
- AKF立方体：从功能职责、数据、服务实例三个维度来分解架构职责。
- PC 模式：生产者消费者模式，亦称发布-订阅模式。任何组件都可以发布和监听事件，或者发送消息和订阅消息。当事件发布时，监听者获得通知并进行处理；当消息发送后，订阅者将获得消息进行处理。通常用于解耦多个生产者和消费者。
- 共享数据模式：多个应用通过共享数据库来访问数据。实际微服务架构模式中，数据库通常只能被所属的微服务访问，而不能被其它微服务访问。
- 大泥球模式：构建一个聚合大应用，通常是为了尽快交付一次性使用系统，不考虑长远维护。
各个架构模式的详细讲解及所能达成的质量属性，可参阅： 《软件架构基础（影印版）》。
团队架构模式
- 专业协作模式：由不同的专业团队组成和协作，每个专业团队负责自己所负责技术领域的服务、工具、支持等。互联网企业里最常见的团队架构模式。比如开发、测试、产品、、DBA、运维团队等。
- 开源贡献模式：从质量和完整性角度审核其它人提交的组件和更改。
- 能力中心模式：CoC团队，为架构提供模式、技术、最佳用例、开发支持工具、培训等。
架构技能
确定关键架构需求（ASR）
显著影响架构设计的需求。主要有：约束、质量属性、影响大的功能需求。此外，需要考虑团队和组织架构的影响、法律政策相关的影响。
用约束限制设计选择
约束有业务约束、技术约束和法律政策文化上的约束等。约束确定后不能讨价还价，因此接受约束要慎重。适当约束可以简化问题，过度约束会增加设计难度。
定义质量属性
质量属性是架构需求中最主要要满足的需求，用来指导技术、结构、模式以及评估设计决策合理性。用场景描述质量属性，定义量化目标。
影响大的功能需求分类
比如入侵检测系统，规则管理、检测流程、告警列表与详情、响应阻断就是影响非常大的功能需求，需要着重考虑。
考虑团队和组织架构的影响
现代企业里，一般会分为前端团队、客户团队、服务团队、大数据团队、DBA（如果有的话）、测试团队、产品团队、运维团队。某一领域比较专业化的话，还会细分，比如存储模块团队、网络模块团队等。每个团队在内部又会根据具体业务来划分成不同的小组。比如 A 小组负责容器业务，B 小组负责主机业务等。做架构设计往往涉及到多个团队的协作，因此需要考虑架构实施如何分配到多个团队里。
建立架构模型
架构模式优点
- 构建设计词汇
- 关注重要细节
- 推演质量属性
- 展示架构构思
建立架构模式的方法
- 设计元模型
- 分离新概念
- 选择合适架构模式
- 保持一致性
- 好的命名
架构转为代码
- 统一使用架构词汇
- 组织代码突出架构
- 贯彻元素关系：模块结构、组件连接器结构、分配结构
- 添加代码注释
- 用代码生成模型
拿新入侵检测系统为例：
- 构建设计词汇、设计原模型的基础实践就是名词解释。比如新入侵检测系统中，定义了如下几个关键名词：元素、告警、事件、规则、评分、检测方式。整个系统围绕这几个名词展开，不乱增概念，不一词多义，也不多词一义混用。
- 何为分离新概念呢？ 比如告警和事件难以描述一次入侵行为的全貌。因为一次入侵行为往往表现为（但并不完全映射成）一系列关联的告警序列和元素关联关系。当告警和事件也不足以抽象一次入侵行为时，就需要新的概念来填补其中的空白。
- 选择合适的架构模式。通常是客户端经过一系列检测后上报数据给服务端，服务端进行检测（若有必要的话）、告警构建、存储、过白名单、发送大数据等流程。由于服务端很多检测流程都是通用的，因此可以采用组件编排的方式来构建服务端流程，保证服务端流程的可复用性和可扩展性。组件编排，比较类似于管道和过滤器模式。而在系统中还存在着各种事件及变更处理，则适合于采用订阅推送模式。
- 组织代码突出架构，好的命名。比如采用组件编排的方式，那么就有 components 的包结构，将所有检测相关组件都放在这个包下。采用策略模式，则有 XXXStrategy 命名；采用装饰器模式，则有 XXXDecorator 命名；构建器，则有 XXXBuilder 命名。
- 推演质量属性。这个非常关键。因为质量属性是架构设计的重点目标。参考 《服务端代码质量概要属性》，结合该系统的核心功能需求，来推演质量属性。
探索设计
够用的设计
- 将解决方案看成实验；
- 简化问题；
- 快速迭代学习；
- 同时考虑问题和解决方案。
设计策略
- 决定做多少前期设计。 1000w 大系统 37% ，1w 小系统 5%
- 风险作为导航。风险： 条件-影响-范围。
- 主动选择架构、根据系统监控被动设计。
- 制订设计计划：结束设计的条件、必要的设计成果、时间节点、重大风险、概念架构设计。
沟通与交谈
- 利益相关方关系图。
- 记录业务目标： 主体-业务目标-背景。
- 换位思考。
探索方案
【书中有实操指南，需要团队集体创作，还没怎么实践】
- 分而治之
- 概念图
- 组件-功能-协作者卡片
- 架构演变记录
- 白板涂鸦
- 循环设计
- 事件风暴
- 团队海报
展示设计
展示总体设计
- 用不同的视图展示展现架构：开发架构、业务架构、部署架构、数据架构等。
- 元素功能视图、粗略视图、精细视图、质量属性视图、映射视图、自定义视图
- 绘制出色的图表：使用图例、突出模式、简洁一致、描述性文字
展示总体设计常用的图
- 系统全景图。采用分层视图，展示系统的基础组件层、业务底座层、核心业务能力层、系统模块与依赖模块层、具体产品层。
- 系统模块图。展示了构成系统的各个模块及模块之间的关联关系。比如数据依赖（信息、配置等）、控制依赖（开关下发等）、服务依赖（文件服务、引擎检测等）等。
- 数据流图。 展示一个核心功能里，数据如何从源端流转到各个模块或组件，最终抵达目的端。
- 系统部署图。展示了构成系统的各个组件的服务器部署、通信端口及连接方式（别人画的）。这里的组件通常指微服务、存储组件与中间件。
- C4 图。主要是练习了 C4 图的绘制。包括：系统与用户上下文交互、技术选型图、开发导航图、组件图、某个组件的具体内部图。
重在实践！限于内部技术方案敏感性，这里不公开了。网络上有很多优秀开源系统的架构图，可以仔细揣摩研究哈。
展示设计决策的常用方法
- 架构主旨：用一页文档将系统的所有架构决策精华全部囊括在内。相当于系统架构首页。
- 架构决策记录（ADR）：用多页文档或卡片记录关于系统的一系列主要决策及背景、依据、状态等。
- 精选阅读列表：用一个表格展示关于系统的一系列重要技术问题及方案文档。
- 系统模块交互图：见上述系统模块图。
- 制作原型：在构建一个中大型系统之前，先做一个原型，验证基本想法是可行的。比如在大规模迁移老的入侵检测能力到公司新技术架构上之前，先做一个原型，验证一个主要功能是可以迁移并成功运行的。
- 时序图： 开发常用，用于技术方案文档中。
- 系统隐喻： 用一个易懂的故事或寓言来讲解系统的架构设计及影响。需要会讲故事。主要是讲给非技术人员听的。
- 未采纳的决策：记录未采纳的决策及缘由，避免后续维护的人做重复无用功。
评估设计
评估设计方案的常用方法
- 架构简报
- 决策矩阵
- 场景走查
- 测量和监控
- 问题、评论、关注事项
- 风险风暴
- 合理性检查
- 代码审查
架构师与团队
提升团队架构技能
- 提倡架构思维
- 传授技能、辅助决策
- 创建实践机会（结对设计、搭建支架、引入架构导轨、交流会）
- 设计授权
- 共同设计架构
设计授权的七个层次
- 告知。自己做设计决策，告诉团队结果。
- 贯彻。自己做设计决策，说明设计依据缘由。
- 咨询。 咨询团队意见，自己做设计决策。
- 商定。 与团队合作，达成共识。平等话语权。
- 建议。 通过观点、见解影响团队，由团队成员做设计决策。
- 审查。 由团队做决策，并由他们解释为什么这么做。
- 委托。 委托团队成员做决策，并由他负全责。作为辅助，帮助收集信息。