系统前端框架设计分析.docx

系统前端框架设计分析.docx

《系统前端框架设计分析.docx》由会员分享，可在线阅读，更多相关《系统前端框架设计分析.docx（12页珍藏版）》请在冰豆网上搜索。

系统前端框架设计分析

系统前端框架设计分析

星巴克消息开放项目从0到1，从点到面的思考

目录

1.摘要3

2.需求介绍4

3.点到面的思考5

4.实践方案8

5.总结15

1.摘要

从满足星巴克项目需求单点出发，发散到从点到面的思考。

从而总结了自己思考的基本流程（方法论）。

从如下四个递进方面思考。

∙业务拓展：

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

∙业务趋势：

业务的特点和趋势是如何。

技术可以如何储备来应对未来业务的变化。

∙技术趋势：

技术命题，技术趋势。

选择适合的技术来解决现在的问题。

保持技术对未来的弹性。

∙需求问题：

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

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

本文会从如下几个方面去介绍。

∙点：

项目背景及需求难点（支付宝星巴克小程序入驻客服接待），以及现有的能力。

∙面：

需求做完反向思考，当前BC/CC遇到的问题及痛点，如何在同一个领域模型下做推动标准化能力。

2.需求介绍

项目背景

客服接待能力由手淘消息平台和CCO团队合作共建，整体采用AMP＋XSPACE的方案落地，AMP承接C端用户聊天界面，XSPACE承接B端聊天界面，同时接待又需要原有BC的聊天能力。

星巴克客服接待两纵一横，底部需要对接不同的服务端，上层需要保证同一套UI来提升一致性体验。

设计思路

总体设计思想：

设计分离出数据层和UI层，数据层和UI层以标准化协议对接。

这样分层就可以解决当前业务遇到的问题，如下是当时需求的标准SDK事例

3.点到面的思考

星巴克客服消息接待开放是一种轻量级（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脚手架体系提供相应工具链路支持，包括项目模板生成，项目测试，项目构建，完善可持续集成。

业务价值

在阿里做每件事情，需要明确这件事情的价值，这件事情投入产出比是多少。

上文也陆续在提价值。

如图可以说明这件事价值

4.实践方案

上面几章介绍了项目背景，设计思路，思考模型和业务价值（PS：

类似于论文前两章在介绍背景和理论知识）。

这章主要是讲的项目实践。

站在前端的角度，从四个方面去实践，并付相应代码地址。

∙标准化协议：

由于消息领域模型是一致的，可以抽象出标准的会话和消息格式。

他是SDK和组件能力的桥梁

∙SDK能力开放：

提供标准化数据对接的能力，负责插件扩展能力。

业务入驻只需要开发业务相应的中间件（插件）。

例如：

各自业务的编解码模块，登录模块，消息处理模块

∙组件能力开放：

提供标准化的聊天能力组件。

例如聊天入口接入标准化组件

∙工具链路支撑：

基于DEF脚手架体系，开发了def-kit-tbms套件。

支撑项目全链路开发

领域模型（标准化协议）

为了达到消息标准化能力，需要把基本概念和接口达成一致。

梳理两个基础概念：

会话和消息。

∙会话conversation:

它是指AB通讯之间维持的一种关系，它是消息存储的载体

∙消息message:

 消息是一个对话的基本组成部分,根据业务分为两大块消息，会话内消息和系统通知消息。

会话内消息又可以分为基本消息和自定义消息。

会话类型

即时通讯SDK的核心概念「会话」，即Conversation。

我们将单聊和群聊（包括聊天室）的消息发送和接收都依托于Conversation这个统一的概念进行操作。

消息类型

IMSDK内的消息可以分为两类：

会话内消息和系统通知消息。

会话内消息只能出现并展示在聊天界面里，一般是应用内的一个用户发给另一个用户（或群组/聊天室）的消息，例如文本消息、图片消息都属于会话内消息。

：

会话和消息标准化格式

∙标准化协议

https:

//g-

∙标准化会话格式

https:

//g-

∙标准化消息格式

https:

//g-

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-chatwatertbms-components

工具链路支撑

基于DEF脚手架体系，开发了def-kit-tbms套件。

提供项目全链路开发支撑。

这个项目后续的项目搭建都采用standard-dev脚手架生成项目目录。

例如：

tbms-toolkit，tbms-packages

5.总结

这是一次完整的一个项目从0到1，从点到面的思考过程，建立模型到付诸于实践。

从完成业务需求（需求做什么）到帮助业务成长（我能做什么）的思考过程。

虽然只是站在前端角度在思考问题，但是方法论相信可以通用。