乐视电商云的整体架构与技术实现

本帖最后由 levycui 于 2016-4-12 12:09 编辑
问题导读：
1、电商系统的发展过程有哪些？
2、乐视电商云架构有哪些框架组成？
3、电商云平台架构有哪些？

简介
本次分享将带大家了解电商系统的发展过程，并分析在高速发展期的电商面临的问题，同时跟大家分享乐视电商云的架构和实践方案。

1. 电商系统发展过程
电商网站在不同时期的架构复杂度有所不同：

初创期：商品类型少，业务复杂度低，系统架构简单。采用高可用数据库、分布式缓存、文件存储等基本组件就可满足需求。
发展期：数据量、业务复杂度、系统复杂度、计算资源需求都剧增。则需要业务拆分并独立部署，采用CDN、高可用数据库、分布式缓存、分布式消息队列、分布式文件存储等。

电商技术基础架构图，如下所示：

2. 高速发展期的电商面临的问题

2.1 业务的快速扩张、资源需求快速扩张，但利用率低下企业的主要目标是在市场上抢得先机，降低经营成本。传统租用服务器或数据中心的方式对硬件资源、人力资源都要有很大的开支，而且从采购、招人到系统部署上线周期很长，效率低下。

2.2 系统复杂度的直线上升，耦合严重，牵一发动全身随着业务规模的扩大，大部分时间在进行新功能的开发和bug修复，可能没有精力对系统进行及时梳理与重构，导致系统日益庞大与臃肿，耦合度比较高，牵一发动全身。
甚至有些公用的代码在不同项目中存在多份拷贝，修改一份公有代码后其他的却忘了同步，出问题不好排查，复用率低下。

2.3 安全性问题愈加严重业务做大了以后容易招致DDoS、恶意刷单、恶意渗透、用户隐私泄露等安全风险。在新网络安全法草案的规约中，对电商企业提供服务的安全性也提出了明确的标准。
一般的企业核心在商业市场上，而不是在技术保障上。小微电商或传统电商都难有相应的技术实力去做这些安全保障。
以上问题通过使用电商云可以很好的解决。系统复杂度的问题通过微服务架构来进行处理，资源需求、安全问题通过电商云解决。

3. 架构向微服务化演进
伴随着网站规模的增大、功能的复杂、服务和数据处理种类的增多，微服务化的架构设计思路逐渐成为了业界的广泛共识。

推荐以循序渐进的方式拆分，不轻易进行推翻式的重构。

拆分也要有个度，不是越细越好，主要还是要关注在业务领域，同时注意提取公共组件，进行分层抽象。

3.1 微服务化的优势

将服务分割成高内聚低耦合的模块，有利于软件的开发维护。每个独立团队关注在自己独立的领域里，更加专注于业务。
不同的微服务可以进行分布式部署，可针对瓶颈模块进行独立弹性伸缩，提高系统并发能力。控制粒度更细。

3.2 微服务化的劣势

服务数量增加，加大部署、管理、监控等运维操作的难度与工作量，同时对运维人员的质量与数量也提出了新的要求。
服务内部通信增多，增加依赖关系管理的复杂度。
故障排查的难度增加，一个请求需要经过的处理节点增多。

3.3 电商微服务体系结构电商微服务体系结构如下图所示：

电商体系可能包含很多子系统，大致可以归类为三层：

业务层
产品信息、购物车、订单系统、支付系统、抢购、库存、物流系统、评论系统、客服系统、推荐系统等等。
公共服务层
在业务层之下需要有一个公共服务层，这一层专门为业务层提供公共服务。也就是所有业务层或者部分业务层共有的逻辑或者内容需要调用的部分。
基础组件层
业务层面系统依赖一些基础层面组件，例如：高可用DB、分布式缓存、分布式消息队列、NoSQL等。基础组件层更偏向PaaS服务，可由电商独立构建，也可以采用已有的云组件提供服务。

要发挥微服务架构的优势和克服它的缺点，可以通过电商云和容器技术来解决。

4. 乐视电商云
微服务化的提出比较早，但在云成熟落地后，微服务架构才有了比较好的载体。近年逐渐形成了垂直领域云的风潮，不断推出适合垂直领域的产品，使客户的使用门槛降低，且能提供更多偏向垂直领域中的通用服务，更贴近现实与解决迫切的问题。乐视电商云是针对电商行业提供了一整套帮助企业利用云计算优势的解决办法。

4.1 电商行业对垂直云的要求

高性能
高可用
良好伸缩性
方便地拓展性
安全保证

4.2 电商云的产品形态4.2.1 电商公有云比如电商的初级客户，希望快速构建电商系统。在电商公有云只需注册一个账号，即可开通面对电商的完整服务体系。从服务到基础设施无缝衔接，复杂的技术体系与适配硬件设备等工作对客户透明，且可提供带运维的增值服务。
用户访问服务（域名）经 DNS解析，通过DNS轮询做第一次负载均衡，静态资源请求流量会导至离用户地理位置较近的CDN节点。云防护系统先进行流量过滤，清洗无效流量、恶意流量，拦截攻击行为等安全防护。
电商业务系统推荐以微服务的方式进行架构设计并实施，上述微服务第三层的组件技术层可以采用 PaaS组件服务，如RDS、分布式消息队列、OSS、分布式缓存等。
微服务化的业务通过容器部署在IaaS资源上，Service Router或API Gateway将负责引导请求进入各服务集群进行逻辑运算。

4.2.2 电商私有云随着电商企业的成长，公有云服务可能不能满足用户的特殊化需求，电商私有云可以提供客户需求的定制化服务，提供整套的解决方案。
从数据中心建设中的方案推荐，到服务部署实施都可打包对外销售。帮助中型的电商客户快速成长，由于数据全部在客户的数据中心里，免去客户对公有云数据安全性的担忧。

4.2.3 电商混合云混合云模式可以同时拥有公有云和私有云的优势。电商公有云可以快速帮助客户屏蔽掉营销带给基础服务的冲击，可以将面对终端用户的请求量与业务逻辑全部由电商公有云来承载，免去客户对基础设施的持续投资。
与此同时，财务、用户信息等核心数据又可以存留在电商私有云里，不用担心泄露的风险。
通过混合云的方式不仅保障核心业务与数据由企业自己掌控，还保证了特定业务下对资源需求的弹性控制，按量付费，不仅节约成本，还可轻松应对秒杀、抢购等高并发应用场景。
通过全局负载均衡来导流，将请求转发至公有云或私有云，按业务类型单独或者合作，为终端用户提供服务。

4.3 电商云平台架构电商云平台架构如下图所示：

4.3.1 日志收集用户通过自助化方式购买日志服务。日志分析结果将以接口的方式提供给用户，用户可以按需请求数据或通过乐视云提供的数据可视化服务来监控成交量、用户行为、热销商品等数据。客户通过数据来改进自己的业务流程、调整产品研发方向、改进业务系统服务质量等，达到以数据驱动业务的目的，减少决策失误。

4.3.2 监控监控服务可以基于日志、接口、服务参数等因子进行采集，并且通过预先设定的阀值，进行不同级别的报警。目前已支持电话、短信、微信等方式通知客户上线处理。对因子和报警方式都做了抽象，支持不同的组合，灵活可配置。让管理人员对整个系统运行状态了如指掌。

4.3.3 伸缩应用举例：电商购物节
1）在预定好电商抢购节之前，及时进行系统的扩容，加强系统的服务能力。
2）云平台配合进行压力及伸缩实验，做好峰值的压力测试，帮助企业达到快速便捷的能力扩展。
3）在关键流量节点做好资源冗余，核心业务数据确保万无一失。
4）在购物节过后，快速进行资源的销毁，帮助企业节省资金。

4.3.4 流量调度上云后，结合电商企业自定义的流量调度机制可以实现更大范围的调度，也可以把流量调度策略放在电商云中，做更无缝的代理功能。流量调度不仅是容灾的考虑，更为了在抢购或者秒杀期间，能抗住前一个小时或者半个小时的海量并发请求。其中包括跨地域、跨机房、集群内的三个层级的流量调度策略。第一层DNS，第二层负载均衡，第三层Service Router，配合流量卡尺算法和资源池服务能力，灵活变更流量调度策略。使全网能安全度过最初半小时的请求量，完成订单转化。

4.3.5 计费1）按量计费。PaaS层组件按照请求量进行计费，阶梯制进行计费。
2）服务套餐选择，多服务灵活组合，按套餐计费方式提供。

4.4 混合云体系及访问数据流示意图

4.5 电商云支持抢购的案例解析

抢购活动最基本的技术特征是瞬时高并发，具体举措在用户端到服务端，应用层到基础设施层都有所体现。

4.5.1 抢购的指导思想

减少到达服务端的流量
减少数据库的直接操作
保证资源冗余
从应用程序到操作系统等各个层次实施好最小权限原则（安全性保证）

4.5.2 场景列举及应对方法
场景一：用户不断刷新页面获取商品信息造成大量访问请求，会占用大量的带宽资源。

解决办法：页面尽量静态化，压缩页面内容，优化HTTP头，可以使用乐视CDN做静态加速。一些不必保持全局一致性的元数据，可以使用缓存进行保存。

场景二： CDN解决了静态资源的问题，但仍有大量有效或恶意的请求被转发至服务端，服务器压力很大。

解决办法：乐视云盾可进行流量过滤，把非正常流量、无效流量在到达服务端之前清洗掉，可以屏蔽绝大部分DDoS，并接入WAF程序对HTTP请求进行分析，可以有效拦截SQL注入、XSS跨站、获取敏感信息、漏洞利用等常见攻击行为。
请求预处理，通过业务逻辑限制尽早拦截无需继续处理的请求；透传的流量将作用在提前扩容的资源上。

场景三：大量要处理的请求导致数据库压力巨大，频繁的操作导致数据库性能低下甚至宕机。

解决办法：针对业务设计高效的缓存策略，热数据利用OCS进行缓存，需全局一致性数据存储在乐视RDS。

场景四：高并发下数据不一致性会导致超卖等情况。

解决办法：通过上面请求预处理后已经大大减少了订单的创建和超卖的可能，但超卖还是可能存在的。首先，利用消息队列来缓冲请求，超过设定阈值的请求不处理，直接返回抢购结束。
其次，利用分布式消息队列来同步商品库存量，操作库存时临时加锁，将库存减扣和订单更新等必要操作封装成事务。

5. 容器技术容器技术的出现大大促进了微服务架构和云的发展

5.1 容器技术优势

更高的资源使用率
启动销毁的速度快
结合容器技术可以比较完美的支持水平伸缩业务

5.2 容器技术劣势

隔离性
容器中对于网络的支持

下面介绍乐视云平台基于容器的支撑体系。在此体系中，主要包括： Matrix 和 BeeHive两个系统。

6.BeeHive & Matrix
Matrix系统，负责用户体系与资源及组件关系维护、跨域资源的全球调度。支持自助化组件申请，服务监控报警，计费，服务编排等服务。
Beehive 系统，负责在IaaS层之上进行组件服务的调度管理。支持容器资源的构建、集群管理、容器管理等服务。

6.1 Matrix & Beehive协同部署示意图

6.2 BeeHive资源调度系统
6.2.1 BeeHive核心设计思想

开放
抽象
包容

6.2.2 BeeHive内部结构示意图

Beehive分为调度抽象层、计算抽象层、网络抽象层、存储抽象层四部分，调度层位于其他三层之上。
可以把这四个抽象都理解为接口，共同完成了对各方面资源及调度能力的抽象，对外为乐视云提供统一的抽象接口提供资源能力输出代理，屏蔽不同容器管理系统的复杂性和多样性。支持可插拔和多接口适配设计。
Beehive先期为这几层之下都提供了默认实现，后期可以考虑接入业内成型的开源系统，开放包容。在资源隔离方面，提供内存、CPU、磁盘IO、网络IO的隔离机制。

6.2.3 网络结构示意图

vRouter 是我们支持的网络模式之一，基于SDN思想，通过vRouter将物理机构成网络整体。

控制层：去中心化和高可用，部署至实体机，构成网络集群。
转发层：通过kernel routor方式转发，没有NAT性能损耗的缺点。

除此之外还支持MacVLAN方式和NAT等网络方式。

7. 全球化
2016年是乐视集团全球化战略元年，电商云作为乐视云上的一朵云，也具有这种基因。随着从去年开始跨境电商的兴起，电商云如何为客户提供更好的基础设施与服务，是我们必须认真思考的问题。

7.1 使用场景客户需要电商网站能触及东南亚，北美，印度等新兴或者传统市场，达到商品的全球化销售或者代购，系统肯定推到离用户越近的区域，用户的体验越好。

7.2 保证此场景的举措

乐视基础设施遍布全球几十个国家，电商云可以依托强大的资源池，帮助用户轻松达到跨境售卖与建站的诉求。
乐视云的全球化消息队列在各大基础设施间进行消息同步与分发。Beehive依托消息，进行全局化的调度，无中心节点设计原则。
各大洲分别部署多套电商云的架构，独立进行服务。同时在各大洲分别部署全局的控制中心，保证云服务的稳定性与性能。
业务镜像可以支持不同地域的镜像构建，支持全球化的镜像市场，支持全球化存储和区域存储。

8. 展望
8.1 DCOS（Data Center Operation System）

在企业数据中心里两大核心应用

并行计算
微服务

如何更高效能的管理服务与复用资源提供利用率等课题，摆在我们的面前。数据中心里多数服务独占资源，且属于长运行，但未必占用很多资源。这部分剩余资源的调度与使用是关键。将数据中心的零散资源，当做一台计算机的资源管理看待，是业内普遍的抽象思路与探寻的目标。

电商云也在探索并实践，期望提高乐视云的资源使用率，在提供稳定资源服务的同时，减少企业成本，环保经营。
在DCOS的概念下，BeeHive逐步演进为 Le Distribution Kernel（LDK）, 作用在IaaS基础设施之上，PaaS层之下的资源调度与管控层。LDK的主要思想是通过集成Service Framework来构建一个完整的DCOS体系。对于DCOS需管控服务类型，LDK留有通用API，其他服务框架可以通过可插拔的方式轻松接入，不与具体框架做强绑定关联。

做好对计算、存储、网络资源的高度抽象，支持现有的可插拔接口设计，兼收并蓄，吸收业界优秀的开源资源管理系统的优点或者复用，完成对资源合理调度与虚拟资源的全生命周期管理。

8.2 电商云服务治理框架
结合通用服务框架，电商云内置服务治理框架。在一些企业如果还不能达到进行服务拆分与服务治理的能力时，可以使用此框架达到立杆见影的效果。无语言相关性，页面可配置接口，可形成调用关系图谱，可视化管理微服务集群。

服务上线
当有新服务需要上线的时候，先在服务注册器里注册该服务，不仅方便管理，而且可以监控微服务之间的依赖关系，避免循环依赖的发生，提前预警。注册服务的同时，调度器会通知自动部署程序进行自动部署，部署程序自动进行从代码仓库拉取代码，制作镜像，部署上线等一系列操作。

服务发现
服务在注册器登记以后，通过消息队列发布服务通知服务消费者，服务消费者订阅服务。

服务优先级
服务注册后会添加服务路由，服务路由负责记录服务的优先级信息、路由信息以及控制服务的开关。在应对特定需求时通过服务路由来控制服务的升级与降级以保证优先级高的服务高可用。

服务授权
专门的服务权限管理系统来管理服务的权限，当服务请求到达服务路由层时，路由向权限系统请求检查该消费者是否有权访问服务提供者，如果鉴权通过则进行路由服务，鉴权失败则停止路由服务返回错误状态。

服务监控与SLA
服务消费者在请求服务的过程中会监控服务提供者是否可用，并将状态反馈给监控程序；自动部署程序也会将部署成功、失败、启动、停止等信息反馈给监控程序，资源消耗等情况也会送达监控程序，监控程序判断各项指标是否达到SLA中约定的阈值，当达到阈值时，触发自动报警。

弹性伸缩
监控器会向调度器报告服务的运行情况与资源消耗情况，再由调度器控制容器资源的伸缩。

使用服务
服务消费者请求服务后，将会被服务路由拦截，在服务路由先进请求授权系统进行服务鉴权，鉴权通过后路由转发服务。服务转发过程中会进行一次负载均衡，将服务按优先级或根据资源的闲置情况来决定最终由哪些容器中的服务来提供。

9. 后记
我们随后会分享：乐视RDS
RDS组件在资源调度层使用Beehive提供的服务。目前RDS在乐视集团内部已达到60%的使用规模，线上已运行了近1500个容器。

10.Q&A
Q1：多机房,高并发,去中心化的情况下,例如购买的场景,如何保证数据一致性?A1：首先要做数据分区，数据存储在用户本区域的关系型存储中，乐视云提供全球化RDS。如果数据需全球唯一且可以支持并发，我们目前还达不到这种能力。目前只能回写到全球唯一的一个节点上，再做全球数据同步。这种场景还需要业务进行配合，目前还做不到完全透明。

Q2：基于Beehive的Docker集群有对同一个宿主机上的Docker instance之间的通讯做优化吗？
A2：对于同一种业务，上线时即考虑了高可用部署，业务都不在同一台宿主机上。同时我们也不推荐业务部署在同一宿主机上。不同的业务的优化主要在于网络通讯上，我们采用vRouter来做流量转发，通过kernal router做转发，流量都不会经过交换机。

Q3：为什么不直接使用Mesosphere 的DCOS 而自己构建BeeHive DCOS？
A3：主要有以下三个原因：

BeeHive 是基于我们自己的技术栈建立的。
BeeHive 深度适配乐视云各类业务系统架构，更适合我们。提供了抽象代理层，可兼容不同的实现，这个实现也可以我们自己做。
Mesosphere 的 DCOS 是商业化版本，并未直接开源。

Q4：为什么说微服务化的提出比较早，但在云成熟落地后，微服务架构才有了比较好的载体？
A4：微服务化的理念很早都已经有了，只是由于微服务的缺点（部署困难，运维复杂）导致微服务并没有得到理想的应用推广，后来容器技术快速发展，就很好地解决了微服务的痛点，而乐视电商云很好的利用容器技术或者虚机资源来使得微服务架构有了比较好的承载。

Q5：请问乐视有关大数据引擎的部署和微服务运维架构的关系是怎么样的？
A5：资源复用，提高资源利用率是我们一直以来的初衷。分长时和短时的任务进行调度。在微服务化的资源处于空闲时段时，会减少微服务实例，用来跑一些MR或RDD任务。同理，在需要扛高并发的业务时，短时运行资源也会减缓运行速度，以空出一部分资源，部署上微服务的资源。

Q6：请问高 iops、cpu、pps的业务场景在云端是如何应对的？解藕？
A6：通过底层的资源池来调度分配。例如高iops会对应pcie ssd设备；高cpu任务，我们提供多核的高配机。通过自定义的业务属性，来做更高层的任务分配与复用。后期通过机器学习，能更准确的识别资源利用率，做更智能的资源调度，用户标记的任务属性作为一个决策因子。这也正是我们要做DCOS的初衷，数据中心资源的管控，像是一台计算机一样在调度。

Q7：数据分区,例如A用户,第一次访问在洛杉矶,然后A用户去了中国, 那A用户是否以后都会在洛杉矶?
A7：目前用户数据还在洛杉矶。后期计划中，我们的处理方法是，首先A在美国存储数据，数据会通过全球一致性同步到世界各地的数据中心，一是为数据容灾，二是为考虑此种情况。但还是像上面的问题，数据全球唯一性且支持并发，目前还无法支持。

Q8：如上一个问题中所说，A用户第一次访问在洛杉矶，然后A用户去了中国, A用户以后访问都会在洛杉矶，这种处理方式会带来哪些问题呢？
A8：目前是A去了洛杉矶之后，数据保存在洛杉矶，之后去了中国，还是访问洛杉矶的数据。带来的问题：这种情况数据有一定的延迟，数据加载缓慢。
如果变成异步全球同步数据的机制，还需要解决并发访问的问题（用户在异地同时登陆对唯一资源进行操作），这种情况还需要通过业务协助来解决，限制不能对全球唯一的数据同时进行多地操作。

Q9：基于BeeHive的Docker集群有考虑对不同的Docker设置不同的带宽吗？好像Mesos还不支持这个功能。
A9：目前还没有限制，正在考虑使用TC来限制网络带宽，参考OpenStack中的做法。Service Router会做流量分配，对流量做好监测，把请求代理转发到其他地域与机房，当然这是在更高的层级进行管控。如遇像Redis，Ceph这类的组件服务，在构建服务时，优先选择千兆网卡的机器等策略支持。

Q10：热数据是怎么判别并加到ocs里的？乐视商城现在ocs的发展情况是怎么样的？
A10：热数据的写入，目前还是通过业务的实现来完成。由于系统比较复杂，需要多级缓存来缓解压力。如果您问的是希望RDS来自动加载到OCS中的方式，目前据我了解乐视RDS目前还不支持此种方式，这部分可以由RDS团队来专门介绍一下。

Q11：大文件存储和小文件存储都是用了什么软件或服务？
A11：大文件存储使用Ceph。小文件存储是在Ceph的基础上，加入缓存机制进行。下面也准备测试一下Ceph新版本对于小文件存储的能力。存储服务是由我们云平台内部另一个团队负责的。

来源：H2EX