如何去设计前端框架能力？星巴克消息开放项目从0到1，从点到面的思考

本文由淘宝前端工程师罗嗣分享，主要讲述了做者在星巴克消息开放项目中的总结和思考，但愿对你们有帮助，让业务分享更加有价值。

摘要

从知足星巴克项目需求单点出发，发散到从点到面的思考。从而总结了本身思考的基本流程（方法论）。从以下四个递进方面思考。

• 业务拓展：拓展自有业务的边界，和其余业务合做共建，造成标准的能力透出, 协力共建。
• 业务趋势：业务的特色和趋势是如何。技术能够如何储备来应对将来业务的变化。
• 技术趋势：技术命题，技术趋势。选择适合的技术来解决如今的问题。保持技术对将来的弹性。
• 需求问题：客观存在的事实，如今需求存在哪些问题，咱们如何去帮助业务更加稳定，更加高效。

本文提纲

笔者从0到1构建一个IM前端系统，再从点到面思考整合突破原有的自有业务限制，尽可能设计出的可扩展，可交互，甚至小而美的系统能力。本文会从以下几个方面去介绍。

• 点：项目背景及需求难点（支付宝星巴克小程序入驻客服接待），以及现有的能力。
• 面：需求作完反向思考，当前BC/CC遇到的问题及痛点，如何在同一个领域模型下作推进标准化能力。

需求介绍

项目背景

客服接待能力由手淘消息平台和CCO团队合做共建，总体采用AMP＋XSPACE的方案落地，AMP承接C端用户聊天界面，XSPACE承接B端聊天界面，同时接待又须要原有BC的聊天能力。星巴克客服接待两纵一横，底部须要对接不一样的服务端，上层须要保证同一套UI来提高一致性体验。

设计思路

整体设计思想：设计分离出数据层和UI层，数据层和UI层以标准化协议对接。这样分层就能够解决当前业务遇到的问题，以下是当时需求的标准SDK事例

点到面的思考

星巴克客服消息接待开放是一种轻量级（H5形式）的客服接入能力。思考当前业务的问题是什么，如何改进，业务价值的意义等。 笔者会从以下几个方面去思考。

1. 原有H5旺旺因为历史缘由有稳定性和体验的问题，这套方案能不能提供替换成原来的H5旺旺，同时对聊天接入统一收口（标准化组件）。从而达到更加稳定，更加的体验性。
2. H5旺旺聊天能够投放到阿里系的其余端上（优酷，饿了嘛，拍卖等），甚至如今不少外投的广告业务。把H5聊天能力作强对淘宝的引流及成交都有很大的意义。
3. 同时集团里面还有小蜜做为客服聊天能力。能不能站在前端的角度思考整合输出。

4. 针对集团二方业务。须要定制个性化消息和UI能力，须要把SDK能力提供给他们去进行上层业务扩展，

   1. 为保证他们低成本的接入须要提供基础能力，二方去扩展插件。
   2. 同时工具链路上须要保证提升效率。生成闭环的开发环境，接入业务方只要关系本身的业务需求

思考模型

基于以前的背景和诉求，总体设计思路: 抽离UI层和数据层（模块），UI层和数据层基于Message实体进行标准化协议对接（桥梁）。工具链路垂直支持提升效能。 有以下几个方面衔接点：

1. 开放 UI组件 和 标准化SDK能力，让二方业务快速搭建，UI层 和 数据层之间用 标准化协议作桥梁链接
2. 在基础SDK上，会透出Context上下文（内部核心对象message，session，app)让业务去定制修改，业务方只须要去扩展插件。
3. 基于DEF脚手架体系提供相应工具链路支持，包括项目模板生成，项目测试，项目构建，完善可持续集成。

业务价值

在阿里作每件事情，须要明确这件事情的价值，这件事情投入产出比是多少。上文也陆续在提价值。 如图能够说明这件事价值

实践方案

上面几章介绍了项目背景，设计思路，思考模型和业务价值（PS：相似于论文前两章在介绍背景和理论知识）。这章主要是讲的项目实践。站在前端的角度，从四个方面去实践，并付相应代码地址。

• 标准化协议： 因为消息领域模型是一致的，能够抽象出标准的 会话和 消息 格式。他是SDK和组件能力的桥梁
• SDK能力开放：提供标准化数据对接的能力，负责插件扩展能力。 业务入驻只须要开发业务相应的中间件（插件）。例如：各自业务的编解码模块，登陆模块，消息处理模块
• 组件能力开放：提供标准化的聊天能力组件。例如聊天入口接入标准化组件
• 工具链路支撑：基于DEF脚手架体系，开发了def-kit-tbms套件。支撑项目全链路开发

领域模型（标准化协议）

为了达到消息标准化能力，须要把基本概念和接口达成一致。梳理两个基础概念： 会话 和 消息。

• 会话conversation: 它是指AB通信之间维持的一种关系，它是消息存储的载体
• 消息message: 消息是一个对话的基本组成部分, 根据业务分为两大块消息，会话内消息和系统通知消息。会话内消息又能够分为基本消息和自定义消息。

会话类型

即时通信 SDK 的核心概念「会话」，即 Conversation。咱们将单聊和群聊（包括聊天室）的消息发送和接收都依托于 Conversation 这个统一的概念进行操做。

会话属性	备注
id	会话ID
scene	场景
to	聊天对象，帐号或者群ID
updateTime	会话更新时间
unread	未读数
lastMsg	此会话的最后一条消息
custom	扩展Json字符串

消息类型

IM SDK内的消息能够分为两类：会话内消息和系统通知消息。会话内消息只能出现并展现在聊天界面里，通常是应用内的一个用户发给另外一个用户（或群组/聊天室）的消息，例如文本消息、图片消息都属于会话内消息。：

会话内消息类型	备注
文本消息	消息内容为普通文本
图片消息	消息内容为图片URL地址、尺寸、图片大小等信息
语音消息	消息内容为语音URL地址、时长、大小、格式等信息
视频消息	消息内容为视频文件的URL地址、时长、大小、格式等信息
文件消息	消息内容为文件的URL地址、大小、格式等信息，格式不限
地理位置消息	消息内容为地理位置标题、经度、纬度信息
通知消息	自定义消息能够用于消息接入扩展。 例如卡片消息，红包消息等。
自定义消息	**通知消息属于会话内的一种消息，用于会话内通知和提示场景。
例如：群名称更新、某某某退出了群聊等。**

会话和消息标准化格式

• 标准化协议
• 标准化会话格式
• 标准化消息格式

SDK能力开放

SDK的设计参考了Koajs的设计原理（底层微创新了下）。Koajs的中间件思路： 中间件对于一次请求来处理，context分别集成了request和response对象， 同理能够映射成对一条收发消息的处理，面向切面的编程方式。。 在context中会集成message(消息),session(会话),app(如用户，初始化sdk信息等其余信息)。
整个项目经过lerna进行了包管理，用Typescript写了SDK，并作了充分的单元测试，你们能够放心使用。整个项目分为了以下几个模块：

• @ali/tbms-compose: 函数组合模块，用于@ali/tbms-middlware服务
• @ali/tbms-middleware: 中间件模块
• @ali/tbms-util: 通用函数分装：如promise同步执行队列，mtop请求，event事件系统
• @ali/tbms-sdk: 消息标准化基础SDK，可让业务扩展，补充插件

测试说明：

对底层支持的SDK都作了充分的单元测试，保证稳定性。后续版本更新提供差别性修改的检查

使用事例

组件能力开放

因为须要多端投放，某些二方应用支持weex能力。从而选择了RAX技术方案。再在H5表现下对单聊作性能优化，现阶段完成聊天入口的统一接入组件，上层的组件在陆续完善中（完成度20%）。@ali/rax-tbms-chatwater tbms-components

工具链路支撑

基于DEF脚手架体系，开发了def-kit-tbms套件。提供项目全链路开发支撑。这个项目后续的项目搭建都采用standard-dev脚手架生成项目目录。例如：tbms-toolkit，tbms-packages

总结

这是一次完整的一个项目从0到1，从点到面的思考过程，创建模型到付诸于实践。从完成业务需求（需求作什么）到帮助业务成长（我能作什么）的思考过程。虽然只是站在前端角度在思考问题，可是方法论相信能够通用。

后续Action

改善原来的H5旺旺，使之更加稳定和更好的体验性。同时对聊天接入统一收口（标准化组件和标准化接入SDK）。Flag：利用业余时间，一月中旬前初版本里程碑发布

原文连接