【首度披露】乐视电商云的整体架构与技术实现

主题简介

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

1. 电商系统发展过程

电商 站在不同时期的架构复杂度有所不同：

• 初创期：商品类型少，业务复杂度低，系统架构简单。采用高可用数据库、分布式缓存、文件存储等基本组件就可满足需求。

• 发展期：数据量、业务复杂度、系统复杂度、计算资源需求都剧增。则需要业务拆分并独立部署，采用CDN、高可用数据库、分布式缓存、分布式消息队列、分布式文件存储等。

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

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

• 业务层
  产品信息、购物车、订单系统、支付系统、抢购、库存、物流系统、评论系统、客服系统、推荐系统等等。

• 公共服务层
  在业务层之下需要有一个公共服务层，这一层专门为业务层提供公共服务。也就是所有业务层或者部分业务层共有的逻辑或者内容需要调用的部分。

• 基础组件层
  业务层面系统依赖一些基础层面组件， 例如：高可用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.5 电商云支持抢购的案例解析

6.2 BeeHive资源调度系统

6.2.1 BeeHive核心设计思想

• 开放

• 抽象

• 包容

6.2.2 BeeHive内部结构示意图

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

• 控制层：去中心化和高可用，部署至实体机，构成 络集群。

• 转发层：通过kernel routor方式转发，没有NAT性能损耗的缺点。

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

7. 全球化

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

7.1 使用场景

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

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

• 并行计算

• 微服务

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

电商云也在探索并实践，期望提高乐视云的资源使用率，在提供稳定资源服务的同时，减少企业成本，环保经营。

在DCOS的概念下，BeeHive逐步演进为 Le Distribution Kernel（LDK）, 作用在IaaS基础设施之上，PaaS层之下的资源调度与管控层。LDK的主要思想是通过集成Service Framework来构建一个完整的DCOS体系。对于DCOS需管控服务类型，LDK留有通用API，其他服务框架可以通过可插拔的方式轻松接入，不与具体框架做强绑定关联。

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

8.2 电商云服务治理框架

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

Q&A

Q1：多机房,高并发,去中心化的情况下,例如购买的场景,如何保证数据一致性h3>

A1：首先要做数据分区，数据存储在用户本区域的关系型存储中，乐视云提供全球化RDS。如果数据需全球唯一且可以支持并发，我们目前还达不到这种能力。目前只能回写到全球唯一的一个节点上，再做全球数据同步。这种场景还需要业务进行配合，目前还做不到完全透明。

Q2：基于Beehive的Docker集群有对同一个宿主机上的Docker instance之间的通讯做优化吗h3>

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

Q3：为什么不直接使用Mesosphere 的DCOS 而自己构建BeeHive  DCOSh3>

A3：主要有以下三个原因：

1. BeeHive 是基于我们自己的技术栈建立的。

2. BeeHive 深度适配乐视云各类业务系统架构，更适合我们。提供了抽象代理层，可兼容不同的实现，这个实现也可以我们自己做。

3. Mesosphere 的 DCOS 是商业化版本，并未直接开源。

Q4：为什么说微服务化的提出比较早，但在云成熟落地后，微服务架构才有了比较好的载体h3>

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

Q5：请问乐视有关大数据引擎的部署和微服务运维架构的关系是怎么样的h3>

A5：资源复用，提高资源利用率是我们一直以来的初衷。分长时和短时的任务进行调度。在微服务化的资源处于空闲时段时，会减少微服务实例，用来跑一些MR或RDD任务。同理，在需要扛高并发的业务时，短时运行资源也会减缓运行速度，以空出一部分资源，部署上微服务的资源。

Q6：请问高 iops、cpu、pps的业务场景在云端是如何应对的h3>

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

Q7：数据分区,例如A用户,第一次访问在洛杉矶,然后A用户去了中国, 那A用户是否以后都会在洛杉矶h3>

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

Q8：如上一个问题中所说，A用户第一次访问在洛杉矶，然后A用户去了中国, A用户以后访问都会在洛杉矶，这种处理方式会带来哪些问题呢h3>

A8：目前是A去了洛杉矶之后，数据保存在洛杉矶，之后去了中国，还是访问洛杉矶的数据。带来的问题：这种情况数据有一定的延迟，数据加载缓慢。

如果变成异步全球同步数据的机制，还需要解决并发访问的问题（用户在异地同时登陆对唯一资源进行操作），这种情况还需要通过业务协助来解决，限制不能对全球唯一的数据同时进行多地操作。

Q9：基于BeeHive的Docker集群有考虑对不同的Docker设置不同的带宽吗Mesos还不支持这个功能。

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

Q10：热数据是怎么判别并加到ocs里的商城现在ocs的发展情况是怎么样的h3>

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

Q11：大文件存储和小文件存储都是用了什么软件或服务h3>

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