文档中台类软件的需求及挑战
文档中台产品把在线文档能力赋能给第三方业务系统，综合了桌面文档编辑/基于WEB的协同服务/中台产品的特点，因而内在的复杂度很高：
1．操作的对象是文档，文档本身的定义就异常复杂，对象和属性极度细分，具体功能点繁多。
2．实时在线协同编辑的能力对服务端提出较高要求。
3．需要在前端和后端分别提供api赋能三方系统。
另一方面作为一个优秀的软件产品，需要最大限度的把复杂逻辑封装起来，降低用户使用和集成的复杂度：
1．终端用户需要现代高效的使用体验。
2．系统管理运维人员希望产品能够快速部署升级，运维简单。
3．集成开发人员需要最大程度简化集成工作复杂度。
01
Filez文档中台技术理念和架构
Filez文档中台为了支撑上述的需求，在整体架构和具体研发实践中做了如下的选择：
客户端研发理念
专业：深化文档领域的专有算法，例如：
文字文档应用的高精度的内容排版能力。
电子表格应用的高性能渲染能力。
Office文档格式导入导出高保真支持。
高可靠的OT（协同变换）算法及协同编辑文档会话模型。
分层：利用分层结构来对抗复杂性，便于维护和演化。
框架framework层负责各应用统一视图模型灵活管理，UI界面绑定，命令流转，api调用，前后端交互等。
底层抽象屏蔽UI组件的具体实现，UI组件库可以独立演化。
中间层模块化分割各应用共享的业务逻辑业务对象。
顶层应用层采用微前端的设计模式，各应用可以独立编译部署。
复用：跨应用复用，跨平台复用，跨前后端复用。
UI组件和核心逻辑完全解耦，核心逻辑模块可以同时运行在前端和后端。
效果：
例如在文字文档应用里，针对流式文档（*.docx格式）排版的同样代码同时运行在前后端，从而前端的不同浏览器不同字体环境下的排版效果之间，以及后端导出pdf的结果之间，都做到了多端排版一致，换行和分页位置分毫不差，真正的所见即所得。
对于消耗计算资源的核心逻辑尽量运行在前端（browser）上，从而减轻后端服务器的资源消耗，支持高并发。
分层分模块解耦，让业务逻辑可以快速进化，及时响应文档中台用户的需求变化。
服务端研发理念
部署简化优先，服务端尽量轻，以微服务的理念拆分解耦，以单体服务的形式集成部署。图中每一个虚线框在概念上都是一个微服务：职责单一，边界清晰；但在形态上是容器内的被管理的进程组，整体对外表现为单体服务。
无状态和异步设计，设计时假设所有的依赖都随时可能失效。
性能驱动开发实践，开发过程中时刻保证新增功能和已有功能的高性能。
可监控性驱动开发实践，开发过程中时刻保证最终的部署系统是可监控可运维可排查的。
文档中台运行时架构
Docs容器内部的每个逻辑server（例如文档协同编辑，格式转换等）各司其职，多份进程打包进同一个容器内由PM2进程管理器来管理。进一步减少部署单元提升运维效率和资源利用率。
Filez文档中台只引入必要的中间件，让每一个部署单元都充分利用，例如Redis既作为消息队列，又作为缓存层，还是分布式协调的能力中心。MongoDB既存储结构化数据又存储文件流数据。
autoheal 容器和filebeat 容器分别负责高可用保活和日志采集
效果
标准单节点部署半小时即可完成首次安装，后续10分钟可升级版本。可以支持容器化部署，非容器化部署以及K8S云平台部署。
服务端高性能，高可用，可水平扩展。8核16G配置即可支持800用户同时在线编辑。
标准单节点部署半小时即可完成首次安装，后续10分钟可升级版本。可以支持容器化部署，非容器化部署以及K8S云平台部署。
服务端高性能，高可用，可水平扩展。8核16G配置即可支持800用户同时在线编辑。
Filez文档中台和第三方业务系统集成便捷，只需要第三方实现4个接口。1~2天即可完成编辑预览赋能对接开发。
02
总结
基于上述技术理念和架构打造的Filez文档中台与业务系统完美融合，为企业的文档处理提供了一个安全、高效、便捷的平台。在数字化的时代，Filez文档中台是企业提升竞争力的不可或缺的伙伴。
【END】
