电商网站构建

电子商务团队是在企业内部利用互联网开展企业电子商贸活动，利用网络将企业的销、产、供、研等活动串在一起，实现了企业网络发展的多人团体。下面，结合实际谈谈如何加强电子商务团队的建设。

一、确定优秀的电商团队负责人

建设电子商务团队，首先关键的一点是要找到团队的负责人，这个人就是整个团队的核心，直接决定了整个团队的执行能力，决定了整个团队的成败。团队负责人必须要有计划能力、分析能力、执行能力、控制能力、管理能力，同时还要懂得电子商务的方方面面，包括：电子商务战略规划、商城建设及营运、互联网营销、网站建设、SEO优化等等，还要懂得传统商业运作，例如品牌规划、营销策略、渠道建设等，还要具备实战能力，用经验来归纳总结理论，从而进一步指导电子商务战略、战术的规划和执行。

二、构建合理的电商管理团队

构建一个结构完整的电子商务团队一般可分为七个部门：客服部、市场部、物流部、技术部、网站运营部、财务部和人力资源部。客服部的职能就是客服服务、客户咨询、客服培训考核等；技术部负责网站、呼叫中心和电子商务系统的建设，以及采购系统、仓储系统、CRM系统和各种系统之间的对接等；市场部负责互联网和其他媒体推广、品牌宣传和公关、网站合作、支付合作、网站策划、CRM营销；物流部负责根据采购名单进行招标和采购、网站仓储在的布局和设计、制定仓储标准和物流配送标准、设计仓储管理系统、选择物流配送合作伙伴、设计产品配送包装、根据订单的进行配送、并根据销售状况调节产品在不同仓储之间的库存等；网站运营部负责制定产品定价，设计产品文案，拍摄并处理产品图片，分析各类型产品，制定采购名单，优化购物流程，提高用户的购物体验，并根据销售状况制定促销方案，配合市场部完成对外推广的促销宣传。

三、加强电子商务团队的管理

电子商务团队组建起来后，必须要有清晰的目标，明确的岗位分工，确定各人职责，这就加强电子商务团队建设的主要内容。从五个方面分析一下如何加强团队管理，来实现最大的效益。

一是要有系统的团队培训。要切实提高团队每个成员的专业素质和能力水平，使整个团队协作起来。可以请专业的人来给员工上课，让大家充电，也可申请机会外出学习和交流。此外还要想办法留住人才，防止他们跳槽，让团队在高强度的工作下保持进取心和战斗力。

二是团队的目标要一致。只有目标一致了，大家的方向相同了，才能够齐心协力向着同一个方向走。好的项目主管善于捕捉成员间不同的心态，理解他们的需求，帮助他们树立共同的奋斗目标。劲往一处使，使得团队的努力形成合力。

三是加强团队交流和分享。电商团队要经常召开交流会，交流各自工作的收获和心得，交流才是能够让大家最快的进步的方法。在交流中，您可以收获别人的收获，也可以在交流中对自己做的对的和好的地方加以肯定，而增强自信心；另一方面也可以在交流中发现自己的不足。交流的过程，更是一种多项互动，多项学习的过程。

四是加强对员工的管理。要对每位员工的工作进行统筹管理，准确把握住整体的工作情况和任务完成情况。要能够全方位的让员工得到发展，又能相互协作，共同发展。我们一直使用日事清进行团队的管理，日事清兼顾个人管理和团队协作功能，具有先进的时间管理和效率管理理念。能更清晰的梳理年度计划、周月计划，将每个计划分解成多个子任务，并可以随时展开讨论，帮助更直观、及时的反映出每个员工的工作内容和进展，提升团队协作能力和管理效率。

五是加强团队文化建设。电子商务团队文化也非常重要。整点打卡上下班，这种传统的工作模式显得太死板，新的电商团队每个人需要有每时每刻随时随地都在工作状态的意识。比如现在每个电商团队成员上班下班都在用手机和客户沟通，不断学习和了解行业知识和新闻，为自己充电。这种工作状态的转变是电商团队成员必须具备的。

引言

并发，在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理机上运行，但任一个时刻点上只有一个程序在处理机上运行。

“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。

一、 设计理念

1. 空间换时间 多级缓存，静态化

客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag）

反向代理缓存

应用端的缓存(memcache)

内存数据库

Buffer、cache机制（数据库，中间件等）

2) 索引

哈希、B树、倒排、bitmap

哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。

B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。

倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。

Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。

2. 并行与分布式计算

1) 任务切分、分而治之(MR)

在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。

MR模型是无共享的架构，数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理(map)，将处理后的数据进行合并(combine)、排序(shuffle and sort)后再分发(至reduce节点)，避免了大量数据的传输，提高了处理效率。

2) 多进程、多线程并行执行(MPP)

并行计算（Parallel Computing）是指同时使用多种计算资源解决计算问题的过程，是提高计算机系统计算速度和处理能力的一种有效手段。它的基本思想是用多个处理器/进程/线程来协同求解同一问题，即将被求解的问题分解成若干个部分，各部分均由一个独立的处理机来并行计算。

和MR的区别在于，它是基于问题分解的，而不是基于数据分解。

3. 多维度的可用1) 负载均衡、容灾、备份

随着平台并发量的增大，需要扩容节点进行集群，利用负载均衡设备进行请求的分发；负载均衡设备通常在提供负载均衡的同时，也提供失效检测功能；同时为了提高可用性，需要有容灾备份，以防止节点宕机失效带来的不可用问题；备份有在线的和离线备份，可以根据失效性要求的不同，进行选择不同的备份策略。

2) 读写分离

读写分离是对数据库来讲的，随着系统并发量的增大，提高数据访问可用性的一个重要手段就是写数据和读数据进行分离；当然在读写分离的同时，需要关注数据的一致性问题；对于一致性的问题，在分布式的系统CAP定量中，更多的关注于可用性。

3) 依赖关系

平台中各个模块之间的关系尽量是低耦合的，可以通过相关的消息组件进行交互，能异步则异步，分清楚数据流转的主流程和副流程，主副是异步的，比如记录日志可以是异步操作的，增加整个系统的可用性。

当然在异步处理中，为了确保数据得到接收或者处理，往往需要确认机制(confirm、ack)。

但是有些场景中，虽然请求已经得到处理，但是因其他原因(比如网络不稳定)，确认消息没有返回，那么这种情况下需要进行请求的重发，对请求的处理设计因重发因素需要考虑幂等性。

4) 监控

监控也是提高整个平台可用性的一个重要手段，多平台进行多个维度的监控；模块在运行时候是透明的，以达到运行期白盒化。

4. 伸缩1) 拆分

拆分包括对业务的拆分和对数据库的拆分。

系统的资源总是有限的，一段比较长的业务执行如果是一竿子执行的方式，在大量并发的操作下，这种阻塞的方式，无法有效的及时释放资源给其他进程执行，这样系统的吞吐量不高。

需要把业务进行逻辑的分段，采用异步非阻塞的方式，提高系统的吞吐量。

随着数据量和并发量的增加，读写分离不能满足系统并发性能的要求，需要对数据进行切分，包括对数据进行分库和分表。这种分库分表的方式，需要增加对数据的路由逻辑支持。

2) 无状态

对于系统的伸缩性而言，模块最好是无状态的，通过增加节点就可以提高整个的吞吐量。

5. 优化资源利用1) 系统容量有限

系统的容量是有限的，承受的并发量也是有限的，在架构设计时，一定需要考虑流量的控制，防止因意外攻击或者瞬时并发量的冲击导致系统崩溃。在设计时增加流控的措施，可考虑对请求进行排队，超出预期的范围，可以进行告警或者丢弃。

2) 原子操作与并发控制

对于共享资源的访问，为了防止冲突，需要进行并发的控制，同时有些交易需要有事务性来保证交易的一致性，所以在交易系统的设计时，需考虑原子操作和并发控制。

保证并发控制一些常用高性能手段有，乐观锁、Latch、mutex、写时复制、CAS等；多版本的并发控制MVCC通常是保证一致性的重要手段，这个在数据库的设计中经常会用到。

3) 基于逻辑的不同，采取不一样的策略

平台中业务逻辑存在不同的类型，有计算复杂型的，有消耗IO型的，同时就同一种类型而言，不同的业务逻辑消耗的资源数量也是不一样的，这就需要针对不同的逻辑采取不同的策略。

针对IO型的，可以采取基于事件驱动的异步非阻塞的方式，单线程方式可以减少线程的切换引起的开销，或者在多线程的情况下采取自旋spin的方式，减少对线程的切换(比如oracle latch设计)；对于计算型的，充分利用多线程进行操作。

同一类型的调用方式，不同的业务进行合适的资源分配，设置不同的计算节点数量或者线程数量，对业务进行分流，优先执行优先级别高的业务。

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支持session sticky。

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客户�...

引言

并发，在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理机上运行，但任一个时刻点上只有一个程序在处理机上运行。

“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。

一、 设计理念

1. 空间换时间 多级缓存，静态化

客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag）

反向代理缓存

应用端的缓存(memcache)

内存数据库

Buffer、cache机制（数据库，中间件等）

2) 索引

哈希、B树、倒排、bitmap

哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。

B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。

倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。

Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。

2. 并行与分布式计算

1) 任务切分、分而治之(MR)

在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。

MR模型是无共享的架构，数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理(map)，将处理后的数据进行合并(combine)、排序(shuffle and sort)后再分发(至reduce节点)，避免了大量数据的传输，提高了处理效率。

2) 多进程、多线程并行执行(MPP)

并行计算（Parallel Computing）是指同时使用多种计算资源解决计算问题的过程，是提高计算机系统计算速度和处理能力的一种有效手段。它的基本思想是用多个处理器/进程/线程来协同求解同一问题，即将被求解的问题分解成若干个部分，各部分均由一个独立的处理机来并行计算。

和MR的区别在于，它是基于问题分解的，而不是基于数据分解。

3. 多维度的可用1) 负载均衡、容灾、备份

随着平台并发量的增大，需要扩容节点进行集群，利用负载均衡设备进行请求的分发；负载均衡设备通常在提供负载均衡的同时，也提供失效检测功能；同时为了提高可用性，需要有容灾备份，以防止节点宕机失效带来的不可用问题；备份有在线的和离线备份，可以根据失效性要求的不同，进行选择不同的备份策略。

2) 读写分离

读写分离是对数据库来讲的，随着系统并发量的增大，提高数据访问可用性的一个重要手段就是写数据和读数据进行分离；当然在读写分离的同时，需要关注数据的一致性问题；对于一致性的问题，在分布式的系统CAP定量中，更多的关注于可用性。

3) 依赖关系

平台中各个模块之间的关系尽量是低耦合的，可以通过相关的消息组件进行交互，能异步则异步，分清楚数据流转的主流程和副流程，主副是异步的，比如记录日志可以是异步操作的，增加整个系统的可用性。

当然在异步处理中，为了确保数据得到接收或者处理，往往需要确认机制(confirm、ack)。

但是有些场景中，虽然请求已经得到处理，但是因其他原因(比如网络不稳定)，确认消息没有返回，那么这种情况下需要进行请求的重发，对请求的处理设计因重发因素需要考虑幂等性。

4) 监控

监控也是提高整个平台可用性的一个重要手段，多平台进行多个维度的监控；模块在运行时候是透明的，以达到运行期白盒化。

4. 伸缩1) 拆分

拆分包括对业务的拆分和对数据库的拆分。

系统的资源总是有限的，一段比较长的业务执行如果是一竿子执行的方式，在大量并发的操作下，这种阻塞的方式，无法有效的及时释放资源给其他进程执行，这样系统的吞吐量不高。

需要把业务进行逻辑的分段，采用异步非阻塞的方式，提高系统的吞吐量。

随着数据量和并发量的增加，读写分离不能满足系统并发性能的要求，需要对数据进行切分，包括对数据进行分库和分表。这种分库分表的方式，需要增加对数据的路由逻辑支持。

2) 无状态

对于系统的伸缩性而言，模块最好是无状态的，通过增加节点就可以提高整个的吞吐量。

5. 优化资源利用1) 系统容量有限

系统的容量是有限的，承受的并发量也是有限的，在架构设计时，一定需要考虑流量的控制，防止因意外攻击或者瞬时并发量的冲击导致系统崩溃。在设计时增加流控的措施，可考虑对请求进行排队，超出预期的范围，可以进行告警或者丢弃。

2) 原子操作与并发控制

对于共享资源的访问，为了防止冲突，需要进行并发的控制，同时有些交易需要有事务性来保证交易的一致性，所以在交易系统的设计时，需考虑原子操作和并发控制。

保证并发控制一些常用高性能手段有，乐观锁、Latch、mutex、写时复制、CAS等；多版本的并发控制MVCC通常是保证一致性的重要手段，这个在数据库的设计中经常会用到。

3) 基于逻辑的不同，采取不一样的策略

平台中业务逻辑存在不同的类型，有计算复杂型的，有消耗IO型的，同时就同一种类型而言，不同的业务逻辑消耗的资源数量也是不一样的，这就需要针对不同的逻辑采取不同的策略。

针对IO型的，可以采取基于事件驱动的异步非阻塞的方式，单线程方式可以减少线程的切换引起的开销，或者在多线程的情况下采取自旋spin的方式，减少对线程的切换(比如oracle latch设计)；对于计算型的，充分利用多线程进行操作。

同一类型的调用方式，不同的业务进行合适的资源分配，设置不同的计算节点数量或者线程数量，对业务进行分流，优先执行优先级别高的业务。

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支持session sticky。

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客户�...