架构设计核心维度
2021-11-24 15:22:54 0 举报AI智能生成
架构设计核心维度
作者其他创作
大纲/内容
本地高可用、逻辑保护、容灾、多活、妥协、流程
What
生产系统-架构设计的核心，高可用-生产系统的核心
Why
理论分析、案例分享（全称带飞）、面试实战
How
本章概述
清除单点故障，确保链路所有环节系统高可用
定位：本地，针对生产中心的内部故障
故障类型：服务器、硬盘、配置器网卡、网络
特点：快速恢复、自动接管、实施简单、RPO~0
核心实现
本地高可用
防止删库跑路，减少人员、流程、软件对可用性的影响
定位：针对致命的软件错误或人工失误保护
故障类型：操作系统、数据库、应用、服务
特点：数据保护为主、人工决策、人工干预、人工追数
业务逻辑保护
防治区域灾难、数据中心故障，实现多数据中心共赢
定位：异地，针对生产中心的机房或大面积设备故障
故障类型：HA方案失效、主站点（基础架构）失效、自然灾害
特点：恢复时间较长、手动切换负载、涉及内部多个部门、容忍部分数据丢失、有必要制定灾难恢复计划
容灾多活
保证业务连续性
可用性三叉戟
整体思想方法论
一致性C
可用性A
分区容错性P
应用集群：Unix（PowerHA）、Linux（RedHat Cluster Suite）、第三方（Veritas Cluster Server））
中间集群：WebLogic、WebSphere
数据集群：Oracle RAC、DB2 pureScale、General Parallel File System、磁盘RAID整列
集群架构
站点的主备同步
系统集成商主推架构案例
案例分析
采用高可用A和一致性C实现架构是集群架构
AP
分布式应用
分布式中间件
分布式数据库
一致性、脑裂、雪崩、击穿
如何实现存在很多问题
分布式系统设计
分布式架构
采用可用性A和分区容错P实现架构是分布式架构
CAP理论
维修、迁移、备份/恢复，新系统上线，现有系统升级等
装备更新，旧系统下线等
计划内事件：~85%
流程或认为错误-40%（最需要投资优化）
软件错误-40%（最需要投资优化）
硬件故障（服务器、网络、存储等）-20%
计划外非天然事件：~15%
天然灾害
天然事件：<1%
影响高可用的真正影响因素
磁带数据备份
快照数据备份
严谨的应用与系统架构
N与N-1版本共存
彻底的变更审核
第一道防线：预防
监控工具
自动化脚本
应用与系统正常行为描述
应用与系统异常行为侦测
第二道防线：发现
应用与系统回滚
一键恢复
自动恢复
快速数据恢复
第三道防线：修复
逻辑保护三部曲
备份
快照
快照由1~n，在每个时间都有备份随时可以恢复到某个时间
保证最小数据丢失
CDP连续数据保护
预防
事件溯源、逻辑恢复
修复
逻辑保护技术
生产虚拟带库
异地虚拟带库
电信运营商，远程备份去重
数据逻辑保护
用户所有的业务系统同时在同城的两个数据中心运行，同时为用户提供服务，当某个数据中心的应用系统出现问题时，有另一个数据中心的应用来持续的提供服务。好处是服务能力是双倍的，且对用户来说不可感知。
同城双活
将一个网络扩展到多个数据中心，并且实现服务器和应用的虚拟化数据中心互联网技术：随着高可用远程集群技术以及虚拟机迁移技术在数据中心容灾以及计算资源调配方面的广泛应用，在数据中心间需要大二层网络连接
网络双活
是一种独特的存储技术，是信息能在数据中心内部以及数据中心之间共享、存取或移动，从而将各种不同的存储系统联合成为单一资源。它允许位于地理上分离站点的存储系统同时进行数据存取，对客户透明，且保证了数据可靠性和可用性。
存储双活
异地之间采用双活目前不够事前。因为上午很好的技术能够实现远程距离的实时数据同步。当两个站点距离超过100公里以上，数据同步只能采用数据异步存储数据复制方式。
异地双活
指两个数据库系统可以在相隔比较远的情况下运行、支持相同的应用负载，并且在一方出现故障时能够迅速切换到另一方（分钟级），保证业务高可用性。
数据库双活
在应用处理层面上实现了完全冗余，交易通过负载均衡自动路由到不同的应用服务器，但是数据库层面上还是依赖在某一个数据库。
应用双活
双活中心不同层次
代表产品IBM SVC、LSI SVM、HDSUSP、EMC VPlex、EMC RecoverPoint、飞康CDP...
远程异步FCIP
对上层应用及数据库透明
不占用主机资源及性能
可能产生性能瓶颈
可能是新故障点
多平台存储汇聚资源池|统一管理
适用于异构存储环境
数据一致性通过SAN层数据复制功能保证
重点关注：存储环境、产品性能（存储性能瓶颈）、单点故障、数据一致性、RPO
SAN网络层容灾
代表产品：IBM MM/GM/ERM、EMC SRDF、HDS TrueCopy...
FCIP
地上层应用及数据库透明
FC
适用于同构存储环境
数据一致性由数据控制器数据复制保证
重点关注：存储环境、数据一致性、RPO
存储层容灾
数据级
应用层容灾
代表产品DB2 HADR、Oracle dataguard、sybase Mirror Activator、Golden Gate、Shareples...
复制链路主要依赖IP，消耗IP宽带
特定数据库产品增加功能，主要异步模式
占用一定主机资源以及性能
通常需要同构主机环境
可适用于异构存储环境
护具一致性通过数据库逻辑保证
重点关注：主机性能规划，网络宽带规划、数据库环境权衡、管理复杂度（切换\\回切\\演练）
数据库层容灾
OS层容灾
应用级
数据中心A（上海浦东）
数据中心B（上海其他）
数据中心C（北京地区）
两地三中心
上海两中心
无锡两中心
两中心主备按照季度切换
金融企业两地四中心
T0项目启动
准备阶段项目启动
T01风险分析
T02可恢复性分析
T03业务影响分析
阶段一需求调研与分析
T04制定容灾策略
T05容灾复制技术选型
T06灾备系统架构设计
T07设计未来演进路线
阶段二容灾架构设计
T08制定灾难恢复预案
T09制定容灾演练流程
T10制定灾备系统运维管理流程
阶段三容灾流程设计
T11容灾机房环境建设
T12容灾系统IT基础架构建设
T13数据级容灾系统建设和演练
T14应用级容灾系统建设和演练
阶段四灾备系统实施
T15灾备系统监控
T16业务连续性运维管理
阶段五运营管理
T17 知识转移专业培训
T18项目管理
阶段六 培训与管理
消费品企业DRP
目标：通过对业务系统管理关系的分析，确定业务系统的重要级别以及恢复顺序
RTO：系统可容忍最大中断时间
RPO：系统可容忍最大数据丢失时间
RPO：Recovery Point Objective
RTO：Recovery Time Objective
灾难发生RTO和RPO对比
银行 业务影响分析
案例分享
业务影响分析
DRP规划
纸上谈兵：核查性能测试（看文档）、结构化的排练（读文档）
大事化小：模拟测试（非生产，只能用预生产），并行测试（复制生产数据测试）
搞大了：全中断测试（切换和回切）
完成批量作业
数据全量备份
系统、网络和复制状态检查工作
演练前准备工作
停止对外网站
横向联网系统
外围系统停止服务
停止集群A/B上的应用和WebLogic的服务程序
核心应用系统停止服务
停止集群C/D上的数据库系统服务程序、
核心数据库停止服务
通过存储复制工具执行暂挂操作
通过存储复制工具执行恢复操作
存储正向切换操作
断开到主机房征管系统链接线路
网络切换工作
生产中心：切换准备工作
联通到备机房征管链接线路
测试网络连通性
灾备系统核心主机激活VG并检查
核心主机Mount文件系统
启动数据库集群
启动中间件集和应用系统
启动对外网站、横向联网系统等
外围系统启动服务
切换后业务测试
对外营业、提供正常服务
灾备中心：切换后恢复工作
税务企业 容灾演练
容灾演练
DRP：BCP的绝对主题
其他专题：本地高可用、数据逻辑保护、系统安全运营
非技术性：人员、沟通、财务、损失估算
NCP文档很流程
数据中心A，100%资源
数据中心B，100%资源
双活数据中心的成本
数据中心A，50%资源
数据中心B，50%资源
数据中心C，50%资源
多活数据中心成本
200%
2*1
双活
150%
50%*3
三活
n*(1/(n-1))
多活
计算公式
多活反而省钱
请求路由
单元封闭
数据同步
导航企业的Set单元化
多活方案
数据一致性妥协：CAP理论、最终一致性
子主题
妥协方案-实现高可用的代价和妥协
多活和妥协
SLI：Google四大黄金指标：延迟（Latebcy），流量（Traffic），错误（Errors）和饱和度（Saturation）
SLO：一定时间内（半年内），一定支付范围（支付子系统）的SLI（Error Rate）满足一定规则（环比下降10%）
SLA：针对汇总SLO，提供奖惩措施
每个部门，每个周期开始复原为100%
周期内，根据实际SLI情况，不停衰减
一旦变成0%，拒绝该部门的变更和发布申请
目标本周服务正确率：98%
本周实际第一个小时的服务正确率SLI：99.3%
1小时后剩余Error Budget是多少？99.8%
案例说明
Google-错误预算
Google-SRE文化
使用CHaos Monkey，停掉一台服务器
使用Chaos Gorilla，停掉部分城市服务器
使用Chaos Kong，停掉一个地区的服务器
ATP：Avaukability to Promise说到做到
算法：ATP=1-（预算交易数-实际交易数）/预计交易数*（影响时间/统计时间）*业务影响因子
难点：交易预计（节假日、季度、抢购）
SAP-业务高可用评估
Netflix-混沌工程
MTBF：平均故障间隔时间（3年，五年）
MTTR：平均故障修复时间（3小时，5小时）
HA=MTBF/(MTBF+MTTR)
计算说明：HA=99.9%*99.9%=99.8%
串联架构：HA=HA1*HA2
计算说明：HA=1-(1-99.9%)*(1-99.9%)=99.9999%）
并联架构：HA=1-（1-H1）*（1-HA2）
实例分享：世界500强 子系统高可用评估
串联架构-系统高可用评估
IBM-系统高可用评估
APM Metric 时间聚合
Trace 特定交易
Log 事件告警
汇总成：交易特征
时间聚合和特定交易
汇总成：事件聚合
时间聚合和事件告警
汇总成：交易事件
特定交易和事件告警
汇总成：报告
时间聚合和特定交易和事件告警
美团点评、携程-CAT应用监控
高可用流程
本地高可用的架构、高可用流程
题眼
结合实际业务需求（99.999%）、方法（集群、分布式）、流程（错误预算、全链路测试、混沌工程、监控等）
加分项
题目1：聊一聊如何实现本地高可用？
数据逻辑保护（备份、快照、事件溯源、用户访问等）
博闻强识（思科事件、微盟事件）、应对方案逐一分析
题目2：如何防治删库跑路
容灾架构（应用、数据、网络、存储层）、容灾流程（DRP、BCP）、多活/单元化架构
结合技术细节，描述项目经验。如单元化考量点（请求路由、单元封闭、数据同步）、业务影响分析、容灾演练等
题目3：聊聊异地多活、单元化
题目1：对平时负责的子系统，进行高可用自查，评估一下系统高可用达到了几个9，瓶颈在哪里
题目2：故事分享：分享一个曾经才用过的高可用方案或流程，说说付出了哪些？收获了哪些？
扩展思考
可用性维度
流程安全性、架构安全性、安全实现方案概述
企业成长过程不可避免的痛，讳疾忌医的哪些日子
抛砖引玉，点出安全事宜的关注点
安全性实现方案
2017年Equifax Inc信用评估系统，透漏客户信息，导致损失股票1/2
2018年Facebook，个人信息透漏损失6800多万、股票下跌30%
2018年万豪集团，泄露客户开放信息，损失5亿
2019年拼多多优惠券损失200亿
安全大事记
可用性-Availability
完整性-Integrity
机密性-Confidentiality
安全基本原则
Zachman
Sabsa
IATF
P2DR
IPDRR
企业框架
COBIT
NIST
自使用安全
网络韧性
完善安全架构
ITIL
六西格玛
其他辅助安全架构
安全架构
安全测试：SAST静态测试、IAST交互测试、安全扫描
威胁模型：攻击树分析、DREAD风险评估
渗透测试：红蓝对抗、白帽黑帽
安全评估方法
流程安全性
人员安全：权责分离
访问控制：枷锁、网络隔离
入侵检测：威视、警告等
物理安全
访问权限：责任分层、最小特权
数据加密：对称秘钥、费对称秘钥、数字签名
数据保护：数据逻辑保护、数据高可用
数据安全
DDoS拒绝服务
DNS劫持
重放攻击
ARP地址解析欺骗
最强之剑：网络攻击
WAF应用防火墙
IDS/IPS入侵检测和防
VPN/IPSEC安全通道加密
PGP邮件加密
TLS HTTP隧道加密
最强之盾：网络防御
通信安全
Authentication认证：你是谁（目录、用户认证）
Autgorization授权：MAC、RBACOAuth第三方授权
Audit审计：审计管理控制、审计技术控制
身份安全
操作系统安全：病毒、蠕虫、特洛伊木马、零日攻击、补丁
数据库安全：防止SQL注入、防止推理攻击
Web应用安全：防止XSS跨站点脚本攻击、防止重放攻击
软件安全
AES对称加密
PKI基础架构
JWT签名
IDS入侵检测
网络应用防御手段
RBAC访问控制
SAML安全断言
用户防御手段
SQL注入预防
XSS跨站点攻击防治
其他专门防御手段
实现方案
安全性架构（物理、数据、通信、身份、软件）
能结合实际案例，重点突破某个安全架构实现方案
题目1：你在架构设计中有没有考虑过安全性
决策派、安全架构、其他需求（功能、架构核心维度）
结合实际案例，如果实现架构妥协，保证安全性
题目2：当安全性和其他需求发生冲突时如何决策
题目1：对自己负责的子系统，可能存在的安全隐患？有什么优化的想法？
扩展题目
安全五芒星
架构安全
安全性维度
伸缩性场景、思路、实现方案（入口、应用层、基础架构、有状态、无状态）
人生有潮起潮落，企业也不例外
理论分析、云平台实战、面试交流
电商的秒杀和抢购
热点业务：支付、下单、添加购物车、商品详情页、搜索
热点数据：秒杀产品、动态数据、静态数据
时间久，使用虚拟机
时间短，预配虚拟机使用容器方式
思路：时间与空间转化、系统伸缩性
伸缩性场景
水、电、燃气、道路等等
基础设施
房子、医院、写字楼、景区等等
生活资源
人才引进机制等等
人才引入
城市伸缩-上海发展
数据放在云平台可以快速进行通信
数据中心
基础建设
容器方式
系统资源
引入访问者
网络引流
微服务伸缩
伸缩性思路
伸缩性场景与思虑
应用无状态
函数式编程
响应式编程
常见编程方式
事件驱动
流驱动
常见业务模式
->无穷大
从0资源
一个或者一套系统进行观测
观察
决策
执行
实现方式
无服务器化Serverless
HPA：水平横向扩展
CornHPA：容器节点扩展
Autoscaler：底层增长架构
九阳真金缩骨功
Kubernetes 弹性伸缩实战
类似孙悟空的“大大大”
lstio +Knative+Kubernetes 称为三剑客
Template
Costom
Source
Build
Scaling
Routing
Snapshots
Server
Pireliness
Tciggers
Event
What is Knative
Kubernetes用来管理Knative
Lstio+Knative+Kubernetes
第一次访问的时候Kubernetes时候，没有pod会生成一个pod会比较慢
第二次访问直接访问当前Pod比较快
时间久没有访问Pod会被回收，当超过一定时间的时候会重新生成一个Pod会也会比较慢
案例分析阿里云K8s集群
无状态应用弹性伸缩
将有状态应用区分：共享磁盘模式和Share Nothing模式
共享磁盘模式 -> 无状态应用
Share Nothing模式 -> 采用合适的集群管理方式和CAP目标
结构化数据 -> 共享数据库
非结构化数据 -> 共享缓存、对象存储、搜索引擎等
减少文件系统依赖（如CDN直接对对象存储等）
向无状态应用转移
共享磁盘模式
CAP-优化可用性和分区性，拓华一致性
经常采用一致性HASH
集群管理-优化选举、仲裁、阶段提交、副本、分片管理
比如秒杀需要在一定时间内进行预配置
动态的增加部分节点
资源预配置
Share Nothing架构
应用说明
有状态应用弹性伸缩
伸缩性实现方案
伸缩性架构、高性能的设计
结合实际案例，重点突出业务爆发的场景，分析如何应对有状态应用恨无状态应用
题目1：如何在架构设计中应对高爆发的业务场景？
能从多维度总结这些架构。比如：无状态的Serverless架构、自动伸缩架构；有状态应用如何向无状态转移
能结合具体细节，比如Kubernetes的HPA/VPA技术，Knative的Serverless技术，讲清楚实战的方式和原理
题目2：介绍一下业界流行的伸缩架构？
分享一个曾经采用过的伸缩方案，说说你要面对的突发业务的特征？室友状态还是无状态？如何应对？
伸缩性维度
确定系统边界，定义内聚耦合，如何实现高内聚低耦合
合久必分、分久必合-解耦，架构师永远的主题
理论分析、案例分析、面试实战
国与国-系统边界、领域边界
省市县-子系统（子域）边界、模块边界、聚合边界
教育（高校）、军事（军团）-分层边界
边界是什么
DSSA-特定领域架构划分
ABSD-听客户/用户需求划分架构
定制剪裁方法论-使用ABSD和DSSA共同划分
定义边界
王大锤相亲问题，一见如故，身体每个细胞都在想她
模块组成部分执行同一功能
只想她一个人
只执行一个功能
想她天长地久
专一在这个功能
功能内聚
约上另外两个相亲对象，先想粉衣女，再想白衣女
前一组成部分完成后，后一组成部分继续
先出现粉衣女出现白衣女，相互交替
可以理解为登录模块，用户-》登录页面-》首页
结合MapReduce的底层理论理解
前一模块的输出，是后一模块的输入
顺序内聚
只要相同的香水我就感兴趣，会吸引我
配件编号查询库存和单价的模块聚合到一起，由于输入
模块各部分使用相同的输入或输出数据
通信内聚
来到女儿国，国王指挥所有人都轮流跟大锤相亲
模块各部分受同一控制流支配
过程内聚
他们同时出现就喜欢
模块各组成部分在同一时间段内执行
他们同时离开
整体模块在特定时间内完成
例如一功能的初始化单元和终止单元
时间内聚
他们曾经都如此相似
各组件的逻辑功能类似
每次选择都这么艰难
腿长
尖脸
白
Flag内聚标签标示，大锤花心
由传输给模块的判断参数来确定
逻辑内聚
现任跟前任没有任何相似之处
模块组成部分批次没有关联
现在对象黑瘦，难道是命运的安排
各组成部分刚好放在同一模块
证明大锤是花心大萝卜
偶然内聚
7大内聚分类，内聚性由高到低，模块独立性由强到弱
聚焦内聚
两个模块没有直接关系
模块独立性很强
非直接耦合
两个模块之间有数据值参数传递
比如：街道、县之间运货的都是有规划地点的没有耦合关系
开发货单模块跟计算金额模块只需要单价和数量计算出来金额
模块之间影响最小的耦合关系
数据耦合
发送住户详情到计算水费服务，算出水费
发送住户详情到计算电费服务，算出电费
租房费用核算
发送本月用水量到计算水费服务，计算水费
发送本月用电量到计算电费服务，计算电费
租房费用核算优化
两个模块与同一个数据结构有关
传递的数据结构化或数据结构的地址
标记耦合
两个模块之间传输控制信息（如开关、标志等）
调用模块需要知道被调用模块的内部逻辑
增加了相互依赖和理解、编程的复杂度
A用户密码不正确
B用户不存在
C用户名密码正确
用户登录
X
不要让控制流在两个模块之间进行传输，要让控制流脱离模块
控制耦合
一组模块与外部环境关联
这组模块访问同一全局变量
外部耦合有时候必不可少，但应该尽量减少此类模块数量
外部耦合
一组模块均访问同一全局数据区
公共耦合设计一种不良耦合，他给模块维护、修改带来障碍
全局变量
黑板
仓库
数据库
公共数据区
只有A修改B查看
松散的公共耦合
A可以修改也可以查看，B也可以修改也可以查看
紧密的公共耦合
模块间关系复杂
软件可理解性降低
修改变量名和属性困难
公共软件可维护性降低
公共区域和全部变量无保护措施
软件可靠性降低吧
公共耦合的弊端
公共耦合
一个模块直接操作或修改另一个模块的内部数据
一个模块不通过正常入口访问另一个模块
最糟糕的耦合情况，必须避免
内容耦合
你设计的模块间是什么耦合？
7大耦合分类，耦合性由低到高，模块独立性由强到弱
关注耦合
一个对另一个模块的调用
一个模块想另一个模块传递的数据量
一个模块施加到另一个模块的控制是多少
模块之间接口的复杂成都
耦合关注点
多用接口隐藏实现的细节
多用接口
遵循一个定义只在衣蛾地方出现
唯一定义
少使用全局变量
避免全局变量
少用public，多用private关键字
避免public
多用设计模式
避免使用直接SQL语句操作数据库，最好封装Dao
避免直接SQL
避免直接操作或调用其他模块或类
避免内容耦合
尽量使用数据耦合，少用控制耦合
避免控制耦合
限制公共耦合的范围
限制公共耦合
低耦合原则
模块的功能划分尽可能的单一
单一职责原则
模块只对外暴露最小限度的接口
六边形理论，服务对外接口不超过留个
接口隔离原则
一切向功能聚靠拢。杜绝偶然内聚
杜绝偶然内聚
高内聚原则
如何实现高内聚低耦合
CEO的根据996福报转成10107，影响到薪资跟代码贡献值的
计算工时
CFO资金出现问题
计算工资
CTO大家效率变低，看来需要杀鸡儆猴
计算代码贡献值
CEO、CFO、CTO需求员工管理报告
违背了架构原则之：SRP单一职责原则
采用了偶然内聚：居然变得比猪八戒还要花心
需要三者需求进行解耦
没有为架构演进做准备
案例三大败笔
员工管理报告案例
拆分不能过细，更加不能形成闭环，需要适可而止
无依赖环原则
功能类似或者相同的考虑合并包
共同闭包原则
依赖关系，泛化、继承或者实现
依赖反转原则
稳定的内容抽取，
稳定依赖原则
架构环路案例
案例新公司新气象
需求驱动、领域驱动
结合ABSD、DSSA、AT等方法论，定制化剪裁
题目1：在架构设计中如何划分系统边界
高内聚低耦合、结合需求和领域
能结合实际案例，聊聊模块交互的成与败
题目2：你在架构设计中如何定义和设计各个模块的？
模块间解耦、减少领域模块的依赖
结合依赖反转原则、稳定依赖原则，分析模块间交互
题目3：我们公司的中间件和数据库系统会不定期的升级和替换，如何减少主业务代码对于这些系统的依赖
题目1：对于平时负责的子系统如何重构，实现高内聚低耦合
分享一下模块紧耦合带来的坑？
题目2：故事分享
讨论题目
边界、内聚及耦合
架构扩展（应用、数据）、组织扩展性、流程扩展性
大型电商平台西天取经的九九八十一难
中文翻译可以随便扩展
可以简单复制的业务
增加人力量大的业务
失败随时可以重来
x轴-无脑克隆
需要法语、西班牙语翻译，则需要招聘响应的技术人员
分割责任、功能和数据
流水线责任制
与业务模块、组件的划分相关
y轴-功能分割
根据客户需求进行打印
分割请求者和客户
对于业务透明
提供优先级服务
提供就近服务
z轴-客户分割
扩展立方体
核心方法论
无状态应用，多节点克隆复制
负责均衡器，控制业务负载流向
有状态应用，状态剥离（比如Session处理）
优势：弹性扩缩容、性能规划、业务解耦、环境同构
x轴-横向克隆
微前端
前端应用，URL拆分
后端应用，子系统模块、聚合拆分
后台数据响应进行Y轴分割
优势：服务互不干扰、资源迭代分配、数据一致性、业务应用的耦合性
y轴-服务分割
分割服务释放业务压力
用户UserID分割，多节点水平复制
北京访问北京服务器、上海访问上海服务器
地理位置分割，Set单元化
产品ID分割、SPU/SKU区别
优势：加速查询服务、有状态服务、业务解耦、环境同构
z轴-特征分割
A-N分配到服务A
O-Z分配到服务B
z轴的：A应用
z轴的：B产品
z轴的：C库存
x轴的：承载服务
大娃-y轴扩展
套娃组合法
应用扩展
传统SQL，读写分离，一写多读
NoSQL，多副本replica
缓存读取横向扩展
优势：CAP最终一致性、CDC便捷复制、数据高可用
缺点：存储空间浪费
x轴-水平复制
配合应用y轴分割
表库享有独立数据库集群、节点
微服务、康威定律
优势：数据故障隔离、资源迭代分配、强一致性
需要了解业务
缺点：业务耦合性
y轴-库表分割
支持各种Key：User、SPU、SKU
传统SQL，分表分库（MyCat等）
NoSQL，多shard/chunk分片
优势：加速查询搜索、扩展无上限、业务解耦、强一致性
z轴-哈希取模
z轴-Hash取模
单个节点ES
x轴-创建replica
两个节点ES
多节点ES
商品搜索引擎扩展
用户搜索引擎扩展
订单搜索引擎扩展
y轴库表扩展
数据扩展
架构扩展性
2个人沟通需要1分钟
3个人沟通需要3分钟
12个人需要12*（21-1）*2=66分钟
n个人沟通需要N*（N-1）/2
康威定律的沟通问题
康威定律
每天盼着披萨
目标一致
人员数量较少
配合和应用和数据的y轴扩展
披萨组织
潮牌Sporify就是打败iTunes的音乐的
产品
开发
运维
运营
创业小分队
私密分会
罢工行会
tibr部落孵化器
是什么打败了苹果的iTunes
部落联盟
扩展性验证-无角色
数据扩展性-无角色
应用品扩展性-无角色
产品扩展性-无角色
扩展性愿景-A拍肩膀
扩展性文化-R执行人
CEO
数据扩展性-A拍肩膀
应用品扩展性-A拍肩膀
产品扩展性-A拍肩膀
扩展性愿景-R执行人
扩展性文化-无角色
CTO
产品扩展性-R执行人
扩展性愿景-S我顶死你
产品/项目经理
扩展性验证-S我顶你
数据扩展性-R执行人
应用扩展性-R执行人
产品扩展性-S我顶你
架构师
数据扩展性-S我顶你
应用扩展性-S我顶你
研发攻城狮
SRE
InfoSec
扩展性验证-R执行人
QA
RASCI矩阵
组织扩展
ITIL流程管理
ITSM服务管理
大型汽车产商使用的
6 西格玛
CI/CD持续发布流程
JAD联合架构设计
ARB架构评审会
可扩展流程需要注意什么？现在有哪些理论
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。
01、初始级-拍脑袋
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
02、可管理级-方法论
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
03、已定义级-文档化、制度化
分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。
04、量化管理级-SMART原则
过程的量化反馈和先进的新思想、新技术促使过程持续不断改进
05、优化管理级-现今为止只存在理论
CMMI软件成熟度模型
或者票查询能力扩容5倍
具体
S
高峰期平均5万的QPS
可度量
M
预算翻倍。可以采用云平台分流
可达成
A
读写分离
公有云方式
每次整改能力提升至少30%
现实
R
6个月内整改完成
时限性
T
SMART原则
流程扩展
分布式架构设计横向扩展
多
云架构设计实现
应用：无状态、容器化、Serverless无服务器化
分布式架构理论
数据：多副本、读写分离、冷热分离
中间件：缓存、最终一致性
阿里的Canal
工具：SQL CDC技术
x轴无脑克隆复制
快
微服务架构理论
DDD领域驱动设计
服务拆分、界限上下文交互
Spring CLoud服务治理
服务发现、服务治理、负载均衡、服务追踪
y轴服务和数据分割
好（最难）
应用：负载均衡（客户端Ribbon；服务端Nginx、K8s Service；中间件ESB、Api Gateway）
数据：分布式多片架构、分表分库（客户端sharding-jdbc、数据库Spanner；中间件MyCat、Aurora）
z轴哈希取模特征分割
省
多块好省实现扩展性
RDS/MySQL数据水平拆分
RDS只读、MySQL备库读写分离
DRDS多重方式存储
OLTP数据库
业务逻辑层
数据加速
OLAP数据库
省OLTP数据库
互联网化
抢购资格
抢购信息
抢购结果
抢购发布
抢购修改
抢购终止
抢购数据
业务系统
互联网化营销
抢购数据监控
抢购数据分析
抢购数据查询
运营系统
核心业务需求
微厅
流量秘书
CDN
HAProxy
应用虚拟机100台
mysql单台
支撑2w用户抢购没有问题
100节点部署
全容器技术，开发部署一致
应用x轴扩展
钱够系统（微厅）和运营系统（流量秘书）分离
应用y轴扩展
不区分客户ID，Round Robin负载均衡
应用z轴不扩展
Altibase数据库多副本，Redis缓存预加热
数据x轴扩展
抢购数据和运营统计数据库分离
数据y轴扩展
Redis UserID、SKU_ID分片，多节点分布
数据z轴扩展
架构决策
流量监控、抢购交易、结果查询
服务总线
资格审查、防刷控制
Altibase
mysql集群、Redis缓存
服务总线的仲裁节点
Etcd
管理所有的容器
Zookeeper
管理所有机房
Mesos
管理所有作业调度系统
Marathon
备注：Mesos+Marathon=K8s功能类似
在Docker部署完整，实现上万个容器部署
10000节点部署架构
电信运营商-抢购秒杀系统
单体应用从100节点到了10000节点的扩展历程
阿里数据库之多块好省
单体应用y轴扩展，配合x轴横向扩展，z轴特征切分
能从系统、网络和数据多层次深入讨论
题目1：如果给你一套传统架构的单体架构，如何确保应用的扩展性来满足未来3-5年的发展需求
决策论，可扩展组织可扩展流程
结合RASCI责任矩阵、CMMI成熟模型、SMART原则
题目2：架构决策时如何考量扩展性，企业的不同角色岗位该如何配合？
数据的x轴水平复制、y轴库表分割、z轴哈希取模
结合具体产品进行技术阐述，比如MySQL和MongoDB
题目3：说说关系数据库和NoSQL如何扩展实现扩展性
对于平时负责的子系统，挑选一个，尝试进行zxy轴扩展
故事分享：分享一个早期扩展性问题设计导致的天坑
扩展性实现方案
扩展性维度
What：架构性能关注点、高性能流程，实现方案（缓存为王、异步为帅、分布式为将）
Why：高并发高性能、互联网公司面试不变的话题
How：理论分析、案例分享（妥协方案）、面试实战
概述三要素
1000万用户
100万日活用户
数万-数十万峰值并发数
大概分布方式是怕松分布
0.5ns
L1 Cache
7ns
L2 Cache
100ns
内存
0.1-20ms
磁盘
0.5-100ms
扩机房
响应延时金字塔，各种延迟为一体，下面五个参数融合很难优化到很快的
数亿条记录，数百万GB数据
单库
数百亿记录，数十TB数据
主库
数据量
数亿在线用户
数千万活跃用户
数十数百万并发请求
并发
数万TPS，数十万QPS
平时
数十万TPS，数百万QPS
交易峰值
备注：TPS跟QPS占有比例，大概是1:20
交易量
大厂业务的体量级
并发数，我来猜
QPS、TPS、响应延时、出错率
交易业务
吞吐量（1GB/s=8Gbps）、处理窗口、滞后时间
流业务
CPU、内存、存储、网络
系统
性能参数
真正线上生产
天猫：54.4万TPS
压力测试
eBay支付压测：100万TPS
是把每十分钟的契约计算在内了
EOS区块链：100万TPS
TPS=并发数/（平均响应时间+思考时间）
案例
高性能思考-十万级、百万级、千万级并发
业务指标（UV、PV、交易量）
系统目标（CPU、内存、网络、磁盘）
应用目标（TPS、QPS、Session、并发数）
目标设定
架构设计评估图
容量评估方法（基线、水位）
规划方法
压测
监控
预测
实战
容量规则
正常运行压力下的响应时间、资源利用率、稳定性
测试目标
历史为基
标准
QA、准生产、生产
环境
测试案例
定义
自动化
统计
分析
录入
报告
反复
迭代
测试手段
测试是一个长期的过程
测试核心思想
负载测试
发现系统的拐点（失效点）、远高于正常负载
目标
关键业务
负载测试瓶颈
关键服务
大量测试数据
负载
减少生产差异
设置告警
录入分析结果
关注拐点-服务行为、响应时间、CPI内存磁盘利用率低、线程、SQL、交易失败率
性能测试
时序数据
维度聚合
性能指标
报表告警
性能监控
衣带渐宽终不悔
TraceID、SpanID、DyeID
出错归因
延迟瓶颈
链路监控
为人消得人憔悴
业务、应用、系统关联
告警去重
业务追踪
蓦然回首，那人却在灯火阑珊处
APM监控三境界
APM监控作为眼睛
扩容决策引擎（Auto Scale策略）为大脑
资源管理（虚拟机、容器、网络负载、Serverless）为手
弹性扩容
高性能流程
Cache vs Buffer
读 vs 写
能用的话先用这个，比如页面缓存Cache-Controll
Content Delivery Network内容分发网络
其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输得更快、更稳定。
通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。
其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。
Edge边缘缓存
静态文件缓存
反向代理方式处理缓存
网络缓存，优化由高到低
本地对象缓存缓存
应用缓存
键值对服务器
对象缓存
缓存为王
科学家就餐问题，餐厅有五个座位，每个人都需要两个叉子就餐，总共四个人就餐。服务员最能解决这个问题，就是时间空间排队方式，挂个牌子本餐厅只同时接受两个人就餐。
同步问题思考
磁盘、SQL这两点比较难
API、URL这两点比较容易
减少等待
微服务解耦
Y轴扩展更随意
y轴扩展
泊松分布、银行队列
削峰填谷
异步为帅
提高吞吐能力和明显提升QPS
x轴扩展
出错率明显降低
延时降低、TPS/QPS明显提升
z轴扩展
分布式为将
有时候不得不割地赔款
各个城市、各种网络等都需要钱来满足
需要缓存服务，增加服务器性能
数据、应用都要线性扩展
这三种都要很多的资源开销
高性能的代价
DNS解析指向排队系统
获得令牌后再跳转到CDN
排队系统
DNS解析CDN
应用服务器，跳转到排队系统等待领牌
排队变种
类似漏桶方式处理
令牌桶方式
上面两者都是一用消息队列和键值对实现
内部限流
另类的队伍
例如：A股出现5%涨跌半熔断，出现7%的涨幅就出现全熔断不可交易
网站的关闭评价系统，淘宝双十一关闭订单查看
熔断
拆东墙补西墙
丢弃非核心产品
服务治理、网格会详细介绍
降级
丢卒保车
妥协方案
高性能实现方案
分布式计算和数据=x+z轴扩展；高并发高性能=缓存、异步通信、分布式、妥协；多线程=CPU调度
针对具体技术展开，比如不同并发压力下，不同负载特征情况下（计算密集型/IO密集型）线程池的大小选择
题目1：聊一聊分布式、高并发和多线程
反向代理Nginx等的应用缓存功能，如何配合4层负载均衡（F5、LVS、Keepalived）实现高可用
挑选一种反向代理，详细讨论如何调整配置参数来进行性能调优
题目2：如何实现高性能高可用的反向代理
NIO、消息队列、Pub/Sub、P2P
异步通信知识面
结合具体产品进行技术阐述，比如Netty、WebClient、Kafka、RocketMQ、RabbitMQ、Redis等
题目3：说说如何通过异步通信机制来提高网站性能
1、对于平时负责的子系统，挑选一个尝试进行缓存、异步、分布式化，来提升QPS、TPS？
2、故事分享：分享一个曾经采用过的妥协策略，来满足有限资源情况下的性能和并发要求
扩展题目：
性能维度
架构设计核心维度
0 条评论
回复 删除
下一页
