当当网高可用移动入口与搜索技术架构1.docx

PAGE 20 当当网高可用移动入口与搜索技术架构  每年一次的互联网电商的双十一，是对一年工作的总结和洗礼，在 2017 年的双十一到来之际，我们希望通过本文梳理一下当当的一些行之有效的方法。 面对爆发性增长的流量，首要任务是让系统在大流量冲击的情况下能够先存活下来，通过应用限流，您可以了解到当当如何在流量洪峰中保持现有系统的服务能力。 在众多的系统中，系统之间的交互过于繁杂，一套全方位的链路监控系统，可以快速定位某个子系统的问题，通过 APM 系统，您将了解到当当在大量服务并存的情况下如何快速定位系统问题。 MAPI 是载当当大部分入口流量的移动端网关，通过 MAPI 对服务治理以及性能的分享，您将能够以点带面地一窥当当业务系统的设计思路。 搜索系统的重要程度不言而喻，而且它与业务系统的侧重点不尽相同，今年当当重点对搜索系统进行了重构，您可以通过对搜索新架构的解读一同探索技术的点点滴滴。 应用限流 电商平台的流量因促销、抢券、秒杀、热销品开卖等情况会出现大大小小的流量洪峰。流量洪峰的瞬时冲击（比如双十一零点的电商大促），可能导致系统响应缓慢，甚至整体崩溃，将对公司带来直接损失，因此大部分互联网电商都会有自己的一套解决方案，比如：流量疏导、服务降级、应用限流等。接下来介绍下当当在应用限流的设计思路和一些做法。 限流体系的整体架构图如下： 当当的应用限流包含 3 个子系统： 基于 Openresty/Nginx 的限流引擎，包含限流策略和限流算法。 基于 Prometheus 和 Grafana 的流量监控模块 基于 Hadoop（计划中）和 java Web 的配置中心 下面分别介绍各子系统的一些设计经验。 限流引擎子系统 在实际业务中，绝大部分应用服务器部署在反向代理服务器（Nginx）后面。一般情况下，Nginx 的性能不会成为瓶颈，后端的应用服务器会由于各种原因（如数据库缓慢、I/O 等待时间长、代码自身的缺陷等）成为瓶颈，所以主要是根据 Nginx 后端连接的应用服务器的负载情况来决定采用何种策略对前面的 Nginx 进行限流。同时对应用服务器层无需做任何调整即可实现流量控制，开发简单，维护成本低。 反向代理服务器使用的是 Openresty（），一个基于 Nginx 的 Lua 环境封装，使用 LuaJIT 作为 Lua 编译器，由于 Just-In-Time 的方式，比传统 Lua 运行更高效。当当的限流逻辑基于它开发。 首先介绍一下 限流算法，常用的拥塞控制算法有两种： 漏桶算法可以用在控制应用服务器发送请求到其他应用服务器的速率，确保一个稳定的速率，主要用于控制回调洪峰（其他系统的调用）的，针对用户洪峰更适合令牌桶算法。 但是如果无差别拒绝请求，会导致用户体验的严重下降，因此 需要策略组的配合，按照一定的规则拒绝请求，比较合理的做法是： 通过防刷算法，拒绝疑似攻击的请求 通过用户识别码、IP、所在区域、上网特征和接口特征等方式拒绝频繁访问的用户，保证服务器资源能服务更多的用户。 尽量不影响已服务用户的使用体验 对于正在挑选商品的用户（较多的单品页、添加购物车等操作），要尽量保证不被限流挡住，否则会降低用户的使用粘性。可以做的方法是增加一个访问令牌，记录用户一些重要操作时间，在流量不够的情况下，优先放行具备访问令牌的用户。 尽量保证会员的使用体验 平台的会员尤其是高级会员一般是具备较大网购需求的用户，他们往往更能影响平台的口碑，所以平台要服务好这部分的会员。 其次将限流引擎中的参数进行整理，对外提供 HTTP Rest 接口，可以热更新限流策略和相关参数，对接应用限流 - 配置中心子系统。值得注意的是，openresty 提供了一种 dict 的类型是子进程内存共享的，可以跨 worker 访问，如果操作是进程不安全操作记得加锁，另外这种类型在声明时需要提供开辟内存大小，根据业务负载情况进行指定，超过内存大小会通过 LRU 算法进行内存回收。以下介绍了一些重要参数的说明： 最后提供了 流量指标上报 模块，按照配置参数进行定时数据上报，目前上报总流量、通过流量、拒绝流量、分流流量、主机 IP、应用名等实时信息。上报数据进入流量监控子系统，进行实时流量监控和离线分析，稍后会在流量监控模块详细说明。 流量监控子系统 Prometheus 作为一种 time series 数据库，很适合做实时业务监控。因此根据上文上报数据的配置，经过 Prometheus Push Gateway 将数据初步汇总，最终通过 Prometheus 拉取数据。 Grafana 则接入 Prometheus 数据源，提供实时流量页面和告警功能。可以通过查询各个应用集群的流量分布，通过率低于阈值或者一定时间流量为 0 则直接