本文由淘宝前端工程师罗嗣分享，主要讲述了作者在星巴克消息开放项目中的总结和思考，希望对大家有帮助，让业务分享更加有价值。
摘要
从满足星巴克项目需求单点出发，发散到从点到面的思考。从而总结了自己思考的基本流程（方法论）。从如下四个递进方面思考。
业务拓展：拓展自有业务的边界，和其他业务合作共建，形成标准的能力透出, 合力共建。
业务趋势：业务的特点和趋势是如何。技术可以如何储备来应对未来业务的变化。
技术趋势：技术命题，技术趋势。选择适合的技术来解决现在的问题。保持技术对未来的弹性。
需求问题：客观存在的事实，现在需求存在哪些问题，我们如何去帮助业务更加稳定，更加高效。
本文提纲
笔者从 0 到 1 构建一个 IM 前端系统，再从点到面思考整合突破原有的自有业务限制，尽量设计出的可扩展，可交互，甚至小而美的系统能力。本文会从如下几个方面去介绍。
点：项目背景及需求难点（支付宝星巴克小程序入驻客服接待），以及现有的能力。
面：需求做完反向思考，当前 BC/CC 遇到的问题及痛点，如何在同一个领域模型下做推动标准化能力。
需求介绍
项目背景
客服接待能力由手淘消息平台和 CCO 团队合作共建，整体采用 AMP+XSPACE 的方案落地，AMP 承接 C 端用户聊天界面，XSPACE 承接 B 端聊天界面，同时接待又需要原有 BC 的聊天能力。星巴克客服接待两纵一横，底部需要对接不同的服务端，上层需要保证同一套 UI 来提升一致性体验。
设计思路
总体设计思想：设计分离出数据层和 UI 层，数据层和 UI 层以标准化协议对接。这样分层就可以解决当前业务遇到的问题，如下是当时需求的标准 SDK 事例
点到面的思考
星巴克客服消息接待开放是一种轻量级（H5 形式）的客服接入能力。思考当前业务的问题是什么，如何改进，业务价值的意义等。笔者会从如下几个方面去思考。
原有 H5 旺旺由于历史原因有稳定性和体验的问题，这套方案能不能提供替换成原来的 H5 旺旺，同时对聊天接入统一收口（标准化组件）。从而达到更加稳定，更加的体验性。
H5 旺旺聊天可以投放到阿里系的其他端上（优酷，饿了嘛，拍卖等），甚至现在很多外投的广告业务。把 H5 聊天能力做强对淘宝的引流及成交都有很大的意义。
同时集团里面还有小蜜作为客服聊天能力。能不能站在前端的角度思考整合输出。
针对集团二方业务。需要定制个性化消息和 UI 能力，需要把 SDK 能力提供给他们去进行上层业务扩展，
为保证他们低成本的接入需要提供基础能力，二方去扩展插件。
同时工具链路上需要保证提高效率。生成闭环的开发环境，接入业务方只要关系自己的业务需求
思考模型
基于之前的背景和诉求，整体设计思路: 抽离 UI 层和数据层（模块），UI 层和数据层基于 Message 实体进行标准化协议对接（桥梁）。工具链路垂直支持提高效能。有如下几个方面衔接点：
开放 UI 组件 和 标准化 SDK 能力，让二方业务快速搭建，UI 层 和 数据层之间用 标准化协议做桥梁连接
在基础 SDK 上，会透出 Context 上下文（内部核心对象 message，session，app) 让业务去定制修改，业务方只需要去扩展插件。
基于 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：利用业余时间，一月中旬前第一版本里程碑发布
未完待续
有什么 IM 相关的需求都可以联系我 @罗嗣，共建标准化和生态。
本文作者：罗嗣阅读原文
本文为云栖社区原创内容，未经允许不得转载。