构建高并发高可用的电商平台架构实践.docx
《构建高并发高可用的电商平台架构实践.docx》由会员分享，可在线阅读，更多相关《构建高并发高可用的电商平台架构实践.docx（29页珍藏版）》请在冰豆网上搜索。
构建高并发高可用的电商平台架构实践
构建高并发高可用的电商平台架构实践
一、 设计理念
1. 空间换时间
1） 多级缓存，静态化
客户端页面缓存（httpheader中包含Expires/CacheofControl，lastmodified（304，server不返回body，客户端可以继续用cache，减少流量），ETag）
反向代理缓存
应用端的缓存（memcache）
存数据库
Buffer、cache机制（数据库，中间件等）
2） 索引
哈希、B树、倒排、bitmap
哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。
B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。
倒排索引实现单词到文档映射关系的最佳实现式和最有效的索引结构，广泛用在搜索领域。
Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。
2. 并行与分布式计算
1） 任务切分、分而治之（MR）
在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。
MR模型是无共享的架构，数据集分布至各个节点。
处理时，每个节点就近读取本地存储的数据处理（map），将处理后的数据进行合并（combine）、排序（shuffleandsort）后再分发（至reduce节点），避免了大量数据的传输，提高了处理效率。
2） 多进程、多线程并行执行（MPP）
并行计算（ParallelComputing）是指同时使用多种计算资源解决计算问题的过程，是提高计算机系统计算速度和处理能力的一种有效手段。
它的基本思想是用多个处理器/进程/线程来协同求解同一问题，即将被求解的问题分解成若干个部分，各部分均由一个独立的处理机来并行计算。
和MR的区别在于，它是基于问题分解的，而不是基于数据分解。
3. 多维度的可用
1） 负载均衡、容灾、备份
随着平台并发量的增大，需要扩容节点进行集群，利用负载均衡设备进行请求的分发；负载均衡设备通常在提供负载均衡的同时，也提供失效检测功能；同时为了提高可用性，需要有容灾备份，以防止节点宕机失效带来的不可用问题；备份有在线的和离线备份，可以根据失效性要求的不同，进行选择不同的备份策略。
2） 读写分离
读写分离是对数据库来讲的，随着系统并发量的增大，提高数据访问可用性的一个重要手段就是写数据和读数据进行分离；当然在读写分离的同时，需要关注数据的一致性问题；对于一致性的问题，在分布式的系统CAP定量中，更多的关注于可用性。
3） 依赖关系
平台中各个模块之间的关系尽量是低耦合的，可以通过相关的消息组件进行交互，能异步则异步，分清楚数据流转的主流程和副流程，主副是异步的，比如记录日志可以是异步操作的，增加整个系统的可用性。
当然在异步处理中，为了确保数据得到接收或者处理，往往需要确认机制（confirm、ack）。
但是有些场景中，虽然请求已经得到处理，但是因其他原因（比如网络不稳定），确认消息没有返回，那么这种情况下需要进行请求的重发，对请求的处理设计因重发因素需要考虑幂等性。
4） 监控
监控也是提高整个平台可用性的一个重要手段，多平台进行多个维度的监控；模块在运行时候是透明的，以达到运行期白盒化。
4. 伸缩
1） 拆分
拆分包括对业务的拆分和对数据库的拆分。
系统的资源总是有限的，一段比较长的业务执行如果是一竿子执行的式，在大量并发的操作下，这种阻塞的式，无法有效的及时释放资源给其他进程执行，这样系统的吞吐量不高。
需要把业务进行逻辑的分段，采用异步非阻塞的式，提高系统的吞吐量。
随着数据量和并发量的增加，读写分离不能满足系统并发性能的要求，需要对数据进行切分，包括对数据进行分库和分表。
这种分库分表的式，需要增加对数据的路由逻辑支持。
2） 无状态
对于系统的伸缩性而言，模块最好是无状态的，通过增加节点就可以提高整个的吞吐量。
5. 优化资源利用
1） 系统容量有限
系统的容量是有限的，承受的并发量也是有限的，在架构设计时，一定需要考虑流量的控制，防止因意外攻击或者瞬时并发量的冲击导致系统崩溃。
在设计时增加流控的措施，可考虑对请求进行排队，超出预期的围，可以进行告警或者丢弃。
2） 原子操作与并发控制
对于共享资源的访问，为了防止冲突，需要进行并发的控制，同时有些交易需要有事务性来保证交易的一致性，所以在交易系统的设计时，需考虑原子操作和并发控制。
保证并发控制一些常用高性能手段有，乐观锁、Latch、mutex、写时复制、CAS等；多版本的并发控制MVCC通常是保证一致性的重要手段，这个在数据库的设计中经常会用到。
3） 基于逻辑的不同，采取不一样的策略
平台中业务逻辑存在不同的类型，有计算复杂型的，有消耗IO型的，同时就同一种类型而言，不同的业务逻辑消耗的资源数量也是不一样的，这就需要针对不同的逻辑采取不同的策略。
针对IO型的，可以采取基于事件驱动的异步非阻塞的式，单线程式可以减少线程的切换引起的开销，或者在多线程的情况下采取自旋spin的式，减少对线程的切换（比如oraclelatch设计）；对于计算型的，充分利用多线程进行操作。
同一类型的调用式，不同的业务进行合适的资源分配，设置不同的计算节点数量或者线程数量，对业务进行分流，优先执行优先级别高的业务。
4） 容错隔离
系统的有些业务模块在出现错误时，为了减少并发下对正常请求的处理的影响，有时候需要考虑对这些异常状态的请求进行单独渠道的处理，甚至暂时自动禁止这些异常的业务模块。
有些请求的失败可能是偶然的暂时的失败（比如网络不稳定），需要进行请求重试的考虑。
5） 资源释放
系统的资源是有限的，在使用资源时，一定要在最后释放资源，无论是请求走的是正常路径还是异常的路径，以便于资源的及时回收，供其他请求使用。
在设计通信的架构时，往往需要考虑超时的控制。
二、 静态架构蓝图
整个架构是分层的分布式的架构，纵向包括CDN，负载均衡/反向代理，web应用，业务层，基础服务层，数据存储层。
水平向包括对整个平台的配置管理部署和监控。
三、 剖析架构
1. CDN
CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。
其目的是使用户可就近取得所需容，解决 Internet网络拥挤的状况，提高用户访问的响应速度。
对于大规模电子商务平台一般需要建CDN做网络加速，大型平台如淘宝、京东都采用自建CDN，中小型的企业可以采用第三CDN厂商合作，如蓝汛、网宿、快网等。
当然在选择CDN厂商时，需要考虑经营时间长短，是否有可扩充的带宽资源、灵活的流量和带宽选择、稳定的节点、性价比。
2. 负载均衡、反向代理
一个大型的平台包括很多个业务域，不同的业务域有不同的集群，可以用DNS做域名解析的分发或轮询，DNS式实现简单，但是因存在cache而缺乏灵活性；一般基于商用的硬件F5、NetScaler或者开源的软负载lvs在4层做分发，当然会采用做冗余（比如lvs+keepalived）的考虑，采取主备式。
4层分发到业务集群上后，会经过web服务器如nginx或者HAProxy在7层做负载均衡或者反向代理分发到集群中的应用节点。
选择哪种负载，需要综合考虑各种因素（是否满足高并发高性能，Session保持如解决，负载均衡的算法如，支持压缩，缓存的存消耗）；下面基于几种常用的负载均衡软件做个介绍。
LVS，工作在4层，Linux实现的高性能高并发、可伸缩性、可靠的的负载均衡器，支持多种转发式（NAT、DR、IP Tunneling），其中DR模式支持通过广域网进行负载均衡。
支持双机热备（Keepalived或者Heartbeat）。
对网络环境的依赖性比较高。
Nginx工作在7层，事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器/反向代理软件。
可以针对域名、目录结构、正则规则针对http做一些分流。
通过端口检测到服务器部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。
对于session sticky，可以基于ip hash的算法来实现，通过基于cookie的扩展nginx-sticky-module支持sessionsticky。
HAProxy支持4层和7层做负载均衡，支持session的会话保持，cookie的引导；支持后端url式的检测；负载均衡的算法比较丰富，有RR、权重等。
对于图片，需要有单独的域名，独立或者分布式的图片服务器或者如mogileFS，可以图片服务器之上加varnish做图片缓存。
3. App接入
应用层运行在jboss或者tomcat容器中，代表独立的系统，比如前端购物、用户自主服务、后端系统等
协议接口，HTTP、JSON
可以采用servlet3.0,异步化servlet,提高整个系统的吞吐量
http请求经过Nginx，通过负载均衡算法分到到App的某一节点，这一层层扩容起来比较简单。
除了利用cookie保存少量用户部分信息外（cookie一般不能超过4K的大小），对于App接入层，保存有用户相关的session数据，但是有些反向代理或者负载均衡不支持对session sticky支持不是很好或者对接入的可用性要求比较高（app接入节点宕机，session随之丢失），这就需要考虑session的集中式存储，使得App接入层无状态化，同时系统用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的。
Session的集中式存储，需要满足以下几点要求：
a、高效的通讯协议
b、session的分布式缓存，支持节点的伸缩，数据的冗余备份以及数据的迁移
c、session过期的管理
4. 业务服务
代表某一领域的业务提供的服务，对于电商而言，领域有用户、商品、订单、红包、支付业务等等，不同的领域提供不同的服务，
这些不同的领域构成一个个模块，良好的模块划分和接口设计非常重要，一般是参考高聚、接口收敛的原则，
这样可以提高整个系统的可用性。
当然可以根据应用规模的大小，模块可以部署在一起，对于大规模的应用，一般是独立部署的。
高并发：
业务层对外协议以NIO的RPC式暴露，可以采用比较成熟的NIO通讯框架，如netty、mina
可用性：
为了提高模块服务的可用性，一个模块部署在多个节点做冗余，并自动进行负载转发和失效转移;
最初可以利用VIP+heartbeat式，目前系统有一个单独的组件HA,利用zookeeper实现（比原来案的优点）
一致性、事务：
对于分布式系统的一致性，尽量满足可用性，一致性可以通过校对来达到最终一致的状态。
5. 基础服务中间件
1） 通信组件
通信组件用于业务系统部服务之间的调用，在大并发的电商平台中，需要满足高并发高吞吐量的要求。
整个通信组件包括客户端和服务端两部分。
客户端和服务器端维护的是长连接，可以减少每次请求建立连接的开销，在客户端对于每个服务器定义一个连接池，初始化连接后，可以并发连接服务端进行rpc操作，连接池中的长连接需要心跳维护，设置请求超时时间。
对于长连接的维护过程可以分两个阶段，一个是发送请求过程，另外一个是接收响应过程。
在发送请求过程中，若发生IOException，则把该连接标记失效。
接收响应时，服务端返回SocketTimeoutException，如果设置了超时时间，那么就直接返回异常，清除当前连接中那些超时的请求。
否则继续发送心跳包（因为可能是丢包，超过pingInterval间隔时间就发送ping操作），若ping不通（发送IOException），则说明当前连接是有问题的，那么就把当前连接标记成已经失效；若ping通，则说明当前连接是可靠的，继续进行读操作。
失效的连接会从连接池中清除掉。
每个连接对于接收响应来说都以单独的线程运行，客户端可以通过同步（wait,notify）式或者异步进行rpc调用，
序列化采用更高效的hession序列化式。
服务端采用事件驱动的NIO的MINA框架，支撑高并发高吞吐量的请求。
2） 路由Router
在大多数的数据库切分解决案中，为了提高数据库的吞吐量，首先是对不同的表进行垂直切分到不同的数据库中，
然后当数据库中一个表超过一定大小时，需要对该表进行水平切分，这里也是一样，这里以用户表为例；
对于访问数据库客户端来讲，需要根据用户的ID，定位到需要访问的数据；
数据切分算法，
根据用户的ID做hash操作，一致性Hash，这种式存在失效数据的迁移问题，迁移时间服务不可用
维护路由表，路由表中存储用户和sharding的映射关系,sharding分为leader和replica，分别负责写和读
这样每个biz客户端都需要保持所有sharding的连接池，这样有个缺点是会产生全连接的问题；
一种解决法是sharding的切分提到业务服务层进行，每个业务节点只维护一个shard的连接即可。
见图（router）
路由组件的实现是这样的（可用性、高性能、高并发）
基于性能面的考虑，采用mongodb中维护用户id和shard的关系，为了保证可用性，搭建replicatset集群。
biz的sharding和数据库的sharding是一一对应的，只访问一个数据库sharding.
biz业务注册节点到zookeeper上/bizs/shard/下。
router监听zookeeper上/bizs/下节点状态，缓存在线biz在router中。
client请求router获取biz时，router首先从mongodb中获取用户对应的shard,router根据缓存的容通过RR算法获取biz节点。
为了解决router的可用性和并发吞吐量问题，对router进行冗余，同时client监听zookeeper的/routers节点并缓存在线router节点列表。
3） HA
传统实现HA的做法一般是采用虚拟IP漂移，结合Heartbeat、keepalived等实现HA，
Keepalived使用vrrp式进行数据包的转发，提供4层的负载均衡，通过检测vrrp数据包来切换，做冗余热备更加适合与LVS搭配。
Linux Heartbeat是基于网络或者主机的服务的高可用，HAProxy或者Nginx可以基于7层进行数据包的转发，因此Heatbeat更加适合做HAProxy、Nginx，包括业务的高可用。
在分布式的集群中，可以用zookeeper做分布式的协调，实现集群的列表维护和失效通知，客户端可以选择hash算法或者roudrobin实现负载均衡；对于master-master模式、master-slave模式，可以通过zookeeper分布式锁的机制来支持。
4） 消息Message
对于平台各个系统之间的异步交互，是通过MQ组件进行的。
在设计消息服务组件时，需要考虑消息一致性、持久化、可用性、以及完善的监控体系。
业界开源的消息中间件主要RabbitMQ、kafka有两种，
RabbitMQ,遵循AMQP协议，由在高并发的erlanng语言开发；kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。
对消息一致性要求比较高的场合需要有应答确认机制，包括生产消息和消费消息的过程；不过因网络等原理导致的应答缺失，可能会导致消息的重复，这个可以在业务层次根据幂等性进行判断过滤；RabbitMQ采用的是这种式。
还有一种机制是消费端从broker拉取消息时带上LSN号，从broker中某个LSN点批量拉取消息，这样无须应答机制，kafka分布式消息中间件就是这种式。
消息的在broker中的存储，根据消息的可靠性的要求以及性能面的综合衡量，可以在存中，可以持久化到存储上。
对于可用性和高吞吐量的要求，集群和主备模式都可以在实际的场景应用的到。
RabbitMQ解决案中有普通的集群和可用性更高的mirror queue式。
kafka采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上。
总体来讲，RabbitMQ用在实时的对可靠性要求比较高的消息传递上。
kafka主要用于处理活跃的流式数据,大数据量的数据处理上。
5） Cache&Buffer
Cache系统
在一些高并发高性能的场景中，使用cache可以减少对后端系统的负载，承担可大部分读的压力，可以大大提高系统的吞吐量，比如通常在数据库存储之前增加cache缓存。
但是引入cache架构不可避免的带来一些问题，cache命中率的问题, cache失效引起的抖动，cache和存储的一致性。
Cache中的数据相对于存储来讲，毕竟是有限的，比较理想的情况是存储系统的热点数据，这里可以用一些常见的算法LRU等等淘汰老的数据；随着系统规模的增加，单个节点cache不能满足要求，就需要搭建分布式Cache；为了解决单个节点失效引起的抖动 ，分布式cache一般采用一致性hash的解决案，大大减少因单个节点失效引起的抖动围；而对于可用性要求比较高的场景，每个节点都是需要有备份的。
数据在cache和存储上都存有同一份备份，必然有一致性的问题，一致性比较强的，在更新数据库的同时，更新数据库cache。
对于一致性要求不高的，可以去设置缓存失效时间的策略。
Memcached作为高速的分布式缓存服务器，协议比较简单，基于libevent的事件处理机制。
Cache系统在平台中用在router系统的客户端中，热点的数据会缓存在客户端，当数据访问失效时，才去访问router系统。
当然目前更多的利用存型的数据库做cache，比如redis、mongodb；redis比memcache有丰富的数据操作的API；redis和mongodb都对数据进行了持久化，而memcache没有这个功能，因此memcache更加适合在关系型数据库之上的数据的缓存。
Buffer系统
用在高速的写操作的场景中，平台中有些数据需要写入数据库，并且数据是分库分表的，但对数据的可靠性不是那么高，为了减少对数据库的写压力，可以采取批量写操作的式。
开辟一个存区域，当数据到达区域的一定阀值时如80%时，在存中做分库梳理工作（存速度还是比较快的），后分库批量flush。
6） 搜索
在电子商务平台中搜索是一个非常的重要功能，主要有搜索词类目导航、自动提示和搜索排序功能。
开源的企业级搜索引擎主要有lucene, sphinx，这里不去论述哪种搜索引擎更好一些，不过选择搜索引擎除了基本的功能需要支持外，非功能面需要考虑以下两点：
a、 搜索引擎是否支持分布式的索引和搜索，来应对海量的数据，支持读写分离，提高可用性
b、 索引的实时性
c、 性能
Solr是基于lucene的高性能的全文搜索服务器，提供了比lucene更为丰富的查询语言，可配置可扩展，对外提供基于http协议的XML/JSON格式的接口。
从Solr4版本开始提供了SolrCloud式来支持分布式的索引，自动进行sharding数据切分；通过每个sharding的master-slave（leader、replica）模式提高搜索的性能；利用zookeeper对集群进行管理，包括leader选举等等，保障集群的可用性。
Lucene索引的Reader是基于索引的snapshot的，所以必须在索引commit的后，重新打开一个新的snapshot，才能搜索到新添加的容；而索引的commit是非常耗性能的，这样达到实时索引搜索效率就比较低下。
对于索引搜索实时性，Solr4的之前解决案是结合文件全量索引和存增量索引合并的式，参见下图。
Solr4提供了NRT softcommit的解决案，softcommit无需进行提交索引操作，就可以搜素到最新对索引的变更，不过对索引的变更并没有sync commit到硬盘存储上，若发生意外导致程序非正常结束，未commit的数据会丢失，因此需要定时的进行commit操作。
平台中对数据的索引和存储操作是异步的，可以大大提高可用性和吞吐量；只对某些属性字段做索引操作，存储数据的标识key，减少索引的大小；数据是存储在分布式存储HBase 中的，HBase对二级索引搜索支持的不好，然而可以结合Solr搜索功能进行多维度的检索统计。
索引数据和HBase数据存储的一致性，也就是如保障HBase存储的数据都被索引过，可以采用confirm确认机制，通过在索引前建立待索引数据队列，在数据存储并索引完成后，从待索引数据队列中删除数据。
7） 日志收集
在整个交易过程中，会产生大量的日志，这些日志需要收集到分布式存储系统中存储起来，以便于集中式的查询和分析处理。
日志系统需具备三个基本组件，分别为agent（封装数据源，将数据源中的数据发送给collector），collector（接收多个agent的数据，并进行汇总后导入后端的store中），store（中央存储系统，应该具有可扩展性和可靠性，应该支持当前非常流行的HDFS）。
开源的日志收集系统业界使用的比较多的是cloudera的Flume和facebook的Scribe，其中Flume目前的版本FlumeNG对Flume从架构上做了较大的改动。
在设计或者对日志收集系统做技术选型时，通常需要具有以下特征：
a、 应用系统和分析系统之间的桥梁，将他们之间的关系解耦
b、 分布式可扩展，具有高的扩展性，当数据量增加时，可以通过增加节点水平扩展
日志收集系统是可以伸缩的，在系统的各个层次都可伸缩，对数据的处理不需要带状态，伸缩性面也比较容易实现。
c、 近实时性
在一些时效性要求比较高的场景中，需要可以及时的收集日志，进行数据分析；
一般的日志文件都会定时或者定量的进行rolling，所以实时检测日志文件的生成，及时对日志文件进行类似的tail操作，并支持批量发送提高传输效率；批量发送的时机需要满足消息数量和时间间隔的要求。
d、 容错性
Scribe在容错面的考虑是，当后端的存储系统crash时，scribe会将数据写到本地磁盘上，当存储系统恢复正常后，scribe将日志重新加载到存储系统中。
FlumeNG通过Sink Processor实现负载均衡和故障转移。
多个Sink可以构成一个Sink Group。
一个Sink Processor负责从一个指定的Sink Group中激活一个Sink。
Sink Processor可以通过组中所有Sink实现负载均衡；也可以在一个Sink失败时转移到另一个。
e、 事务支持
Scribe没有考虑事务的支持。
Flume通过应答确认机制实现事务的支持，参见下图，
通常提取发送消息都是批量操作的，消息的确认是对一批数据的确认，这样可以大大提高数据
升级会员 