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