目前可用於檔案儲存的網路服務選擇有很多，比如阿里雲OSS、七牛雲、騰訊雲等等，但是收費都有點小貴。為了幫公司節約成本，之前一直是使用fastDFS作為檔案伺服器，準確的說是圖片伺服器。直到我發現了MinIO，我決定放棄FastDFS。
關於MinIO的使用方法，我就不說了。大家去看MinIO官網地址：docs.min.io/cn/ ，非常詳細。我就從對比的角度來說說我為什麼果斷的放棄了fastDFS，轉而使用MinIO作為圖片儲存伺服器。
理由一：安裝部署(運維)複雜度
之前公司在使用fastDFS的時候，只有少數的幾個人能夠掌握fasdtDFS的部署結構。所以只要出現有點問題，能夠頂上的只有這麼幾個人。如果將一個fastDFS分散式服務部署完成，需要具備以下的知識
- linux基礎的目錄操作
- 常用的分散式主從原理
- C語言程式碼的編譯
- nginx安裝部署
- nginx外掛的使用（防盜鏈）
如果僅僅是上面的這些基礎知識，安排幾個程式設計師學一學還好說。主要是fastdfs的部署結構之複雜，如果我長時間不回顧，自己都會忘了這複雜的架構是怎麼回事。
當我看到MinIO的安裝過程之後，以及分散式的部署命令之後（分散式MinIO快速入門），放棄fastDFS的決心就已經做出了一大半。
說白了：FastDFS的部署不過是零件的組裝過程，需要你去理解fastDFS的架構設計，才能夠正確的安裝部署。MinIO在安裝的過程是黑盒的，你不用去深入關注它的架構，也不需要你進行零件組裝，基本上可以做到開箱即用。普通的技術人員就能夠參與後期運維。
理由二：文件
我覺得從我知道fastDFS開始，也有十年了。竟然沒有官方文件，所有的文件全是某某公司的自己總結的文件，或者是某某網友自己總結的文件。
從這點上看fastDFS真的是一敗塗地，當然阿里餘慶大神在做這個專案的時候可能也沒有考慮到後來會有這麼多人用。即使用的人多了，在餘慶大神眼裡可能覺得這只是自己開發的一個小玩具，沒有繼續深入運營的必要。
理由三：開源專案運營組織
fastdfs是阿里餘慶做的一個個人專案，在一些網際網路創業公司中有應用，沒有官網，不活躍，6個contributors。目前已經很少做更新。
MinIO目前是由2014年在矽谷創立的公司MinIO.Inc運營的開源專案，社群論壇的活躍度目前也非常的不錯。
理由四：UI介面
我們都知道fastDFS預設是不帶UI介面的，看看MinIO的介面吧。這個介面不需要你單獨的部署，和服務端一併安裝。開箱即用，愛了愛了。
理由五：效能
MinIO號稱是世界上速度最快的物件儲存伺服器。在標準硬體上，物件儲存的讀/寫速度最高可以達到183 GB/s和171 GB/s。關於fastDFS我曾經單執行緒測試寫了20萬個檔案，總共200G，大約用時10個小時。總體上是很難達到MinIO“號稱的”以G為單位的每秒讀寫速度。
理由六：容器化支援
MinIO提供了與k8s、etcd、docker等容器化技術深度整合方案，可以說就是為了雲環境而生的。這點是FastDFS不具備的。
理由七：豐富的SDK支援
fastDFS目前提供了 C 和 Java SDK ，以及 PHP 擴充套件 SDK。下圖是MinIO提供的SDK支援，MinIO幾乎提供了所有主流開發語言的SDK以及文件。同志們，重要的是文件。
不是說PHP不主流啊，不想引戰。求生欲很強。
理由八：AWS S3標準相容
Amazon的S3 API是物件儲存領域的事實標準。MinIO是S3相容性的事實上的標準，是第一個採用API和第一個新增對S3 Select支援的標準之一。包括微軟Azure在內的750多家公司使用MinIO的S3閘道器，這一數字超過了業內其他公司的總和。
什麼意思？就是說你現在為了節約成本使用MinIO，等你的公司壯大了、有錢了。不想自己運維基礎設施了，你就可以把物件儲存放到雲上，只要雲廠商支援S3標準，你的應用程式是不需要重新開發的。
歡迎關注我的部落格，裡面有很多精品合集
- 本文轉載註明出處（必須帶連線，不能只轉文字）：字母哥部落格。
覺得對您有幫助的話，幫我點贊、分享！您的支援是我不竭的創作動力！ 。另外，筆者最近一段時間輸出瞭如下的精品內容，期待您的關注。