打车app开发架构实践.docxVIP

打车 app 开发--酷点网络打车 app 开发架构实践深圳打车 app 开发公司《酷点网络》滴滴，快的打车最初只有两个系统，一个 提供 HTTP 服务的 Web 系统，一个提供 TCP 长连接服务的推送系统，所有业务 运行在这个 Web 系统里，代码量非常庞大，代码下载和编译都需要花较长时间。系统分布式业务代码都混在一起，频繁的日常变更导致并行开发的分支非常多，测试和代码 合并以及发布验证的效率非常低下，常常一发布就通宵。这种情况下，系统的伸 缩性和扩展性非常差，关键业务和非关键业务混在一起，互相影响。因此我们 Web 系统做了拆分，将整个系统从上往下分为 3 个大的层次：业务层、 服务层以及数据层。我们在拆分的同时，也仔细梳理了系统之间的依赖。对于强依赖场景，用 Dubbo实现了 RPC 和服务治理。对于弱依赖场景，通过 RocketMQ 实现。Dubbo 是阿里开源的框架，在阿里内部和国内大型互联网公司有广泛的应用，我们对Dubbo 源码比较了解。RocketMQ 也是阿里开源的，在内部得到了非常广泛的 应用，也有很多外部用户，可简单将 RocketMQ 理解为 Java 版的 Kafka，我们 同样也对 RocketMQ 源码非常了解，快的打车所有的消息都是通过 RocketMQ实现的，这两个中间件在线上运行得非常稳定。借着分布式改造的机会，我们对系统全局也做了梳理，建立研发流程、代码规范、SQL 规范，梳理链路上的单点和性能瓶颈，建立服务降级机制。打车 app 开发--酷点网络无线开放平台当时客户端与服务端通信面临以下问题。每新增一个业务请求，Web 工程就要改动发布。请求和响应格式没有规范，导致服务端很难对请求做统一处理，而且与第 三方集成的方式非常多，维护成本高。来多少请求就处理多少，根本不考虑后端服务的承受能力，而某些时候需 要对后端做保护。业务逻辑比较分散，有的在 Web 应用里，有的在 Dubbo 服务里。提供 新功能时，工程师关注的点比较多，增加了系统风险。业务频繁变化和快速发展，文档无法跟上，最后没人能说清到底有哪些协 议，协议里的字段含义。针对这些问题，我们设计了快的无线开放平台 KOP，以下是一些大的设计原则。1.接入权限控制为接入的客户端分配标示和密钥，密钥由客户端保管，用来对请求做数字签名。服务端对客户端请求做签名校验，校验通过才会执行请求。2.流量分配和降级同样的 API，不同接入端的访问限制可以不一样。可按城市、客户端平台类型做 ABTest。极端情况下，优先保证核心客户端的流量，同时也会优先保证核心 API 的服务能力，例如打车 app 开发--酷点网络登录、下单、接单、支付这些核心的 API。被访问被限制时，返回一个限流错误码，客户端 根据不同场景酌情处理。3.流量分析从客户端、API、IP、用户多个维度，实时分析当前请求是否恶意请求，恶意的 IP 和用户会被冻结一段时间或永久封禁。4.实时发布上线或下线 API 不需要对 KOP 进行发布，实时生效。当然，为了安全，会有 API 的审核机 制。5.实时监控能统计每个客户端对每个 API 每分钟的调用总量、成功量、失败量、平均耗时，能以分钟 为单位查看指定时间段内的数据曲线，并且能对比历史数据。当响应时间或失败数量超过阈 值时，系统会自动发送报警短信。实时计算与监控我们基于 Storm 和 HBase 设计了自己的实时监控平台，分钟级别实时展现系统运行状况和业务数据（架构如图 2 所示），包含以下几个主要部分。打车 app 开发--酷点网络图 2 监控系统架构图1.核心计算模型求和、求平均、分组。基于 Storm 的实时计算Storm 的逻辑并不复杂，只有两个 Bolt，一个将一条日志解析成 KV 对，另外一个基 于 KV 和设定的规则进行计算。每隔一分钟将数据写入 RocketMQ。基于 HBase 的数据存储只有插入没有更新，避免了 HBase 行锁竞争。rowkey 是有序的，因为要根据维度和 时间段查询，这样会形成 HBase Region 热点，导致写入比较集中，但是没有性能问打车 app 开发--酷点网络题，因为每个维度每隔 1 分钟定时插入，平均每秒的插入很少。即使前端应用的日志 量突然增加很多，HBase 的插入频度仍然是稳定的。2.基于 RocketMQ 的数据缓冲收集的日志和 Storm 计算的结果都先放入 MetaQ 集群，无论 Storm 集群还是存储节点， 发生故障时系统仍然是稳定的，不会将故障放大；即使有突然的流量高峰，因为有消息队列 做缓冲，Storm 和 HBase 仍然能以稳定的 TPS 处理。这些都极大的保证了系统的稳定性。RocketMQ 集群自身的健壮性足够强，都是物理机。SSD 存储盘、高配内存和