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

来源: 云栖社区 作者: 罗嗣 | 发布时间: 2018-12-18 21:16:53

本文由淘宝前端工程师罗嗣分享,主要讲述了作者在星巴克消息开放项目中的总结和思考,

云栖君导读:本文由淘宝前端工程师罗嗣分享,主要讲述了作者在星巴克消息开放项目中的总结和思考,希望对大家有帮助,让业务分享更加有价值。


摘要


从满足星巴克项目需求单点出发,发散到从点到面的思考。从而总结了自己思考的基本流程(方法论)。从如下四个递进方面思考。


  • 业务拓展:拓展自有业务的边界,和其他业务合作共建,形成标准的能力透出, 合力共建

  • 业务趋势:业务的特点和趋势是如何。技术可以如何储备来应对未来业务的变化

  • 技术趋势:技术命题,技术趋势。选择适合的技术来解决现在的问题。保持技术对未来的弹性

  • 需求问题:客观存在的事实,现在需求存在哪些问题,我们如何去帮助业务更加稳定,更加高效



本文提纲


笔者从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能力提供给他们去进行上层业务扩展,


  • 为保证他们低成本的接入需要提供基础能力,二方去扩展插件。

  • 同时工具链路上需要保证提高效率。生成闭环的开发环境,接入业务方只要关系自己的业务需求


思考模型


基于之前的背景和诉求,整体设计思路: 抽离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 这个统一的概念进行操作。



消息类型


IM SDK内的消息可以分为两类:会话内消息和系统通知消息。会话内消息只能出现并展示在聊天界面里,一般是应用内的一个用户发给另一个用户(或群组/聊天室)的消息,例如文本消息、图片消息都属于会话内消息。:



会话和消息标准化格式


  • 标准化协议

    https://g-assets.daily.taobao.net/tb-chatting/tbms-protocol/index.html

  • 标准化会话格式

    https://g-assets.daily.taobao.net/tb-chatting/tbms-protocol/Conversation.html

  • 标准化消息格式

    https://g-assets.daily.taobao.net/tb-chatting/tbms-protocol/IMMessage.html


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,从点到面的思考过程,建立模型到付诸于实践。从完成业务需求(需求做什么)到帮助业务成长(我能做什么)的思考过程。虽然只是站在前端角度在思考问题,但是方法论相信可以通用。




end

Spring Cloud Config 规范

十分钟构建双十一交互分析大盘

阿里毕玄:技术人应如何选择职业发展路线?

2018年阿里巴巴重要开源项目汇总(持续更新中)

更多精彩

公众号导航