Trip.com 机票React Native整洁架构2.0实践_软件工程_佳璐

FCon7折倒计时最后一周：日程已上线70%！查看详情>>> 了解详情 



 写点什么

一、前言

2019 年上半年携程机票前台团队基于 clean architecture 思想，结合具体业务特点和复杂度，对 App 机票查询列表页进行了一次技术重构。重构后的机票列表页视图与逻辑分离，多个业务模块分治业务场景，降低整体业务复杂度，提升了页面的可维护性，可测试性。

在近一年的业务迭代过程中开发团队发现了新的问题，并在原有1.0版本架构上做进一步优化。

二、架构优化

软件架构是软件的基本结构，针对业务场景实现合适的软件架构是软件可维护、可拓展的重要因素之一。

随着业务发展，大量业务逻辑迁移至前端实现以减少请求服务的次数，带给用户更平滑、顺畅的使用体验，前端的业务复杂度大大提高。现阶段前端的主要业务场景可抽象为：

1）请求服务。

2）根据业务逻辑将服务数据转化为业务状态。

3）根据展示逻辑将业务状态转化为展示状态，并渲染至界面。

4）响应用户交互，根据展示逻辑更新展示状态，根据业务逻辑更新业务状态。

前端页面的复杂度在于业务逻辑、展示逻辑繁多复杂，且业务逻辑间、展示逻辑间存在大量联动关系。如下图，大量复杂的业务逻辑、展示逻辑互相关联，导致整个页面的复杂度指数级上升。

2.1 原有问题

原架构借鉴 clean architecture 思想，将页面拆分为多个同构的业务模块，业务模块间可以嵌套组合。单个业务模块使用 MVP 模式进行管理：

View - React 代码，只负责界面展示、样式和响应用户交互。
Presenter - 连接 View 和 Model，连接外部模块，不存在业务逻辑。
Model - 业务实体，封装了业务逻辑和展示逻辑供 Presenter 调用。

其架构如图：

对比原架构设计与实际业务场景，可以发现其设计存在不合理之处：

业务逻辑实现在业务模块内，与展示逻辑强耦合。当界面不展示业务模块时，对应的业务逻辑也无法执行，容易出现程序 bug。
业务逻辑与展示逻辑难以复用。
页面内多个业务模块实现同一业务逻辑时，只能通过拷贝相关代码解决。
跨页面复用模块时，由于不同页面间的业务逻辑存在差异，导致无法直接复用。
模块间数据通信方式复杂，由于业务逻辑实现在不同业务模块内且业务模块在页面中呈树状结构，页面逻辑复杂时数据通信容易出现下图中的状态。

2.2 解决方案

新架构针对上述问题进行优化，核心改动点为：

优化数据通信方式，模块只与 Service 通信，实现单向数据流。
新增业务 Service 概念，承载页面业务逻辑，业务模块调整为只承载展示逻辑。

三、插件功能优化

前端页面中除了业务功能外，还需实现大量非业务性功能，例如用户行为埋点、线上监控等。

3.1 原有问题

原架构中这类非业务性功能通常散落在代码各处，自身缺乏收口方式，对正常业务代码侵入性强，严重影响代码的可读性、可维护性。

以最常见的埋点功能为例，假设现在需对页面内具有联动关系的展示数据进行监控，当数据间展示不同步时上送报错埋点。在原架构下我们的实现方式为：

// ModuleA/Presenter/index.tsexport class ModuleAPresenter {    private monitor: Monitor;    constructor(monitor: Monitor) {        this.monitor = monitor;    }
    public updateView() {        // 收集模块A的最新状态。        this.monitor.updateState(this.model.getViewModel(), 'ModuleA');        this.view.updateView(this.model.getViewModel());    }}// Monitor/index.tsexport class Monitor {    private stateMap = new Map();    public updateState(state, moduleName) {        this.stateMap.set(moduleName, state);        // 检查模块A、模块B的状态是否同步。        this.checkState();    }}

复制代码

上述代码有几个明显的问题：

1）埋点代码直接侵入业务代码，两者互相强耦合，后续对埋点逻辑的改动很可能破坏业务代码，反之亦然。

2）业务模块需持有埋点类的实例，增加了对 Monitor 类的依赖，降低了自身的可复用性、可测试性。

3）对埋点逻辑的修改需要改动多个位置的代码，产生了”散弹枪式修改“的坏味道。

3.2 解决方案

基于面向切面编程的思想，在架构设计时预留”切面“并提供插件功能。用户可将非业务性功能封装在插件内维护与业务代码完全隔离，插件可通过切面获取如程序生命周期、特定用户行为等必要信息，无需入侵业务模块代码。同时业务模块也可访问插件实例，利用插件收集的数据完成特定功能。

面向切面编程（Aspectoriented programming）旨在将业务主体与非业务性功能分离，以提高程序的模块化程度。它将代码逻辑切分为不同的业务功能集，每个功能集包含了多个功能点，部分功能点会在多个功能集中都有出现，它们被称为”切面“。非业务性功能利用切面进行封装、维护，使原本分散在整个页面中的逻辑变得可管理、可维护。

上述例子使用插件改写后如下：

// ModuleA/Presenter/index.tsexport class ModuleAPresenter {    public updateView() {        // 业务模块中不再有无关逻辑        this.view.updateView(this.model.getViewModel());    }}// Monitor/index.tsexport class MonitorPlugin implements IGrtPlugin {    private stateMap = new Map();
    // ”切面“方法    public onUpdateState(state, moduleName) {        this.stateMap.set(moduleName, state);        // 检查模块A、模块B的状态是否同步。        this.checkState();    }}