1,分布式微服务架构设计原理
2,彻底解决分布式系统一致性的问题
3,服务化系统容量评估和性能保障
4,大数据日志系统的构建
5,基于调用链的服务治理系统的设计与实现
6,java服务的线上应急和技术攻关
7,服务的容器化过程
8,敏捷开发2.0的自动化工具
1,分布式微服务架构设计原理
传统单体架构到服务化架构
javaee->ssh->服务化(soa[webservice,esb])->微服务
微服务架构的产生
Web Service 的问题如下
依赖中心化的服务发现机制。
使用 SOAP 通信协议，通常使用 XML 格式来序列化通信数据， XML 格式的数据冗余太大，协议太重。
服务化管理和治理设施并不完善。
ESB 的问题如下
ESB 虽然是 SOA 实现的 种方式，却更多地体现了系统集成的便利性，通过统务总线将服务组合在起，并提供组合的业务流程服务
组合在 ESB 上的服务本身可能是 个过重的整体服务，或者是传统的 JEE 服务等。
ESB 视图通过总线来隐藏系统内部的复杂性，但是系统内部的复杂性仍然存在
对于总线本身的中心化的管理模型，系统变更影响的范围经常会随之扩大
微服务架构
微服务把每一个职责单 的功能放在 个独立的服务中
每个服务运行在一个单独的进程中。
每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑伸缩的效果。
每个服务有自己的数据存储，实际上，每个服务应该有自己独享的数据库、缓存、消息队列等资源。
每个服务应该有自己的运营平台，以及独 的运 人员，这包括技术运维和业务运营人员：每个服务都高度自治，内部的变化对外透明。
每个服务都可根据性能需求独立地进行水平伸缩
微服务架构与 SOA 服务化的对比
1.目的不同
SOA 服务化涉及的范围更广 些，强调不同的异构服务之间的协作和契约 ，并强调有效集成、业务流程编排、历史应用集成等，典型代表为 Web Service ESB
微服务使用 系列的微小服务来实现整体的业务流程，目的是有效地拆分应用，实现敏捷开发和部署，在每个微小服务的团队里，减少了跨团队的沟通，让专业的人做专业的事，缩小变更和迭代影响的范围，并达到单一微服务更容易水平扩展的目的。
2.部署方式不同
微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容、缩容的 Docker 技术来实现自动化的容器管理 每个微服务运行在单 的进程内，微服务中的部署互相独互不影响。
SOA 通常将多个业务服务通过组件化模块方式打包在 War 包里，然后统部署在一个应用服务器上。
3.服务植度不同
微服务倡导将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理，拆到职责单 甚至小到不能再进行拆分。
SOA 粒度没有要求 在实践中服务通常是粗粒度的，强调接口契约的规范化，内部实现可以更粗粒度
根据康威定律，团队的交流机制应该与架构设计机制相对应
微服务架构中职能团队的划分
在业务服务的内部实现需要升级或者变更时，团队内 的各角色成员进行沟通即可，而不需要进行跨团队沟通，这大大提高了沟通效率。只有服务之间的接口需要变更时才需要跨部门沟通
微服务的去中心化治理
微服务倡导去中心化的治理，不推荐每个微服务都使用相同的标准和技术来开发和使用服务
微服务的交互模式
读者窑错模式
读者容错模式（ Tolerant Reader ）指微服务化中服务提供者和消费者之间如何对接口的改变进行容错
参数可以使用枚举值,返回值的DTO中禁止使用枚举值
消费者驱动契约模式
提供者契约(提供者规定)
消费者提供契约(要求提供者提供需要的数据)
消费者驱动契约(提供者向消费者提供承诺遵守的约束,不可随意改变)
去数据共享模式
不要共享缓存和数据库资源
微服务的分解和组合模式
领域的动词和名词来划分微服务,每个名词和动词都可以是一个微服务
服务代理模式
对读请求切换设计一个开关,打开时请求新系统,关闭时查询老系统
服务聚合模式
查询后聚合返回
服务串联模式
扣减库存(需要同步的场景)
服务分支模式
使用服务组合和服务代理模式时,不要使用服务串联模式和服务分支模式
服务异步消息模式
服务共享数据模式
共享缓存数据(公共不可删除数据)
单元化架构
微服务共享资源(缓存/数据库)
遗留的整体服务
没有完全理解和有把握的情况下(数据库表)可以保持现状
微服务问题措施和方案
船舱隔离模式
微服务容器分组
线程池隔离
熔断模式
限流模式
计数器
令牌桶
信号量
失效转移模式
java平台微服务架构的项目组织形式
微服务项目的依赖关系
微服务项目层级结构(永远不要在本地事务中调用远程服务)
微服务项目的持续发布
服务化管理和治理框架的技术选型
RPC
JDK RMI
Hessian/Burlap
Spring HTTP Invoker
服务化
Dubbo
HSF
Thrift
AXIS
MuleESB
微服务
springboot
Netflix
SpringcloudNetflix
2,分布式一致性问题(重点)
水平拆分(横向线性扩展)
垂直拆分(功能划分)
一致性问题
下单和扣库存如何保持一致
尽量保证将订单和库存放入同一个数据库分片
同步调用超时
异步回调超时
掉单
系统间状态不一致
缓存和数据库不一致
本地缓存节点间不一致
缓存数据结构不一致
模式和思路
A:原子性
C:一致性
I:隔离性
D:持久性
cap
C:一致性
A:可用性
P:分区容忍性
base
BA:基本可用
S:软状态,状态可以在一段时间内不同步
E:最终一致性(中间状态继续处理未完成的请求或者退回到原始状态)
1,定时任务捞取未完成的任务(注意数据库性能问题)
2,写前日志
3,状态字段
数据库事务->同一个分片->不同分片(最终一致性)
分布式一致性协议
应用程序,事务管理器(协调者),资源管理器(参与者),通信资源管理器
两阶段提交协议(不使用)
1,准备,2,提交
问题:阻塞,单点故障,脑裂
三阶段提交协议
添加超时机制
询问阶段:异常中止
准备阶段:询问时异常中止,超时会提交
提交阶段:中止则undo
TCC(try,comfirm,cancel)
自我修复能力 + 人工
问题
极端情况会有参与者没有收到指令,需要通过补偿的方式自动修复
脑裂
最终一致性
查询模式
提供接口(唯一标识)查询状态
补偿模式
快速失败策略
异步确保模式
定期校对模式
可靠消息模式
消息的可靠发送
1,待发送状态后维护
2,消息数据库独立
消息处理器的幂等性
常用方法:
使用数据表的唯一建进行滤重,拒绝重复的请求
使用分布式表对请求进行滤重
使用状态流转的方向性来滤重,通常使用数据库的行级锁来实现
根据业务的特点,操作本身就是幂等的(增删查)
缓存一致性模式
如果性能要求不是非常高,则尽量使用分布式缓存,而不要使用本地缓存
写缓存时数据一定要完整
使用缓存牺牲了一致性,数据库与缓存只需要保持弱一致性
读的顺序是先读缓存,后读数据库,写的顺序要先写数据库,后写缓存
超时处理模式
同步调用模式(JDBC的短小同步阻塞(BIO))
接口异步调用模式(适用于非核心链路上负载较高的处理环节)
消息队列异步处理模式(适用于非核心链路上负载较高的处理环节(上下游))
同步与异步的抉择
尽量使用异步替换同步操作
能用同步解决的问题,不要引入异步
同步调用模式下的解决方案
服务契约
两状态(成功/失败)
同步调用超时发生在使用方调用此同步接口的过程中(第一个服务)
查询模式+超时重试(幂等)
同步调用超时发生在内部服务1调用服务2的过程中
快速失败策略
三状态(成功/失败/处理中)
同步调用超时发生在使用方调用此同步接口的过程中(第一个服务)
查询接口补上
同步调用超时发生在内部服务1调用服务2的过程中
返回处理中(没有回复则可以重试),服务2接口实现幂等性
异步调用模式下的解决方案
受理和未受理
异步调用接口超时
查询补齐状态
异步调用内部超时
查询接口,处理成功后异步调用
异步调用回调超时
通知子系统专门处理回调通知
重新补偿
消息队列异步处理模式的解决方案
消费队列的生产者超时(重试三次/定期校对模式)
消息队列的消费者超时(自动增长消费的偏移量(自动确认消费)/手工提交消费的偏移量(手动确认消费))
允许丢消息使用自动确认消费,不允许丢消息使用手工确认消费
超时补偿原则
快速失败和内部补偿
调用方补偿和接收方补偿
A调用B,如果有响应则成功,如果B处理失败由B重试或补偿
A调用B,如果没有响应则重试,B做幂等
迁移开关的设计
订单开关
3,服务化系统容量评估与保障(重点)
视图: 数据视图/逻辑视图/开发视图/进程视图/物理视图/性能视图/安全视图
ATAM方法论
是一个能够在项目实施之前评估架构是否能够满足这些非功能质量的方法论
性能: 运行效率,性价比
可用性: 宕机时间,出错恢复,可靠性
可伸缩: 垂直伸缩,水平伸缩
可扩展: 可插拔,组件重用
安全性: 数据安全,加密,熔断,防攻击
非功能质量需求的具体指标
应用服务器
负载均衡策略
高可用策略
IO模型
线程池模型
线程池中的线程数量
是否多业务混合部署
每天的请求量
各接口的访问峰值
平均的请求响应时间
最大的请求响应时间
在线的用户量
请求的大小
网卡的IO流量
磁盘的IO负载
内存的使用情况
CPU的使用情况
请求的内容是否包含大对象
GC收集器的选项和配置
数据库
复制模型
失效转移策略
容灾策略
归档策略
读写分离策略
分库分表策略
静态数据和半静态数据是否使用缓存
有没有考虑缓存穿透并压垮数据库的情况
缓存失效和缓存数据预热策略
当前的数据容量
每天的数据增量
每秒的读峰值
每秒的写峰值
每秒的事务量峰值
查询是否走索引
有没有大数据量的查询和范围查询
有没有多表关联,关联是否用到索引
有没有使用悲观锁,是否可以改造成乐观锁,是否可以利用数据库内置行级锁
事务和一致性级别
使用的数据源及连接数等配置
是否开启数JDBC诊断日志
有没有存储过程
伸缩策略(分区表,自然时间分表,水平分库分表)
水平分库分表实现方法(客户端,代理,nosql)
缓存
复制模型
失效转移
持久策略
淘汰策略
线程模型
预热方法
哈希分片策略
缓存内容的大小
缓存内容的数量
缓存内容的过期时间
缓存的数据结构
每秒的读峰值
每秒的写峰值
冷热数据比例
是否有可能发送缓存穿透
是否有大对象
是否使用缓存实现分布式锁
是否使用缓存支持的脚本(Lua)
是否避免了Race Condiction
缓存分片方法(客户端,代理,集群)
消息队列
复制模型
失效模型
持久策略
每天平均的数据增量
消息持久的过期时间
每秒的读峰值
每秒的写峰值
每条消息的大小
平均延迟
最大延迟
消费者线程池模型
哈希分片策略
消息的可靠投递
消费者的处理流程和持久机制
技术评审提纲
现状
业务背景
技术背景
需求
业务需求
性能需求
方案描述
概述
详细说明(结合图)
中间件
逻辑架构(模块划分,模块通信)
数据架构(数据结构,存储策略)
异常处理
性能评估
单机并发量
单机容量
单机吞吐量的峰值
预估资源
方案的优缺点
方案对比
风险评估
工作量评估
量级评估标准
通用标准
容量:5倍冗余
用户的常用地址容量: 30年
数据物流订单的容量: 3年
第三方物流查询接口: 5000/s
mysql
单端口读: 1000/s
单端口写: 700/s
单表容量: 5000万条
redis
单端口读: 40000/s
单端口写: 40000/s
单表容量: 32G
kafka
单机读: 30000/s
单机写: 5000/s
应用服务器
请求量的峰值: 5000/s
假设需求方案
1,最大性能方案
数据库容量评估
读操作吞吐量
1400万且50%的下单时段集中在两个小时内计算
1400w*0.5/(2*60*60)=1000/s
五倍冗余=1000/s*5=5000/s,需要5端口数据库服务读
写操作吞吐量
20%用户在下单时会增加一条常用地址
1400w*0.2+5w/(2*60*60)=400/s
五倍冗余=400/s*5=2000/s, 需要3端口数据库服务写, 2倍对齐,需要4端口
2亿用户,5个常用地址,30年
2(亿+5万*365*30)*5=35亿
五倍冗余=35亿*5=175亿,需要350张表,2倍对齐,需要512张表
混合部署8主8备
主从部署3主6从,与两倍数量对齐,4主8从
512表 = 4端口*32库*4表
缓存容量评估
缓存24小时,每天下单的用户均为不同用户,每个用户5个常用地址,每个地址大小为1K
1400w*5*1K=70GB
五倍冗余=70*5=350GB
每台redis32G, 需要11台机器
应用服务器资源评估
数据库读写可以满足,避免单台,2台
考虑第三方接口吞吐量的限制
2,最小资源方案(考虑分库分表)
初期
单台机器
暂不考虑使用缓存和消息队列(但是保留接口(开关控制))
常用地址
1端口*128库*4表, 1主1从
物流订单和订单记录
1端口*512库*8表, 1主1从
性能评估参考
常用的应用层性能指标参考标准
通用标准
容量按照峰值的5倍冗余计算
分库分表后的容量一般可存储30年的数据。
第三方查询接口吞吐量为5000/s
单条数据库记录占用大约1KB的空间。
mysql
单端口读: 1000/s
单端口写: 700/s
单表容量: 5000万条。
redis
单端口读: 40000/s
单端口写: 40000/s
单端口内存容量: 32GB
kafka
单机读: 30000/s
单机写: 5000/s
性能测试方案的设计和最佳实践
明确压测目标
吞吐量=1s/响应时间*并发数(核数)
对外输出
平均响应时间
最大响应时间
可伸缩能力
持续运行时间
压测场景设计和压测方案
业务模型分析
接口调用比例
确定测试类型
基准测试(单线程单接口无压力)
容量测试(加大并发用户量)
负载测试(梯度加压,不断增加并发数)
混合业务测试
稳定性测试
异常测试
确定加压方式
瞬间加压
逐渐加压(抛物线)
梯度加压(梯度函数)
确定延时方式
一个请求一个请求
时间间隔请求
时间间隔均衡地发送请求
确定吞吐量200/s
100/s|200/s|300/s
并根据目标吞吐量和基准测试的响应时间，估算出需要使用的并发数
将基准测试的响应时间作为客户端发送请求的步长,将并发数作为客户端施加负载的线程数
一个测试脚本一个单独的业务流程
系统的资源占用情况
系统层面的指标： CPU、内存、磁盘 1/0 、网络带宽、线程数、打开的文件句柄、 线程
切换和打开的 Socket 数量等。
接口的吞吐量、响应时间和超时情况等
数据库的慢 SQL SQL 行读、锁等待、死锁、缓冲区命中情况和索引的使用情况等。
缓存的读写操作的吞吐量、缓存使用量的增加数量、响应时间和超时情况等。
消息列队的吞吐量变化情况、响应时间和超时情况等
压测报告
压测过程中记录的压测数据。
分析是否满足既定的压测目标
指出系统存在的瓶颈点。
提出系统存在的潜在风险
对系统存在的瓶颈点和潜在风险提出改进意见
有用的压测工具
ab -> http 性能
jmater -> 分析整体性能
mysqlslap -> 模拟读写,混合读写,查询等不同场景
mysqlslap -a -uroot -pyouarebest
100个线程
mysqlslap a - c 100 -uroot - pyouarebest
结果求平均值
mysqlslap -a i 10 -uroot - pyouarebest
测试读
rnysqlslap - a -clO --nurnber-of-quer es=lOOO --auto-generate-sql-load- type=read
-uroot -pyouarebest
测试写
mysqlslap -a -cl 0 --number-of-queries=l 000 - -auto-genera te- sql-load- type=wri te
-uroot -pyouarebest
读写混合
mysqlslap -a -clO --number-of-queries=lOOO --auto-generate-sql-load-type=mixed
-uroot -pyouarebest
sysbench -> cpu性能测试
sysbench --test=cpu --cpu-max-prime=20000 run
线程锁性能测试
robert@robert-ubuntul410 : ~$ sysbench --test=threads --num-threads=64
--thread-yields=lOO --thread-locks=2 run
磁盘io性能测试
sysbench --test=fileio --file- num=l6 -- file total ze=lOOM prepare
sysbench --test=fileio --file-total-s ze=lOOM - - file - test- mode=rndrd
--max-time=lBO --max-requests=lOOOOOOOO --num-threads=l6 --init- rng=on --file-num=l6
--file-extra-flags=direct --file-fsync-freq=O -- le-block size=l6384 run
sysbench --test=fileio --file- num=l6 --file-total-size=2G cleanup
内存性能测试
sysbench --test=memory --num-threads=512
--memory-block-size=256M --memory total-size=32G run
mysql事务性操作测试
sysbench --test=oltp --mysql-table-engi e=myisam oltp-table- size=lOOO
--mysql-user=root --mysql-host=localhost - - mysql-password=youarebest
--mysql-db=test run
dd -> IO读取速度
dd if=/home/robert/test-file of=/dev/null bs=512 count=l0240000
loadrunner -> 商业化(功能齐全)
hprof -> jdk自带
java agentlib : hprof=cpu=times,interval=20,depth=3 com.dsa.HprofSample
4,大数据日志系统的构建
JDK Logger
Commons Logging
Slf4j(接口)
Log4j
Logback
Log4j2
开发人员的日志意识
日志级别设置
最佳实践
QA 环境可以使用 debug 及以下级别的日志。
刚刚上线的应用还没有到稳定期，使用 debug 级别的日志
上线后稳定的应用，使用 info 级别的日志
常年不出现问题的应用使用 πor 级别的日志即可
对于不同的情况应该使用的日志级别如下。
使用 trace 级别的日志输出最细粒度的信息事件，通过这些信息可以跟踪程序执行的任一步骤。
使用 debug 级别的日志输出细粒度的信息事件，这些信息对调试应用程序非常有用。
使用 info 级别的日志输出粗粒度的信息事件，突出强调应用程序运行的关键逻辑和过程。
使用 warn 级别的日志输出可能出现的错误，或者输出潜在发生错误的环境信息，或打印用户输入的非法信息。
使用 eηor 级别的输出错误事件，但仍然不影响系统的继续运行，在 Java 程序中发生异
定要记录 erro 志，并且打印异常堆拢。异常在封装后抛出时一定要保留根源异
常和错误信息，构成异常树，因为在解决线上问题时，日志中的异常堆棋和异常信息
都是非常重要的线索。
fatal 级别代表严重的错误事件，将会导致应用程序的退出。
日志数量和大小
不要随便把对象json序列化打印出来
每个项目单条日志不能超过1Kb
日志采集器
logstash
fluentd
flume
scribe
fsyslog
Logstash 会用更多的内存，对于大量的服务节点可以使用 Fi lebeat 来代替
相比Logstash,Fluentd 会用更少的内存,可以用Fluent Bit Fluentd Forwarder实现更轻量级的收集器
日志缓冲队列
日志解析
日志存储和搜索
日志展示系统
监控和报警
日志系统的容量和性能评估
ELK系统的构建与使用
5,基于调用链的服务治理系统的设计与实现
pinpoint
zipkin
cat
调用链跟踪的原理
traceid/spanid/parentspanid
java应用系统的采集方法
应用层主动推送,aop推送,javaagengt字节码增强,大数据日志推送
6,服务的线上应急和技术攻关(重点)
海恩法则
事故的发生是量的积累的结果。
再好的技术、再完美的规章 在实际操作层面也无法取代人自身的素质和责任心
墨菲定律
任何事情都没有表面看起来那么简单
所有事情的发展都会比你预计的时间长
会出错的事总会出错。
如果你担心某种情况发生，那么它更有可能发生
应急原则
应第一时间恢复系统而不是彻底解决问题，快速止损。
有明显的资金损失时，要在第一时间升级，快速止损
应急指挥要围绕目标，快速启动应急过程和快速决策止损方案。
当前应急责任人如果在短时间内不能解决问题，则必须进行升级处理。
应急过程中在不影响用户体验的前提下，要保留部分现场和数据。
线上应急的方法和流程
发现问题
定位问题
问题系统最近是否进行了上线？
依赖的基础平台和资源是否进行了上线或者升级？
依赖的系统最近是否进行了上线？
运营是否在系统里面做过运营变更？
网络是否有波动？
最近的业务是否上量？
服务的使用方是否有促销活动？
解决问题
消除影响
回顾问题
避免措施。
服务化治理脚本
show-busiest-java-threads
./show-busiest-java-threads -p 进程号 -c 显示条数
./show-busiest-java-threads -h
find-in-jar
grep-in-jar
jar-conflict-detect
http-spy
show-mysql-qps
jvm提供的监控命令
jad
jad AbstractidServiceimpl.class
btreace
btrace [-p port] [-cp classpath] pid btrace-script
jmap
jmap -histo:live 2743
jmap 2743
jmap -heap 38574
jstat
jstat -gcutil 2743 5000 10
jstack(用于打印给定的 Java 进程ID的线程堆枝快照信息)
jstack 2743
jinfo(以输出 井修改运行时的Java进程的环境变量和虚拟机参数。)
jinfo 38574
linux基础命令和工具
grep
find
uptime(查看机器的启动时间)
lsof(列出系统当前打开的文件句柄)
ulimit
curl
scp
vim
dos2unix
unix2dos
awk
sed(文本编辑和替换)
tr(字符替换)
cut(选取命令)
wc(统计字数和行数)
sort
uniq(去重或者分组统计)
zip
tar
进程
ps
top
pidstat(于监控全部或指定的进程占用系统资源的情况 pidstat urd -p 进程号)
free
pmap(令用来报告进程中各个模块占用内存的具体情况 pmap -d 2862)
cpu监控
vmstat(令显示关于 内核线程、虚拟内存、磁盘 ν0、陷阱和 CPU 占用率的统计信息。)
mpstat(于实时监控系统 PU 一些统计信息，这些信息存放在 proc/stat 文件中，)
磁盘io监控
iostat(于监控 CPU 占用率、平均负载值及 νo 读写速度等)
swapon(查看交换分区 的使用情况 /sbin/swapon - s)
df(查看文件系统的硬盘挂载点和空间使用情况。)
网络信息
ifocnfig
ping
telnet
nc(网络应用调试分析器)
mtr(网络连通性测试工具，也可以用来检测丢包率。)
nslookup(检测网络中 DNS 服务器能否正确解析域名的工具命令)
traceroute(提供从用户的主机到互联网另一端的主机的路径)
sar(输出每秒的网卡存取速度)
netstat(显示网络连接、端口信息)
iptraf(实时监控网络流量的交互式的彩色文本屏幕界面)
tcpdump(网络状况分析和跟踪工具，是可以用来抓包的实用命令)
nmap(扫描端口信息)
ethtool(查看网卡 配置情况。)
pstack(显示每个进程的本地调用拢)
strace(来监控一个应用程序所使用的系统调用)
文件系统
显示 CPU 信息
cat /proc/cpuinfo
显示 存信息
cat /proc/meminfo
显示详细的内存映射信息
cat /proc/zoneinfo
显示磁盘映射信息
cat /proc/mounts
查看系统的平均负载
cat /proc/loadavg
md5sum
sha256
base64
7,服务的容器化过程
8,敏捷开发的自动化工具
4种开发模式
瀑布式开发
迭代式开发
螺旋式开发
敏捷开发
devops = 文化观念的改变＋自动化工具＝不断适应快速变化的市场
