最近几年的技术变化大吗?到底有多大?
近几年,电子商务开展的如火如荼,几家大型电子商务网站为了争夺市场份额,价格战和各类促销活动此起彼伏,天猫每年一度的双11促销更将这一盛况演绎成一场全民狂欢。
电子商务网站的大型促销活动虽然让网站、卖家、消费者都得到好处,但是却让网站技术面临极大的挑战。
一次成功的电子商务网站的促销活动通常会吸引数倍于网站平常的访问量和交易量,而高峰期的访问量更可能是正常访问量的数十倍。如此不同寻常的访问量会给网站基础技术设施带来巨大的压力。
促销活动时,用户主要访问的页面是商品详情页面,这个页面包含了大量的商品图片、商品描述信息。信息量大也意味着打开商品详情页面需要消耗更多的网络带宽,粗略估算,天猫双11促销开始时的网络带宽压力可达数百Gbps。
显然如果仅仅依靠网站数据中心的处理能力不可能应付如此庞大的数据传输压力。大型电商网站通常会选择使用CDN服务,将网站图片、JS、CSS等静态文件缓存至最终用户较近的网络运营商机房,分摊网站整体带宽压力,减轻机房服务器压力,改善用户访问速度。
CDN服务器本质上是一个缓存服务器集群,在网站进行大型促销活动前,通过水平扩容的方式增加CDN服务器,提高数据存储和吞吐能力,并向网络运营商临时租借更多网络带宽,以满足促销时所需的网络带宽压力。
同样,应用服务器也面临大量用户访问的压力,随着并发访问用户数增多,应用服务器的处理能力逐渐降低,超过某个临界点以后,系统性能急剧恶化,并很快趋于崩溃。应用服务器并发访问性能曲线如图1。
图1 应用服务器并发访问性能曲线
正常情况系统运行在最佳运行区间,网站促销的时候,由于大量用户突然访问,系统将超过最大负载点,导致用户响应延迟,而这将进一步导致更多请求阻塞在服务器,形成恶性循环,最终导致服务器崩溃。
通常网站将应用服务器设计为无状态的应用服务器,这样可以通过负载均衡设备将一组相同的应用服务器组成一个服务器集群,共同对外提供服务。每台服务器都分摊部分请求负载,以保持单台服务器运行在最佳运行区间。当网站进行促销活动的时候,通过配置负载均衡设备,向应用服务器集群增加更多服务器,使单台服务器的并发请求负载仍然维持在一个可接受的水平。
目前而言,CDN的水平扩容和应用服务器的负载均衡技术都比较成熟。而数据服务器的扩容则相对比较棘手,前一段时间,某些B2C电商网站逢促销必宕机,以及某票务系统的崩溃,基本上都源于数据库服务器不能承受如此高并发的访问压力而导致的。
所以保证数据库服务器在高并发访问下能正常运行就成为许多大型电子商务网站重要的技术难题。目前常用的处理手段是使用分布式数据库,根据业务划分将不同业务数据库部署在不同服务器上。如果单一数据表数据量十分庞大,比如淘宝的商品表和用户表(数亿条记录),就进行水平切分,将一张表切分成多个部分,储存在一组服务器上,实现数据库的水平扩容。
即使是使用了分布式数据,进行大型促销活动的时候,仍然可能会超过数据库的最大负载能力,这种情况下,还需要使用排队的手段,将交易请求缓存在消息队列中,根据数据库负载能力,逐步处理请求,以保证数据库的安全。
需要特别说明的是,不管是分布式数据库还是请求排队,从技术实现到业务迁移都需要较长时间的开发部署和系统磨合,所以必须要及早进行。如果等到业务部门通知要大型促销才开始准备,一定会死的非常难看。
不管是CDN、应用服务器还是数据库服务器,应对促销时大规模并发访问的主要手段就是水平扩容,通过增加集群内服务器的方式使并发请求分摊到更多的服务器上,降低单台服务器的负载压力,保证用户访问的顺利进行。
实现水平扩容的技术方案也称作伸缩性架构,指系统能够通过增加(减少)自身资源规模的方式增强(减少)自己计算处理事务的能力。如果处理能力的增减和服务器数量的增减是成比例的,就被称作线性伸缩性。
使用负载均衡设备进行请求转发是应用服务器实现伸缩性架构的主要手段,负载均衡的基本原理如图2。
图2负载均衡的基本原理
负载均衡服务器(网站较常用的是包含LVS模块的Linux服务器)通过某种负载均衡算法(轮询、随机。。。)将用户请求转发给应用服务器集群中某台服务器,使用户请求较平均地分摊到集群中所有服务器上,保证每台服务器的负载压力都维持在一个合适的水平。
异步处理请求是网站在高并发访问时实现排队的主要技术手段,如图3。
图3 通过异步方式实现数据库访问排队
应用服务器在收到用户请求以后,不是同步直接访问数据库进行数据处理,而是将请求作为一个消息发送到消息队列服务器,由消息队列服务器根据数据库服务器负载压力,异步地将请求排队后逐渐发送给数据库服务器进行处理,以维持数据库负载压力保持在一个可接受的水平(实践中,通常会部署专门的消息消费者服务器,从消息队列服务器中读取消息,再写入数据库)。
使用缓存是网站性能优化、缓解服务器负载压力的主要手段,一方面通过缓存快速获取数据使得用户请求尽快返回,改善用户体验,另一方面,通过缓存获取数据从而降低数据库的读取访问压力。缓存访问模型如图4。
图4 缓存访问模型
电子商务网站的数据访问是典型的有热点数据访问,热门商品会被更多人访问。应用程序在第一次访问的时候从数据库上读取数据,然后缓存在缓存服务器上,以后所有对于该商品的访问都可以直接从缓存服务器上读取。
一个典型的大型电子商务网站架构模型如图5所示。
图5 大型电子商务网站架构模型
用户静态资源请求直接访问离他最近的CDN服务器,大部分最耗流量的商品图片都是通过CDN返回的。动态内容请求(以及CDN不存在的静态资源请求)则发送到网站数据中心的反向代理服务器集群,反向代理服务器主要有两个作用,一是缓存静态资源,快速将静态响应信息返回给用户;另一方面是保持连接,减轻应用服务器的压力。
动态请求通过负载均衡服务器分发给应用服务器集群,应用服务器主要通过分布式服务框架调用各种分布式服务,以完成用户操作请求并构造动态响应信息。而分布式服务则通过本地和远程分布式缓存访问缓存数据,如果缓存不命中,再通过统一数据访问模块访问各种持久化的数据源(关系数据库,文件服务器,搜索引擎,NoSQL系统)。
应用服务器之间(以及分布式服务之间)还会通过分布式消息队列进行异步调用,某个应用服务器将自己接收的请求(或构造的请求)发送到分布式消息队列,其他应用和服务注册监听该消息,接受到消息后继续处理。
天猫双11促销堪称电子商务网站促销活动的典范,其技术应对方案也有很多值得业界参考的地方。天猫应对双11大促的技术方案可分为活动前和活动中两部分。
发布冻结:为了保证促销活动的顺利进行,在双11前几周天猫都会冻结发布。除非Bugfix或者是针对双11的需求和项目,其他需求和项目发布一律冻结,不许上线,以避免系统不稳定,造成大促期间发生事故。
线上压测:虽然线下测试环境已经进行了充分的压力测试,但是线上生产环境和线下环境还是有很大不同(硬件环境、外部服务依赖,用户访问模式),因此天猫通过引流的方式对线上服务器进行压测。即通过调整负载均衡,使某些服务器负担更大的负载,通过观测这些服务器的负载响应能力,结合运营团队估算的访问流量,规划促销时的服务器集群规模。
集群扩容:必须通过水平扩容的方式扩大服务器集群规模才能降低服务器单机负载压力。每年阿里巴巴集团为天猫双11大促新增服务器都达数万台之多。
异步化改造:交易和支付环节因为有大量的数据库事务操作,是整个购物流程的瓶颈,通过分布式消息队列,使交易和支付请求处理异步化,减轻这些系统的峰值压力。
静态化改造:前面提到,网站访问压力最大的页面就是商品详情页面,通过将这些页面构造成静态页面,缓存在CDN及反向代理服务器,极大地改善应用服务器负载压力。
应急预案:为了避免在活动当天出现险情时慌乱应对,天猫为双11活动准备了数百个应急预案。各种可能出现的险情,以及对应的解决方案和的负责人都有预先记录并进行演练。
组织保障:天猫为双11当天的大促活动组织了专门的作战指挥室,由相关技术专家和业务模块负责人组成,统一协调调度各种资源,及时处理活动中遇到的各种技术问题。
系统预警:依赖于淘宝强大的监控系统,在双11当天如果有服务器系统及业务指标超过警戒阈值,监控系统立刻报警,相关责任者迅速响应,根据应急预案采取对应措施。主要是各种降级和限流措施。
功能降级:如果发现某些系统(主要是交易和支付系统)因为并发访问压力太大,超过警戒值而报警,天猫技术保障团队就会关闭部分非核心业务功能,比如确认收货(需要交易和支付系统支持),以保证当前确认订单交易顺利进行。
品质降级:活动过程中,如果网络带宽和CDN压力超过最大负载能力,就会通过降低图片品质(使用更小图片或者低质量图片)来减小响应数据包,节省带宽流量。
系统限流:如果其他手段都不能有效使系统负载下降到警戒值以下,那么就不得不进行系统限流,即拒绝部分用户请求(比如来自IE浏览器的用户J),使网站服务器运行在最大负载能力之下,保护网站不至于整体崩溃,大部分用户仍然可以正常访问。
电子商务的快速发展,今天网站促销活动的访问压力也许只是明天正常的访问压力,所以今天为促销而准备的技术方案明天就会成为系统的正常架构。为网站业务持续发展而进行技术积淀和改造是网站工程师的份内之事,也是网站技术最有挑战和最有乐趣的事。关于大型网站技术架构更多信息可参考电子工业出版社出版的《大型网站技术架构-核心原理与案例分析》。
在此不得不佩服阿里,京东这些电商平台,实力还真不是吹的,敬畏技术.