从 IM 通讯 Web SDK 来看如何提升代码可维护性与可扩展性

时间 2020-05-31

标签通讯 web sdk 来看如何提升代码可维护性扩展性栏目 HTML 繁體版

原文原文链接

本文内容概述

在架构设计和功能开发中，代码的可维护性和可扩展性一直是工程师不懈的追求。本文将以我工做中开发的 IM 通讯服务 SDK 做为示例，和你们一块儿探讨下前端基础服务类业务的代码中对可维护性和可扩展方面的探索。前端

本文不涉及具体的代码和技术相关细节，若是想了解 IM 长链接相关的技术细节，能够阅读我以前的文章：web

背景介绍

大象 SDK 是美团生态中负责 IM 通讯服务的基础服务。做为 IM 通讯服务的 Web 端载体，咱们对不一样的业务线提供不一样的功能来知足特定的需求，同时须要支持 PC、Web、移动端H五、微信小程序等各个平台。编程

不一样的业务方需求和不一样的平台对 Web SDK 的功能和模块要求都不相同，所以在整个 Web SDK 中有许多部分存在须要适配多场景的状况。小程序

处理这种常见的场景，咱们通常有如下几个思路：segmentfault

针对不一样的场景单独开发不一样的基础服务代码。这种操做灵活性最强，可是成本也是最高的，若是咱们须要面对 M 个业务需求和 N 个平台，咱们就须要有 M * N 套代码。这个对于技术人员来讲，基本上是一个不可能接受的状况。
将全部的代码所有聚合到一个业务模块中，经过内部的 IF ELSE 判断逻辑来自动选择须要执行的代码逻辑。这种方案不会出现相同代码重复编写的状况，同时也兼顾了灵活性，看上去是一个不错的选择。可是咱们仔细一想就会发现，全部的代码都堆积到一块儿，在后期会遇到大量的判断逻辑，在可维护性上来看是一个巨大的灾难。同时，咱们全部的代码都放到一块儿，这会致使咱们的包体积愈来愈大，而其余业务在使用相关功能时，也会引入大量无用代码，浪费流量。

那么，咱们在既须要兼顾可维护性，有须要保证开发效率的状况下，咱们应该如何去进行相关业务的架构设计呢？微信小程序

核心原则

在个人设计理念中，有这么几个原则须要遵照：设计模式

针对接口规范编程，而不针对特定代码编程（即设计模式中的策略模式）。咱们在进行架构设计时，优先判断各个功能和模块中流转的数据格式和交互的数据接口规范，这样咱们能够保证在进行特定代码编写的时候，只针对具体格式进行数据处理，而不会设计到数据内容自己。
各模块权责分明，宽进严出。每一个模块都是单一全责，暴露特定数据格式的 API，处理约定好数据格式的内容。
提供方案供用户选择，而不帮用户作决策。咱们不去判断用户所在环境、选择功能，而是提供多个选择来让用户主动去作这个决策。

具体实践

上面的原则可能比较抽象，咱们来看几个具体的场景，你们就可以对这个有一个特定的概念。浏览器

链接模块设计（长链接部分）

链接模块包含长链接和短链接部分，咱们在这里就用长链接部分来进行举例，短链接部分咱们能够按照相似的原则进行设计便可。在设计长链接部分时，咱们须要考虑的是：链接策略与切换策略。总的来讲就是咱们须要在何时使用哪种长链接。微信

首先，咱们以浏览器端为例，咱们能够选择的长链接有：WebSocket 和长轮询。这个时候，咱们可能首先以 WebSocket 优先，而长轮询做为备选方案来构成咱们的长链接部分。所以，咱们可能会在代码中直接用代码来实现这个方案。相关伪代码以下：websocket

import WebSocket from 'websocket';
import LongPolling from 'longPolling';

class Connection {
    private _websocket;
    private _longPolling;

    constructor() {
        this._websocket = new WebSocket();
        this._longPollong = new LongPolling();
    }

    connect() {
        this.websocket.connect();
        // 只表达相关含义用于说明
        if (websocket.isConnected) {
            this.websocket.send(message);
        } else {
            this.longPolling.connect();
        }
    }
}

在正常状况下来看，咱们发现这个代码没有什么问题。可是，若是咱们的需求发生了某些变化呢？好比咱们如今须要在某些特定的场景下，只开启长轮询，而不开启 WebSocket 呢（好比在 IE 浏览器里面）？以前的作法是在构造器的时候，传递一个参数进去，用来控制咱们是否是开启 WebSocket。所以，咱们的代码会变成如下的样子。

class Connection {
    private _useWebSocket;
    private _websocket;
    private _longPolling;

    constructor({useWebSocket}) {
        this._useWebSocket = useWebSocket;
        this._websocket = new WebSocket();
        this._longPollong = new LongPolling();
    }

    connect() {
        if (this._useWebSocket) {
            this.websocket.connect();
            // 只表达相关含义用于说明
            if (websocket.isConnected) {
                this.websocket.send(message);
            } else {
                this.longPolling.connect();
            }
        } else {
            this._longPolling.connect();
        }
    }
}

如今，咱们经过增长一个判断参数，对connect函数进行了简单的改造，知足了在特定场景下的指使用长轮询的需求。

很不幸，咱们的问题又来了，咱们在针对移动端 H5 的场景下，咱们须要一个只要 WebSocket 链接，而不须要长轮询。那么，根据咱们以前的方式，咱们可能又须要在增长一个新的参数useLongPolling。这个代码示例我就不增长了，你们应该可以想象出来。

在线上运行了一段时间后，新的需求又来了，咱们须要在微信小程序里面支持 IM 的长链接。那么，根据咱们以前的思路，咱们须要在私有属性和connect方法中增长一堆判断逻辑。具体示例以下：

import WebSocket from 'websocket';
import LongPolling from 'longPolling';
import WXWebSocket from 'wxwebsocket';

class Connection {
    private _websocket;
    private _longPolling;
    private _wxwebsocket;

    constructor() {
        // 若是在微信小程序容器中
        if (isInWX()) {
            this._wxwebsocket = new WXWebSocket();
        } else {
            this._websocket = new WebSocket();
            this._longPollong = new LongPolling();
        }
    }

    connect() {
        if (isInWx()) {
            this._wxwebsocket.connect();
        } else {
            this.websocket.connect();
            // 只表达相关含义用于说明
            if (websocket.isConnected) {
                this.websocket.send(message);
            } else {
                this.longPolling.connect();
            }
        }
    }
}

从这个例子，你们应该能够发现相关的问题了，若是咱们再支持百度小程序、头条小程序等更多的平台，咱们就会在咱们的判断逻辑里面加更多的逻辑，这样会让咱们的可维护性有明显的降低。

如今有一些类库能够支持多平台的接口统一（你们去GitHub上面找一下就能够发现），那么为何我没有用相关的产品呢？这是由于 SDK 做为一个基础服务，对包大小比较敏感，同时用到的须要兼容 API 并很少，因此咱们本身作相关的兼容比较合适。

那么，咱们应该如何设计这个方案，从而解决这个问题呢。让咱们回顾下咱们的设计理念。

针对接口规范编程，而不针对特定代码编程。
各模块权责分明，宽进严出。
提供方案供用户选择，而不帮用户作决策。

经过这些设计理念，咱们来看下具体的作法。

三个设计理念咱们须要组合使用。首先是针对结构规范编程。咱们来看下具体的用法。

首先咱们定义一个长链接的接口以下：

export default interface SocketInterface {
    connect(url: string): void;
    disconnect(): void;
    send(data: any[]): void;
    onOpen(func): void;
    onMessage(func): void;
    onClose(func): void;
    onError(func): void;
    isConnected(): boolean;
}

有了这个长链接的接口类型后，咱们可让 WebSocket 和长轮询两个模块都实现这个接口。所以，他们就有了统一的 API。有了统一的 API 以后，咱们就能够将链接策略中的操做“泛化”，从操做具体的链接方式转换为操做被选中的链接方式。

其次，根据咱们的各模块全责分明的原则，咱们的链接模块应该只控制咱们的链接策略，并不须要关心她使用的是 WebSocket 仍是长轮询，仍是说微信小程序的 API。

道理很简单，可是具体咱们应该怎么来实践呢？咱们来看下下面这个示例：

class Connection {
    private _sockets = [];
    private _currentSocket;

    constructor({Sockets}) {
        for (let Socket of Sockets) {
            let socket = new Socket();
            socket.onOpen(() => {
                for (let socket of this._sockets) {
                    if (socket.isconnected()) {
                        this._currentSocket = socket;
                    } else {
                        socket.disconnect();
                    }
                }
            });
            this._sockets.push(socket);
        }
    }

    connect() {
        for (let socekt of this._sockets) {
            socket.connect();
        }
    }
}

经过上面这个示例你们能够看到，咱们泛化了每个链接方式的差别，转为用统一的接口规范来约束相关的模块。这样带来的好处是，咱们若是须要兼容 WebSocket 和长轮询时，咱们能够把这两个的构造函数传递进来；若是咱们须要支持微信小程序，咱们也只须要将微信小程序的 API 封装一次，咱们就能够获得咱们须要的模块，这样能够保证咱们的链接模块只负责链接，而不去关心它不应关心的兼容性问题。

那么由用户就会问了，那咱们是在哪一层来判断传入的参数究竟是哪些呢？是在这个模块的上一层吗？这个问题很简单，还记得咱们的第三个规则是什么吗？那就是提供方案供用户选择，而不帮用户作决策。所以，咱们在构建长链接部分的时候，咱们就在 Webpack 里面定义一些常量用于判断咱们当前构建时，咱们生产的的包是用于什么场景。具体示例以下：

import Connection from 'connection';
import WebSocket from 'websocket';
import LongPolling from 'longPolling';
import WXWebSocket from 'wxwebsocket';

class WebSDK {
    private _connection;

    constructor() {
        if (CONTAINER_NAME === 'WX') {
            this._connection = new Connection({Sockets: [WXWebSocket]});
        }

        if (CONTAINER_NAME === 'PC') {
            this._connection = new Connection({Sockets: [WebSocket, LongPolling]});
        }

        if (CONTAINER_NAME === 'H5') {
            this._connection = new Connection({Sockets: [WebSocket]});
        }
    }
}

咱们经过在 Webpack 中定义 CONTAINER_NAME 这个常量，咱们能够在打包时构建不一样的 Web SDK 包。在保证对外暴露 API 彻底一致的状况下，业务方能够在不一样的容器内，采用对应的打包方式，引入不一样的 Web SDK 的包，同时不须要改动任何代码。

可能有人会问了，这个方式看上去其实和以前的方式没有什么不一样，只是把这个 IF ELSE 的逻辑移动到了外面。可是，我能够告诉你们，这里有两个明显的优点：

咱们能够抽象单独的模块去管理和维护这个独立的判断逻辑，它不会和咱们的长链接部分代码进行耦合。
咱们能够在打包过程当中使用 tree-shaking，这样咱们可让咱们的 Web SDK 构建的包中，不会出现咱们不须要的模块的代码。

消息流处理

上面的长链接部分，咱们看到了三个原则的使用。接下来咱们来看下咱们如何使用这个原则进行数据流的处理。

在 IM 场景中，咱们会遇到许多类型的消息。咱们以微信公众号为例，咱们会碰到单聊（单人-单人）、群聊（单人-群组）、公众号（单人-公众号）等聊天场景。若是咱们须要去计算消息的未读数，同时用消息来更新左侧的会话列表，咱们就须要三套几乎彻底同样的逻辑。

那么，咱们有没有什么更优的方法呢。很明显，咱们能够根据上面介绍的原则，定义一个消息接口。

interface MessageInterface {
    public fromId: string;
    public toId: string;
    public fromName: string;
    public messageType: number;
    public messageBody;
    public uuid: string;
    public serverId: string;
    public extension: string;
}

经过以前的例子，你们应该能够理解，咱们如今的全部业务逻辑，好比更新未读数、更新会话列表的预览消息时，咱们就只须要针对整个消息接口里面的数据进行处理。这样的话，咱们的处理流程就会变成一个流水线做业，咱们只负责处理特定逻辑的数据，而无论具体的数据内容是什么样子的。

所以，若是咱们新增一类会话类型，好比客服消息，咱们也能够按照上面这个接口去实现客服消息类，复用原来的逻辑，而不须要从新实现一套完整的代码。

咱们的在一开始就须要对数据进行转换，这样才可以保证咱们在内部流转时不会犹豫数据格式不一样致使代码维护性变差。须要注意的是，根据咱们的各模块权责分明，宽进严出原则，咱们在像其余模块输出时，咱们也须要保证咱们只输出这一种格式的数据，而接受的数据，咱们应该尽最大的努力去适应各类场景。

可能有人会问，咱们内部本身规定使用那个系统就能够，控制了严出了，咱们天然就不用处理宽进了。可是，你写的代码和模块颇有可能会和其余人一块儿维护，这个时候，你只能从规范上面来约束他，而不能控制他。所以，咱们在接收其余非同一开发模块的数据时，咱们可能会遇到一些异常状况。这个时候若是咱们对宽进有作处理，也可以保证该模块能够正常运行。

有了以前的经验，你们对这个示例应该很好理解，我就很少作介绍了。

总结

这一篇文章没有介绍什么代码层面的东西，而是和你们一块儿交流了一下，我在平常工做中遇到的一些可能的问题，以及关于设计模式相关的应用场景。

若是咱们须要做为一个基础服务提供方，须要让本身的代码有扩展性和可维护性，咱们须要：

面对接口规范编程。
单一全责、宽进严出。
不帮用户作决策。

固然，在用户产品层面，可能上面的设计有部分相同的地方，也有部分不一样的地方，有时间的话，我会在后面再和你们进行分享。

你们若是有兴趣的话能够在评论区发表下本身观点，也能够在评论里面留言进行讨论，也欢迎你们发表本身的观点。

做者介绍与转载声明

黄珏，2015年毕业于华中科技大学，目前任职于美团基础研发平台大象业务部，独立负责大象 Web SDK 的开发与维护。

本文未经做者容许，禁止转载。