本篇文章内容来自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人次。包含产品、团队、架构、运维、大数据、人工智能等多个技术专场，现场学习谷歌、微软、腾讯、阿里、百度等一线互联网企业的最新研发实践。大会开幕式单天体验票申请入口
