画布 1
架构师
  架构内容
    关键词
      高并发
        TPS
        QPS
      高可用
        弹性计算
          SOFAMesh
        极致性能
          Oceanbase
        限流/流量整形
          Noah
        灾备
        同步
        削峰填谷
      快速变更
        CICD
          DevOps
        容器化
        轻量级框架
      可扩展性
        推翻？
          成本
          关系架构
      安全性
        DDos
        示例
          Amazon
            2.3TB/s
          Github
            1.35TB/s
        产品
          阿里云SCDN
        内部访问控制
          鉴权
          审计
      成本控制
        直接成本
          弹性计算
        间接成本 ＆ 业务效率
    架构设计坑点
      追寻大公司方案
        考虑方向
          团队
            团队技术能力
            运维能力
          业务体量
            高并发
            高可用
        选择经济适用方案
          快速试错
          投入资源
          团队能力
        看待方案
          云平台
            低配版本
          借鉴指导
          技术储备
      技术方案，喜新厌旧
        优势
          近期远期优势
          业务效率
          技术债务
        成本
          成本投入
          效益产出
      不要脱离实践
        解释
          理论来源于实践
          纸上得来终觉浅
        示例
          微内核架构
          响应式的服务架构
          应用内分层
      高谈阔论
        落地
          短中长期规划
          上下游业务依赖梳理
          集团资源需求
          团队配置
          招聘计划
          业务目标、验收标准
          上线后业务开展
        总结
          蓝图
            短
            中
            长期
          交付节点、节奏
            效果定义
          资源计划
      博而不精
        项目经验
          知识广度
            会用
            用过
            解决了什么问题
        难点攻坚
          知识深度
            难点
            解决
            特点
            底层
            替代
            一问到底
      技术至上
        严重偏科
        全面发展
          技术实力
          软实力
      看完就忘
    面试
      大型应用中架构设计的考量点
        高可用、吞吐量、扩展性、快速变更、成本平衡和安全性要素
        控制2分钟
        大局观
  架构师
    什么是架构师
      能力
        业务场景化能力
        快速扩展
        降低业务成本
        核心
          技术服务业务
      特征
        能力
          单兵突破
            POC & Hands on
          技术能力
            知识迁移
        业务
          跨界能力
          产品业务
          具体
            业务模式
            新业务点
            业务效率
        大局观
        面向未来架构
          技术
          生态路线
        个人能力扩展，扩张影响力
          利益共同体
          折中
      三位一体
        技术人员
          知识𨑳移
          源码思想
          技术面
        产品经理
          懂业务
          精研业务
          转变视角
          无中生有
        项目经理
          软实力
          聚光灯
          落地能力
      面试
        职业生涯规划的问题
          初期强调技术路线
            不要好高骛远
          远期转管理路线、培养软实力
            目标不错，接下来2-3年如何付诸行动
            业务重要性
              技术调研
              产品熊力
              大局观
              影响力的构建
    架构师如何精进
      缺少哪些特质
        沉淀总结能力
          固化经验
          思路方法
          多走半步
          分享传播
        走进业务
          转变业务思维
          闭门造车
          讲人话
        默默无闻
          影响力传播
          表达想法
          向上管理
          学会拒绝
      技术人员偏执的本性
        提防
          情怀
          快速响应
        用性价比高的方案
      具体怎么做
        业务驱动技术
          还有什么没有被挖掘的需求
          如何通过技术手段提高业务效率
          解决人工成本->Automation
          思考作为程序员以外的职责
        走到聚光灯下
          跳出舒适区
            积极跑位才有机会
          主动承担
            主动承担一个项目，为结果负责
          表达想法
            没有想法？还是想的太少
        会思考有勇气
          智勇双全
      面试
        你的什么特质使你从一个团队中脱颖而出
          1. 避免不必要的错误：架构师的误入岐途（概括1.5分钟，视情况再站考）
          2. 取长补短一节中提到的
          软硬实力+业务能力
    架构师养成
      二转路线
        应用域架构师
          职责领域
            技术底子+大局观
              跨应用
              广度+深度
              懂业务
              业务抽象能力
            团队架构
              开发组长
          技术面
            强技术导向
              主流技术栈
                深度
                广度
              可行性验证
                POC
              技术选型
              技术敏感度
                技术趋势
                源码阅读
                  理念
                  素材
            应用内、跨应用
组件化与模块化结构
              业务抽象
              数据组构
              服务划分
              对外接口
          业务面
            理解业务
              从用户角度
            需求分析与拆解
              业务理解层次
            持续反馈
              业务方
              技术团队
        业务架构师
          懂业务的架构师最值钱
          业务领域架构师
            业务建模
              业务抽象
              领域建模
              生命周期
                状态机
              工作流
            特定领域
              支付领域
                Enroll登记卡号
                收单
                对账
                  会计
                  分账
                  例子
                    物流
                    关税
                      国税
                      地
                    增值
                    优惠
                    折扣
                    服务费
                    手续费
                Settlement清账
                生命周期
                  Auth
                    鉴权
                  Capture
                    扣款
                  Refund
                    退款
                  Void
                    回退
                  transfer
                    转账
                具体做
                  每一个流程非常清楚
              银行系统
              营销域
                玩法
                  满减
                  满折
                  满赠
                  送券
                  送积分
                范围
                  单用户
                  单门店
                  跨店
                  全站
                  商品范围
                透出
                  定义
                    把关键信息透传到前端页面
                  主搜
                  详情页
                  购物车
                  下单页
                计算核销
                  优先级
                  叠加券
                  最大优惠
              商品域
            扩展性
              技术领域
              大厂
                技术方案最佳实践
          解决方案架构师
            真的脱离了写代码的低级趣味
            特点
              行业资深顾问
                实施顾问
                  SAP
                  Oracle
                咨询公司
                  麦肯锡
                  埃森哲等
                解决方案
              丰富的实施经验
              业务最佳实践
                着重需求分析
              项目规划落地方案
        系统/企业架构师
          可执行层面
            企业
            事业群
            跨业务系统
          宏观层面
            路线图
            技术演进
            生态、中台
          落地层面
            业务执行
            非业务
          核心
            快速试错
            从宏观露情怀
            从实际落地
        面试
          个人职业生涯规划
            架构师方向是一个几乎不会出错的答案
          对架构师能力模型的认识
            理解业务
              需求分析与拆解
              业务对接
              领域治理
            单兵能力（深度+广度）
              技术选型
              有码在手
              组件和模块化结构
      架构视野提升
        大厂案例解读一技术路线和演进规划
          业界
            H5变革
              原生
                Apple
                  iOS
                Google
                  Android
              如何看哪些是H5
            微服务化趋势
              测试自动化
（测试开发）
              持续集成
快速迭代CICD
              敏捷实践
              扁平化团队
              弹性计算
分段降级
              核心思想
                分而治之
                结合
                  系统复杂度
                  用户基数
            胖瘦客户端演进
              后端
                PHP
                JSP
                ASP
              胖客户端
              瘦客户端
                特点
                  降低服务器压力
                  降低流量、带宽
                前端/浏览器
                  增加客户端表现力
                  提高用户体验
                云主机
            Go语言兴起
              简洁
              并行
              快速
              安全
          技术生态的思考
大厂如何利用技术制造技术壁垒
            业务中心
              降低业务成本
              小程序路线
                由外向内
            技术中台
              打磨中间件黑科技
                示例
                  HSF
                    淘系服务器治理
                  Open Search
                  Oceanbase
                  PTS性能测试
                  Aone云效
                  RocketMQ
                    消息组件
                  Diamond/Switch
                    配置平台
配置管理中心
                  Memchache
                    缓存
                  鹰眼
                    链路追踪
                技术平台输出路径
                  由内到外
              疯狂造轮子
                资源浪费
                优胜劣汰，倒逼进步
            面试
              所在行业的技术发展趋势/业务发展趋势
                BAT管理岗喜欢问：开放平台是BAT的战略方向
                中台化的看法
                  肯定公司的业务方向
                  借鉴行业第一的经验来回答
        如何推进架构方案的执行和落地
          优先级
            识别重点
            主链路
              p0
              p1
          时间表
            项目交付节奏
              里程碑
              独立测试
          协调能力
            当面聊
            资源
              共同利益
            具体方法
              有打法
              厚脸皮
            鸡汤
              大多情况下，你只能跟直属领导站队
              从职业发展角度，跟好业务不如跟熟人领导
              眼界放宽，技术能力不是决定性因素
        一线大厂的技术生态拓张案例
          拆解技术瓶颈
            三段论
              发现问题
              解题思路
              药到病除
            以分布式事务为例
              三段论如何应用在实践当中
              双引擎回归测试框架的构建
          大厂案例-天猫线迈巴赫团队之殇
            面对
              中国特色主义电商
                QPS
                TPS
              复杂业务扩展
            早期
              满减
              满折
              满送
                积分
                商品
              优惠券
              核销
                背包
                拆单
                退单
            失败原因
              回归复杂
                牵一发动全身
              自动化率低
                依赖手工测试
              节奏紧
                倒排期
            解决方案
              所有架构问题都是从大到小的问题
                深陷细节
              抽象能力
                举重若轻
                顶层设计
                一看就懂
              问题域界定
                角色
                边界
                功能
              分层构建解决方案
细节控
                实现方式
                技术细节
                一个不漏
            具体设计
              全局分布式事务
                一个错误全部回滚
                角色
                  全局事务
                    TC
                      角色：协调器
                      边界：中心化
                      功能：全局事务协调
                  分支事务
                    TM
                      角色：事务发起者
                      边界：链路起点
                      功能：发起全局事务
                    RM
                      角色：分支资源管理：
                      边界：各个分支
                      功能：注册分支事务提交回滚
              解决方案
                以大化小
                  测试样本构建
                  前后比对
                    无人力介入
                职责领域划分
                  角色
                    部署
                      角色：新代码部署机
                      边界：线上影子机
                      功能：执行真实流量跑出结果
                    数据工厂
                      角色：采样器
                      边界：线上服务/网关
                      功能：Copy线上％流量
                  前后比对
                    数据比对
                      角色：Response比对器
                      边界：数据工厂
                      功能：比对线上结果和金丝雀结果的不同
                分层构建细化方案
          心态建立
            示例
              请你今年写一本技术书籍
              如果今年要出本书籍，你应该做些什么准备
            惰性 = 本性
              被动式转主动式
            元芳的困惑
              架构问题如何看？
              主动思考
                这个问题可以从三个方面来看
          面试
            讲一讲你在项目当中碰到的难题
              错误答案
                我技术能力强，没碰到有挑战的
                吹牛B，项目Low爆
              强技术导向、不要讲推进时候的困难
            你是怎么解决他的
              有思考有打法：三段论
              业务背景一技术痛点-拆解问题以大化小
              学到了什么
      围绕业务做架构案例
        技术助力业务的方向
          让业务赚钱
            开源
              运营
                获客
                玩法
              技术
                新业务开发
            节流
              技术手段
              降低业务成本
          食物链
            业务规划
              需求
                运营团队
                业务团队
                产品团队
            技术团队
        案例分析一如何培养技术团队的业务素质
          阿里系绩效Top1业务部门
            新零食
              内容
                采购
                质检
                前场卖场
                分拣打包
                补货计划
                后场仓
                物流履约
                线上业务
              本质
                线上+门店
            问题
              闭门造车
                VS
                  持续反馈
              技术至上
                vs
                  贴近业务
          多管齐下
            门店轮岗
              技术部门
              线下门店
              作用
                贴近一线业务
                用户思维
            店长培训
              资深零售行业从业者
              每月一次定期授课
                行业思考
                发展方向
                一线业务
                IT需求
            人人都是用户
              用户视角看问题
        围绕业务特征构建技术路线
          阿里系中台服务治理的缘起
          思考问题：抖音视频审核业务
        业务外包与采购的权衡
          三要素
          阿里系业务供应链系统发展历史
        利用技术手段提升业务效率
        面试
          谈一谈职业发展 一基础平台类？Or业务类
            10年前：到技术强的部门去（情怀）
            现在：到业务复杂的部门（现实）
          聊一聊具体项目
            业务为先一先让面试官明白你的业务
            技术主线一为什么选用这个技术？和业务的关系
            想象空间-未来的改进点，业务量double架构方案？
      技术发展线路图
        如何规划短中长期技术路线图
          短期
            强业务驱动
            多短
              1-4周
            特点
              业务驱动
                业务团队主导
              优先级
                p0
          中期
            承上启下
              向上拆解长期计划
              向下输送短期计划
            业务+技术驱动
              腰部力量
                调结构促增长
              容量，稳定性
                双11压测
          远期
            面向未来
            技术面
              中台化
              内外部技术生态
              底层技术框架
            长期业务发展方向
              新业务
              业务效率
        如何规划面向未来的架构
          目标
            业务
            稳定性
            成本
          容量规划
            目前的情况
              日常应用水位
              历史峰值
              99.9%压测
              QPS VS RT
            未来
              未来业务容量
              稳定性基线
              余量规划
              主链路规划
          底层技术趋势
            大厂实践 强指导意义
            后端主流技术趋势
              既定标准
              特点
                快速复制
                  容器编排
                分治理论
                  MVC-> 萌芽
                  微服务-＞ 深化
                轻量级
                  易接入
                  易使用
                  易替换
        如何调整路线图执行过程中的偏差
          竞对业务和市场
          技术层面
            主线
              技术栈
              替代方案
              云维成本
            支线
              PlanB
          内部审查
            周期
              月度
              季度
              半年度
            上务目标
            容量目标
            移完性
        糙快猛之下的敏捷开发
          Scrum
            研发主管
            研发经理
            产品经理
            码畜
          跟着项目走
            规划
            业务验收
        面试
          团队管理岗＆架构岗快节奏的项目迭代下，如何把控交付节奏&项目规划
            短期规划一强业务需求
            中期规划一业务需求+业务量支撑一稳定性规划、双11
            长期规划一技术反哺业务
          探讨当前业务的发展超势，你的看法
            蚂蚁一支付行业的国内、国外机会
            头条一短视频行业的几种业务模式，在线教育行业的爆发
  架构设计
    什么是架构设计
      架构设计定义
        组成派
        决策分析派
      软件架构发展
        原先
          语言
            C
            JAVA
            Python
            Go
          结构设计
            数据结构
            设计模式
            算法
          统一建模
            UML
            CBM
        如今
          多视角
            逻辑
            物理
            应用
            技术
            功能
            部署
          体系框架
            ABSD
            DSSA
            AT
        未来
          云化
            Iaas
            Paas
            Saas
          演进式架构
            业务：跟随业务发展、扫清技术债务
            架构：架构向前演进、向后兼容
            技术：技术成熟度、复杂度、买还是建
      软件架构的意义
        SWOT
          Strengths
            优势
          Weaknesses
            劣势
          Opportunities
            机会
          Opportunities
            威胁
          具体
            RASCI决策矩阵
              定义组织中各个角色在项目、流程、任务等中所扮演的角色和职责的工具
              R-执行人；A-负责人；
              S-支持者；C-顾问;I-知情人
            ADMEMS方法论
              定义任务或项目：首先需要清晰地定义每个任务或项目的目标、范围、时间和预算等关键要素，以便后续进行评估和排序。
              评估任务或项目：使用ADMEMS矩阵中的五个维度（紧急性、重要性、规模、技能和风险）对每个任务或项目进行评估，以确定其在不同维度上的表现。
                ADMEMS矩阵
              分类任务或项目：根据ADMEMS矩阵中四个象限的定义，将每个任务或项目分类为A、D、M或E类。
              确定优先级：根据任务或项目的分类和重要性，确定其优先级和资源分配方案。例如，将高优先级的任务或项目放在更高的优先级，分配更多的资源等。
              监控和调整：定期监控任务或项目的进展和表现，并根据需要进行调整和重新分配资源。
        交流的可能问题
          语境不同
          立场不同
          渠道失真
        架构演进的模式
          拆迁者模式
          绞杀者模式
          修缮者模式
        测试驱动架构
          原子vs整体适应度函数
          触发式vs持续式适应度函数
          静态vs动态适应度函数
          自动vs手动适应度函数
          临时vs预设适应度函数
        架构师的思考
          如何解决环境问题：开发、QA和生产的不匹配
          如何解决耦合问题：凤凰项目和传统系统耦合
          如何决绝资源共用问题：关键人员疲于在多项目中切换
          如何满足峰值需求：突发性业务需求、性能测试需求
          如何解决安全问题：最小代价完成安全合规审计
      架构特性
        可复用
          方法论复用（ABSD、 DSSA、 AT、 EA、 TOGAF)
          模型复用(UML、 SOA、 CBM
          工件复用（素材、图片、表格、图标、文件）
          剪裁（三七原则，保留30%还是70%
          架构资产更新（内部资产库、外部架构社区）
      架构认证
        OpenGroup架构认证
          类型
            TOGAF企业架构（广度、知识点、案例分析、笔试）
            Master Architect 主架构师认证（应用架构、数据架构、集成架构、技术架构）
          过程
            三个完整方法论案例（需求、设计、风险、决策、结果）
            20+架构师评测点（各2-3个案例论证）
            评测重点：方法论、模型的复用，架构资产的贡献
        高级信息系统项目管理师
      软件架构风格
        数据流风格
          批处理
          管理
        调用返回风格
          主程序-子程序
          面向对象
          层次结构
        独立构件
          进程通信
          事件驱动
        虚拟机
          解释器
          基于规则
        仓库风格
          数据库
          超文本系统
          黑板
      方法论
        ABSD架构方法论
          体系结构6大过程
            架构需求
            架构设计
            架构文档化
            架构复审
            架构实现
            架构演化
          强调将系统设计和构建分为多个层次，并在每个层次上使用属性进行描述和优化
          场景
            一种用于设计和构建分布式系统的方法
        DSSA方法论
          面向特定领域的软件架构设计方法
          步骤
            领域建模：使用领域建模技术对特定领域进行建模，以便深入了解业务需求和问题。
            架构设计：根据领域建模结果，确定系统的基本架构和设计模式，并建立一个面向特定领域的架构模板。
            设计模式：基于特定领域的架构模板，选择适合该领域的设计模式，以满足特定领域的需求和问题。
            架构评估：对所设计的架构进行评估和优化，以确保其满足特定领域的需求和问题。
            架构实现和部署：根据所设计的架构，实现并部署系统，并对其进行监控和管理。
        AT方法论
          定义
            AT方法论（Architectural Thinking）是一种面向架构师的方法论，其主要目的是通过在软件开发的早期阶段考虑和优化软件架构，以提高软件系统的质量和可维护性。
          内容
            需求分析：AT方法论强调在架构设计的初期，应该从需求的角度出发，了解用户的需求和期望，并将这些需求转化为可测试的架构需求。
            架构设计：AT方法论强调在架构设计中，应该考虑软件系统的可扩展性、可维护性、可靠性、安全性等方面的问题，并在架构设计中应用设计模式和最佳实践。
            架构评估和演进：AT方法论强调需要对架构进行评估和演进，以确保架构的合理性和可行性，并在架构演进的过程中持续优化和改进。
            文档和沟通：AT方法论强调需要建立清晰的架构文档，并与团队成员和利益相关者进行良好的沟通，以确保团队成员之间的协同工作和沟通。
          维度
            业务
            应用
            数据
            技术
    设计架构
      原则
        六大派
          单一职责原则（Single Responsibility Principle, SRP）
          开放封闭原则（Open-Closed Principle, OCP）
            对扩展开放
            对修改关闭
          里氏替换原则（Liskov Substitution Principle, LSP）
          接口隔离原则（Interface Segregation Principle, ISP）
          依赖倒置原则（Dependency Inversion Principle, DIP）
          迪米特法则（Law of Demeter, LoD）或最少知识原则（Least Knowledge Principle, LKP）
        组合与聚合复用原则
          Design Pattern 书
          组合与聚合 优先 代码继承
        局部并发原则
        高可用系统设计原则
          降级
            主动
              开关推送
                配置中心
              多级降级
            被动
              超时降级
              异常降级
              失败率
              熔断保护
          限流
            网关层
              nginx
                Limit模块
              Gateway
                Redis+Lua
            业务层
              本地限流
                Guava
              分布式限流
                Sentinel
            恶意IP
            识别DDos
          弹性计算
            示例
              下单场景
                主搜
                  全文检索
                  优惠透出
                详情
                  用户评论
                  优惠信息
                  客服通道
                购物车
                  收藏夹
                  底部推荐
                下单
              全链路进行弹性
                k8s+Docker
          流量切换
            多机房环境
            方法
              DNS端
                客户端切换
              虚拟IP
                HaProxy
                LVS负载均衡
              应用层
                Nginx+服务网关
          回滚
            版本控制
              配置中心
              CICD Pipeline
        轻量架构
          DRY
            Don't Repeat Yourself
          KISS
            Keep it simple and stupid
            框架层面
              无感知
              接入成本
              0/极少配置
              Clean Code
          YAGNI
            Your Ain't Gonna Need it
              过度设计
            示例
              分布式事务
              数据异构
              规则引擎
              Graph QL
      框架层面发展趋势
        设计范式
          约定大于设计
        实现
          定制化
            隐藏共性，突出个性
          默认值
      微软推荐
        数据访问层
        业务逻辑层
        UI层
      服务拆分
        压力模型
          高频高并发流量
            商品详情页
            优惠计算
          低频突发流量
            秒杀
            批量上架
        服务隔离
        主链路规划
    衡量架构设计
      清晰的定义和概念
        系统边界
          系统/领域
          子系统/子域
          微服务
          聚合
          实体
          值
        内聚
          功能内聚
          顺序内聚
          通信内聚
          过程内聚
          时间内聚
          逻辑内聚
          偶然内聚
        耦合
          非直接耦合
          数据耦合
          标记耦合
          控制耦合
          外部耦合
          公共耦合
          内容耦合
      探讨高内聚、低耦合的实现和避坑指南
        耦合关注点
          一个模块对另一个模块的调用
          一个模块向另一个模块传递的数据量
          一个模块施加到另一个模块的控制的多少
          模块之间接口的复杂程度
        低耦合原则
          多用接口隐藏实现的细节
          遵循一个定义只在一个地方出现
          少使用全局变量
          少用public，多用private关键字
          多用设计模式
          避免直接用SQL语句操作数据库
          避免直接操作或调用其它模块或类（内容耦合）
          尽量使用数据耦合，少用控制耦合
          限制公共耦合的范围
        高内聚
          模块的功能划分尽可能的单一（单一职责原则）
          模块只对外暴露最小限度的接口（接口隔离原则，
          一切向功能内聚靠拢，杜绝偶然内聚
      分析扩展性架构，探究三维扩展立方体
        CMMI软件成熟模型
        SMART原则
      分析高性能架构，探究三大实现和妥协机制
        多、快
          多：分布式架构设计、横向扩展
          应用：无状态、容器化、Serverless无服务器化
          数据：多副本、读写分离、冷热分离
          快：X轴无脑克隆和复制
          中间件：缓存、最终一致性
          工具：SQL CDC技术
        好
          好：Y轴服务和数据分割
            微服务
          服务拆分、界限上下文交互
            DDD领域设计
          服务发现、服务治理、负载均衡、服务追踪
        省
          省：Z轴哈希取模特征分割
          应用：负载均衡（客户端Ribbon；服务端 Nginx、 K8S Service；中间件ESB、 API Gateway
          数据：分布式多片架构、分库分表（客户端sharding-jdbc、数据库Spanner；中间件MyCat. Aurora)
      分析高可用架构，探究本地高可以用、异地容灾、多活方案
        高性能
          案例
            天猫
              54.5万TPS
            eBay支付
              100万TPS
            EOS区块链
              100万TPS
          概念
            TPS
              并发数/平均响应时间
            QPS
              每秒查询率
                每秒能够相应的查询次数
          延迟
            CPU->内存->磁盘->网络跨地
          大厂业务体量
            数据量：单库（数亿条记录，数百GB数据），主库（数百亿记录，数十TB数据）
            并发：数亿在线用户、数干万活跃用户、数十数百万并发请求
            交易量：平时（数万TPS，数十万QPS），交易峰值（数十万TPS，数百万QPS）
          性能参数
            交易业务：QPS、TPS、响应延时、 出错率
            流业务：吞吐量(1GB/s=8Gbps）、处理窗口、滞后时间
            系统：CPU、内存、存储、网络
        高并发
          容量规划
            目标设定：业务指标（UV、 PV、交易量），系统目标(CPU内存、网络、磁盘），应用目标(TPS、 QPS、 Session、并发数）
            规划方法：容量评估方法（基线、水位）
            实战：压测、监控和预测
          性能测试
            负载测试
              测试目标：正常运行压力下的响应时间、资源利用率、稳定性
              测试手段：标准（历史为基），环境(QA、准生产、生产），定义（测试案例），执行（自动化），分析（统计），报告（录入），迭代（反复）
              测试核心思想：测试是个长期的过程
            压力测试
              测试目标：发现系统的拐点（失效点）、远高于正常负载
              测试手段：目标，关键服务（关键业务、负载测试瓶颈），负载（大量测试数据），环境（减少差异），监视，执行，分析（录入）
              测试核心思想：关注拐点 -服务行为、响应时间、CPU内存磁盘利用率、线程、SQL、交易失败率
            APM监控
              性能监控
                时序数据，纬度聚合，性能指标，报表告警
              链路监控
                TracelD、 SpanID、 DyeD，出错归因，延时瓶颈
              业务追踪
                业务、应用、系统关联，告警去重
        落地方案
          缓存方案
            读vs 写
            Cache vs Buffer
            哪些缓存
              网络缓存
              应用缓存
              对象缓存
            方案
              架构方案
          异步方案
            意义
              减少等待：磁盘、SQL、 API、 URL
              Y轴扩展：微服务解耦、Y轴扩展更随意
                Z
                  分割请求者和客户
                  对于业务透明
                  提供优先级服务
                  提供就近服务
              削峰填谷：泊松分布、银行队列
                拿时间换空间
          分布式
            x轴扩展：吞吐能力和QPS明显提升
            Y轴扩展：出错率明显降低
            Z轴扩展：延时降低、TPS/QPS明显提升
          妥协方案
            方案的不足
              缓存为王
                静态文件分布到各大IDC机房
                配置缓存
              异步
                通信压力
                消息队列
              分布式
                机房
                网络
              上面的方案，开销大
            排队方案
              漏桶
              令牌桶
            丢卒保车
              熔断
              降级一拆东墙补西墙
            具体方案
              防刷、减压
                验证码
              排队、整流
                当前排队显示
          阿里方案
            缓存为王
              Akamai
              OpenResty
                nginx变种
              Ehcache
              Terracotta
              CouchBase
                后端服务缓存
            异步为帅
              Kafka
                流式
              ActiveMQ
            分布式
              Solr
              Hadoop
        高可用
          本地高可用
            消除单点故障，确保链路所有环节系统高可用
            核心
              定位：”本地〞，针对生产中心的内部故障
              故障类型：服务器、硬盘、适配器卡、网络
              特点：快速的恢复、自动的接管、实施简单、 RPO~0
            CAP理论
              一致性
              可用性
              分区容错
            集群架构
              应用集群：Unix( PowerHA)、 LinuxRedHat ClusterSuite）、第三方(Veritas Cluster Server’
              中间件集群：WebLogic. WebSphere
              数据集群：Oracle RAC、 DB2 pureScale、 GeneralParallel File System、 磁盘RAID整列
            分布式架构
              分布式应用
              分布式中间件
              分布式数据库
          业务逻辑保护
            防止删库跑路，减少人员、流程、软件对可用性的影响
            核心
              定位：针对致命的软件错误或人工失误的保护
              故障类型：操作系统、数据库、应用、服务
              特点：数据保护为主、人工决策、人工干预、人工追溯
            影响因素
              计划事件：85%
                维修，迁移，备份恢复，新系统上线，现有系统升级等
                装备更新，旧系统下线等
              计划外非天然事件：~15%
                流程或人为错误-40%
                软件错误 -40%
                硬件故障（服务器，网络，存储等）-20%
              天然事件：<1%
                天然灾害
            保护三部曲
              第一防线：预防
                磁带数据备份
                快照数据备份
                严谨的应用与系统架构
                N与N-1版本共存
                彻底的变更审核
              第二防线：发现
                监控工具
                自动化脚本
                应用与系统正常行为描述
                应用与系统异常行为侦测
              第三防线：修复
                应用与系统回滚
                一键恢复
                自动恢复
                快速数据恢复
          容灾多活
            防治区域灾难、数据中心故障，实现多数据中心共赢
            核心
              定位：”异地〞，针对生产中心的机房或大面积设备故障
              故障类型：HA方案失效、主站点（基础架构）失效、自然灾害
              特点：恢复时间较长、手动切换负载、涉及内外多个部门容忍部分数据丢失、有必要制定灾难恢复计划
            异地多活
              同城多活
                用户所有的业务系统同时在同城的两个数据中心运行同时为用户提供服务，当某个数据中心的应用系统出现问题时，有另一个数据中心的应用来持续的提供服务。好处是服务能力是双倍的，且对用户来说不可感知。
              网络多活
                将同一个网络扩展到多个数据中心，并且实现服务器和应用的虚拟化数据中心互联技术：随着高可用远程集群技术以及虚拟机迁移技术在数据中心容灾以及计算资源调配方面的广泛应用，在数据中心间需要大二层网络连接。
              存储双活
                是一种独特的存储技术，使信息能在数据中心内部以及数据中心之间共享、存取或移动，从而将各种不同的存储系统联合成为单一资源。它允许位于地理上分离站点的存储系统同时进行数据存取，对客户透明，且保证了数据的可靠性和可用性。
              异地双活
                异地之间采用双活目前不够现实。因为尚无很好的技术能够实现远距离的实时数据同步。当两个站点距离超过100公里以上，数据同步只能采用数据异步的存储数据复制方式。
              数据库双活
                指两个数据库系统可以在相隔比较远的情况下同时运行、支持相同的应用负载，并且在一方出现故障时能够迅速切换到另一方（分钟级），保证业务高可用性。
              应用双活
                在应用处理层面上实现了完全冗余，交易通过负载均衡自动路由到不同的应用服务器，但是，数据库层面上还是依赖在某一个数据库。
      分析高安全性架构，实现流程和架构安全
      分析伸缩性架构，实现弹性扩缩容
        APM监控
        扩缩容决策引擎
          Auto Scale策略）
        资源管理（虚拟机、容器、 网络负载Serverless
    架构设计模式
      架构设计
        架构设计模式
          功能拆分
          迭代
        需求分析
          设计输入
            功能性
              who
              which
              what
              how
            限制
              基本三要素
                范围
                时间
                资源
              进阶三要素
                业务
                技术
                法规
            质量
              安全、稳定、方便
              并发
                QPS
                TPS
              性能
              发布
              ..
            资产和技术
          输出
            架构规划
              文档
              图
                甘特图
                  测试组
                  项目组
                  产品组
                  研发组
                燃尽图
            研发设计
              业务关系图
                内到外
              流程图
              数据库设计
                权限
              接口设计
            测试方案
              TDD
              测试规范
            部署方案
              物理架构
                服务器
                网络
                机房
                云平台
              非功能性
                容灾
                多活
                单元化
                CDN缓存
              发布流程
                应用
                数据
                网络
                CICD
            采购与外包
              RFP 招标需求
              POC 原型验证案例
              招标和产品决策
        架构验证
          清晰的边界
          系统验证
            JAD联合架构设计
            Architecture Review Board（架构审查委员会）
          商业验证
          用户验证
            单元测试、集成测试、系统测试、用户验收测试
          方法
            RAID
              风险
                •已知风险是否缓解或规避
                发现的新风险
              假设
                前提假设是否正确
                引入新的假设条件
              问题
                影响项目进展的问题
                影响产品验收的问题
              依赖
                业务和应用依赖
                IT技术依赖
      架构落地
        需求分析
          系统上下文图
            画出主要的用户、角色
            这些角色的关系
            独立的模块
              区分内部与外部
                这就是边界
          用例模型
            主要功能
            功能之间的关系
          质量和限制
            文档
            内容
              性能
              高可用
              扩展
              弹性伸缩
              资金
              项目时间
              企业问题
              监管要求
              ...
          需求驱动
            功能性需求
              功能性模型
                模块定义
                  如何定义？
                    高内聚
                    低耦合
                  整体架构草图AOD
                    垂直
                      子系统
                    横向
                      用户
                模块关系
                模块细化
                  输入：用例模型
                  中间过程：鲁棒图、实体关系ER图
                    时序图
                    流程图
                模块映射
                  参考产品
                  参考架构
            运行性模型
              质量
              限制
              运行性模型
                关注点
                  购与外包
                  软件包和产品选择
                  组织架构
                  服务治理
                  容量规划
                  系统监控
                  性能
                  可用性
                  安全性
                环节
                  单元拆解
                    展现单元
                    执行单元
                    数据单元
                    安装单元
                  架构转换
                    组件
                    指定位置
                    调整组合方案
                    功能到运行，应用到技术，逻辑到物理
                三张图
                  应用逻辑运行图
                  逻辑运行图
                  物理运行图
        架构设计方法
          应用&技术
            应用：Java、 Python应用代码实现的功能
            技术：支撑业务的基础架构（中间件、数据库、AAA等）
          功能&运行
            功能：Who、 HowWhat
            运行：Where、 When
          逻辑&物理
            逻辑：技术定型、产品未定型
            物理：产品定型
          示例
            商品中心/用户中心
              用户视角
            NoSQL/文档库
              技术视角
            CURD
              功能性视角
            分布式
              运行视角
            Springboot+MongoDB
              逻辑视角
            阿里云ASK+云数据库MongoDB
              物理视角
          误区
            只关注功能性需求、忽略非功能性需求
            微观设计、架构设计文档信息过度
            关注点分离，观点混杂
            过渡设计、冷门技术、不适合需求变更和架构迭代
            专注擅长的技术栈，忽略其他潜在选项
        工具
          图
            mac
              OminiGraffle
            windows
              Visio
            在线
              processOn
              draw.io
          如何绘制
            需求示例
              业务
                利用当今热点技术（分布式架构、NoSQL、对象存储技术等）
                建立一个数字化、网络化、自动化、高效率的节目制做、采、编、播、存、管、发布一体化系统
                打造一个全方位的音视频资料服务的业务平台
              技术
                收录系统、转码系统、迁移系统、检索系统等相关渠道的有效整合
                解决多媒体数据资料的数字化存储、编目管理、检索查询素材转码、资料发布等问题
                采用新的业务流取代已有工作模式和操作模式，从而满足各种新的业务需要
            上下文
              准备素材
              画关系
            用例
              具体的业务
              需求矩阵
                分类
                  功能
                  非功能
                描述
            写架构草图
              准备素材
              从业务出发
                从功能到运行
                  从逻辑到物理
            时序图
              模块关系
            流程图
              技术实现
              业务流转
            数据架构图
              ER图
            运行架构图
            技术架构图
        参考竞品
          项目加速
          避坑指南
          减少意见冲突