亿级网关janus性能优化与jvm调优实践分享
2018-06-08 本文已影响322人
双刃夜
亿级网关janus性能优化与jvm调优实践
个人简介
蔡磊 在唯品会基础架构服务化团队，负责唯品会API Gateway/Reverse Proxy的设计与开发，性能调优与疑难杂症。
大纲
- janus背景介绍与技术选型
- 线程模型与优化
- netty深度调优与实践
- 性能瓶颈快速定位工具与方法论
- 高并发下的gc优化与排查,控制每月一次频率
- 通用计数器需求场景实现
- 一个有意思的gc问题
- 踩坑后的代码规范总结
janus网关背景
- 定位:高性能，高可用，可扩展，可管理，可治理，安全的网关产品，作为所有流量的入口
- 网关价值:中心化网关所能提供的所有统一控制。权限，安全，资源限制，防刷，聚合，熔断与重试，同机房路由，灰度导流等等
- 底层技术选型，从servlet到akka到netty
- 目前主要是ApiGateway 由于容器与功能复用，也做了部分反向代理
线程模型与优化
- 经典的netty boss worker模型
- 多个worker线程池共享:接入请求的worker与转发的http/rpc请求线程worker共用相同线程池
- 一次转发的worker线程尽量不切换:接收请求的netty的worker与转发请求的worker在同一线程，减少切换，不会放入队列再出队
- 插件化引入共享线程池+独立线程池模型
- 性能数据介绍
netty深度调优与实践
- 基于worker线程内共享,无锁化;安全共享处理各种非线程安全代码,全异步化
- netty native epoll
- bytebuf有解析请求时使用堆内对外对比
- boss线程根据端口数来决定,
- 重写netty handle的提前半解析优化
- 重度使用netty InternalThreadLocalMap jdk7使用PlatformDependent工具
- worker线程池合并
- 一次请求过程worker线程不切换上下文
性能瓶颈快速定位工具与方法论
- 没有魔法，尽可能的善用工具，识别优化最大价值点
- 从系统底层监控到jvm层
- 火焰图:系统函数调用＋jvm方法栈消耗
- jmc java自带分析工具
- jmh 最好通读官方demo，避免写错误的使用
高并发下的gc优化与排查
- 控制每月一次cms频率
- 内存溢出问题各种踩坑：熔断与指标统计
- log4j2升级2.6版本free gc
- 源码无秘密:jdk7默认出发cms为什么是92%
- kafka原生代码的指标采样导致old区晋升过快
- 高io导致jvm停顿，gc日志放ramfs，并生产环境加入-XX:+PerfDisableSharedMem来避免生成perf
- 重用对象减少垃圾对象数量
通用计数器实现方案
- 滑动窗口实现:时间轮+数组桶
- 提前清理vs使用时清理
- 清理对象复用 使用时清理：清理上次时间到当天时间，需要加锁，自旋锁清理
- 内存与性能:AtomicLong vs LongAdder
- 哪些场景可以用到(限流 防刷 熔断所有要计数的需求)
一个有意思的gc问题
- 使用lru使用角度来谈gc问题选择
- lru准确性，由于不够用，所以尽量大则准确，那么gc问题就来了
- 跟着ygc随波逐流，释放对象，解决就要根据流量模型设置大小
- 进一步抽象，所有能熬过ygc到老年代，并且存在反复创建的都有此问题，比如从各种链接池清理闲置链接
网关代码总结几条：
- 尽可能复用对象，尽快释放对象
- 参考netty代码实现技巧
- 尽量无状态无锁，一定要有状态优先线程内共享其次cas
- 了解你所写的每行代码内部逻辑，jmh测试度量(一个简单gson例子)
