Java技术体系
2022-04-26 10:19:34 0 举报AI智能生成
Java技术体系
作者其他创作
大纲/内容
分布式系统
分布式系统理论
分布式一致性和CAP理论
CAP
C：一致性
强一致性
A：可用性
99.999%
宕机时间
P：分区容错性
分布式系统只能三选二，不能占全
分布式一致性算法
Raft算法
Leader
Replica，只有一个
Leader下线以后再次上线，而且这个Leader还带了一个Follower。这就是脑裂问题。
这时候比较老的Leader会变更成Follower
Follower
选民
如果Leader出现问题，则Follower则成为Candidate。
如果出现两个Candidate，出现平等数值，选举还没结束，继续进行加时赛
Candidate
候选人
(n/2)+1过半的时候才会出现推举成为Leader，如果不超半数则自己加票
拜占庭将军问题
共识算法
节点选举问题，有些节点不可信问题
因此Raft算法解决上面问题
分布式环境中的脑裂和Lease解决方案
脑裂
由于网络互不连通，出现两个Leader，同一个客户端收到两个Leader的不同指令
使用全局过半的选举解决方案，Zookeeper就是这么一个解决方案
Lease机制
租约的方式
Lease告诉Leader节点，现在计时10s内是Leader
集群你有一个租约发布的机器或者集群，每10s会发送一次
当Leader在有效期内挂了，等到下次发布集群的lease发布lease才会选举Leader
底层数据设计策略
分表分库与热点数据
关系型数据库的伸缩
读写分离
数据库商品数据为例，只有在发布商品之前是写数据，发布商品之后搜索等都是读数据。读多写少
因此，性能瓶颈在于读数据
集群数据库一个Master节点多个Slave节点
写数据主要在Master
排它锁（事务锁）
读数据在于Slave
共享锁
Master和Slave之间的锁是把两个锁分开
Sharding Proxy
集群扩展
分库分表
分表
垂直分表
PRODUCT
Name
Price
PROD_TEXT
Blob Desc
PROD_IMG
Blob Img
水平分表
PRODUCT_01
PRODUCT_02
PRODUCT_03
分表方法
商品ID去取模选择表
不好水平扩展，每次水平扩展都涉及到数据迁移
订单时间片
根据时间分片，可能出现数据分布不均匀
分库
水平分库
水平分库跟水平分表有异曲同工之妙
DB_01
DB_02
水平分库和水平分表如何计算
先进行ID取模：x=n/(分表数量 * 分库数量)
以商品ID为100，水平库为2，水平表为3，为例：100/(3*2)=4
根据ID取模的值x计算分库取除数：y=x/分库表的数量
算出所在库：4/3=1
根据ID取模的值x计算分表取余：y=x%分库表的数量
算出所在表：4%3=1
业务层面分库分表
用户
订单
数据异构
订单ID维度分库分表
用户ID维度分库分表
难点：数据同步、跨存储介质同步数据等
商品
分库分表数据扩容：0宕机
小山也能出道
路由第一步
DB_01_master
DB_01_slave
DB_02_master
DB_02_slave
路由第二步，转slave为Master
DB_01_master
Pid%4=0
DB_01_slave
Pid%4=2
DB_02_slave
Pid%4=3
DB_02_master
Pid%4=1
路由第三步骤，增加新的Slave
DB_01_master
DB_01_slave
DB_02_master
DB_02_slave
DB_03_master
DB_03_slave
DB_04_master
DB_04_slave
扩容成倍增加
4进8,8进16,16进32
增量存储同步
路由第一步，设置两台数据库机器
DB_01_master
DB_03_master
路由第二步，扩容两台机器到四台机器
DB_01_master
DB_03_master
Pid%4=0
DB_02_master
DB_04_master
Pid%4=1
路由第三步，更改路由规则，到新增的DB
DB_01_master
Pid%4=0
DB_03_master
Pid%4=2
DB_04_master
Pid%4=3
DB_02_master
Pid%4=1
热点数据（团灭发动机）
数据场景
翔厂发布百亿补贴，抢购全民商品
前端拦截大部分请求
这种是可以预测热点数据
高点播的新闻，高管出轨，志玲姐姐结婚
不可以预测的热点数据
热点数据的隔离方案
为什么会对热点数据隔离？
缓存方案
路由
DB_01_master
Pid%4=0
DB_03_master
Pid%4=2
DB_04_master
Pid%4=3
DB_02_master
Pid%4=1
热点数据
分布式缓存
缓存
缓存
缓存
缓存
热点抢购
特点
数量少
访问频繁
存储方案
热点散列
热点库
多级缓存
是在超高
多级缓存
由于分布式缓存的服务压力过高，造成数据服务不可用
使用JVM+分布式，可能会因为大对象造成GC频繁
热点库方式
热点散列
监控热点数据
识别热点（最难）
商城热点商品过程
订单中心下单
商品中心
营销中心
库存中心
热点数据发布
热点来源
搜索页
详情页
RPC、Gateway
日志抓取
聚合分析热点发布
隔离热点
缓存预热
访问单元隔离
数据隔离
接口隔离
性能优化
缓存
降级熔断
限流
思考问题
题目1：设计一个支撑xxx并发量的应用，从数据层面有什么要考虑的
底层数据
读写分离+集群扩展
备库
异构+分库分表
热点方案
题目2：热点数据怎么防范
预知热点
热点库
本地缓存+多级缓存
动态热点
热点数据侦听
接口参数聚合
通知送达节点
日志埋点统计
题目3：分库分表以后，业务量增加需要扩容，如何处理
分库分表数据的迁移和扩容
主库转备库
2n的增加方案
扩展问题
了解分库分表的业务场景
搭建一个简单的Demo处理热点数据
通过MQ接收一个消息推送（热点ID）
从Redis中获取该热点缓存在本地
后续访问从本地获取热点
如何应用重启了？后续热点数据如何同步
高可用数据
数据备份和失效转移
数据备份
冷备：最最最坏的情况
定时
低成本
数据丢失
数据不一致
案例
历史订单
业务报表
时效不高
热备
特点：实时备份
同步热备
存在数据同步问题
主从热备
主从热备
业务操作
主库
通过Canal或者日志
备库1
备库2
mysql支持天然支持主从备份
失效转移
mysql支持主从备份
mysql的Master与Slave之间有主从的半同步
发送事务提交Master到备库，会提留一定时间当备库master确定以后才可以同步
FailOver，当主库出现问题的时候会切到备库里面
数据迁移
基于Binlog的数据迁移方案
阿里系数据同步黑科技
Canal（数据迁移神器）
主要应用场景
数据镜像
增量同步
数据异构
代码层面如何控制缓存和DB的一致性
缓存本质上也是一种读写分离
传统方案
代码写DB，同步更新缓存
阿里方案
代码只需要写入DB，会有工具同步DB数据到缓存
Canal能够实现数据同步和异构
ES
DB
Redis
MySQL数据同步：mysql的Master存储日志Bin Logs，Slave通过IO线程同步数据，在使用一个SQL线程执行Master相同语句
Canal偷天换日实现方式
NoSQL
常见NoSQL数据库
HBase
列数据库
行表
容易随机读
列表
Load速度
大量数据
聚合操作
适用场景
数仓
数据分析
数据存储
并行查询、压缩
Redis
同族兄弟：Tair、Memcached
MongoDB
枪头草数据库，最接近于SQL
很多数据库SQL应用都可以使用MongoDB
对跨文档事务支持比较差，跨文档事务适用需要小心适用
面向集合，其实就是JSON，Free Style
Collection
文档2
文档2
适用场景
复杂模型变更，JSON格式，不强求Schema
高QPS读写
大对象存储
主从切换+sharding都是内置功能
Neo4J
图形化数据库不仅仅是Neo4J，其中包含GraphQL查询的数据库
适用场景
网状关系的数据查询
ES、Solr
搜索引擎
全文检索
分词
倒排序索引
由Value找到对应的Key数据
适用场景
数据异构方案
DB可以用Canal同步数据到ES
打破传统数据库范式
数据冗余
范式无用论
1NF
原子字段，不可分解
2NF & 3NF
主键相关、不可冗余
尽信书不如无书
在互联网数据库三大范式就是个P
关联表
在互联网不会使用Join
Hibernate使用很少，用的话也不用复杂查询（Many To Many）
图形数据
数据异构方式结局
快照、冗余
大宽表冗余
互联网场景
数据异构和冗余
业务第一，怎么快怎么来
阿里系数据订正流程
数据库人员构成
Owner（创建数据者），拥有变更权限
DBA（指派），拥有变更权限
码农
变更流程
1、Owner、DBA-提交审核
2、Owner->主管执行审核
3、少量数据变更，Owner或者DBA可以直接执行
4、如果数据量较大，可以由DBA审核之后再执行
Owner+DBA把控
阿里系开源项目Druid监控SQL效率
德鲁伊DB连接池
添加Druid依赖
Druid连接池配置项
Druid监控大盘
思考问题
除了主从以外，你还在项目中应用了哪些其他的灾备手段
冷备
热备（数据实时镜像/同步）
数据异构方案的设计（数据迁移）
Canal是这类问题的终结者
场景题目设计-底层存储
NoSQL
互联网数据冗余十之十一
谈谈MySQL的同步方式
Binlog方案
Canal方案
扩展问题
使用Canal完成几个简单场景
将数据库中的数据库变更反映到redis中
消费某个特殊数据变更场景，并且发布数据到MQ
中间件和平台运行监控
缓存三大坑
缓存击穿
正常读取方式
热点数据读不到缓存会发生缓存击穿
缓存过期策略
初级玩家：永不过期
高级玩家：读写分离架构-Canal数据异构方案
热点缓存策略
热点库单独存放
互斥锁-Mutex
初级玩家：到期上锁
高级玩家：提前上锁，异步刷缓存
缓存雪崩
缓存中的Key集中过期，所有业务打到数据库，把数据库打崩，会造成缓存雪崩
缓存过期策略
我们同样可以去，去调整缓存过期策略
基础时间+动态散列时间
缓存预热
在业务正式开始之前，把缓存构建起来
缓存穿透
用户请求P03数据不存在，在缓存中也没有，数据库中也没有。
黑客或者用户利用这个漏洞多次访问数据库打崩数据库
黑客或者用户利用这个漏洞多次访问数据库打崩数据库
不存在的数据，构建空的缓存Value
布隆过滤器
普通玩家：一般布隆过滤器
高级玩家：进击版的布隆过滤器
布隆过滤器
一般的BloomFilter，不能删除操作
有一定的误判率
空间越大越准
全量同步缓存
进阶的BloomFilter，解决不能删除操作，利用技术方式解决问题
消息组件选型分析
四大天王
ActiveMQ
已经过时，不能支撑互联网现在业务
RocketMQ
RabbitMQ
Kafka
三个主要特性
可靠性
RocketMQ和RabbitMQ
重试
死信队列
事务能力
Kafka的
At least once
At most once
Exctley once
会带来很大的性能开销
消息堆积能力
Kafka堆积能力最高
T+级-堆积能力
顺序读写
PageCache
吞吐量
可扩展性
集群模式
水平扩展能力
高可用 & FO
链路追踪和线上故障响应
线上监控预警机制
Splunk、Kibana各类日志报警
国外企业使用工具：Slack、Email等
国内企业使用工具：钉钉、企业微信等
业务埋点
审计日志可以埋点到Logs中或者后台业务中
关键资源
后台人员操作
统计分析
用户画像
AB测试
线上问题
Pager Duty机制
三级响应
一线开发
短信和邮件为先
其次是电话
TeamLeader（领导）
大领导
故障步骤
1、故障发生
2、技术人员接收到故障
3、问题的根本原因
4、问题的Fixed
5、RCA故障响应会议
6、资损（资源损失）
装机容量评估和应用水位
QPS
(PV * 80%)/36000s*24h*20%
双十一计算公式：(PV * 40%) / 3600s
容量评估
QPS评估/单机平均匀QPS(也是性能基线)+弹性容量
应用水位
当前QPS/容量评估承压QPS
弹性
当前QPS/性能基线QPS * 机器数
目的
监控预警
弹性计算
思考问题
题目1：项目中的缓存场景，如果并发量+++
缓存雪崩、缓存击穿、缓存穿透
热点缓存淘汰策略，多级缓存，布隆过滤器等
题目2：为什么这个场景使用RabbitMQ，换成Kafka呢
中间件特性，可靠性要求
题目3：业务埋点的场景和用途
内部审计、监控预警等
题目4：设计一套轻量级的系统水位监控系统
异步化
基于日志埋点（网络日志&应用日志）
扩展问题
缓存场景模拟
搭建数据查询接口（SpringBoot+Redis）
使用JMeter模拟用户接口（QPS不要太高）
编码实现防缓存穿透手段
Null值Key
布隆过滤器（Guava）-预先设置好值
应用层设计
服务集群的伸缩性
DNS层负载均衡
简单应用服务
扩展简单应用为集群
反向代理 & IP负载均衡
反向代理
数据链路层负载均衡
Mac地址负载均衡直接路由
利用消息组件进行解耦的场景
削峰填谷性能问题先不看
三个方向
前提条件任务可异步化执行
长任务
商户数据变更
自动风控评分
商品中心
商品编辑 & 发布流程
报表任务
生成报表并发送
任务特点
时间久
逻辑重
可异步
交互体验需要很多变更
非实时
用户验证
手机验证码
通知消息
验证邮箱
用户通知
支付业务
付款回调接口
任务特点
轻任务
低容忍
能异步就异步
发布订阅
多个下游需要消费相同语义的情况（多下游 相同语义）
语义：商品发布
富文本发布
图片空间
初始化库存
库存中心
商品上架
淘系商品
语义：商户支付过审
客户评分
风控平台
银联接入
支付中心
商户通知
邮件中心
性能规划
性能指标
RT响应时间
QPS每秒访问
吞吐量
并发数
并发能力
应用层性能版优化的方向
集群+前端优化+熔断降级暂时不考虑
复杂业务性能优化
并行和异步化
Future
商品主搜
列表页渲染
商品发布（同步）
Thread
Thread Pool
Spring Aysnc
MQ
Error
存储优化
数据缓存
分布式缓存
本地缓存
数据库层面
数据异构\冗余
SQL调优/Hints
构建性能基线
并发曲线
稳定测试
缓存的多种使用场景
全量同步场景（Canal，布隆过滤器）
非全量缓存（过期时效） - 非热点
热点数据方案参考
既然都上了缓存，那就应该有不一致的觉悟
时效缓存场景
时效缓存场景-读取缓存
时效缓存场景-写入缓存
复杂业务状态的设计原则
有限状态机的流转
订单状态
状态四要素
当前状态
触发事件
响应函数
目标状态
状态实现
规则引擎
复杂业务
业务团队可配置
MQ驱动
Job驱动
轻量级状态机
Spring Statemachine
基于Spring StateMachine的轻量级状态
思考问题
题目1：开放式问题：业务层性能调优
首先考虑异步化（MQ、异步编排、池化等）
分布式/本地缓存
数据异构（非一致性场景快速返回、查找）
题目2：缓存的一致性问题
读/写场景的一致性
Setnx，Watch+multi乐观锁
题目3：复杂业务中状态流转（订单系统设计）
规则引擎
轻量级状态机实现Spring Statemachine
扩展问题
使用Spring StateMachine丰富订单场景
Guard（状态准入）
Action（状态转移后的逻辑）
建议阅读Spring Statemachine的官方文档
微服务架构设计核心
微服务与服务建模
微服务架构设计核心点
微服务服务治理
服务生命周期
主链路规划
网络层搭建
配置管理
服务监控和调用链梳理
业务埋点
无痕埋点
用户画像采集
离散点分析
调用链梳理
微服务认知
大话微服务
微服务优缺点
糙快猛
微服务+敏捷编程
996加班+严重化内卷
上古时代
牵一发动全身
同生死共进退
一块上线一块回滚
发布周期长
半年或者一年发布一次
应用复杂度
代码混用、数据访问混乱
微服务时代（996）
小步快跑
独立演进
独立部署
快速迭代
团队赋能
在我的地盘你就得听我的
特战队
边界清晰
以大化小
服务拆分
三高应用
分治
Two Pizza原则和微服务团队
大象不能跳舞
沟通成本
互联网精神-小步快跑
微服务人员配比
设计人员
跨团队架构师
开发人员成员6-10人，不会超过10个人
Lead不是一个管理岗位
Feature Owner是在接收管理岗位出现问题时处理问题
一般负责一个子领域
测试人员
具备很强开发能力，能够完成集成测试
主链路规划
什么是主链路规划
业务的最小可用性
电商
下单
社交
点对点消息
资源调配（开源）
应用水位
弹性计算
容错方案（节流）
降级熔断
自动或者手动
分段限流
淘系主链路规划方案
服务治理
维护可用服务列表
三个问题
点对点两个微服务之间互相有哪些服务器，以及服务是否处于正常状态？
微服务的器增加、删除操作，如何确定增加或者下线？
如果微服务出现网络故障或者Out Memory等导致服务不可用或者宕机、下线？
服务治理的生命周期
1、服务注册
2、服务发现
3、服务续约/心跳
4、服务剔除
5、服务下线
案例说明
淘系下单场景的主链路案
主搜导购
导流端
站内主搜
流量占比高
阿里妈妈
现金奶牛
聚划算
直通车
分会场
类目渠道
直播
抖音等
转化端
SKU模块
商品子类（转化对象）
库存模块
生产要素（转化对象）
用户评论
图片空间
图片转化率降低
富文本TFS
文本信息转化率Factor低
收藏夹
客服中心
热销排行
视频空间
营销计算
活动信息
购物车
核心功能
商品列表信息
添加购物车
页面内部操作
修改商品
删除商品
导购模组
掌柜热卖
最近浏览
画像推荐
商家信息模组
营销计算
订单下单
下单页
创建订单
商品列表信息
营销计算
地址模块
订单转化要素
制度系统对接
微服务外围设施
微服务架构的网络层搭建
简化微服务环境搭建
注册中心或者服务备份
微服务部署结构
容器编排部署方式
思考问题
题目1：高并发系统、资源有限、如何保障业务顺利执行？
限流降级
主链路规划
由面到点
业务角度规划主链路
流量
转化率
变现场景
漏斗模型
越往下越重要
限流降级、弹性计算等
题目2：服务治理
维护一个可用服务列表，保持服务间调用正确性
服务治理声明周期
扩展问题
主链路规划思考，作为架构师你如何设计
公司项目
热门App
技术调研
主流的注册中心提供的服务治理能力
统一管理配置信息
配置中心场景
属性分发
静动态推送配置数据
开放注册
registration=false
静态文件 vs 实时推送
蓝绿测试
资源隔离
配置业务隔离
环境隔离
服务隔离
配置选型
配置中心高可用选择
拒绝单点
如何解决单点问题
单点故障
服务治理
高可用改造
配置也是一个服务
本地缓存版本控制方式
Spring Cloud-利用服务将配置管理作为服务
服务监控和调用链路梳理
业务埋点
业务埋点的意义
业务埋点的技术方向
监控预警
基于业务日志文件
业务流程
关键指标
日志关键信息
Elactic
统计分析
内部审计
操作员/操作资源维度查找
长期可追溯
业务日志：海量、可查找、长期保存
ABTest
关键链路问题排查
用户画像分析
如何埋
前端SDK代码埋点
可视化埋点
服务端埋点
理想方式
代码埋点
服务端埋点
业务埋点服务的存储特点
数量级大
需要长期保存
支持业务特征查询
适合使用文档数据库
经典案例
根据日志埋点做用户画像分析
淘系用户画像
行为数据
识别主链路转化率
漏斗模型
购物车
收藏夹
各业推荐
群体画像
午夜后购物的人有什么消费习惯
高客单价的人群有什么群体特征
地区性消费习惯
精准画像
收藏/复购最多类目
浏览/购买活跃时间段
大盘数据
PV、日均
复购率
转化率
埋什么
时间
行为数据发生时间点
地点
触发动作所在的地点
页面元素
人物
匿名用户
登录用户
事件
业务数据
埋点的几种方式
后台业务埋点
业务定制
注解埋点
使用Spring AOP原理埋点
可视化埋点
也是声明式埋点
控件响应
响应函数
埋点开关
埋点函数
埋点特点
埋点前置
降低业务入侵
成本降低
APP埋点局限
无痕埋点
无差别记录用户事件
业务事件
控件节点
后台可配
数据传递
前后数据关联
埋点特点
埋点成本低
数据清洗难度高
埋点方式选择
数据分析
无痕埋点
可视化埋点
关键链路
后台业务埋点
链路监控离群点分析
离散点分析
监控层面
异常筛查
模式识别（噪音、模型修正）
模式识别的应用
视频审核、人工审核
标签关联度
链路追踪核心
微服务之间的链路梳理
线上场景问题，如何实现链路追踪
Global Trace ID+Span ID
Zipkin
思考问题
题目1：设计一套业务埋点方案
由点到面
业务埋点
优势、场景
可视化埋点
优势、场景
无痕埋点
优势、场景
题目2：线上故障排查
链路追踪、上下游调用链
ELK、EFK
题目3：离散点分析
相通点=TP99稳定性指标
子主题
扩展问题
技术调研
链路追踪系统
尝试搭建个ELK？后面会讲
单元化（Set）架构设计
单元化架构基础
话说天下大势，分久必合，合久必分
扩展性（Scalability）
特点
可伸缩性/弹性
度量增加系统处理能力的指标
系统能力
延迟：系统处理单次请求所需时间
吞吐量：单位时间内系统处理次数
伸缩性 & 性能 & 成本等的综合结果
优点
高伸缩性
添加资源就可以对应处理能力需求增长
用户/流量/数据增长，性能指标不下降
缺点
伸缩性差
单用户性能正常
用户增长后性能指标下降
性能提升成本高
横向扩展（Horizontal Scale）
Scale Out
增加更多机器，提高系统整体性能和处理能力
分布式架构
理论上可以无线扩展
经济成本
法律法规
物理限制（机房大小）
纵向扩展（Vertical Scale）
Scale UP
曾加/强单机资源，提升单机性能，从而提高系统整体性能
CPU/内存/存储设备/ETC
集中式架构
上限低，成本高
扩展魔方
X轴扩展（Horizontal Duplication）
原点
起点，系统最初都是单机版
特征
将原始系统改造为Share nothing
复制并Load Balance
状态都存在于数据库
优点
简单易行
缺点
数据为单点
无法应对复杂度高系统
Y轴扩展（Split by Function or Service）
特征
按照功能切分系统，并以此各自扩展
Bounded Context
服务改造，代码拆分，数据拆分
优点
当X轴扩展无法满足需求时，使用Y轴扩展
微服务化后，系统更内聚
Fault isolation
缺点
改造难度高，成本高
Z轴扩展（Customer/Requestor Oriented Splits）
特征
按照用户属性来切分系统，以实现各自扩展
业务切分，如地理位置、用户类别等
数学切分，如用户ID、IP等
优点
根据不同用户提供不同服务
更近一步的Fault isolation
可与Y轴扩展联合
缺点
不能降低系统复杂度，增加运维复杂度
一致性
数据库事务一致性 - ACID
A：Atomicity（原子性）
全部成功或者全部失败
C：Consistency（一致性）
从一个正确状态转移到另一个正确的状态（强一致性）
I：Isolation（隔离性）
并发事务隔离，互不干扰
D：Duration（持久化）
状态变更不丢失
最终一致性
分布式系统达成高可用、高扩展需要
数据分主/从（或源/副本）
写入主库成功，用户读取从库，数据不是最新（不一致）
从库同步成功，读取主从库都是最新数据（一致）
保证整体系统最终都是最新数据从而实现一致性（即最终一致性）
从不一致到一致的时间无论长短，都是最终一致性
相对数据库ACID的一致性，最终一致性是弱一致性
高可用HA（Availability）
系统不能提供服务的时间趋近于零
MTBF（Mean Time Between Failure）
平均无故障工作时间
MTTR（Mean Time To Repair）
平均修复时间
A = MTBF/(MTBF+MTTR)
解决方案
冗余
目的是尽量缩短宕机时间，增加服务维持时间
可靠性（Reliability）
在给你的时间间隔和给定条件下，系统可以无故障持续运行的概率
影响可靠性的因素
所有可能引起故障的因素
故障率较高，可靠性越低
重点在故障次数
Reliability是Availability的子集
稳定性（Stability）
在一个运行周期内，一定条件下，在持续操作时间内出错的概率，性能劣化趋势
不能出错
系统响应是否一致，行为是否稳定
要求范围内响应
Availability是Stability的子集
符合预期
高可用、可靠性、稳定性关系
容错（Fault Tolerance）
在错误发生时，系统依然能够提供正确的功能的能力
直接关联到可靠性和可用性
解决方案
空间冗余（Space redundancy）
提供额外的组件、功能或数据（硬件/软件/信息）
时间冗余（Time redundancy）
重试（重新计算/重新传输）
分布式系统
主要特点
一组独立计算的单元通过网络连接，并透明地对外提供统一服务
组件可以支持各自独立并发
对用户透明，用户感知是一个系统而非多个组件
组件间通过消息进行通信
易于扩展
分布式系统CAP理论
C：Consistency（一致性）
系统中任何一个节点对外提供相同的、最新的、成功的写的结果
A：Availabilty（可用性）
系统中的存活节点总能对外提供读写功能
P：Partition toleration（分区容错）
部分分区失效时，系统仍旧提供正确的读写功能
遵循CAP理论系统应用特点
一致性、可用性和分区容错三者无法在分布式系统中被同事满足，并且最多只能满足其中两个
CA系统
不允许P（分区），则保证C（强一致性）和A（可用性）
CP系统
不要求A（可用），系统内多节点同步时间长，如数据库集群
AP系统
高可用允许分区，每个节点用本地数据，放弃一致性
单元化架构核心问题与概念
Why需要单元化复杂架构
应对增长
传统架构无法满足日益增长的互联网用户需求
扩容
需要新架构更近一步提升系统的扩展能力
系统稳定性
新架构需要高可用】相对独立和故障隔离使整体系统更稳定
灰度发布
系统和组件都纳入版本管理，按需求部署并进行灰度发布
核心问题
应用扩展性
应用单体化进化到分布式
应用扩展达到上限
数据库无法支撑应用层的扩展
数据中心扩展性
单数据中心上限受物理因素限制
系统需求超过单数据中心如何扩展
应用如何在多数据中心灵活切换
容错性
应用层面
组件冗余
数据冗余
时间冗余（重试）
数据中心
系统冗余（多地部署）
数据冗余（数据复制）
架构进化史
分层（Layer）架构
系统以服务的形式满足内外的业务要求
以SOA或微服务架构为技术指导原则来构建各种服务
按照特定规则讲不同服务分配到不同层，并定义层与层之间的依赖（接口）
层自主权高、逻辑清洗、单向依赖，满足大部分系统需求
架构层的扩展性上限受诸多因素制约
分段（Segment）架构
Agile开发方式、虚拟化和容器化可以在同一架构层中通过隔离和自主权划分为更细粒度的逻辑段（Segment）
根据业务能力，在每一层中将不同的组件划分到不同段中
实现手段
Runtime Partitioning
Multi-tenancy
Platform as a service
分段架构无法实现一个自由扩展的、自包含的去中心化系统
单元化（Blocking）架构
将系统按照数据特征和功能垂直地划分为一个个单元
一个单元就是一个能完成所有业务操作的自包含集合
包含业务所需的所有业务、数据及资源
一个单元可以独立部署、管理及监控
部署在一个或多个数据中心，提升整体系统的扩展上限
单元化架构下，系统仍然分层
层的任意组件都属于且仅属于同一单元
上层调用下层时，仅依赖于本单元内的层
用户
用户就是系统交互的人
将系统拆解单元化时，用户是很重要的参考因素
按照用户的属性、地域等特征将系统单元化
组件
组件是单元化架构里最小院子单位
一个组件就是代表一组业务功能或服务
组件自定义范围和形态，在其定义域内独立运行
组件依赖于其他组件，也可以被其他组件依赖
功能尽量不要跨组件完成
单元与组件的关系
一个单元由一个或者多个组件组成
一个单元就是一组从设计到实现被分配到一个部署单位的组件
一个单元就是一个可以被构建、部署和管理的不可分割的完备组件
名称和版本
所有单元都必须被命名，且全局唯一
命名的主要作用是为后续发布和管理
单元也会迭代和进化，必须一版本管理形式来控制
单元内的组件，也必须被命名和版本化管理
独立性
所有单元必须是独立的，才能达成容错/容灾
所有单元都是可以被独立部署的
设计单元时，各单元功能是独立的
逻辑无重叠
避免不必要的依赖
完全性（完备性）
一个业务功能在一个单元内完成，避免跨单元完成
尽量避免跨单元
按照逻辑划分单元，相关业务场景应置于同一个单元，达成逻辑完备
一个单元能提供的功能，其所需要服务和数据都要划分到如同一个单元内
独立部署
一个单元就是一个可以被独立部署的组件
设计单元的最终目的是该单元独立部署
三层迭代
单元内组件可以独立迭代
各个单元可以独立迭代
系统作为多个单元的集合可以整体迭代
单元内外通信
一个单元由一组或者多组组件构成，并对外申明其功能
单元的功能必须提供某种网络访问接口，内部的组件不能直接暴露，只能通过统一的Ingress对外提供服务
如果单元对外界有依赖，必须通过egress进行访问
单元内的组件可以通过允许的通信协议互相通信
When
什么时候？什么情况下我们的系统需要运用单元化架构？
异地多活
系统功能和用户所在地域有强关联性
外卖、物流和所有的O2O等
高可用要求较高，不能大规模长时间宕机的系统
如银行、电信、证券等系统
互联网用户天然分布式、多地数据中心以提高访问速度
预防极端气候现象
地震、飓风、水灾引起的数据中心整体不可用
突破扩展上限
系统能力或用户数发展到单机房/单数据中心成为瓶颈
多机房部署而不改造架构，引起的跨机房调用性能下降
数据库主库单点，连接数有限，不能支持应用的持续发展
系统所服务的用户数超过了阈值，单数据中心无法支撑其增长
超十亿用户微信、支付宝、Google、Facebook\Whatsapp等
单元化架构设计
设计原则
单元化架构设计的方式和方法
透明
对开发透明
在做实现时，不依赖于单元划分和部署
对组件透明
在组件运行时，不感知其承载单元
对数据透明
数据库并不知道为哪个单元提供服务
业务可分片
系统业务复杂度足够高
系统可以按照某一维度进行拆分
系统数据必须可以被拆分
业务可包含
同一业务功能必须在单元内完成
统一业务操作所需数据也在该公办呢个单元内
尽量避免跨单元依赖
设计三要素
系统切分
功能
用户
系统路由
公有云
中间件
数据复制
一致
延时
系统单元化切分
业务
DDD切分领域服务、数据和业务流程
切分出的服务和数据属于同一单元
出现交集（重叠）时，一单间访问量做决策指标
业务流程所需组件和数据划分在同一单元
一个业务流程在同单元执行，保证性能和稳定性
尽量避免跨单元的服务访问和数据库读写
同单元高内聚，单元间低耦合
与组织架构和核心业务流程强相关
核心业务保证高可用，高增长必须单元化部署
边缘业务跟随核心业务数据分配单元
功能力度要适当
粗粒度单元，轻易超过单元资源承载上线，需要二次拆分
细粒度单元，单元内资源浪费，性价比低
开发团队随着单元化架构调整
整个过程需要持续迭代
用户
用户属性对系统核心功能有决定性作用
外卖、叫车、共享等业务严重依赖于用户的地狱属性
VIP用户、大买家等不同类型的用户
新用户按照规则自动分配单元，存量数据按规则做数据迁移
相同属性的数据聚集在同一单元
一个单元内完成系统所有核心业务，单元内不再按功能拆分
数据ID规则
不提供单元同时产生数据，且数据有同步需求，ID必须保证跨单元不重复
由ID可以按规则推算所属单元
用户属性划分导致单元规模层次不齐
过于庞大的单元，二次拆分
合并多个小单元为一个常规单元
当用户属性改变时、系统自动同步数据
该类属性是低频变化
系统同步速度高于属性变化表速度
数据
按照数据某种属性进行单元划分
无业务含义，不可更改，不重复，一般选ID或者时间戳
水平扩展上限高
账户、订单、流水、商户、商品等比较容易于切分
通过规则推算所属单元
设计规则使数据均匀
单元分配的数据比例等于其整体流量比例
无业务依赖，跨单元访问不可控
引入中间件实现开发者透明
如何处理
无法切分的数据，高频访问
创建页数属性附属单元
该单元必须和切分单元在同一数据中心\机房，以降低访问延时
任何一个切分单元对附属单元的写入都会同步到其他附属单元
大部分系统都是邪少读多，写复制的成本远低于高频读操作
数据实时性要求高的系统可能会失败
无法切分的数据，低频访问
系统共享同一单元
低频读写，时延不影响主业务流程，代价可接受
根据数据中心距离，选择与所有数据中心都相对应最近的数据中心作为共享单元的部署地
单元内部垂直切分
单元瓶颈优秀考虑内部垂直切分
综合库
创建单独的综合库，同步汇总所有单元的数据，供非实时业务使用
单元组成元素
组件
服务，业务逻辑
不直接被单元外访问
独立构建、发布
数据
仅限该单元数据
中间件
内部通信
与单元路由有关的中间件
反向代理
单元内服务的反向代理服务器，供外部访问
单元选择功能的路由器
安全和控制策略的中心
网关
单元内访问外部服务的代理服务器
单元选择功能的代理服务器
单元路由
外网访问
为不同的数据中心的不同单元分配不同域名
建立全局路由规则服务
或客户端登录后本地计算所属单元（或数据中心）
客户端直接访问所属单元
未改造客户端、匿名用户等
利用云有云就近提供服务
由业务服务设置Cookie标志，指定所属单元
Tag、Cookie或URL参数指定要访问单元
公有云或CDN提供此服务
单元网关
单元网关也是该单元的反向代理服务器
单元网关根据规则计算请求所属单元
属于当前单元，直接路由请求到正确的组件（服务）
属于其他单元，转发到对应的正确单元并上报路由错误信息
无法判定，根据路由规则发送给组件，由业务逻辑进一步辨别
Tag、Cookie或URL参数指定要访问单元
应用层
统一封装的开发框架处理请求，或者拦截或者过滤器层对开发者透明
根据请求计算所属单元，属于本单元则继续处理
不属于本单元则转发
无法判定就交予业务逻辑层或数据库访问层来决定
业务层
普通对单元无感知的业务，按原有逻辑直接处理
依赖于单元信息的业务，可以自行计算或从容器注入单元信息
应用层操作Cookie设置单元信息，方便后续单元网管路由
中间件
远程调用框架要透明化支持自动单元路由
RPC
HttpClient
根据请求计算出正确的目标单元并自动路由
数据访问层
最后防线
通过数据访问的驱动程序或架构改造，使其对开发者透明
如果有误，将错误的访问路由到正确的数据库（或表）
数据复制
单元化的数据为本单元组件服务
依赖决定是否需要复制数据
单元间互相复制
通过数据中台复制
根据业务场景选择
强一致/最终一致
最大数据延迟
读写失败对业务的影响
关系型数据库复制
MySQL、Oracle
NoSQL数据库复制
MongoDB、Redis
消息中间件复制
Kafka、RabbitMQ
经典案例
某电商公司单元化架构
外卖业务单元化架构
思考问题
当系统出现什么指标，就表示单元化势在必行
可靠性、可用性、稳定性
在系统单元化之后，数据同步如何实施
数据同步
在进行单元化设计时，如何选择单元的，粒度
当前基础架构在一个单元支持的用户量
服务网格架构设计
架构原则的延伸
目标
跟上时代的步伐，玩转大厂的潮牌"Service Mesh"
理解Service Mesh非入侵式服务网格的价值
实战Istio服务网格，实现可用性、安全性、可控性架构
为后续DevOps、服务治理、安全设计和云架构做好铺垫
清洗架构设计原则的延伸-非入侵式架构治理
架构设计原则延伸
环境异构兼容性
What
环境异构兼容性、业务非侵入性、DevOps一体化
Why
互联网新浪潮、大厂趋之若鹜的技术方向
How
理论扩展、案例分析
业务非侵入性
系统、语言、设备
容器集装箱技术，解决不同语言、操作系统等问题
服务治理：出错重试、熔断、限流
服务出现位置与领域等问题，我们就可以抽象服务网格，也就是我们说的Service Mesh
完成功能开发，还需要做什么？
应用授权用户或者账号，也就是我们的说的ID
对称秘钥的认证、授权
网络安全性的延迟、容错、熔断等
服务策略的配额、限流、QoS
可观察性的日志收集、性能监控、链路追踪、拓扑管理等
容器非侵入式POD
边车系统
可用性
故障注入、数据重放、重试、重定向、熔断、蓝绿/金丝雀发布
安全性
传输加密、用户认证、服务授权
可控性
前置检查、限流管理、遥测报告
微服务和DevOps
微服务化和DevOps的矛盾
团队变小 -“微”服务
任务变多 - Dev + Ops
是选择 + 996
互联网萌芽年代
20世纪50年代到90年代
国防、教育、科研、MIT、UCLA、哈佛、贝尔实验室
TCP/IP - 不快、不稳定；（轻盈）下里巴人、底层通信统一
重回DevOps时代
统一：采用一套服务治理机制，完成网格大一统
简化：服务治理外置到便车处理
专注：只关心业务逻辑和核心功能
istio Service Mesh
经典案例
问题描述
RPC怎么玩？
SDK全替换？
Groovy路由策略怎么办？
Sentinel组件得抛弃？
Nacos中心去留？
边车在线升级？
延时？CPU消耗？
解决办法
控制层组合管理、数据层边车增强
蚂蚁金服 SPFAMesh
Service Mesh带来了什么
基础设施下沉
业务逻辑和服务治理框架解耦
SDK轻量化
减少版本碎片和升级困扰
没有“银弹”
思考问题
题目1：你在架构设计中如何实现服务治理？
题眼
认证授权、限流熔断、链路追踪、服务发现、负载均衡
加分项
能级和具体技术栈（Spring Cloud、Service Mesh等），从应用架构、系统架构多角度分享实战经验
题目2：如何设计一套对于业务透明的弹性伸缩架构？
题眼
非侵入式架构、Serverless弹性伸缩
加分项
能结合具体技术栈（比如Kubernetes、Istio、Knative等）
从资源伸缩、负载分流、监控决策等角度深入分析设计的要点和难点
扩展问题
分享一个曾经设计过的对于应用透明的、无侵入式的架构框架或组件，聊一下其中有何难点
架构非功能性实现
理解和实战可用性需求-Envoy Proxy组件
概述信息
What
服务发布、混沌工程、全链路测试、业务中断防护
Why
可用性-生产系统的核心需求
How
理论讲解、手把手实战
服务发布
蓝绿发布
金丝雀/灰度发布
Istio负载管理
Virtual Service虚拟服务 - 客户视角
Destination Rule目标规则 - 资源视角
两者结合 - 内部网络管理
Istio Envoy实现细节
Destination Rule是多个
经典案例
BookInfo多语言应用
混沌工程
故障注入
混沌工程主要手段之一
目标：验证模块耦合性、服务反腐层、应用熔断能力
Virtual Service 故障注入：Delay延时注入、Abort丢包注入
实现细节
全链路测试
数据包重放
流量镜像服务主要手段之一
目标：网络监控、大数据分析、影子工程、全链路压测
Virtual Service数据包重放：Mirror数据镜像
业务中断防护
出错重试
业务中端防御主要手段之一
目标：链路稳定性，防止网络抖动和异常
Virtual Service 出错重试：Retries重试条件、时间、次数
HTTP重定向
重定向：301、用户可见
重写：修改URL指向、用户不可见
Virtual Service 重定向、重写：Redirect、Rewrite
服务熔断
业务损失最小化的主要手段之一
思路：连接池管理、异常点检测
Destination Rule熔断：ConnectionPool、OurlierDetection
理解和实战安全性需求-Istiod组件
理解和实战可控性需求-Envoy + 第三方工具
架构非功能性实现
Pilot组件实现可用性
Citadel组件实现安全性
Mixer组件实现可控性
0 条评论
下一页
