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