需求说明

1.背景

本文旨在介绍前后端分离架构在自助应用场景下的架构规划和开发计划，以期解决现有技术架构存在的问题，降低开发、维护、沟通等成本，提升架构的拓展性，提升方案的增值性。

2.平台简介

zt-x平台是一个面向内部开发人员的整合开发方案，提供自助应用相应开发套件以帮助银医项目开发团队高效开发、专业测试和快速部署，并提供标准化接口和高模块化定制套件以保证高可扩展性和个性定制满足项目需求

3. 采用新平台的优势/解决问题

3.1. 现阶段问题

模块		问题	影响
TAF	浏览器	浏览器内核较老，无法及时更新	应用无法使用新语法糖需要做兼容，特定页面效果无法实现
		设置浏览器需用配置文件配置无可视化界面设置	配置相对麻烦不直观，而且提供的设置项较少
		应用开发调试较为困难，需借助chrome浏览器	应用有些问题无法直接定位，需在两个浏览器之间切换，有时复现问题较难
		多窗口控制较为复杂	面对多屏、大屏拼接配置和控制较为麻烦
		无法添加/更换字体	面对字体版权侵权问题无法本地导入开源字体
	服务	输入法等涉及UI模块需使用TAF才能调用和调试	应用无法脱离TAF进行远程调试和开发
	服务	银医老控件（OCX）兼容	现阶段暂无替代方案等控件需转发解决
TMS	服务	接口对接定制化较多	可移植性较差，服务模块复用率较低，开发周期较长
		过度依赖TAF	开发、调试、部署较为麻烦
		接口未完全标准化	开发微信公众号、app存在兼容问题
后端服务		模块暂无，未和前端分离	无标准接口输出，导致多端应用无法快速开展，影响未来产品发展；无法与TMS、TAF、应用进行统一通信，各个模块间调度比较杂乱；对于甲方以及第三方过度依赖，无法任何方案输出，对接接口较为被动。
应用		前后端未分离	前后端代码耦合在一起，管理混乱，可控性较差，代码专业化程度低；前后端沟通、维护成本较高，需依赖后端环境；在开发阶段很难做代码层测试；对于个性化较高要求的项目无法快速移植；针对多端应用后端需针对性重新开发，开发成本较高
应用		开发调用硬件对TAF依赖大	硬件调试时间接近代码开发一倍，如有不定因素时间更长无法做整体性的自动化测试和压力测试；远程开发和调试较为麻烦，对环境要求较为苛刻

3.2. 新平台的优势

实现项目模块化分工，使得相关模块开发专业化、规范化，提升可维护性、拓展性，降低开发、实施成本
对前端、后端、调用硬件代码层进行解耦，降低集成和调试的人员沟通成本，解耦后的代码更易于定位问题和维护
后端对接接口、TAF彻底服务化，业务逻辑移至前端应用，实现多端应用共用一套服务，降低应用开发风险，使后续的标准化开发成可能
规范代码、接口定义提高项目交付质量和开发效率
制定工作流优化项目管理，提升项目交付质量、降低开发成本
前端使用TAF时开发、测试阶段进行分离，通过工具模拟实现与硬件脱离，提升开发效率

4. 平台概括

4.1. 模块规划

STD平台的模块包含6大块：

工具集：前端应用开发的工具，包含浏览器、UI库、TAF模拟服务和TAF调用插件；
应用：终端业务应用，包括Web、安卓、微信公众号和微信小程序；
后端服务：整个框架的交互核心节点，负责与前端、TMS、第三方对接；
TMS：涉及终端管理的服务；
TAF：涉及终端部件调用的服务。
UI设计：组件设计规范

4.2. TAF模块

目标：

TAF提供驱动调用服务，原有涉及系统UI的模块屏蔽移至浏览器层，比如输入法、手写板等，仅提供硬件相关模块。

4.3. 后端模块

目标：

后端服务提供同时兼容graphql和restful风格的API供TMS和应用调用。
作为平台的中枢神经所有与医院或者第三方渠道通信均需要经过后端服务处理后转发，以防止第三方的影响对平台内应用造成代码污染和接口破碎化问题。
作为平台唯一与外界接口对接的服务，可以做到拦截、过滤、抓取接口数据，当接口达到一定规模或者接口数据价值高时可以做一些额外增值服务（需甲方同意），比如对账、交易统计、敏感数据监测等等。

4.4. TMS模块

目标：

对终端设备进行监控，通过与TAF通信实时监控设备状态并实时推送终端设备状态信息，同时可以对管理内的终端进行设置和远程操作；
对应用进行业务和个性化需求进行设置；
对数据处理这块，通过后端服务提供的数据进行存储分析，将终端交易过程的数据、日志、账单、生成的音像等对用户进行可视化展示，以便用户实时监测。

4.5. 应用模块

目标：

根据需求提供web版（带调用硬件）、android、微信公众号、小程序应用，接口来源于后端服务，硬件调用对接TAF服务（web版），应用个性化配置由TMS配置。