随着各大电商平台的崛起，当电商达到一定规模时，会发展成为平台型电商，引入第三方商家在平台中销售。由第三方商家直接进行服务，同时平台方需要对第三方商家的坐席和服务情况进行管理。
原来企业访客端IM实体是一个人对应一个聊天窗口的概念。见《构建客服系统一些实践及经验》
平台型电商的访客端IM实体变成一个人对应多个商户的概念。
对于AOS，IOS纯客户端的IM系统应用来说， WEB端的IM系统我们需要解决更多的问题，面临着更大的挑战。 AOS和IOS本地可以进行数据的持久化，所有的数据可以通过Socket从服务器推送过来。 但是WEB端的所有数据都是来源于服务器。我们不是数据的生产者， 我们只是大自然的搬运工。
基本会有如下问题：
- 多浏览器Tab之间的通信
- 页面防刷新处理(初始化处理)
- 数据通信
- 历史消息同步
- 离线消息，漫游消息处理
虽然这些处理再之前的企业访客端IM系统中也会遇到，但是操作的Level提高到了一对多的关系。
对于特定业务（客服系统）的IM系统， 设计上会有一定的特异性。
我们的原则会有如下几点：
- 从需求本身出发，抽象精简 -> 化繁为简->从简到繁的过程。
精简 --> 复杂 数据层和表现层分离底层协议和数据层分离事件总线[eventBus]来管理所有通信（事件及接口）生命周期的方式来扩展或者打点
对于单页应用， 内存数据层的处理是最重要的环节。 相信很多杭研的前端同学基本都使用过NEJ开发项目，Cache模块是NEJ的一个很重要模块。NEJ的Cache我们可以简单理解为一个内存数据管理层。
但是NEJ的 Cache 和 xdr 模块是共同使用的， 耦合性很强，灵活性会差很多。
很多项目中 请求层 不一定会用到NEJ， 但是系统中又需要对内存数据进行存储， 及不同数据模块间通信。 个人感觉单独抽出Cache管理会更灵活。
推荐（deep clone）：
immutable.js 是由facebook开源的一个项目，主要是为了解决javascript Immutable Data的问题。本质上任何数据的操作都是一个deep copy, 数据之间不会影响（没有存在引用关系）。
PS： 没有怎么使用过， 不要做评价
在项目实践中我们会发现两个矛盾： 基于实体的NEJ-Cache（Hash 和 List 存在引用关系）非常好用，虽然Cache层存在引用关系， 但是正是因为有这种关系，才能使我们能进行不同实体之间的数据通信。
忧伤点是因为NEJ-Cache被继承进了NEJ的框架里面， Cache层 和 xdr层 耦合在一起不能单独使用。 那么，自己不妨基于NEJ-Cache原理写一个纯粹的内存管理库。
推荐 (reference)： 七鱼缓存层基于实体的数据模型设计, 引用关系来实现不同缓存之间的通信（https://github.com/NSFI/ui-cache）。七鱼缓存库实现如下三个功能：
实体和列表的存储- 多个缓存的实例引用同一份数据源
- 不同缓存实例之间的通信
基于上文的分析 和 《构建客服系统一些实践及经验》文章的分享。大家对业务需求也有一定的了解了。 加上平台化电商特定业务的需求，我们可以抽象出如下实体结构。
我们还是抽象出两个实体： 商户（会话） 和 消息， 但是这两个实体随着业务的不同，又有些特异性。 例如：会话转接， 当前会话的实体是随时会变， 但商户实体是不变的，且当前有且只有一个会话。
逻辑框图可以如下所示：
PS: 前面三个会话都是之前接待过， 会话4是才是当前会话
为了保证工程的scalable, flexiable。 我们做了如下的设计规划：
- 数据层代码规划：
- NEJ单页模块规划：
- UMI的配置模块
PS： chat模块为 message消息列表模块
通信我们可以分为三大类：1.接口， 2. 广播（NEJ中类上面分发），3.Emmiter（实例上分发）。
- 数据层代码规划：
- eventBus 调度处理事件
- manage 数据管理， 通信及共享
- push 底层云信协议交互
- message 消息实体
- session 会话（商户）实体
- 数据层通信框图：
举个例子： 访客在某个商户的聊天窗口输入了咨询内容，要同时在消息列表的新增一条消息 和 这个会话更新最后一条消息。如下图所示：
对于电商平台的应用， 数据层的管理及通信只是这些业务中的冰山一角， 但又是极为核心的模块。我们同样也面临极大的挑战（数据稳定性，异常状态处理等）。 分享出来希望大家一起讨论优化
之后有时间再分享下 《客服系统SDK的设计经验总结》