打车app发架构实践.pdfVIP

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