office设计方案的思路基于开源方案构建文件在线预览与office协同编辑平台的架构实现

导读大家好，又见面了。在构建业务系统的时候，经常会涉及到对附件的支持，继而又会引申出对附件在线预览、在线编辑、多人协同编辑等种种能力的诉求。对于人力不是特别充裕....

大家好，又见面了。

在构建业务系统的时候，经常会涉及到对附件的支持，继而又会引申出对附件在线预览、在线编辑、多人协同编辑等种种能力的诉求。

对于人力不是特别充裕、或者项目投入预期规划不是特别大的公司或者项目而言，通常会选择基于一些开源方案来实现，但是开源组件选择之后，如何将其无缝对接融入到自己的业务系统中并完全支持自身诉求的实现，**不仅要能用、而且要好用，**其实也是一个需要好好思量的问题。

此前在项目中就曾遇到过这么个场景，下面一起分享下具体的架构设计调整演进与最终方案落地策略，以及过程中遇到的一些问题。

开源组件的选择

在正式开始构建在线的文件管理服务前，首先是分析下需要支持的功能诉求：

• 需要支持office文档的在线预览、在线协同编辑能力
• 需要支持常见的主流文件的在线预览，比如图片、视频、文本文档、PDF、压缩包之类的
• 需要支持文件的存储管理能力

对于文件的存储管理，直接采用了公司内部私有云的OSS文件托管服务进行实现，实现起来比较简单。文件在线预览与Office文件在线编辑的能力，则选用相关的开源方案来实现。经过一番对比分析，最终选定了两个开源组件：

• OnlyOffice用于支持office文档的在线协同编辑、预览等能力。
• kkFileView用于支持常规文档的在线预览能力

选型确定之后，就是如何与现有业务系统进行整合了。因为开源组件往往都是通用逻辑设计的，而业务系统的逻辑又各不相同，所以如何去整合并方便扩展出自己需要的定制化能力，成了下一步摆在眼前需要处理的问题。

整体适配对接策略

为了保证业务系统的稳定，避免业务系统中强耦合文件预览相关的开源模块，同时也为了方便业务层的调用，所以规划构建一个统一的入口代理转接服务，统一由此服务对业务系统提供预览与在线编辑相关能力，对业务层屏蔽掉底层具体的开源方案整合逻辑。这样的好处是，不管预览与编辑服务这边如何调整，甚至后面更换实现方案，都不会影响到业务层的调用逻辑。

系统边界划定，对业务系统整体的接入配合而言就简单了：

• 业务系统只需要与预览编辑服务之间进行接口与实现层面的约定对接即可，其实也是系统内部的模块间规范定义
• 预览编辑服务负责完整的业务系统请求的鉴权、与开源组件之间的适配转换、业务定制化的预览与编辑能力扩展等等。

预览编辑服务，作为业务系统的边缘代理适配器模块，需要保证提供给左侧业务系统的接口的稳定，而右侧具体对接的开源方案、内部处理逻辑等，则可以随意调整。

整合OnlyOffice实现Office文档在线预览与编辑让业务代码无耦合的方式使用预览能力

OnlyOffice作为一个负责office在线预览的功能组件，其提供了一个JS API方法。具体使用的时候，需要在html页面中引用其提供的JS文件并调用对应API方法将请求参数传递给OnlyOffice进行处理。这些请求参数里面，既含有对文档在线显示相关的一些属性约定，还包含一个重要的参数，也即需要操作的目标Office文件的获取地址url。在OnlyOffice收到请求之后，需要去给定的地址下载目标Office文件，然后内部解析处理之后，按照请求参数的指定信息，渲染展示到界面上。

在实际的系统规划中，为了便于后续版本升级维护，以及避免OnlyOffice强耦合到各个业务系统中，所以不太倾向于让前端界面直接去集成与调用OnlyOffice相关的JS文件。

所以在实施的时候，在服务端的文件预览编辑服务中进行了封装，对外提供服务端API接口，服务端自带一个简单HTML界面(基于SpringBoot Thymeleaf实现)，业务请求对应服务端提供的独立html界面，并在界面中完成使用OnlyOffice的JS api请求的操作。

具体步骤说明如下：

• 对外提供服务端HttpGet接口，借助Thymeleaf框架，界面跳转出现对应html界面

• 提供简单的HTML界面，用于引入OnlyOffice JS文件，作为最终显示界面外壳：

• 在独立的JS文件中，接收从JAVA逻辑中传入的参数信息，然后转换封装为OnlyOffice需要的格式，然后调用OnlyOffice的API接口发送请求

这样就实现整体的交互封装，业务可以代码无耦合的方式来直接使用预览能力。具体的office文档在线预览与编辑的能力实现，由开源的OnlyOffice来提供。

具体使用的时候，交互逻辑如下：

1. 向文件预览服务发送请求，指定要操作某个文档；
2. 文件预览服务经过对请求的鉴权以及其他处理逻辑之后，浏览器会跳转出OnlyOffice在线文档预览编辑界面，此步骤也会携带上具体的文档操作属性数据（比如文件下载地址、文件更新保存回调地址等）、以及操作的用户信息、允许当前用户执行的具体操作权限等等信息；
3. 在打开的界面上，用户可以执行查看或者编辑等操作；
4. OnlyOffice会通过指定的接口地址，获取要操作的文件的数据，以及编辑之后调用指定的回调接口，将更新后的内容保存。

看似很复杂的逻辑，但是经过封装之后，对于业务使用而言其实很简单，只要在发送给文件预览服务的请求中，给定一个文件下载地址与文件保存回调地址即可。

协同在线编辑能力的关注点

前面有提过，采用OnlyOffice来实现office文档的在线协同编辑，关于OnlyOffice在线编辑的原理，其官网给出的介绍如下：

对上述步骤解释如下：

也即当用户关闭文档编辑界面之后，会触发文档的保存事件，回调callback接口，将保存事件推送给服务端，并告知服务端变更后的文档地址，这样服务端可以从给定的地址下载变更后的文档，然后更新到自己的存储中。

结合到我们具体的项目使用中，其具体的交互过程展开阐述下，就是下图的过程：

这里，一个在线编辑操作的回调请求内容示例如下：

{ "actions": [{"type": 0, "userid": "78e1e841"}], "changesurl": "https://documentserver/url-to-changes.zip", "history": { "changes": changes, "serverVersion": serverVersion }, "filetype": "docx", "key": "Khirz6zTPdfd7", "status": 2, "url": "https://documentserver/url-to-edited-document.docx", "users": ["6d5a81d0"]}

关于回调请求的各个参数的具体含义，可以参见官网介绍，需要特别关注的几个字段梳理如下：