合理的技術棧永遠比語言來的重要

知道個人人都知道我是作在線教育，準確的應該說是高中生在線一對一輔導平臺。

這個平臺最核心的服務應該就是上課服務了，這個上課服務裏面包含着什麼呢？我來列一下：

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 一下，誰還會在意下面一層是用什麼語言？