打车app开发架构实践

打车app开发架构实践

深圳打车app开发公司《酷点网络》滴滴，快的打车最初只有两个系统，一个提供HTTP服务的Web系统，一个提供TCP长连接服务的推送系统，所有业务运行在这个Web系统里，代码量非常庞大，代码下载和编译都需要花较长时间。系统分布式

业务代码都混在一起，频繁的日常变更导致并行开发的分支非常多，测试和代码合并以及发布验证的效率非常低下，常常一发布就通宵。这种情况下，系统的伸缩性和扩展性非常差，关键业务和非关键业务混在一起，互相影响。

因此我们Web系统做了拆分，将整个系统从上往下分为3个大的层次：业务层、服务层以及数据层。

我们在拆分的同时，也仔细梳理了系统之间的依赖。对于强依赖场景，用Dubbo 实现了RPC和服务治理。对于弱依赖场景，通过RocketMQ实现。Dubbo是阿里开源的框架，在阿里内部和国内大型互联网公司有广泛的应用，我们对Dubbo源码比较了解。RocketMQ也是阿里开源的，在内部得到了非常广泛的应用，也有很多外部用户，可简单将RocketMQ理解为Java版的Kafka，我们同样也对RocketMQ源码非常了解，快的打车所有的消息都是通过RocketMQ 实现的，这两个中间件在线上运行得非常稳定。

借着分布式改造的机会，我们对系统全局也做了梳理，建立研发流程、代码规范、SQL规范，梳理链路上的单点和性能瓶颈，建立服务降级机制。

无线开放平台

当时客户端与服务端通信面临以下问题。

1.每新增一个业务请求，Web工程就要改动发布。

2.请求和响应格式没有规范，导致服务端很难对请求做统一处理，而且与第

三方集成的方式非常多，维护成本高。

3.来多少请求就处理多少，根本不考虑后端服务的承受能力，而某些时候需

要对后端做保护。

4.业务逻辑比较分散，有的在Web应用里，有的在Dubbo服务里。提供

新功能时，工程师关注的点比较多，增加了系统风险。

5.业务频繁变化和快速发展，文档无法跟上，最后没人能说清到底有哪些协

议，协议里的字段含义。

针对这些问题，我们设计了快的无线开放平台KOP，以下是一些大的设计原则。

1.

接入权限控制

为接入的客户端分配标示和密钥，密钥由客户端保管，用来对请求做数字签名。服务端对客户端请求做签名校验，校验通过才会执行请求。

2.

流量分配和降级

同样的API，不同接入端的访问限制可以不一样。可按城市、客户端平台类型做ABTest。极端情况下，优先保证核心客户端的流量，同时也会优先保证核心API的服务能力，例如

登录、下单、接单、支付这些核心的API。被访问被限制时，返回一个限流错误码，客户端根据不同场景酌情处理。

3.

流量分析

从客户端、API、IP、用户多个维度，实时分析当前请求是否恶意请求，恶意的IP和用户会被冻结一段时间或永久封禁。

4.

实时发布

上线或下线API不需要对KOP进行发布，实时生效。当然，为了安全，会有API的审核机制。

5.

实时监控

能统计每个客户端对每个API每分钟的调用总量、成功量、失败量、平均耗时，能以分钟为单位查看指定时间段内的数据曲线，并且能对比历史数据。当响应时间或失败数量超过阈值时，系统会自动发送报警短信。

实时计算与监控

我们基于Storm和HBase设计了自己的实时监控平台，分钟级别实时展现系统运行状况和业务数据（架构如图2所示），包含以下几个主要部分。

图2监控系统架构图

1.

核心计算模型

求和、求平均、分组。

基于Storm的实时计算

Storm的逻辑并不复杂，只有两个Bolt，一个将一条日志解析成KV对，另外一个基于KV和设定的规则进行计算。每隔一分钟将数据写入RocketMQ。

基于HBase的数据存储

只有插入没有更新，避免了HBase行锁竞争。rowkey是有序的，因为要根据维度和时间段查询，这样会形成HBase Region热点，导致写入比较集中，但是没有性能问

题，因为每个维度每隔1分钟定时插入，平均每秒的插入很少。即使前端应用的日志量突然增加很多，HBase的插入频度仍然是稳定的。

2.

基于RocketMQ的数据缓冲

收集的日志和Storm计算的结果都先放入MetaQ集群，无论Storm集群还是存储节点，发生故障时系统仍然是稳定的，不会将故障放大；即使有突然的流量高峰，因为有消息队列做缓冲，Storm和HBase仍然能以稳定的TPS处理。这些都极大的保证了系统的稳定性。RocketMQ集群自身的健壮性足够强，都是物理机。SSD存储盘、高配内存和CPU、Broker 全部是M/S结构。可以存储足够多的缓冲数据。

数据层改造

随着业务发展，单数据库单表已经无法满足性能要求，特别是发券和订单，我们选择在客户端分库分表，自己做了一个通用框架解决分库分表的问题。但是还有以下问题：

1.

数据同步

快的原来的数据库分为前台库和后台库，前台库给应用系统使用，后台库只供后台使用。不管前台应用有多少库，后台库只有一个，那么前台的多个库多个表如何对应到后台的单库单表？MySQL的复制无法解决这个问题。

离线计算抽取

还有大数据的场景，大数据同事经常要dump数据做离线计算，都是通过Sqoop到

后台库抽数据，有的复杂SQL经常会使数据库变得不稳定。而且，不同业务场景下的Sqoop会造成数据重复抽取，给数据库添加了更多的负担。

2.

我们最终实现了一个数据同步平台，见图4。

图4数据同步平台架构图

1.数据抽取用开源的canal实现，MySQL binlog改为Row模式，将canal

抽取的binlog解析为MQ消息，打包传输给MQ；

2.一份数据，多种消费场景，之前是每种场景都抽取一份数据；

3.各个消费端不需要关心MySQL，只需要关心MQ的Topic；

4.支持全局有序，局部有序，并发乱序；

5.可以指定时间点回放数据；

6.数据链路监控、报警；