滴滴跨端渲染平台的建设方案及落地

导读

由于网约车业务本身的复杂性以及我们垂直式的领域化架构约束，网约车服务端技术团队在对端渲染业务需求的迭代过程中，碰到了一系列的问题，影响了研发效率。本文从这些具体问题入手，分析产生的原因，介绍我们的解决思路和方案，以及方案的建设落地过程。

1. 服务端架构演进回顾

过去几年，滴滴网约车为了满足不同用户的个性化出行需求，逐步推出了越来越丰富的品类和功能。随着品类功能的不断增加，我们系统的复杂度也越来越高，为了应对这一挑战，网约车服务端技术团队构建了一个「出行平台」，内部又称湾流平台。湾流平台的演进主要经过了以下几个阶段。

湾流平台1.0（2017-2018）

在1.0阶段，滴滴网约车的主要业务重心是丰富品类，为用户提供更多选择，其中包括专车、豪华车、优享等。在这个阶段，湾流平台还是一个单体服务，主要面临的挑战是如何快速新增品类并支持多品类之间的差异化开发。

为了应对这些挑战，我们引入了配置化和插件化。配置化使得新增品类可以快速上线并进行复用，提高开发效率。插件化则能够隔离不同品类之间的差异逻辑，确保各品类的独立性和灵活性

湾流平台2.0（2018-2020）

在2.0阶段，随着品类的不断丰富和个性化功能的增加，开发团队也不断壮大，系统规模逐渐庞大，但日常的迭代效率和稳定性出现了明显下降。为了解决这些问题，我们从两个方向对湾流平台进行了改造。

首先，按照领域驱动设计（DDD）的思路，对单体服务进行了拆分，降低整体系统的复杂度，同时也解决了团队成员并行开发导致的上线冲突和排队的问题，提高了开发效率。

其次，在领域服务内部，我们进行了功能的聚合和抽象，通过将具有相似功能的业务进行聚合，并对其进行抽象，可以避免功能的重复开发，进一步提高了开发效率和代码的可维护性。

湾流平台3.0（2020-至今）

在3.0阶段，我们开发了一套名为DuKang的业务框架，它将API的业务逻辑分为两个层次。首先是流程层，用于串接状态流转，提供了通用的流程实现，不同的品类可以根据自身需求定制自己的流程，以满足差异化的业务要求。

其次是能力组件层，负责完成各个垂类功能。组件内使用策略模式实现不同的行为，例如播单组件内部提供了延迟播单、实时播单等不同方式，不同的品类可以根据自己的需求选择适合自己的方式。同时，组件也支持插件机制，可以让品类注入独有的模式。

通过Dukang框架，我们能够有效约束各服务系统的实现，保持统一的规范，让不同的领域服务可以复用能力组件，提高开发效率和代码的复用性。

湾流平台详细的建设思路，可以参考之前的文章「滴滴出行平台业务架构演进」，系统的架构简单示例如下：

2. 新问题和挑战

在讨论新问题挑战之前，我们先统一一些基本概念。

• 页面：指用户在终端上看到的整体区域，包含各种UI控件，例如打开app看到的乘客首页、司机接单后赶来的等待接