架构师相关职责：
架构师是业务和技术之间的桥梁，架构师不能只顾技术，不懂业务，架构师很容易两头不讨好
三个核心能力：
判断：1业务理解力2.技术能力3.沟通能力
拆解：1技术深度2.技术宽度3.技术广度
宽度与广度 不是一会事，你熟悉Redis跟memcache 是宽度，了解前端与运维是广度。
取舍：1设计理念2.说服能力3.决断能力
这块综合能力要求高，得有理有据，有能力有担当。
确定性思维：消除模糊、不确定的说法和信息，例如"大量用户"应该明确为"XX万用户"
创造性思维：通过排列组合创新，得到更多的方案。
系统性思维：系统思考，有逻辑和推导过程，例如"为什么不用Native而要用H5"
影响系统结构的设计是架构设计，方案设计不影响系统的架构设计。
Rank：改变系统分层的设计属于架构设计，例如将支付宝提升到和淘宝同级别
Role：修改（增删改拆合）角色属于架构设计，例如微服务拆分
Relation：修改角色关系属于架构设计，例如用消息队列代替接口访问
Rule：修改角色之间的运作规则属于架构设计，例如MongoDB将选举算法从Bully改为Raft
架构设计流程：
架构设计前期（开会）
主要任务：
澄清不确定性1.明确利益干系人的诉求；2. 消除冲突的诉求；3. 诉求优先级排序
识别复杂性1.识别核心场景；2.明确或者预估质量需求；3.识别复杂
工作模式：1.与业务方交流2.与利益干系人交流（就是相关人开会）
输出 ：1.总体业务架构图2.核心场景流程
架构设计中期：（架构小组开会和写架构设计文档）
主要任务：
设计备选方案1.头脑风暴；2. 筛选方案；3. 设计备选方案；
选择备选方案1.360度评估；2. 明确选择标准；3. 选择最终方案，并汇报
工作模式：1.架构小组讨论2.架构小组写文档3.向利益干系人汇报
输出：1.备选方案2.方案评估结论3 方案汇报结论
架构设计后期：写文档和开会宣讲！
主要任务：
细化架构：按照4R架构定义来细化架构
完善架构：可维护性、可测试性、可运维性、成本、安全
工作模式：1.写架构设计文档2.给技术团队宣讲架构
输出 ：完整的架构设计方案
架构验证阶段（贯穿项目全流程）
主要任务：
收集架构意见1.开发人员意见2.测试人员意见3.运维人员意见
跟进架构落地效果1.性能测试结果2.压力测试结果3.线上运维情况
工作模式：1.总结复盘2.收集吐槽
**输出：**架构优化建议、架构迭代计划
架构师工作评价，除了架构项目落地情况，相关人员的架构意见反馈也是老板考量因素。
架构师团队本身是小而美的。多数是虚拟团队项目制，没有职级汇报的。
后面是展开架构设计
架构设计前期如何开展工作？
包含：1理解架构设计常见利益干系人和诉求
2.掌握利益干系人诉求排序技巧
利益干系人分析
这个跟PM的很类似，毕竟有人的地方就有江湖。郭东白老师的顺应人性也是不同侧面来讲。
换位思考，从对方利益视角去考虑，才能寻求肯能的合作方案。
投资人：出钱的"爸爸"，【利益诉求】1.成本2.时间3.竞争力 例如：1.你的上级2.业务负责人
监管者：通常是法律要求的组织。利益诉求：合规，处理投诉。
构建着、维护者：开发、测试、运维、运营
使用者，评估者：用户、甲方等
诉求优先级排序
分组、排序、沟通
时间、成本、范围、质量这些也跟项目管理关注的类似。
取舍原则：无法做到面面俱到，需要根据业务目标决定哪个优先
按照影响力大小排序，监管者>投资者>评估者>使用者>构建者>维护者
差异性、冲突性 就需要做排序。差异性：安装影响力点对点沟通，谁权力大听谁的。
冲突性需要开会，一起讨论PK，老板来拍板。要发挥影响力，引导正确的方案，不是简单的听老板的。自己不管只等最后的结果，这个锅后面就得自己背。
复杂度分析
