滴滴后端架构实战( 二 ) _滴滴

业务逻辑比较分散，有的在Web应用里，有的在Dubbo服务里。提供新功能时，工程师关注的点比较多，增加了系统风险。

业务频繁变化和快速发展，文档无法跟上，最后没人能说清到底有哪些协议，协议里的字段含义。

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

接入权限控制
为接入的客户端分配标示和密钥，密钥由客户端保管，用来对请求做数字签名。服务端对客户端请求做签名校验，校验通过才会执行请求。
流量分配和降级
同样的API，不同接入端的访问限制可以不一样。可按城市、客户端平台类型做ABTest 。极端情况下，优先保证核心客户端的流量，同时也会优先保证核心API的服务能力，例如登录、下单、接单、支付这些核心的API 。被访问被限制时，返回一个限流错误码，客户端根据不同场景酌情处理。
流量分析
从客户端、API、IP、用户多个维度，实时分析当前请求是否恶意请求，恶意的IP和用户会被冻结一段时间或永久封禁。
实时发布
上线或下线API不需要对KOP进行发布，实时生效。当然，为了安全，会有API的审核机制。
实时监控
能统计每个客户端对每个API每分钟的调用总量、成功量、失败量、平均耗时，能以分钟为单位查看指定时间段内的数据曲线，并且能对比历史数据。当响应时间或失败数量超过阈值时，系统会自动发送报警短信。

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

文章插图

图2 监控系统架构图

核心计算模型
求和、求平均、分组。
基于Storm的实时计算
Storm的逻辑并不复杂，只有两个Bolt，一个将一条日志解析成KV对，另外一个基于KV和设定的规则进行计算。每隔一分钟将数据写入RocketMQ 。
基于HBase的数据存储
只有插入没有更新，避免了HBase行锁竞争。rowkey是有序的，因为要根据维度和时间段查询，这样会形成HBase Region热点，导致写入比较集中，但是没有性能问题，因为每个维度每隔1分钟定时插入，平均每秒的插入很少。即使前端应用的日志量突然增加很多，HBase的插入频度仍然是稳定的。
基于RocketMQ的数据缓冲
收集的日志和Storm计算的结果都先放入MetaQ集群，无论Storm集群还是存储节点，发生故障时系统仍然是稳定的，不会将故障放大；即使有突然的流量高峰，因为有消息队列做缓冲，Storm和HBase仍然能以稳定的TPS处理。这些都极大的保证了系统的稳定性。RocketMQ集群自身的健壮性足够强，都是物理机。SSD存储盘、高配内存和CPU、Broker全部是M/S结构。可以存储足够多的缓冲数据。
某个系统的实时业务指标（关键数据被隐藏），见图3 。

文章插图

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

数据同步
原来的数据库分为前台库和后台库，前台库给应用系统使用，后台库只供后台使用。不管前台应用有多少库，后台库只有一个，那么前台的多个库多个表如何对应到后台的单库单表？MySQL的复制无法解决这个问题。
离线计算抽取
还有大数据的场景，大数据同事经常要dump数据做离线计算，都是通过Sqoop到后台库抽数据，有的复杂SQL经常会使数据库变得不稳定。而且，不同业务场景下的Sqoop会造成数据重复抽取，给数据库添加了更多的负担。

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