大型网站技术架构演进与性能优化
一,架构演进之路
阶段一 php到java
阶段二 分布式改造
微服务化
分布式rpc框架
异步消息架构
分布式数据层
分布式文件系统
服务发现,注册,管理
分布式session问题
阶段三 无线化改造
阶段四 中台改造
阶段五 国际化
多语言问题
多时区问题
数据路由问题
全球数据的同步与复制问题
二,挑战性能瓶颈
三,组织架构的变迁
四,工程师文化的形成
1,构建大型网站-分布式改造
分布式配置框架
千级
推送模式
万级
拉取模式
1,不要让网卡成为瓶颈
2,要保证配置下发的到达率(版本号)
分布式消息框架
实时消息
异步解耦
最终一致性
消息有序性
多端消费
延时消费
http://queues.io/
分布式数据层
分库分表
主备读写分离
注意读写一致性
分布式文件系统
fastDfs
应用的服务化改造
应用分层设计
微服务化
zookeeper
集群管理
共享锁
队列管理
分布式消息通道服务的设计
典型的分布式集群设计思路
master/slave
对等
2,无线化:无线时代下的架构演进
端的演进
html5的页面优化
cookie压缩(全部压缩/部分压缩)
URL短域名
CDN前置缓存
无线链路的优化
无线端请求合并
CDN动态加速
WebP图片优化
服务端的演进
多端适配
json化接口
业务组件化
3,大型网站平台化演进:大中台和小前台
什么是中台:通过制定标准和机制,把不确定的业务规则和流程通过工业化和市场化的手段确定下来
问题太多导致
4,全球化下的网站演进:全球部署方案
单元化
数据路由方案
1,主键ID上做标识
2,设置路由表
接入层路由
服务层路由
数据层路由
多时区问题
系统统一时区
UTC
数据库中使用long型存储UTC时间
服务层,存储层直接使用long型计算
控制层对时间参数进行处理,将其转换成UTC时间
全球数据同步与数据路由
数据复制
异步通过消息发送
同步通过数据管道复制
各国对数据的保护政策
通用版和定制版的选择
5,应用程序优化:代码级优化
木桶效应
JProfiler
Yourkit
ab 模拟读请求
全链路压测技术 模拟写请求(到影子表)
发现瓶颈
jstack
查看当前请求的TCP连接数
netstat -n | awk '/^tcp {++state[$NF]} END {for(key in state) print key, "\t", state[key]}'
iostat
iotop
设置线程数
最佳线程数=(线程等待时间+线程cpu时间)/线程cpu时间*cpu数量
设置内存
并发请求数*每个请求消耗的内存
Eden区不够,触发minorGC
Survivor不够,copy到old区,触发fullGC
尽量减少线程请求生命周期里的对象数量
不要在非常耗时的操作前创建大对象
减少IO,提升RT
优化CPU,提升QPS
减少字符的编码
使用局部变量
减少方法调用
把对象作为hashmap的key
web.xml配置版本信息可以减少启动时注解的扫描
Logger创建使用statis修饰
少用Thread.getStackTrace();
正则运算尽量cache
减少并发冲突
Class.forName()加缓存ConcurrentHashMap
减少序列化
减少字符到字节的转换
String转byte[],使用stream流输出
使用长连接
html压缩
json减少key的命名长度
6,应用架构探索:合并部署
架构
业务架构抽象
应用架构
平台架构
技术架构
数据架构
网络架构
组织架构
7,链路优化:大秒系统的极致优化思路
热点隔离
业务隔离(单独报名)
系统隔离(分组部署)
数据集群(cache集群)
用户分区(url限流)
区分接口
数据打标识
动静分离
url固定
不包含浏览者相关因素
不包含时间相关的因素(时间通过服务器传送)
不包含地域因素
不包含cookie等私有数据
url唯一化
分离浏览者相关的因素
分离时间因素
异步化地域因素
去掉cookie
一致性hash(容易产生热点)
方案选择
实体单机部署
lvs -> nginx -> cache -> server
统一cache层
cdn
cdn二级cache作为缓存
缓存失效(被动失效/主动失效)
锁或者队列控制瞬间的请求量
数据分层校验
先做数据的动静分离
将90%的数据缓存在客户端浏览器(用于前端校验)
将动态请求的读数据cache在web端
对读数据不做强一致性校验
对写数据进行基于时间的合理分片
对写请求做限流保护
对写数据进行强一致性校验
实时热点发现
构建异步课收集交易链路上各个中间件产品本身统计的热点key
建立热点上报和可以按照需求订阅的热点服务的下发规范
统一热点分析平台
直接使用servlet处理请求
直接输出流数据
同一商品被大并发读的问题
应用层localcahce(划分成动态数据和静态数据分别处理)
静态数据提前缓存到秒杀机器
动态数据上缓存,不一致性由写数据时保证最终一致性
同一数据大并发更新问题
热点商品隔离到单独的热点数据库
应用排队
数据库层排队
修改时间字段更新会非常频繁,可以合并sql,一定时间内只执行最后一条update的sql
8,全局基础设施优化:资源调度优化
容器/编排
小应用虚拟化容器(分配小内存和低核数)
容器标准化运维/标准化部署
数据存储(不在本机存储(无状态),可以实时写日志,永久写数据库,分布式存储场景要做到存储与计算分离)
资源的收集和管理
资源的信息管理
物理机器的集群管理
资源的合理分片策略和算法
资源的信息管理(mesos)
最大内存剩余优先分配策略
最大cpu剩余优先分配策略
最大最小资源公平分配策略
根据资源分配指定分配策略(给机器打标签)
虚拟化技术
计算型业务选择docker
io要求较高的场景下选择LXC作为容器
存储技术
存储与计算的分离(每个容器写的数据都能写到一个集中的存储集群中)
物理资源调度
k8s/mesos
计算分离存储
CEPH
数据和技术的精确匹配,技术节点和存储节点之间的数据量的传输,考虑内网的网络带宽和访问数据的网络延时
在线,离线混合部署
要实现在线离线任务的灵活调度
要实现在线离线任务的资源隔离
要能监控在线任务的QoS
(大数据集群中的瓶颈到底是计算还是存储;将离线和在线业务大数据集群分别部署在两个机房)
应用层调度
集群的容量规划
线下单机压测
线上真实流量的压测
埋点请求url(只适合读请求)
ab/TCPCopy
集群流量引流到单台或多台,夜间操作
弹性调度
ip做路由,需要注意及时清楚缓存并更新ip路由表
域名做路由,naming服务也要足够可靠,主动探活和被动探活的准确性和灵敏性
故障自愈
多版本部署,蓝绿发布
问题排查
jstack dump
pstack pid
strace -p pid
gdb
linux-fincore
systemtap
/run目录挂载类型为内存文件系统tempfs
9,网站高可用建设:大型网站的稳定性建设
电商网站的交易链路必须保障交易链接的可用性达到4个9
架构/编码/测试/发布/运行/故障
避免单点
分组隔离
异步化
异地容灾
错误捕获(IO/远程调用/多线程)
异步线程
超时处理
限流保护
自动化对比测试
beta测试(线上测试用户)
分批发布
多版本发布
实时监控报警(CPU,load,磁盘,内存)
过载保护
自动降级
实时数据对账
发生故障时的稳定性建设
快速回滚
故障定位
快速恢复(多版本,切流量)
体系化建设
压测体系
单系统压测
TCPCopy
全链路压测
流量的制造
流量标记(id999开头/trace标签传递)
测试数据的处理(影子表)
管控体系
开关系统(管理线上常用操作)
预案系统(应急预案)
限流降级系统
监控体系
异常的智能监控系统
调用链路跟踪系统
端到端的链路染色系统
业务数据轨迹重现系统(商品快照)
业务数据对账系统(数据采集,规则匹配校对)
恢复体系
多版本部署
度量体系
性能基线
链路基线
成本基线
线上运维能力
浏览器前端的问题
域名劫持和DNS劫持的问题
前端js的错误定位和资源加载限制问题
无线端的网络特性(tcp连接耗时,数据下载的影响,wifi,4g,弱网内容读匹配)
无线端请求(手机基站->省级网关出口0->服务端网关->应用)
无线端的问题(链路,日志上报,舆情收集)
JDK基本配置参数,内存分配方式和GC调优
应用系统的性能指标(网络,qps,rt,cpu消耗,load,内存dump)
网络部署
cdn部署
稳定性组织保障
实体或虚拟团队
问题排查
问题排查沟通群
经验
不要放过任何很小的错误
涉及数据问题,一定要非常重视
必须熟悉整个商品流量环节
要写健壮性的代码
内存泄露问题
jstat -> jmap dump -> mat
oprofiler
perftools
map
JVM Heap存放数据来排查
总结
结合具体情况找出最有效,最合适自己的方案
相处经验
相互的信任
积极主动
独立的观点