1. 制作onlyoffice镜像
1.1. dockerfile
/root/onlyoffice `#官方镜像 FROM docker.luban.fit/cmp/cmp-onlyoffice:v6
RUN <<EOF bash -ex rm -f /var/www/onlyoffice/documentserver/web-apps/apps/documenteditor/main/resources/img/header/header-logo_s.svg EOF COPY ./header-logo_s.svg /var/www/onlyoffice/documentserver/web-apps/apps/documenteditor/main/resources/img/header/`
1.2. 运行：命令
docker build -t docker.luban.fit/ces/ces-onlyoffice:v8.3.1
2. 运行onlyoffice
2.1. docker-compose方式
3. OnlyOffice 打开文档时提示下载失败
参考文档：blog.csdn.net/m0_53401243…
3.1. 编辑docker中/etc/onlyoffice/documentserver/default.json下的内容
3.2. 操作步骤：
4. onlyoffice系统架构
4.1. 整体设计
先简单说明下webExcel的核心能力，这些能力决定了整体架构：
- 支持多人协同编辑能力：不管是webExcel，还是其他doc、ppt产品线，都支持多人同时编辑同一份文档。前后端依靠协同编辑协议来保证编辑时数据的正确性，协议的核心在服务端，它决定了多人在编辑同一个文档内同一个sheet和单元格范围时，只有一个协同者的操作是有效的。
- 支持原生的xlsx文件，这点也是产品成功的核心要素，因为大部分用户从桌面迁移到在线平台时最大的诉求之一是要能打开原先的xlsx文件，并且做到打开和保存时都是同一份格式。onlyoffice为了支持这个功能，内部自定义一套前端页面能识别的序列化协议，依赖服务端的转换服务将xlsx文件格式转换为该协议内容。
- 在线服务化能力：支持第三方服务方便使用webExcel服务快速打开xlsx文件，目前业界已有wopi协议约定了服务间的接口，webExcel实现了该协议的服务端逻辑，这样三方服务只需要实现基本的文件打开、保存接口即可。
4.2. 架构图
4.2.6. 文档内部状态机
在不影响整体理解情况下，这里只列出核心的状态流转图，图中解释了每个状态改变前后的操作，每个状态都写入数据库里进行持久化存储，重点介绍文件打开和关闭的状态流转。
4.2.6.1. 打开文件
因为打开的xlsx文件需要经过转换服务转换生成Editor.bin，这是一个异步操作，协同服务和转换服务中间通过消息队列传递任务消息，所以为了判断转换是否成功，引入WaitQueue状态，处于该状态表示文件正在转换。
正常情况下如果xlsx文件转换成功后，就会更新状态为OK，然后协同服务异步通知前端页面可以打开Editor.bin文件了。
如果客户端因为网络原因和服务端重连或者重刷页面，此时如果服务端根据状态判断文件处于WaitQueue，那么直接通知客户端进入等待状态。
如果二次打开同一个版本的xlsx文件，那么服务端根据OK状态判断文件已经打开过了，这样避免对文件重新进入转换的流程。
4.2.6.2. 关闭文件
如果服务端收到websocket的close事件后，就进入关闭流程；不过与传统的本地文件立刻保存不一样，webExcel在立刻保存之前等待5s（时间可调），这个时间内的状态称为Save Version；如果5s内收到重新打开文档的请求，那么在这个请求内就将状态重新reset为OK；
如果超过5s会触发真正的save逻辑，此时也是通过Queue通过转换服务转换任务：将当前的op序列化列表作用在Editor.bin文件上并生成新的xlsx文件，生成成功后通知 文档管理服务 下载新版本的文件，同时更新当前docId的状态为Update Version，表示上个文档的版本已更新了。
4.2.7. 服务间耦合重影响部署
目前官方提供Docker镜像封装了上述三个服务和中间件，属于典型的单体式架构，这可以在开发环境上快速使用。但是部署在生产环境上，就需要考虑服务的稳定性和合理性了；至少中间件直接部署在容器里就不符合现阶段微服务的要求；并且中间件生成的结果（文件、消息任务等）直接放在本地，导致没法进行横向扩容。所以这点需要根据业务情况去定制的。
最后做个简单总结：整体来说，webExcel的整体架构比较清晰，前后端服务职责明确，不过工程毕竟是10年前开发，所以源码带有一定历史味道，代码质量不太符合现代化规范，并且官方几乎没有什么技术细节的文档，特别涉及到协同协议和op序列化理解上；所以本文简单梳理服务端架构，理解为什么要这么设计以及过程中需要注意的技术细节，期望给基于onlyoffice进行二次开发的开发者带来帮助。
