微服务场景下的性能提升最佳实践
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
线程VS进程
The problem is shared, mutable data.
Source: http://www.programsys.com.cn/display.asp?id=806
微服务架构
定义：一种架构风格。 1.单个服务尽量专注一件事情，高内聚、低耦合； 2.进程隔离； 3.每个服务可以独立的开发、测试、构建、部署； 4.小且灵活；
注意超时时间和重试带 来的后果
A
B
串行=100ms 单品页
20ms 价格
30ms 库存
50ms 商品
并行=50ms 单品页
20ms 价格
30ms 库存
50ms 商品
Source: http://byterot.blogspot.com/2015/03/qcon-london-2015-from-hype-trendsetting-Part-1microservices-docker-performance-outliers.html
技术栈
• 可以根据需求， 按服务选择不同 技术栈；
演进优化
• 可以按照服务粒 度进行演进优化；
微服务的挑战
•由于服务数量暴增引起的各 种复杂的架构问题。例如一 致性问题、大量远程接口调 用的复杂度；
架构复杂度
•服务数量爆炸导致的管理、 运维成本升高。我们希望交 付周期短，周期短必然引起 变更快，变更是可用性的天 敌。需要通过自动化、可视 化的手段解决问题；
第二步，寻找瓶颈点
Source: http://loricca.com/incident-response-plan-now-stay-prepared/
压力测试——生产环境引流，基于场景 监控——调用链分析，快速定位
测试 分析
Source: http://soledede.iteye.com/blog/1921054
消息中间件
优势： 提升吞吐量 降低响应时间 扩展性 弱依赖 问题： 一致性时间差 例如 下单 登录加积分
下单
下单 MQ
购物车 库存 订单 支付
购物车 库存 订单 支付
分布式缓存
优势： 服务无状态，易扩展 适当平衡数据库压力 极大提升吞吐量 降低响应时间 问题： 一致性 复杂度
跟以前比，不 能降低指标。
Source: http://auto.sina.com.cn/photo/ferraric4/14779.shtml
如何树立目标？
平均响应时间1s？ [2, 5, 3, 4, 301, 4, 2, 8, 7, 3, 3, 1, 1, 8, 2] AVG(f)=23.6 99%请求要在1S内完成？ 不同的业务，响应时间不应该相同； 单纯的设定响应时间毫无意义，要在吞吐量之下进行设定； 支持100万并发用户？ 这并不等于系统吞吐量的设定； 系统目前有多大数据量，增长速度是前提； 错误率 指标再高，有错误也没用。
先定一个小目标
应该根据具体业务场景设定指标。 例如下单操作， 响应时间95%<1s 吞吐量>10万tps 系统数据量：10亿>订单表>1亿…… 增长速度：1亿/年 资源限制：服务器资源…… 其他影响因素……
同时，其他目标也要同步设定，例如 系统整体可用性，一致性等。
Source: http://jmeter.apache.org/usermanual/component_reference.html#Response_Time_Graph
Source：http://www.cnblogs.com/gomysql/p/4395504.html
数据库
索引、冗余、批量写入 减小锁粒度 减小复杂查询 适当转移事务处理 提升硬件性能 读写分离 分库 垂直分表 水平分表 根据业务情况选择NoSql
性能损失
性能提升带来的收益
用户体验 资源消耗
Source: http://auto.sina.com.cn/photo/ferraric4/14779.shtml
性能提升带来的问题
架构复杂度成本 人力成本 空间换时间—资源
Source: http://auto.sina.com.cn/photo/ferraric4/14779.shtml
微服务场景下的性能提升最佳实践
技术创新 变革未来
问题的来源——架构核心要素
性能
可用 性
一Hale Waihona Puke Baidu 性
扩展 性
安全 性
性能是什么？
响应时间（RT） 吞吐量（TPS/QPS） 资源占用（CPU,内存，网络，磁盘）
常见的问题
内存泄露——导致内存耗尽 过载——突发流量，大量超时重试 网络瓶颈——需要加载的内容太多 阻塞——无尽的等待 锁——通过限制 IO繁忙——大量的读写，分布式 CPU繁忙——计算型常见问题 长请求拥塞——连接耗尽
优化
Source: http://zipkin.io/
第三步，优化
Source: http://www.seocool.com/seo-tags-optimization.html
手段
异步 非阻塞 冗余 拆分 合并 压缩 简化环节
服务化框架
并行处理 请求聚合 高效协议 长连接 IO线程和业务线程分离 压缩
交付周期
快速沟通
定制化
• 每个服务可以独 立的开发、测试 和交付，降低周 期；
• 小团队开发，降 低代码耦合度导 致的沟通成本；
• 业务按服务拆分， 新人不需要了解 整体架构，上手 快；
• 可以根据市场需 求，灵活多变的 组合出新的业务 场景；
独立性
单一职责
进程隔离
灵活
隔离性
• 进程隔离方式， 故障范围有效控 制；
管理成本
•例如一个涉及几十个服务的 请求，如何在故障发生的时 候快速定位问题；
故障定位
• 原本一次调用可以返回 结果，现在需要流经几 个或几十个服务才能返 回结果，如何提升响应 时间的问题；
• 由于拆分导致的吞吐量 降低，如何补偿？云化 就意味着可以横向扩展。 架构如何实现扩展？提 升整体的系统吞吐量。
第一步，树立目标
Source: http://loricca.com/incident-response-plan-now-stay-prepared/
通常你得到的需求是这样：
速度要快！
http://www.360doc.com/content/16/1109/17/31931381_605198853.shtml
The problem is shared, mutable data.
Source: http://www.programsys.com.cn/display.asp?id=806
微服务架构
定义：一种架构风格。 1.单个服务尽量专注一件事情，高内聚、低耦合； 2.进程隔离； 3.每个服务可以独立的开发、测试、构建、部署； 4.小且灵活；
注意超时时间和重试带 来的后果
A
B
串行=100ms 单品页
20ms 价格
30ms 库存
50ms 商品
并行=50ms 单品页
20ms 价格
30ms 库存
50ms 商品
Source: http://byterot.blogspot.com/2015/03/qcon-london-2015-from-hype-trendsetting-Part-1microservices-docker-performance-outliers.html
技术栈
• 可以根据需求， 按服务选择不同 技术栈；
演进优化
• 可以按照服务粒 度进行演进优化；
微服务的挑战
•由于服务数量暴增引起的各 种复杂的架构问题。例如一 致性问题、大量远程接口调 用的复杂度；
架构复杂度
•服务数量爆炸导致的管理、 运维成本升高。我们希望交 付周期短，周期短必然引起 变更快，变更是可用性的天 敌。需要通过自动化、可视 化的手段解决问题；
第二步，寻找瓶颈点
Source: http://loricca.com/incident-response-plan-now-stay-prepared/
压力测试——生产环境引流，基于场景 监控——调用链分析，快速定位
测试 分析
Source: http://soledede.iteye.com/blog/1921054
消息中间件
优势： 提升吞吐量 降低响应时间 扩展性 弱依赖 问题： 一致性时间差 例如 下单 登录加积分
下单
下单 MQ
购物车 库存 订单 支付
购物车 库存 订单 支付
分布式缓存
优势： 服务无状态，易扩展 适当平衡数据库压力 极大提升吞吐量 降低响应时间 问题： 一致性 复杂度
跟以前比，不 能降低指标。
Source: http://auto.sina.com.cn/photo/ferraric4/14779.shtml
如何树立目标？
平均响应时间1s？ [2, 5, 3, 4, 301, 4, 2, 8, 7, 3, 3, 1, 1, 8, 2] AVG(f)=23.6 99%请求要在1S内完成？ 不同的业务，响应时间不应该相同； 单纯的设定响应时间毫无意义，要在吞吐量之下进行设定； 支持100万并发用户？ 这并不等于系统吞吐量的设定； 系统目前有多大数据量，增长速度是前提； 错误率 指标再高，有错误也没用。
先定一个小目标
应该根据具体业务场景设定指标。 例如下单操作， 响应时间95%<1s 吞吐量>10万tps 系统数据量：10亿>订单表>1亿…… 增长速度：1亿/年 资源限制：服务器资源…… 其他影响因素……
同时，其他目标也要同步设定，例如 系统整体可用性，一致性等。
Source: http://jmeter.apache.org/usermanual/component_reference.html#Response_Time_Graph
Source：http://www.cnblogs.com/gomysql/p/4395504.html
数据库
索引、冗余、批量写入 减小锁粒度 减小复杂查询 适当转移事务处理 提升硬件性能 读写分离 分库 垂直分表 水平分表 根据业务情况选择NoSql
性能损失
性能提升带来的收益
用户体验 资源消耗
Source: http://auto.sina.com.cn/photo/ferraric4/14779.shtml
性能提升带来的问题
架构复杂度成本 人力成本 空间换时间—资源
Source: http://auto.sina.com.cn/photo/ferraric4/14779.shtml
微服务场景下的性能提升最佳实践
技术创新 变革未来
问题的来源——架构核心要素
性能
可用 性
一Hale Waihona Puke Baidu 性
扩展 性
安全 性
性能是什么？
响应时间（RT） 吞吐量（TPS/QPS） 资源占用（CPU,内存，网络，磁盘）
常见的问题
内存泄露——导致内存耗尽 过载——突发流量，大量超时重试 网络瓶颈——需要加载的内容太多 阻塞——无尽的等待 锁——通过限制 IO繁忙——大量的读写，分布式 CPU繁忙——计算型常见问题 长请求拥塞——连接耗尽
优化
Source: http://zipkin.io/
第三步，优化
Source: http://www.seocool.com/seo-tags-optimization.html
手段
异步 非阻塞 冗余 拆分 合并 压缩 简化环节
服务化框架
并行处理 请求聚合 高效协议 长连接 IO线程和业务线程分离 压缩
交付周期
快速沟通
定制化
• 每个服务可以独 立的开发、测试 和交付，降低周 期；
• 小团队开发，降 低代码耦合度导 致的沟通成本；
• 业务按服务拆分， 新人不需要了解 整体架构，上手 快；
• 可以根据市场需 求，灵活多变的 组合出新的业务 场景；
独立性
单一职责
进程隔离
灵活
隔离性
• 进程隔离方式， 故障范围有效控 制；
管理成本
•例如一个涉及几十个服务的 请求，如何在故障发生的时 候快速定位问题；
故障定位
• 原本一次调用可以返回 结果，现在需要流经几 个或几十个服务才能返 回结果，如何提升响应 时间的问题；
• 由于拆分导致的吞吐量 降低，如何补偿？云化 就意味着可以横向扩展。 架构如何实现扩展？提 升整体的系统吞吐量。
第一步，树立目标
Source: http://loricca.com/incident-response-plan-now-stay-prepared/
通常你得到的需求是这样：
速度要快！
http://www.360doc.com/content/16/1109/17/31931381_605198853.shtml