微信号:infoqchina

介绍:有内容的技术社区媒体

亿级商品数量下,当当这样构建平台化架构

2016-04-29 08:01 张亮
架构平台化是一个很大的话题,本文只针对中间层解决方案阐述,资源层不在讨论范围。本文分享的内容大部分都已开源。回复关键词「平台」,获取本文讲师在QCon 2016 北京站的演讲PPT。

当当业务体系简介

请先看当当的业务特征,这也是绝大多数电商公司的共同特征:


面向互联网海量用户,并且品类繁多。当当作为综合类电商平台,营业范围涵盖图书、日百、服装、母婴等,商品数量是亿级别的。7×24是每个互联网公司的基本要求,流量突增比较容易理解,双11是电商每年的大考,平时各种大促也已渐成常态,5倍以上流量很正常。业务的复杂性,通过这幅简化版的业务架构图说明。


上面部分是面向买家用户的前端系统;下面部分是面向合作伙伴以及运营人员的后端系统;中间是核心业务系统。当当业务核心涵盖了挑选商品 –>下单交易 -> 订单流转 ->库房发货 -> 物流送达的流程。网站由大大小小几百个的系统组成,由于历史原因,系统并不是由单一语言开发。目前主要使用Java和PHP,还有C++和少量遗留的.NET组成。

中间层技术栈

简单介绍了互联网电商的上下文,我抛出一个问题:互联网架构的核心问题究竟是什么?

如果只总结一个点的话,我的看法是:规模。不断扩大的规模是造成后续诸多问题的根源。


海量用户、商品、促销、订单、支付、仓储、物流等汇集成海量数据。随着PV逐步增加,系统响应也会相应迟缓。串行功能、系统间交互也会导致系统变慢。每个系统都有自己的技术栈,过多的系统导致开发成本难以承受。以前的企业模式,系统部署在几台小型机上,运维难度不大,稳定性较易保障。

当今互联网公司面向水平扩展,更愿意将系统部署在成千上万台廉价PC服务器上。水平扩展提供了伸缩性的同时也对稳定性提出了新的要求。每时每刻都可能有机器挂掉,如果挂掉的机器会对系统造成影响,那么系统的稳定性会急剧下降。

针对上述这些问题,我们使用以下方案解决。


服务化、分片化、异步化和规范化,并且需要在这些解决方案中考虑如何高可用和弹性化。用AOP的概念更加容易解释,饼图内是4个独立的功能模块,高可用和弹性化是他们需要关注的共同逻辑,也就是切面。

服务化

为什么需要有服务化的框架?系统拆分后通信方式五花八门,可能通过HTTP、TCP、数据库、消息队列、甚至文件的方式进行交互。若有服务需要下线,如何能够知道哪些消费方仍在调用此服务?没有服务框架的时候,开发工程师需要向整个技术部发邮件询问系统的调用情况,或者根据自行维护的EXCEL判断。如果无人应答或EXCEL更新不同步,服务停掉后才发现有其他系统仍在调用,则悔之晚矣。

服务化框架包括6个核心概念。


服务化框架是为了解决多系统之间调用而产生的框架,透明化远程调用是最基本的需求。最好能够兼容多种RPC和序列化协议。

服务发现用于弹性扩缩容,新上下线的机器,应能通过服务发现自动注册和查找。

负载均衡可根据不同的负载策略分配流量,如轮询,随机或权重等策略。

服务治理用于管理服务依赖和梳理调用关系,也应包含流量控制、服务降级等功能。

监控报警主要是能发现问题,并且将发现的问题通过短信、邮件等方式通知相关处理人。

至于异构语言,前面已经提到过。规模稍大的公司一般不只用单一语言开发,负责各个异构系统交互的服务框架,需要做到支持异构语言。

Dubbo是业界认可度很高的服务框架。


大部分服务化框架应有的功能Dubbo都有。Dubbo是去中心的解决方案,它允许服务的提供者和消费者直接建立连接,而不是将请求通过中心路由节点转发。注册中心只用于分布式协调。

但Dubbo并不是完整的解决方案,有两方面不足。监控中心功能较弱且不具备报警功能,以及对异构语言支持有限。当当在Dubbo的基础上扩展了这两个功能。

监控报警方面,当当使用自主研发的Agent。


Agent将本地收集的调用信息进行SLA计算,以分钟为维度,发送至监控治理中心的Kafka队列。监控治理中心由Storm二次聚合,以时间为维度入库。通过读取数据库内容展现SLA统计和系统关系调用图,并且对接报警接口。

异构语言由DubboX提供。DubboX在Dubbo的基础上扩展了REST协议。


REST协议将RPC字节流转为JSON或XML,以便被其他语言客户端解析。

Dubbo框架通过服务的消费者实现负载均衡,因此使用REST协议的异构语言消费者将失去负载均衡的能力。目前我们由服务提供端使用Nginx做负载均衡的解决方案。Agent独立于DubboX部署,即便是异构语言,也可通过Agent对接监控治理中心。

分片化

分片化用于解决海量数据造成的数据库性能问题。很多NoSQL都有自动分片功能,但NoSQL的稳定性、查询灵活性仍然与关系型数据库有差距,NewSQL作为新生事物还并未成熟。所以公司重要的数据仍存放于关系型数据库。数据量超过阀值将导致查询效率下降,水平分片是互联网场景使用关系数据库的常见方式。

当当很早就开始使用数据水平分片的方案,由各业务团队自行实现,基本方案是动态生成SQL字符串或动态选择数据源等,实现成熟度低,可移植性差。随着业务需求越来越复杂,业务和SQL的共同调整常使开发团队焦头烂额。因此我们决定将业务需求与分片技术彻底分离,引入透明化的数据分片中间件。

首先需要明确选择何种方案实现分库分表中间层。我们的技术栈以Java为主,所以仅关注Java的实现方案,主要有以下3种。


当当使用MySQL最多,也有遗留系统仍使用SQLServer。我们希望能够支持尽量多的数据库种类。

ORM框架在当当以MyBatis为主,也有团队使用Hibernate和Spring JDBCTemplate,个别团队直接使用JDBC。多种ORM框架的支持也是需要的。

虽然当当的业务系统主要由Java和PHP开发,但我们更倾向于使用PHP的系统通过调用Java服务来访问需要分库分表的数据库。这里仅支持java可以接受。

性能损耗越低越好。

基于这些方面考虑,我们决定在JDBC层开发。

通过对现有开源数据中间层解决方案的调研,没有发现非常完善的案例,尤其是基于JDBC的案例几乎为零,我们唯有自主研发。我们自研的数据中间层叫Sharding-JDBC。目前关注点是分库分表和事务。

请看Sharding-JDBC分库分表的架构图。


开发者可以认为在操作一个很大的数据库,真实的分片数据全部由框架屏蔽。使用Sharding-JDBC和使用原生JDBC唯一的区别是分片规则配置,之后就完全由框架托管。

框架在JDBC驱动之上进行封装,将原来的DataSource、Connection、Statement或PreparedStatement和ResultSet的一对一关系转换为一对多的集合关系。

获取到待执行SQL后,先将SQL解析为AST语法树,再提取分片关心的部分至解析上下文。

通过SQL改写模块,将原来单机执行的SQL改写为分布式执行的SQL。以分页举例,如果每页展现10条数据,单机数据库获取第2页数据只需获取11到20条,而分布式的场景下需要获取全部的前两页的数据,再到客户端内存统一整合。

路由模块则将SQL替换为实际表名称后,根据配置的分片规则分发至真实的库和表。

如果最终落至多库或表,会由引擎并行执行SQL。

最后将从多个库或表返回的结果数据根据聚合、排序、分组等不同的场景归并。

经过实际测试,Sharding-JDBC在单库场景性能损耗只有0.02%,SQL解析的损耗属可接受范畴。双库并发场景性能提升了94%,证明Sharding-JDBC的分库分表方案可有效提升数据访问性能。

Sharding-JDBC支持关联查询。在SQL兼容性方面也做了很多努力,支持聚合、分组、排序和分页。

XA的分布式事务方案性能低下,互联网公司几乎不会采用。我们倾向使用柔性事务,以牺牲强一致性来换取性能,并通过补偿、修复等机制达到数据的最终一致性。

柔性事务种类很多,我们实现了其中两种,最大努力送达型和TCC型。


最大努力送达型事务的适用场景是数据最终都将成功,不会回滚。实现逻辑比较简单,只要将未成功的SQL反复执行即可,无需业务代码感知。

TCC型事务更加类似于原生事务,提供了Try、Confirm和Cancel流程,但需要使用方自行实现业务代码。

时间关系,只介绍一下最大努力送达型事务的架构图。


事务分为同步送达和异步送达两部分,在执行失败时根据配置的次数进行有限重试。异步送达需要一个稳定的作业组件提供支撑,这里先卖个关子,一会将介绍作业组件。超过了同步和异步最大送达次数的SQL,则需人工干预。柔性事务的本质是将人工干预尽量降至最低。

异步化

异步化,主要有两种处理方式,任务调度和消息队列。


任务调度是时间驱动。标准的消息队列是事件驱动,由消息中间件将接收到的消息推送给消息订阅方。任务调度常用于处理批量数据。如:每月与快递公司结算,若本月快递送达超过指定数量将给予额外奖励。消息队列则是一个事件进行一次处理。任务调度常用于系统内部,消息队列可作为多系统解耦的手段之一,系统间通过消息队列交互以完成依赖拆解。间隔时间很短的任务调度也可以作为消息队列的触发引擎,这部分内容后面再介绍。

目前难以找到轻量级的分布式任务调度框架,所以我们仍然采用自主研发。我们的分布式任务调度框架叫Elastic-Job。框架由客户端在到达相应时间点时各自触发调度,并无作业调度中心节点。Elastic-job并不直接提供数据处理功能,而是将分片项分配至各个运行中的作业服务器,开发工程师需要自行处理分片项与真实数据的对应关系。

Elastic-Job能够合理利用分布式资源,动态分配分片项。举例说明:3台服务器,分成10片,则分片项分配结果为服务器A=0,1,2;服务器B=3,4,5;服务器C=6,7,8,9。如果服务器C崩溃,则分片项分配结果为服务器A=0,1,2,3,4;服务器B=5,6,7,8,9。在不丢失分片项的情况下,最大限度的利用现有资源提高吞吐量。同理,增加服务器会有效的疏散分片项,达到系统负载降低的目的。


Elastic-Job由异步事件触发组成,难于在一幅架构图中理清脉络。通过此图主要展示Elastic-Job的各个组成部分,包括注册中心、REST API、运维平台以及基于全量的事件和日志的监控。

消息队列主要分为两类,可靠型和性能型。我各自选择一个代表来分析不足。


ActiveMQ作为实现JMS协议的消息中间件,功能众多。但性能一直是受诟病最多的地方。需要明确业务应用是否真的需要用过高的性能指标来换取不可靠性。根据场景来判断ActiveMQ的性能是否满足会更科学一点。

分片是ActiveMQ一直以来的缺失。Broker和存储端都需要用分片来降低过量的消息和访问带来的负载,这和刚才提到的数据分片化是一样的。

消息和业务数据放在同一本地事务同进同退,是最理想的使用方式。ActiveMQ的事务我画了一个问号,不少人认为ActiveMQ的消息和业务数据放入同一事务需要使用XA,其实不必。ActiveMQ可以和业务数据配置同样的数据源来保证事务的本地性。但可用不代表易用,如果业务数据库本身就是分片化的,ActiveMQ注入多数据源显然需要二次开发。

Kafka作为性能型的消息中间件代表,更多的被用于日志处理等数据不敏感的场景。确实,基于海量吞吐量的处理,某一条消息是否丢失就显得不那么重要了。但Kafka是否如很多人担心的那样,会丢失消息和重复消费?答案是使用得当则可以避免,比如合理配置刷盘策略、消息清理策略和ACK机制等。可靠性的提升必然会带来性能的降低,以性能为代价提升可靠性是否有悖于Kafka的初衷。

消息查询是Kafka的麻烦事,因为消息只有偏移量却并无索引,如果业务方想查看某月某日状态是xx的消息是否全部消费了,需要二次开发。

Kafka使用文件系统而非数据库存储消息,所以与业务数据保持同一本地事务不太现实。

消息队列比数据库中间层要成熟的多,但缺少100%完美的解决方案。当当使用消息队列有自己的权衡方案。


初期使用队列表,通过作业读取存储于数据库中的消息。

后来发展到混合使用,有队列表、ActiveMQ、Kafka、MetaQ、RocketMQ。这些技术栈管理有些杂乱。

未来我们打算使用Elastic-Job来做队列表的触发引擎,用Sharding-JDBC实现队列表的水平扩展,以这两种技术组合出一套更加易用的DMQ。DMQ会封装成为更加易用的接口,支持消息分片和本地事务。这不是第一个组合使用Elastic-Job和Sharding-JDBC的案例,之前提到的柔性事务,作业引擎也是用的Elastic-Job。

规范化

规范化提供统一的技术栈解决方案,有效的提升开发效率。

当当对于规范化提出的解决方案是使用统一的应用框架。我们应用框架名字叫dd-frame。


dd-frame定义了一套准入规范和接入标准。中间的核心类包含了可快速启动的容器和基本规范。左边的数据类包含关系型数据库和NoSQL的接入规范。关系数据库复杂一些,需要规范ORM使用,并提供分页组件,代码生成等。右边的集成类主要用于多系统集成,消息队列,调度和服务框架都属于此列。其他类提供了与WEB的整合、单元测试相关和辅助插件。通过dd-frame对接监控生态和集群平台。dd-frame的本质是作为一个胶水,提供便捷整合smart-client的容器。

平台化的理念

聊完框架类解决方案,现在可以聊一下当当平台化的理念了。既然要做平台化,不可避免的需要在中心化和去中心化二选一。当当会选用什么方式,听过之前的介绍,相信答案不难推断,我们选择的是去中心化。


上述介绍的几个技术组件,都遵循这个理念,由客户端和注册中心共同协调分布式系统,并未采用中心分发的机制。没有哪种方案是完美的,所以我们需要权衡中心化和去中心化带来的优势和劣势。

去中心化会降低运维难度,分布式逻辑都在类库中,对运维影响小。中心化的中心节点需要有一套额外的集群做支撑,因为所有的流量都要走中心,一旦中心挂了后果很严重。因此运维和部署的复杂度都会增加。

去中心化由客户端直接定位到提供服务的节点,无二次转发,相比于中心化,性能损耗更小。

去中心化的劣势体现在异构语言的支持和资源控制的难度。

因为主要逻辑在客户端,去中心化需要不同语言各自实现一遍,重复开发的工作量很大。DubboX和Elastic-Job虽然支持异构语言,但使用REST协议的DubboX丧失了负载均衡的能力,Elastic-Job也仅能支持shell和http,做不到全语言支持。

集中资源控制也是难题。如Sharding-JDBC的数据库连接管理,Elastic-Job的统一时间触发等问题,均不易解决。

开源给产品本身带来了质量提升和风险降低,对公司技术品牌提升也有极大的推动。我们希望能够从最初的开源社区索取,渐渐转变成给开源社区反馈。

DubboX、Sharding-JDBC和Elastic-Job均已开源,地址分别是:

延展阅读(点击标题):


「聊聊架构」是InfoQ垂直号

在这儿你能得到:

更多互联网架构实践

更多微信群学习机会

手快的已经扫码关注了!


 
InfoQ 更多文章 年前挖的坑都填了吗?技术债务偿还计划 程序员VS武林高手:技术为外功,思维乃内力 腾讯游戏大数据服务场景与应用(附PPT) 偷师饿了么:怎样用HTTP/2优化iOS APP网络层次架构? 作为高颜值的女程序员是一种怎样的体验?
猜您喜欢 美的大计划 | 揭开世界500强公司神秘内幕 Mysql max_allowed_packet 被修改设置为1GB或者1024B原因 #经验技巧# 15 个实用的 PHP 正则表达式 Mesos和YARN的区别以及它们如何协同工作 高手分享:如何立即跳出两重嵌套循环?