打 车 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....
