近几年O2O很火,凡是做O2O的,几乎都要面临要不要给账号绑定账户?支持哪些形式的支付?如何去结算?如何让用户提现等问题。今天跟大家聊聊新达达两年多财务账户系统的演变。

黑铁时代 - 时间的成本是最大的成本

大部分公司,在创业初期都会面临着人手不够充裕的境地,但市场的机会稍纵即逝,这就要求团队能够尽快的实现功能,不断试错。

达达第一个版本是几个小伙伴在汉庭酒店花费7天的时间做出来的,当然,达达的账户的“黑铁时代”也非常的简单。跟业务系统完全耦合,内嵌在对应的商户和配送员的账号数据表里。

Alt text

阅读全文 »

背景

2014年6月,达达配送上线,并迅速成长为国内领先的同城快送信息服务平台,为数十万商家提供低成本、高效率的配送服务。

2015年7月,为了更好地连接消费者和商家,达达推出了自己的外卖信息服务平台-派乐趣,实现了上游信息服务和下游配送服务的完整闭环。消费者可以通过派乐趣平台获取点餐、支付、配送、评价等一系列服务。成立以后,派乐趣经历了高速的增长,并在2015年底突破了一百万的日单量。

随着派乐趣入驻商家的快速增长,如何对附近的候选商户进行有效排序,帮助用户快速找到最适合自己的餐厅,成为派乐趣面临的一个核心问题。

商户排序问题

所有的信息平台在信息的展现过程中都会碰到排序问题。如何通过排序将更高质量的信息展现给用户,提供更好的用户体验,是信息平台必须解决的一个问题。

和传统的搜索排序和电商排序相比,外卖平台的商户排序有着特殊的需求,需要考虑的因素包括:

  • 距离因素:外卖服务和电商、搜索等线上服务的一个主要区别是受地理因素的限制和影响。比如,商家有一定的配送范围,而用户也会倾向于选择附近的商家,以获得更快的配送体验。因此,对商户的检索、筛选和排序都需要考虑距离因素。
  • 时段和品类:不同时间段用户对外卖的需求是不同的。比如中午12点和晚上6点左右用户对于正餐的需求量是最高的,而在下午3点钟左右用户对饮料、甜品类的需求可能更大一些,这就要求排序算法考虑时间和品类等相关因素。
  • 质量和评价:线下服务的一个特殊之处在于服务的很大一部分是不可见的,例如餐品的口味、送达速度、服务态度等, 在排序的时候需要将这些不可见因素量化,并体现在排序中。
阅读全文 »

背景

随着达达业务的扩大,越来越多的人开始使用达达客户端,参加到众包物流的行业中。达达客户端分为iOS平台和安卓平台。

APP开发也从快速迭代的粗旷性开发转向高可复用,提升用户提现的精细化方向发展。iOS动画交互良好,使用广泛,良好的用户体验离不开流畅的界面变换。为此,达达iOS团队对动画实现以及背后原理做了学习探索。

目的

  • 了解Core Animation 基本框架
  • 理解图层的定义
  • 解析动画的流程
  • 掌握3D动画的原理
  • 实现3D动画的代码实现
阅读全文 »

背景

大多数系统在刚启动时因为初期业务功能单一并为了尽快上线的目的,在系统的设计和技术选型上鲜有考虑,特别是前端方向(基本是 jQuery + Bootstrap )。当然,达达有很多项目也是这么过来的。随着公司业务的快速发展,以下几个问题越来越严重:

  1. 维护困难:JavaScript 的语法比较松散,这也导致全栈工程师在开发时往往以实现业务功能为第一要点,公用模块没抽离,编写方式不统一,遇到 Bug 基本都需要重新去梳理代码。
  2. 网页变慢:随着业务功能的丰富,菜单也会越来越多,在没有使用局部刷新技术的情况下,每打开一个页面都要去重新请求菜单列表,这部分的耗时居然可以达到 2-3 秒钟。
  3. 技术/样式杂乱:既然每个参与项目的同学都以实现业务功能优先,谁都不想去看别人的代码,也不想自己负责的模块上线之后影响到别的模块,最后采取的方式基本都是你用你的资源,我用我的资源。

因此,我们需要有一种前端技术选型可以尽量地来规避这些问题,编写出约束力比较强的代码,在可复用、分治上带来帮助。

阅读全文 »

背景

随着达达业务的快速发展,产品上经常需要对APP的逻辑进行更精准快速的变更,最初通过发布新版本的方式来调整逻辑,由于APP版本更新覆盖需要一定的周期,这样做的效果不是很理想。后面我们采用了友盟在线参数来对一些参数进行动态配置,但友盟的在线参数只是一个简单的key-value配置,无法为配置的key附带更多的业务逻辑(比如限定城市和用户),并且配置变更以后也无法立即通知APP,因此我们设计了达达APP配置系统。

阅读全文 »

背景

随着达达业务迅猛发展,访问量的节节攀升,每天产生大量的日志,单日日志量从原来的约20G/天涨到超过500G/天,我们面临着新的架构设计挑战。

在提出解决方案之前,我们先来了解一下达达当前的日志现状:

阅读全文 »

发展迅速背后的逻辑

短短一年多的时间,达达已经完成了从0到1的跨越,目前平台注册配送人员超过100万,业务覆盖40多个城市,服务超过30多万商家,日订单量超过150万单,已然成为国内最大的众包物流平台。那么,达达发展如此迅速,其背后的逻辑是什么?

在过去的两年内,O2O行业经历了迅速发展阶段。耳熟能详的饿了么、美团外卖、百度外卖、口碑等等,都经历了订单量的突飞猛进,还有很多细分垂直领域的,比如回家吃饭、一米鲜等O2O平台迅速发展壮大。O2O行业,最大的痛点和困难在物流,也就是最后三公里配送。如果平台自己去建设配送团队,那么很难想象各公司会有如此快的发展速度,原因如下:

阅读全文 »

背景

达达后台系统目前每天都要支撑数十亿的访问量,这对于服务系统整体架构是个严峻的考验。考虑到越来越复杂的业务以及不断增加的访问压力,我们对数据层进行了一系列的改造(参见达达-高性能服务端优化之路),也对业务层进行了服务化(参见基于Zookeeper的服务注册与发现)。同时,参照DDD设计,我们引入了一个数据访问层,即ModelService。

ModelService的职责:

  • 封装业务层对数据层的调用
  • 实现对数据库的分库分表(写入以及查询)
  • 实现对部分数据的缓存

ModelService以及我们目前大部分系统提供的对外接口都是RESTful风格。

使用RESTful风格的接口有如下优势:

  • 语言无关(这点对于我们Python+Java的后台系统很关键)
  • 开发效率高、调试方便
  • 接口的语义明确
    阅读全文 »

背景

大多数系统都是从一个单一系统开始起步的,随着公司业务的快速发展,这个单一系统变得越来越庞大,带来几个问题:

  1. 随着访问量的不断攀升,纯粹通过提升机器的性能来已经不能解决问题,系统无法进行有效的水平扩展
  2. 维护这个单一系统,变得越来越复杂
  3. 同时,随着业务场景的不同以及大研发的招兵买马带来了不同技术背景的工程师,在原有达达Python技术栈的基础上,引入了Java技术栈。

如何来解决这些问题?业务服务化是个有效的手段来解决大规模系统的性能瓶颈和复杂性。通过系统拆分将原有的单一庞大系统拆分成小系统,它带来了如下好处:

  1. 原来系统的压力得到很好的分流,有效地解决了原先系统的瓶颈,同时带来了更好的扩展性
  2. 独立的代码库,更少的业务逻辑,系统的维护性得到极大的增强

同时,也带来了一系列问题:

  • 随着系统服务的越来越多,如何来管理这些服务?
  • 如何分发请求到提供同一服务的多台主机上(负载均衡如何来做)
  • 如果提供服务的Endpoint发生变化,如何将这些信息通知服务的调用方?
阅读全文 »

提纲

  • 业务场景
  • 最初的技术选型
  • 读写分离
  • 垂直分库
  • 水平分库(sharding)
  • 总结

业务场景

达达是全国领先的最后三公里物流配送平台。 达达的业务模式与滴滴以及Uber很相似,以众包的方式利用社会闲散人力资源,解决O2O最后三公里即时性配送难题。 达达业务主要包含两部分:商家发单,配送员接单配送,如下图所示。

达达的业务规模增长极大,在1年左右的时间从零增长到每天近百万单,给后端带来极大的访问压力。压力主要分为两类:读压力、写压力。读压力来源于配送员在APP中抢单,高频刷新查询周围的订单,每天访问量几亿次,高峰期QPS高达数千次/秒。写压力来源于商家发单、达达接单、取货、完成等操作。达达业务读的压力远大于写压力,读请求量约是写请求量的30倍以上。

阅读全文 »