合理的技术栈永远比语言来的重要

知道我的人都知道我是做在线教育，准确的应该说是高中生在线一对一辅导平台。

这个平台最核心的服务应该就是上课服务了，这个上课服务里面包含着什么呢？我来列一下：

1. 白板互动系统（屏幕共享系统）

2. 语音即使通讯系统

3. 文字即时通讯系统

4. 课件中心

5. 题库中心

其他服务先不说，首先说说这个课件中心，其实也就是将 PPT、PPTX、PDF 之类的文件转换成图片使其可以在白板互动系统里面使用，看似非常简单的模块，我们却碰到了非常多的问题。我总结了我们才到的几个坑，一一列在下面。

网上搜索到的并非是最完美的方案，仅仅能用而已.

最初我们的解决方式是使用网上 LibreOffice 转换 Office 文档到 PDF ，然后再使用 ImageMagick（或者GhostScript）转换 PDF 到指定图片格式的方案。 这个方案非常的简单，我甚至没有上队列，仅仅使用 CRON 定时脚本就搞定了了。

然后我们很快就放弃了这个方案，因为 LibreOffcie 对于 Microsoft Office的支持实在是太有限，很多 PPT 转换出来简直是面目全非。对于内嵌对象的支持跟上非常糟糕，很多内嵌对象往往无法显示，比如数学公式。当然还有转换时间过长的问题，因为我们屌丝的服务器，基本上转换一个 50 页的文档需要5分钟，这个体验太糟糕了！

某些时候云服务也不是非常靠谱.

鉴于我们使用的七牛存储，而七牛上刚好有 亿方云文档转换服务，所以我们很快就将我们的
PPT 转换到 PDF 这个本地步骤变成了使用亿方云的服务。这种方式我们使用了非常长的一段时间。但是无法转换成功的问题还是断续存在的，虽然转换时间大大降低了。总之我们在第一个方案上碰到的问题基本上第二个方案都有除了频率小了，转换速度快了。

而事实上七牛也含蓄的说明了这个服务是不靠谱的。

有些时候99%的成功概率都难以容忍

随着我们规模的扩大，课件转换问题就像一个幽灵一样环绕在我的周围，因为即使只有 1% 的转换失败概率，那么我们一周也至少会碰到 5 例失败，这个非常影响我们的工作效率。而实际上的转换失败概率远比这个大。所以我明白了很多时候为什么很多公司要把可靠性要定在5个9甚至6个9那么高了。

这个影响非常的大，以至于我们不得不出了一个奇葩的规则补救：如果你上传 PPT 转换失败，请用 WPS 或者 Windows Office 转换成 PDF 再上传。但这个措施一出无异于我们放弃了 PPT 转换的方案，这样还不如直接跟用户说:请用 PDF 上传吧，PPT 我们不支持来的直接。

商业方案也不一定靠谱

到了今年，课件转换这个模块已经可以说是如鲠在喉，不吐不快了，无论是用户还是内部都抱怨多多。

这个时候我们试用了 Aspose.Total 和 Spire.Office 这两套方案，但是很快就被我们排除了，因为通过不了我们的“单元测试”（一大批来自老师的疑难课件）。

而经我们事后了解亿方云使用的就是 Aspose.Total 的解决方案。

PS: 特别夸一下 Spire.Office 是国人开发的，值得推荐。

Linux并非政治正确

这个时候我不得不把目光瞄向了 Microsoft Office，我想如果 Microsoft Office 都无法转换成功，那么这个世界上也没有什么软件可以转换这个课件了。

但如果使用 Microsoft Office 那么必须得安装 Windows Server 系列的系统，这无疑是对大多数Linux系运维架构的一个挑战（我们就碰到 Windows 自动更新自己重启了！自己重启了！！！）。

我用 COM Interop + C# + Windows Office 2013 迅速撸了一个转换命令行工具。然后迅速上架这个功能，发现效果提升非常明显。

首先转换内容出错肯定不存在问题了。第二个我们发现转换速度非常快，50页的PPT只需要上传、打开PowerPoint、输出图片、上传图片、更新数据库只需要不到10秒。而这个在之前是需要至少100秒的。

这使得我们在我们的产品上不得不改口说：

而这个30秒还是我们夸大了讲的。

这套方案成功的转换过 500 多页的 PPT, 而这个 500 多页的 PPT 在以前的转换方案中是 100% 失败的，基本上不是在 LibreOffice 挂了，就是在 ImageMagick 挂了。

合理的技术栈永远比语言来的重要

阿里巴巴用 Java 我们也用 Java 吧？
PHP 这东西没什么难度的？
是不是 C++ 开发的会稳定点？
微软的东西，还是算了吧用开源的吧！

以上这些不是不懂技术的人会讲吗，懂技术的人也会讲。我曾经在微博上说过我们一家对手公司因为使用 C++ 开发客户端导致大半年时间浪费在处理 Windows 系统的兼容性上。我也见过多家公司因为听信 Java 好，而把技术方向从 PHP 转向 Java 导致公司一蹶不振的。对于大多数基础技术公司来讲，这根本不是哪种语言好的问题，而是你能不能 Hold 住的问题。

我一直对外讲我们公司用 PHP + JavaScript，但实际上我们用的还有 Go、TypeScript、C#、C++、Java，每一块都实现的非常好，各居其位、各谋其政。但我们的核心目前还是 PHP + JavaScript。

微服务是未来，虚拟化是未来、接口是未来

学过 Golang 的朋友都知道 Golang 的接口机制非常的奇怪，**因为它的接口机制是你有没有继承不是看你有没有说我继承自某某，而是看你会不会某某的功能。

通俗讲就是：如果我们定义 Bird 类只有一个方法叫 Fly（），如果你能 Fly，那么你也叫 Bird 。

所以你用 PHP 实现或者用 Java 实现一个服务化的功能并不重要，重要的是你实现的完不完美。你能不能 Hold
住。

举个例子：我在13年的时候用PHP实现过一个任务队列系统（PHP Coolie），今年我用 Go 重新实现 Windows 下任务队列的 Worker 。对于我来讲不是 Go 好，而是 Windows 下没有 PHP 没有 pcntl 。

Docker 大行其道的当天，对于大多数服务来讲都只需要 docker run 一下，谁还会在乎下面一层是用什么语言？