目前可用於文件存儲的網絡服務選擇有很多，比如阿里雲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標准，你的應用程序是不需要重新開發的。
歡迎關注我的博客，里面有很多精品合集
- 本文轉載注明出處（必須帶連接，不能只轉文字）：字母哥博客。
覺得對您有幫助的話，幫我點贊、分享！您的支持是我不竭的創作動力！ 。另外，筆者最近一段時間輸出了如下的精品內容，期待您的關注。