架构实战训练营总结
什么是软件架构？
软件架构指软件系统的顶层结构，它定义了系统由哪些角色组成，角色之间的关系和运作规则。即顶层结构（Rank）、组成角色(Role)、角色关系(Relation)、运作规则(Rule)。
架构图分类
系统按照业务划分就是业务架构图
系统按照领域架构划分，包括客户端、前端、后端
客户端和前端按照模块划分就是客户端架构图和前端架构图
后端按照模块、应用、组件划分就有系统/后端架构图、应用架构图、部署架构图
业务架构图描述的是系统对用户提供了什么功能。使用场景是产品人员规划业务、给领导汇报、给新员工培训使用。
客户端、前端、系统/后端架构图都是指的逻辑架构图。用于架构培训、整体架构设计中。
应用架构图描述的是后端系统由哪些应用组成，用于项目开发、测试、部署发布、子域架构设计。
部署架构描述的是后端系统如何部署。用于总体架构设计和运维规划和优化。
系统序列图是指系统之间配合完成一个功能逻辑的处理流程图，用于具体功能开发、调试等
架构设计方法论
面向模式 ：书籍《面向模式的软件架构》共 5 套丛书，对成熟的架构模式进行应用实践。
面向风险 ： 书籍《恰如其分的软件架构》《编程的逻辑》，根据系统风险大小来设计软件架构。
DDD ： 书籍《领域驱动设计-软件核心复杂性应对之道》《架构整洁之道》，是可扩展架构的设计技巧，它兼顾架构设计和方案设计，不关注存储和计算，只关注业务。微服务划分理论指导。
面向复杂度 ：由于软件系统规模不断增长，为了降低软件系统复杂程度，如降低系统的组织和结构方面的复杂度。
面向复杂度设计架构的步骤如下：
1、通过分析系统需求找到复杂的地方。复杂度来源主要有，系统质量要求（高性能、高可用、可扩展、安全、成本）和业务本身的复杂度
2、采用技术手段（分库分表、缓存、集群、分片、微服务、DDD、异地多活）降低复杂度。
3、通过架构设计原则指导我们做更好的架构设计，而不是可用的设计。
三个原则：
合适原则：宣言“合适由于业界领先”。 资源(有技术、有能力、有水平、有积累、有人和团队、是否开发和运维成本低) + 时间（足够的时间和精力） + 业务（合适业务需求），应用：满足业务需要、符合团队和技术的能力水平。
简单原则：宣言“简单优于复杂”。复杂度包含内部和外部复杂度，外部复杂对由于拆分过细导致的，复杂度高带来的问题，可靠性低、不易扩展，故障处理效率低。应用：先按照简单来设计架构，然后不断在实际应用过程中迭代优化。
演化原则：宣言“演化优于一步到位”。建筑和软件本质差异，静态和动态，固化的和演化的。1、设计满足现有业务需求，2、迭代优化（修、改、去、留），3、重构或重写。 应用：当业务发生变化时，扩展、重构或重写架构
它们的优先级：合适原则>简单原则>演化原则
原则常见判断维度：
业务： 当前量级、发展速度、发展形态
团队：团队规模、能力水平、投入的资源
技术：已有技术体系、当前技术能力、技术成熟度
如何设计可扩展架构？
可扩展定义：
系统适应变化的能力，包含可理解和可复用两部分，系统容易理解、容易复用。可理解用于判断哪些需要修改，可复用用于确定修改的范围。
如：系统适应变化能力强，就说明系统扩张性好主要体现在好理解、好复用，应拆分的办法来设计系统，拆分到合适大小就行，用封装的办法来设计或实现系统，预测可能的变化尽量封装，不确定的就不封装。
可伸缩定义：
系统通过添加更多资源来提升性能的能力
复杂度模型:
业务复杂度: 体现在难以理解,难以扩展. 如: 业务数量多,流程长,业务之间关系复杂
质量复杂度: 高可用\高性能\成本\安全
注意：ddd 战略设计关注的是可理解，战术设计关注的是可复用。
设计手段:
拆分：鸡蛋篮子理论第 1 法则，主要是让系统好可理解，用拆分手段将系统拆开，将一个大的化成多个小的。如分层，微服务、插件、package 等。拆分出来的大小会影响拆分出的数量，如何判断大小是否合适呢？需要从拆分出来的模块内部复杂度和模块之间的外部复杂度判断，判断原则有平衡、先粗后细，平衡原则需要拆分的人员来平衡，因为如果内部复杂度低了，外部复杂度必定升高，先粗后细指在把握不准时，先拆少一些，后面遇到问题再继续拆分。
扩展性的复杂度主要是平衡内部和外部复杂度，也是架构设计时需要重点分析的两方面。
封装：预测变化、封装变化，预测会影响如何封装变化。主要是让系统能可复用
预测变化：主要包含预测时间跨度和变化方式
1、预测 2 年内的变化，不要试图预测 10 年后的变化。
2、三次法则，预测没有把握就不要封装，等到需要的时候重构即可。
封装变化：
封装模型：1、规则引擎（美团 MazeGO） 2、微内核(OSGI)。3、抽象层(Linux VFS)。4、设计模式
架构设计时考虑是否需要封装变化，比如是否需要规则引擎、OSGI、抽象变化、设计模式
如何设计高性能架构?
单机高性能如何实现？
计算高性能：
考虑进程是多进程还是单进程多线程；
考虑网络模型用 reactor 还是 ppc；
考虑缓存用本地的还是独立的;
存储高性能：
考虑读，采用读性能好的数据结构，如 b+树;
考虑写，采用读或写性能好的数据结构，如 LSM 树；
用集群如何实现高性能？
任务分配，即将请求任务分配给一群或多个相同类型的服务器来处理。
任务分解，即将请求任务分解给不同类型的服务器来处理。
复杂度分析：
需要添加任务分配器或分解器，可用是独立服务器或者 SDK
分配器需要管理所有服务器，可以是配置文件或 Zookeeper
分配算法，如轮询、hash、随机等
分配器单点问题，需要考虑是否集群，如采用 SDK 则已经解决集群问题
分解器需要记录任务和服务器之间的映射关系
如何设计高可用架构?
注意：高可用必然是集群方案
如何实现系统高可用？
任务分配，即将请求任务分配给一群或多个相同类型的服务器来处理。
任务分解，避免不同业务相互影响。
复杂度分析：
1、任务分配和分解，都需要考虑服务器的状态检查，并且异常处理（切换）
2、其他复杂度与高性能复杂度一样
如何全面提升架构设计的质量？
成本：本质上是对架构的一种约束，与高性能、高可用冲突。
一般在互联网超大规模集群、2B 业务做低成本方案，比如 10000 台机器能节约 1000 台的方案；当在 1000 台服务器的系统中，可以考虑降低成本。
降低成本手段：
优化
1、引入缓存
2、虚拟化
3、采用高性能硬件（性价比高）
4、采用开源
创新
1、NoSQL vs SQL
2、SQL vs 倒排索引
3、Hadoop vs Mysql
4、Facebook HHVM
5、云计算/k83 弹性集群
注：先考虑架构方案，后考虑成本
安全
架构安全（防强盗）
网络隔离
浏览清洗
机房切换
注：一般靠运营商或防火墙，防火墙就是要网络隔离，防火墙检测入侵等
业务安全（防小偷）
业务漏洞 ->保底限制
安全漏洞 -> 安全框架 例如：OWASP
内鬼破坏 -> 权限管控 例如：Shiro,Spring Security
注：业务安全更多是编码和管理的措施
可测试： 可方便测试各种场景
例如：架构上的可测试性：全链路压测、可手动切换主备、触发选举
应用上的可测试性：可修改变量、状态可见、后台可以控制某个功能
可维护：支持定位问题、修复问题的能力
例如：架构上的可维护性：全链路跟踪、降级、下线、切换
应用上的可维护性：可修改变量、查看状态、管理控制某个功能
可观测：能展现系统内部状态
信息输出：打印日志、API、命令行
信息展现：运维平台、管理平台
上述的成本、安全、可测试性、可维护性、可观测性都在确定架构方案后再考虑。可测试、可维护、可观测一般放到一起考虑，没有先后顺序。一般在管理平台中做可测试和可维护，可观测在运维监控平台做。
架构师只需要写 PPT 么？
一、架构师的基本职责：核心职责是消除不确定性和降低复杂性
定位：业务和技术之间的桥梁
三个方面的关键能力： 判断，拆解、取舍, 综合能力要求很高
判断： 业务理解能力、技术能力、沟通能力
拆解：技术深度、宽度（后端中的 redis 或 memcache）、广度（前端和后端）
取舍：设计理念、说服能力、决断能力
三个方面的关键思维： 确定性思维（对应判断）、创造性思维（对应拆解）、系统性思维（对应取舍）
确定性思维：消除模糊、不确定的说法和信息，例如：大量用户 “应该明确”XX 万用户
创造性思维：通过排列组合创新，得到更多的方案
系统性思维：系统思考、有逻辑和推导过程
二、架构设计和方案设计
架构设计：影响系统结构的设计
方案设计：不影响系统结构的设计
主要按照 4R 架构去设计：
Rank：改变系统分层的设计属于架构设计，例如将支付宝提升到和淘宝同级别
Role：修改（增删改拆合）角色属于架构设计，例如微服务拆分
Relation：修改角色关系属于架构设计，例如用消息队列代替接口访问
Rule：修改角色之间的运作规则属于架构设计，例如 MongoDB 将选举算法从 Bully 改为 Raft
三、标准的架构设计流程
前期（跟相关人员开会）
主要任务：澄清不确定性（明确诉求、消除冲突）、明确复杂性
工作模式：与业务方、利益干系人交流
关键输出：总体业务架构图、核心场景流程图
中期（架构小组讨论、交流、写文档）
主要任务：设计备选方案、选择备选方案
工作模式：与架构小组讨论、交流；写文档；向利益人汇报
关键输出：备选方案、方案评估结论、方案汇报结论
后期（开会、开会宣讲）
主要任务：细化架构（按照 4R 架构来细化）、完善架构（可维护性、可测试性、可运维性、成本、安全）
工作模式：写架构设计文档、给技术团队宣讲
关键输出：完整架构设计方案
验证阶段（贯穿前中后期）
主要任务： 收集架构意见、跟进架构落地效果
工作模式：总结复盘、收集吐槽
关键输出：架构优化建议、迭代计划
四、架构设计团队
规模：精英团队，小而美
组织：主架构师，各个领域专家
运作：虚拟团队，项目制
决策：团队讨论，主架构师拍板
架构设计前期应该怎么做？
———分析利益干系人的诉求，然后排序优先级，澄清不确定性， 明确需要做的业务。最后识别复杂度
一、利益干系人分析
投资者
内部：指决定投入人力、物 力、财力开发系统的管理者。如:上级、业务负责人。 利益诉求：成本、时间、竞争力
外部： 指决定购买系统的 金主，适应于 2B 领域。如：各位老板。 利益诉求：价格、时间、竞争力
监管者
政府：按照法律法规对系统进行监管的 政府组织。如：消委会、银监会。利益诉求：合规、 处理投诉
媒体：对系统相关的事件进行广泛报道 的媒体。如：315 晚会、焦点访谈。利益诉求：消息披露、事件回应
使用者: 使用系统完成业务功能的人员或 者其它系统。如: 用户 、下游。 利益诉求：易用性 高可用
评估者: 对系统进行评估的人员或者其它 系统。如: 评测/测试团队、监控系统。利益诉求：可测试性、可维护性。
构件者：负责构建系统的人员，如开发团队、施工队。利益诉求：技术、复杂度、时间
维护者：负责维护系统的人员或其他系统，如：运维团队、IT 部门。利益诉求：可维护性、高可用
二、诉求优先级排序
诉求处理流程包括分组、排序、沟通
分组
时间(项目周期、交付时间)
成本(人力成本、硬件成本)
范围(必做、可做、尽量做)
质量（可维护、可测试、性能、安全、可用性、可维护性）
排序（包括差异性问题、冲突性问题）
取舍原则: 无法做到面面俱到，需要根据业务目标决定哪个优先
影响力原则: 按照影响力大小排序，监管者 > 投资者 > 评估者 > 使用者 > 构建者 > 维护者
沟通：
架构师单独找干系人私聊
有冲突的干系利益人在一起开会 pk，这中情况需要架构师发挥自己的影响力，向自己的意愿靠近。
架构设计中期应该怎么做？
设计备选方案、选择备选方案
什么是备选架构？
能够实现系统业务的一个初步方案
主要做以下 2 点：
确定架构模式【高性能、高可用、可扩展】
技术选型 【存储、负载均衡、分布式决策】
备选方案设计过程
头脑风暴：对可选技术进行排列组合，得到可能的方案
红线筛选：根据公司情况，明令禁止使用的或必须使用的技术进行筛选
4R 设计：确定角色、角色间关系、设计规则
备选方案设计技巧
数量：3-5 个最佳，小于 3 个方案，可能是思维狭隘，多余 5 个方案，会消耗时间和精力，并且方案之间差别不明显
差异性：方案之间有明显的差异
粒度：覆盖核心业务场景，无需全面细化
面对备选架构常见的困难我们应该做到多积累知识、记主关键性能指标、比较学校方案，优缺点分析。
备选方案的选择
从多个维度去评估形成一个环评表格，然后按照优先级别逐级赛选。
后期需要做什么、存储架构、微服务架构等等后续补充。。
业务级灾备架构设计
同城多中心架构
同城市双中心基本架构
关键特征：
一个城市，2 个机房 IDC，距离 50KB 以上
用高速光纤连接。
机房间网络延迟<2ms
本质：
可以当作逻辑机房，即可以当作一个机房来部署应用
可以应对机房级别的灾难
应用技巧：
拉多根高速光纤，比如：电信、移动、联通
同城三中心
几乎很少采用这种架构，因为成本高、收益低。
跨城多中心架构
跨城双中心基本架构
关键特征：
不同城市
光纤互联
本质：
一般不把跨城双中心当作一个逻辑机房
可以应对城市级别的故障
应用技巧：
用作用户分区，例如南北用户分区，提供就近接入
异地多活
跨城双中心落地方案 - 近邻城市，
近邻城市如沪杭、广深、京津、成渝
机房延时<10ms，可以当作同一逻辑机房
可以避免城市级灾难，但无法避免区域性灾难
可以做异地多活，但不能做用户分区
跨城双中心落地方案 - 远端城市，
2 个远端城市，如深圳和北京
机房延时>30ms，不适合作一个逻辑机房
可以避免城市和区域级别灾难
可以做异地多活、分区架构
跨城多中心
三中心， 巨头专用
可以做异地多活、分区、就近接入
还未添加个人签名 2020.02.19 加入
还未添加个人简介
评论