【转】惟品会11.11：峰值系统应对实践

ArchSummit全球架构师峰会北京站将于2015年12月18日~19日在北京国际会议中心召开，大会设置了《揭秘双十一背后的技术较量》专题来深刻解读双十一背后的技术故事，欢迎关注。

区别于其余网购品牌惟品会定位是“一家专门作特卖的网站”， 商业模式为“名牌折扣+限时抢购+正品保险”，即“闪购”（flash sales）模式。天天上新品，以低至1折的深度折扣及充满乐趣的限时抢购模式，为消费者提供一站式优质购物体验，

这种闪购限时特卖业务特色决定了网站随时都须要处理高并发、大流量的用户请求。大量买家在每次新的品牌档期上线后，大量涌入，抢购商品，形成网站承担大量流量。尤为碰到热门商品，网站并发访问剧增，会形成整个网站负载太重，响应延迟，严重时甚至会出现服务宕机的状况。

另外惟品会有众多的业务销售模式，如自营销售模式、JIT、直发、海淘、O2O等等，这些业务销售模式致使系统很是复杂。系统外部须要经过开放平台对接供应商系统和第三方物流系统。内部系统包括诸多系统，如供应商管理、商品选品、商品交易、支付系统、物流仓储、客服系统、商品配送等等。这些系统功能模块之间关联性很是强，逻辑扩展很是复杂，如何快速知足业务发展的须要，是一个很是迫切的问题。

为了保证系统在高并发、大流量访问下工做，而且使系统有较强的扩展性，咱们的设计主要从如下几个方面展开：

• 系统模块有效切分
• 服务化解耦，集中服务治理
• 增长异步访问
• 多阶段缓存，下降后端压力
• 优化数据库访问
• 增强系统监控

系统模块有效切分

惟品会整个业务系统虽然已经拆分红几个相对独立的子系统如交易平台（B2C）、VIS、WMS、TMS、ODS、CS、EBS等，可是这些业务系统在实际运做中业务耦合严重。碰到新业务逻辑加入，就须要每一个模块作大量修改，各个开发团队之间为了业务逻辑放在那里争论不休，浪费了大量的时间，致使开发效率比较低。这主要因为模块划分不合理，致使模块之间边界不清楚。因此咱们架构团队从整个系统角度出发，梳理整个流程，从新作系统定位，将不一样业务子系统作物理分离，减小彼此之间的依赖，使各个子系统独立部署，出现问题后能快速采起措施，隔离出问题模块，将故障影响降到最低。

服务化解耦，集中服务治理

服务化设计已经被主流电商系统证实是一个切实可行的方向。经过SOA服务化改造，实现了服务使用者和服务提供者的分离，使系统间的服务解耦和系统内高内聚，大大简化了系统复杂性，具备更强的伸缩性和扩展性，知足了业务快速发展的须要。

咱们怎么有效管理这些服务呢？

Venus是惟品会自开发的一款基于Spring的Java开发框架, 以下降开发的复杂度, 提升开发人员的开发效率, 提高代码质量, 规范开发流程。

Venus框架涵盖了如下内容：

• 数据库访问层封装，支持分库、分表，链接池优化
• 缓存（Redis/Memcached）接口封装，链接池优化
• CRUD服务代码自动生成（包含数据库操做）
• OSP/REST服务调用接口封装及异步支持
• ValidateInternals
• 单元／集成测试模版代码自动生成
• 配置中心
• 中央文档中心

Venus生态体系

其中开放服务平台（OSP）的主要目标是提供服务化的核心远程调用机制。契约化的服务接口保证系统间的解耦清晰、干净；基于Thrift的通讯和协议层确保系统的高性能；服务能够自动注册并被发现，易于部署；配合配置中心，服务配置能够动态更新；客户端与治理逻辑的分离使服务接入获得极大简化；除此以外，OSP提供了丰富的服务治理能力，如路由、负载均衡、服务保护和优雅降级等，经过OSP，有效的实现了流量控制。

服务分流

首先OSP Proxy具备软负载的做用，系统不须要硬件负载均衡，能够将服务请求均衡地分配到不一样服务主机上。另外OSP能够配置服务的路由，服务请求能够被分配到不一样版本的服务中处理，这样很容易实现灰度发布。

服务限流

在系统流量达到极限时的状况，有自动熔断机制。熔断器是在服务或者周边环境（如网络）出现了异常后主动断开客户端后续的使用，从而避免服务崩溃没法恢复。可是在后续时间熔断将使用小量请求尝试侦测服务是否已经恢复，若是恢复则将服务再次提供给客户端调用。熔断器的机制即保护了服务也减小了人工干预。相关的阀值都在是在配置中心中配置，并支持动态修改生效。限流必定要谨慎使用，要使用恰当的限流策略，区分正常访问和恶意请求，不能将正常的用户请求抹杀掉。若是没法区分是不是恶意请求，须要将应用分级，确保优先级最高的应用能被访问到，好比全部上线的商品信息。而对于下线的商品信息，能够根据请求容量做适当的限流。

Nginx Rate Limiter是一个自主开发的防刷工具，经过Nginx上的LUA脚本插件，实如今Nginx上对本机的HTTP访问进行限流控制的工具，以提升在促销等高业务量环境下保障系统稳定运行的能力。

Nginx Rate Limiter经过RESTful API接口进行配置以及信息查看，能够对全局进行开关等配置，也能够针对指定URL分别添加多个限流配置，包括全局的限流。限流配置能够选择如下一种方式：

1. 最大访问请求速率，超出则丢弃请求
2. 按比例丢弃请求。

服务降级

对于电商系统，为了保证用户体验，在资源有限的条件下，咱们必须保证关键系统的稳定性。经过对不一样业务级别定义不一样的降级策略，对除核心主流程之外的功能，根据系统压力状况进行有策略的关闭，从而达到服务降级的目的，例如在线商品信息，咱们必须保证优先访问，而对于下线的商品信息，咱们能够允许在访问容量受限状况下，允许关闭下线商品详情页面的访问等。

增长异步访问

对于系统间实时性要求不高的操做，若是执行时比较耗时，可经过异步处理提升调用者性能，提升响应能力，尤为经过异步调用通知非主要流程，加快了系统主要业务流程的反应速度和性能，异步处理机制可起到缓冲的做用，被通知的下游系统可依据自身能力控制处理数据量，避免遭受超负荷的冲击，保证系统稳定运行，增长了系统可用性。

分布式异步消息队列服务器可在宕机后确保消息不丢失，异步系统有重试机制，从而提升系统可用性、健壮性和扩展性。

在用户下单后，其余系统如物流、供应商系统、配送、财务等系统须要获取订单详情、订单状态，订单系统经过异步消息方式将订单的变化通知其它系统，异步调用实现系统间隔离解耦，上下游系统业务逻辑分离，下游系统只须要解析异步消息进行处理，不须要依赖上游系统的业务逻辑，从而下降了系统之间的依赖。即便下游系统出现异常，订单系统仍然能正常处理数据。

多阶段缓存，下降后端压力

一、动静分离，静态化

静态化可下降后端压力，一方面经过用户浏览器缓存静态资源，失效时间经过cache-control来控制。另一方面经过CDN缓存，例如商品详情页面，为了提升缓存效率，可将商品详情页面伪静态化，将URL后缀显示为HTML，商品描述信息等静态信息在有用户访问状况下，缓存到靠近用户的CDN节点，另外为了提升CDN效率，提早将商品图片推送到CDN。其它商品动态数据可动态加载，如商品运营信息、商品库存、尺码表等，从而下降了避免没必要要的后台访问。

二、分布式缓存

引入分布式缓存，对缓存数据服务节点作统一集中管理，可支持缓存集群弹性扩展，经过动态增长或减小节点应对变化的数据访问负载，经过冗余机制实现高可用性，无单点失效，不会因服务器故障而致使缓存服务中断或数据丢失。应用端使用统一的API接口访问缓存服务器。

经过分布式缓存，可作应用对象缓存、数据库缓存、会话状态及应用横向扩展时的状态数据缓存。

三、巧用应用服务器本地缓存

分布式缓存虽然有效解决了访问压力，但因为缓存服务器分布在不一样网络端、不一样数据中心中部署，随着访问量增大将致使I/O和带宽瓶颈。为此可将那些基本不修改的配置数据、全局数据能够在应用服务器本地缓存，减小对后端缓存服务器实例的峰值冲击。本地缓存须要谨慎使用，若是大量使用本地缓存，可能会致使相同的数据被不一样的节点存储多份，对内存资源形成较大的浪费。

使用缓存对提升系统性能有不少好处，可是不合理使用缓存非但不能提升系统的性能，反而成为系统的累赘，甚至影响系统运做，产生很大的风险。对于频繁修改的数据、没有热点的访问数据、数据一致性要求很是高的数据，不建议使用缓存。

优化数据库访问

在高并发大数据量的访问状况下，数据库存取瓶颈一直是个使人头疼的问题。若是数据库访问出现性能问题，整个系统将受到影响。

为此须要优化数据库访问，从如下几个方面解决高并发问题：

• 优化复杂查询，提升数据库查询效率，找出关键模块的数据库慢查询进行优化。例如减小数据库表之间的Join、重构数据库表相关索引、对where子句进行优化等。
• 保证在实现功能的基础上，尽可能减小对数据库的访问次数；经过查询参数，尽可能减小对表的访问行数，最小化结果集，从而减轻网络负担；可以分开的操做尽可能分开处理，提升每次的响应速度，查询时用到几列就选择几列，下降数据库访问IO负载压力。
• 基于电商系统读写比很大的特性，采用读写分离技术，经过一主多从，写操做只发生在主表，多操做发生在从表上，能够大大缓解对主数据库的访问压力。
• 对业务和系统的细分，对数据库表进行垂直拆分。将数据库想象成由不少个"数据块"（表）组成，垂直地将这些"数据块"切开，而后把它们分散到多台数据库主机上面，从而能够分散单位时间内数据库访问压力。垂直切分的依据原则是：将业务紧密，表间关联密切的表划分在一块儿。
• 垂直切分后，须要对分区后表的数据量和增速进一步分析，以肯定是否须要进行水平切分。对于核心数据如订单，采起水平分区的方式，经过一致性哈希算法，利用用户Id把订单数据均匀的分配在各个数据库分区上，在应用系统查询时，以用户ID调用哈希算法找到对应数据库分区，从而将高峰时期的数据库访问压力分散到不一样数据库分区上，从而实现数据库的线性伸缩，极大提高数据库的承载能力。
• 借助于分布式缓存，缓存提供了远大于数据库访问的性能。当某一应用要读取数据时，会首先从缓存中查找须要的数据，若是找到了则直接执行，找不到的话则从数据库中找。在设计时，须要防止缓存失效带来的缓存穿透压力。
• 允许必定程度的数据冗余，对于关键模块，为了防止对其它模块的依赖而影响当前模块的性能和可靠性，可适度保存其它模块的关键数据，减小因为访问其它模块服务带来的系统损耗和可靠性压力。
• 使用NoSQL数据库对海量大数据进行存储和处理。

增强系统监控

业务系统一般由众多分布式组件构成，这些组件由web类型组件，RPC服务化类型组件，缓存组件，消息组件和数据库组件。一个经过浏览器或移动客户端的前端请求到达后台系统后，会通过不少个业务组件和系统组件，而且留下足迹和相关日志信息。但这些分散在每一个业务组件和主机下的日志信息不利于问题排查和定位问题的根本缘由。这种监控场景正是应用性能监控系统的用武之地，应用性能监控系统收集，汇总并分析日志信息达到有效监控系统性能和问题的效果。经过监控信息，能够清晰地定位问题发生缘由，让开发人员及时修复问题。

惟品会有三级监控，系统/网络层面监控、应用层面监控和业务层面监控。

系统/网络层面监控，主要是对下列指标进行监控：服务器指标，如CPU、内存、磁盘、流量、TCP链接数等；数据库指标，如QPS、主从复制延时、进程、慢查询等。

业务层面监控，经过两种方法，第一种在指定页面作埋点，第二种方法从业务系统的数据库中，将须要监控的数据抽取出来，作必要的分析处理，存入运维本身维护的数据库中；而后经过浏览器页面，展现监控数据，页面同时提供各类时间维度上的筛选、汇总。对一些业务的关键指标如PV、UV、商品展现、登陆/注册、转化率、购物车、订单数量、支付量、发货量和各仓订单数据。可自定义告警范围，通知相关人以便作出响应。

应用层面监控系统Mercury，是惟品会独立研发的应用性能监控平台。经过在应用程序中植入探针逻辑来实现对应用代码、关系数据库、缓存系统的实时监控。Mercury经过收集日志、上报日志的方式即时获取相关性能指标并进行智能分析，及时发现分布式应用系统的性能问题以及异常和错误，为系统解决性能和程序问题提供方即可靠的依据。同时经过Mercury数据展示平台，用户可轻松便捷的获取应用360度监控信息。

在惟品会体系中，Mercury提供的主要功能包括：

• 定位慢调用：包括慢Web服务（包括Restful Web服务），慢OSP服务，慢SQL
• 定位错误：包括4XX，5XX，OSP Error
• 定位异常：包括Error Exception，Fatal Exception
• 展示依赖和拓扑：域拓扑，服务拓扑，trace拓扑
• Trace调用链：将端到端的调用，以及附加在此次调用的上下文信息，异常日志信息，每个调用点的耗时都呈现给用户
• 应用告警：根据运维设定的告警规则，扫描指标数据，如违反告警规则，则将告警信息上报到惟品会中央告警平台

Mercury架构主要分如下几大模块：

日志由客户端传输到服务端后，分二条路径。第一条路径，裸日志（Trace log / Exception log ）经过kafka，再经过flume直接落地到HBase。这些裸日志用来查询trace调用链信息和异常日志。另外一条路径，日志信息经过kafka直接送到spark stream，经过spark分析后计算后，产生data points性能指标数据，再经过flume写入OpenTSDB。整个传输过程最重要的就是保证数据消费不要丢失和积压。

一旦知足经过运维人员事先配置的告警规则，告警模块可触发告警动做。告警信息可在第一时间将故障上报给中央告警平台。

结束语

以上几点是咱们对高并发系统的一些体会，咱们在不断改进系统，为将惟品会作大作强持续努力，也但愿经过本次分享给你们带来必定收获。