千万级流量的优化策略实战.docxVIP

千万级流量的优化策略实战 2021-07-04 摘要 功能优化涉及面很广。一般而言，功能优化指降低响应时间和提高系统吞吐量两个方面，但在流量高峰时候，功能问题往往会表现为服务可用性下降，所以功能优化也可以包括提高服务可用性。在某些情况下，降低响应时间、提高系统吞吐量和提高服务可用性三者相互冲突，不行兼得。例如：添加缓存可以降低平均响应时间，但是处理线程数量会由于缓存过大而有所限制，从而降低系统吞吐量；为了提高服务可用性，对特别恳求反复调用是一个常用的做法，但是这会提高响应时间并降低系统吞吐量。 对于很多像美团这样的公司，它们的系统会面临如下三个挑战：1. 日益增长的用户数量，2. 日渐简单的业务，3. 急剧膨胀的数据。这些挑战对于功能优化而言表现为：在保持和降低系统TP95响应时间（指的是将一段时间内的恳求响应时间从低到高排序，高于95%恳求响应时间的下确界）的前提下，不断提高系统吞吐量，提升流量高峰时期的服务可用性。这种场景下，三者的目标和改进方法取得了比较好的全都。本文次要目标是为类似的场景供应优化方案，确保系统在流量高峰时期的快速响应和高可用。 文章第一部分是引见，包括接受模式方式讲解的优点，文章所接受案例的说明，以及后面部分用到的一些设计准绳；其次部分引见几种典型的“功能恶化模式”，阐述导致系统功能恶化，服务可用性降低的典型场景以及构成恶化循环的过程；第三部分是文章重点，阐述典型的“功能优化模式”，这些模式或者可以使服务远离“恶化模式”，或者直接对服务功能进行优化；文章最终一部分进行总结，并对将来可能消灭的新模式进行展望。 引见 模式讲解方式 关于功能优化的文章和图书已有很多，但就我所知，还没有接受模式的方式去讲解的。本文自创《设计模式》（Design Patterns-Elements of Reusable Object-Oriented Software）对设计模式的阐述方式，首先为每一种功能优化模式取一个贴切的名字，便于读者快速理解和深刻记忆，接着讲解该模式的动机和原理，然后结合作者在美团的具体工作案例进行深度剖析，最终总结接受该模式的优点以及需要付出的代价。简而言之，本文接受“命名--原理和动机--具体案例--缺点和优点”的四阶段方式进行功能优化模式讲解。与其他方式相比，接受模式进行讲解有两个方面的优点：一方面，读者不只仅能够把握优化手段，而且能够了解接受该手段进行功能优化的场景以及所需付出的代价，这有利于读者全面理解和机警应用；另一方面，模式处理的是特定应用场景下的一类问题，所以应用场景描述贯穿于模式讲解之中。如此，即便读者对原理不太了解，只需遇到的问题符合某个特定模式的应用场景（这往往比理解原理要简约），就可以接受对应的手段进行优化，进一步促进读者对模式的理解和把握。 案例说明 文章的全部案例都来自于美团的真实项目。出于两方面的考虑，作者做了肯定的简化和笼统：一方面，系统可以优化的问题众多，而一个特定的模式只能处理几类问题，所以在案例分析过程中会突出与模式相关的问题；另一方面，任何一类问题都需要多维度数据去描述，而应用功能优化模式的前提是多维度数据的组合值超过了某个临界点，但是精确定义每个维度数值的临界点是一件很难的事情，更别说多维度数据组合之后临界点。因而有必要对案例做一些简化，确保相关取值范围得到满足。基于以上以及其他缘由，作者所给出的处理方案只是可行性方案，并不保证其是所遇到问题的最佳处理方案。 案例涉及的全部项目都是基于Java言语开发的，严格地讲，全部模式适用的场景是基于Java言语搭建的服务。从另外一方面讲，Java和C++的次要区分在于垃圾回收机制，所以，除去和垃圾回收机制紧密相关的模式之外，文章所描述的模式也适用于接受C++言语搭建的服务。对于基于其他言语开发的服务，读者在阅读以及实践的过程中需要考虑言语之间的差别。 设计准绳 必需说明，本文中各种模式所要处理的问题之所以会消灭，部分是由于工程师运用了某些深层次的设计准绳。有些设计准绳看上去和优秀的设计理念相悖，模式所处理的问题好像完全可以避开，但是它们却被广泛使用。“存在即合理”，世界上没有完善的设计方案，任何方案都是一系列设计准绳的妥协结果，所以本文次要关注点是处理所遇到的问题而不是如何绕过这些设计准绳。下面对文中重要的设计准绳进行具体阐述，在后面需要运用该准绳时将不再解释。 最小可用准绳 最小可用准绳（快速接入准绳）有两个关注点：1. 强调快速接入，快速完成；2. 实现核心功能可用。这是一个被普遍运用的准绳，其目标是缩短测试周期，添加试错机会，避开过度设计。为了快速接入就必需最大限度地利用已有的处理方案或系统。从另外一个角度讲，一个处理方案或系统只需能够满足基本需求，就满足最小可用准绳的应用需求。过度强调快速接入准绳会导