华为:微服务场景下的性能提升最佳实践

本篇文章内容来自2016年TOP100summit华为架构部资深架构师王启军的案例分享。

编辑:Cynthia

王启军:华为架构部资深架构师。负责华为的云化、微服务架构推进落地,前后参与了华为手机祥云4.0、物联网IoT2.0的架构设计。曾任当当网架构师,主导电商平台架构设计,包括订单、支付、价格、库存、物流等。曾就职于搜狐负责手机微博的研发。“奔跑中的蜗牛”公众号博主。

导读:随着云时代的来临,软件架构日新月异,各种新技术层出不穷。“微服务”这个词更是如火如荼,得到了业界的广泛认可。但是,微服务并不是银弹,微服务架构下的性能问题在交付项目型的公司尤为重要。

本文主要围绕微服务下的性能问题展开,目的是通过实际问题的解决过程,分析在服务拆分到一定粒度后,服务调用链变长,如何评估、提升整体性能。

一、问题的提出

在架构设计阶段,大家比较关心的几个基本要素包括:性能、可用性、一致性、扩展性、安全性。其中性能问题在起步阶段往往容易被忽略,但随着架构的逐步演进,规模越来越大,性能问题会变得越来越重要,很可能一个小小的改动,就可以节省一半的服务器资源。

那性能到底表现在哪些方面?

●一个是响应时间,也就是发送请求和返回结果的耗时;

●另一个是吞吐量,也就是单位时间内响应次数。

当然这两个指标是在一定资源限制下才有意义。例如要占用多大磁盘、多少CPU、多大内存等。吞吐量和响应时间之间也互为影响,虽然这不是绝对的。

平时比较常见的性能问题包括:

●内存泄露——导致内存耗尽

●过载——突发流量,大量超时重试

●网络瓶颈——需要加载的内容太多

●阻塞——无尽的等待

●锁——通过限制

●IO繁忙——大量的读写,分布式

●CPU繁忙——计算型常见问题

●长请求拥塞——连接耗尽

当吞吐量有问题的时候,我们期望通过线程或者进程的方式来扩展,线程的方式比进程的方式要复杂得多,因为线程方式需要考虑共享数据变化的问题。

微服务就是一种进程扩展的模式。我们可以尝试给微服务下一个定义:

一种架构风格。

●单个服务尽量专注一件事情,高内聚、低耦合;

●进程隔离;

●每个服务可以独立的开发、测试、构建、部署;

●小且灵活;

微服务架构带来的优势包括:

●交付周期。每个服务可以独立开发、测试和交付,降低周期;

●快速沟通。小团队开发,降低代码耦合度导致的沟通成本; 业务按服务拆分,新人不需要了解整体架构,上手快;

●定制化。可以根据市场需求,灵活多变地组合出新的业务场景;

●隔离性。进程隔离方式,故障范围有效控制;

●技术栈。可以根据需求,按服务选择不同技术栈;

●演进优化。可以按照服务粒度进行演进优化;

同时带来的问题包括:

●架构复杂度。由于服务数量暴增引起的各种复杂的架构问题。例如一致性问题、大量远程接口调用的复杂度;

●管理成本。服务数量爆炸导致管理、运维成本升高。我们希望交付周期短,周期短必然引起变更快,变更是可用性的天敌。需要通过自动化、可视化的手段解决问题;

●故障定位。例如一个涉及几十个服务的请求,如何在故障发生的时候快速定位问题;

●性能损失。原本一次调用可以返回结果,现在需要流经几个或几十个服务才能返回结果,如何提升响应时间的问题; 由于拆分导致的吞吐量降低,如何补偿?云化就意味着可以横向扩展。架构如何实现扩展?提升整体的系统吞吐量。

二、实践过程

第一步,树立目标。

通常你得到的需求是这样的:“速度要快!”“跟以前比,性能不能降低”。很明显,这并不是一个有效的指标。

如何设立目标呢?先列出几种常见却无效的目标。

●平均响应时间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亿/年

资源限制:服务器资源……

其他影响因素……

同时,其他目标也要同步设定,例如系统整体可用性、一致性等。

第二步,寻找瓶颈点。

首先进行压力测试。可以从生产环境引流进行测试,测试环境测出来的结果毫无意义。另外,要基于场景测试,单测某个功能无意义。

其次,要进行全面的监控,包括调用链分析,快速定位性能瓶颈点。

第三步,优化。

优化的手段有很多,包括:同步转异步、阻塞转非阻塞、数据冗余、数据拆分、数据合并、压缩、简化业务环节等等。关键取决于应用场景和成本。

服务化框架



如图1所示,一个电商里的详情页面会调用价格、库存、商品等服务,综合展示信息,如果是串行调用,总耗时等于每个服务耗时之和;如果是并行调用,总耗时等于三个服务耗时的最大值,性能提升显著。

还有很多其他的优化点,例如:

●使用高效的序列化协议,protobuf、thrift等协议要比http+json的方式好很多,可以在服务内部使用;

●采用长连接,避免重复建立连接导致的性能损失;

●业务线程和IO线程隔离等。

消息中间件



通过消息中间件可以削峰填谷,提升吞吐量。如图2,下单操作直接发送到MQ即返回,由MQ保障最终一致性,还能够降低响应时间。把依赖关系从强依赖变成弱依赖。也就是说,订单系统的暂时不可用,对下单操作无影响。另外,MQ的吞吐量远远大于关系型数据库,MQ扩展相对要方便很多。

当然,使用MQ也有一定的问题,有一个一致性的时间窗口,对于要求强一致的业务来说,是比较致命的。

分布式缓存

缓存是被用来提升性能的利器。本地缓存不能共享,会导致比较大的内存浪费,另一方面,垃圾回收也会影响业务服务。在微服务架构中,我们普遍要求把状态外置到缓存、数据库中,大型应用多采用分布式缓存。

由于数据库扩展起来比较复杂,带来的后遗症较多,用缓存来平衡数据库的压力是非常好的做法。

分布式缓存,例如redis、memcache,吞吐量大概在10万qps这个级别,相对数据库几千qps来说是一个非常大的提升。

当然,分布式缓存带来的问题就是一致性的问题,什么时候去更新缓存?如果缓存更新失败、数据库更新成功怎么办?

数据库

数据库的优化是非常直接有效的。

以优先级来排序,优化的方式如下:

●索引、冗余、批量写入

●减小锁粒度

●减小复杂查询

●适当转移事务处理

●提升硬件性能

●读写分离

●分库

●垂直分表

●水平分表

●根据业务情况选择NoSql

三、案例分析



如图3,在电商中,一个价格服务,为了提升写的效率,可以采用消息中间件,为了解决重复提交的问题,(特别是当某个系统不可用的时候,用户会频繁提交,导致人为的风暴)可以通过缓存去做排重。

如果一个用户提交了一百万价格变动信息,另一个用户提交了一个价格修改请求,这个请求会被那一百万请求阻塞很长时间,这时候就需要消息中间件有优先级的概念,如果不能做优先级,可以通过建立多个队列分类来解决问题。

如果一个用户提交了一百万条价格修改,发现其中有一个错了,改了其中一条再提交,按照上述方式会导致新版本被老版本覆盖,我们需要通过建立版本号的方式解决这个问题。

四、总结

●并不是所有的地方都需要高性能,需要权衡代码可读性维护性,架构复杂度 ;

●优化之前,找到驱动力;

●正确对待优化带来的其他问题。

11月9-12日,北京国家会议中心,第六届TOP100全球软件案例研究峰会,华为精益敏捷专家陈军将分享《华为百人团队精益看板演进变革之路》;华为云计算测试经理李超峰将分享《华为云虚拟化质量平台建设实践》。

TOP100全球软件案例研究峰会已举办六届,甄选全球软件研发优秀案例,每年参会者达2000人次。包含产品、团队、架构、运维、大数据、人工智能等多个技术专场,现场学习谷歌、微软、腾讯、阿里、百度等一线互联网企业的最新研发实践。

TOP100大会将于11月9日-12日在北京国家会议中心举办,在现场通过对案例的复盘总结,分享成功者背后的经验和方法。大会开幕式单天体验票免费入口。

推荐阅读更多精彩内容

  • 一、微服务将变得轻量级 架构需要由人去设计,这些人被称为架构师。或许很多人并未授予架构师的头衔,但自己却从事着架构...
    justmilkrain阅读 4,483评论 10 107
  • 摘要:本文中,我们将进一步理解微服务架构的核心要点和实现原理,为读者的实践提供微服务的设计模式,以期让微服务在读者...
    Java架构师Carl阅读 3,714评论 0 20
  • “微服务架构”这一术语在前几年横空出世,用于描述这样一种特定的软件设计方法,即以若干组可独立部署的服务的方式进行软...
    ThoughtWorks阅读 12,067评论 1 65
  • 1. 微服务架构介绍 1.1 什么是微服务架构? 形像一点来说,微服务架构就像搭积木,每个微服务都是一个零件,并使...
    静修佛缘阅读 3,190评论 0 37
  • 今天是孝贤第一次离开家人上幼儿园了!下午上两个小时!一个班12人4位老师负责!他还戴着尿片片那!好想我孙儿! 好担...
    姜每文阅读 226评论 0 0