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,状态字段
数据库事务->同一个分片->不同的分片(最终一致性)
分布式一致性协议 应用程序、事务管理器(协调员)、资源管理器(参与者)、通信资源管理器
协议(不交协议(不使用) 准备，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 = 文化观念的改变＋自动化工具＝不断适应快速变化的市场