什麼時候你不應該使用微服務

最近幾年我一直在微服務相關的工作，編碼、學習模式、尋找並使用開源工具，到大會做分享…… 這本《微服務設計》我讀起來還是有很多比較切身的感觸的，這裡記錄下。

首先這本書最後一章有一段說的特別好：

你越不瞭解一個領域，為服務找到合適的界限上下文就越難……服務的界限劃分錯誤，可能會導致不得不頻繁地更改服務間的協作，而這種更改成本更高……”

軟體行業從業者，尤其是那些已經不寫程式碼的從業者，總會期望有銀彈，但銀彈終究是沒有的，微服務也是。

我個人覺得微服務本質上是要解決一個 Scalability 的問題，這裡的 Scalability 不僅僅是指應對使用者量增加，還指業務複雜度增加，資料量增加，團隊人員增加（具體參考《The Art of Scalability》一書）。微服務的一套方法論和具體實踐方法給我們指了一條路，但路總是需要自己走的。

這本書的大量內容是對於其他書籍的提煉並用更現代化的語言闡述，例如，要理解微服務你不得不去閱讀《領域驅動設計》（或者《實現領域驅動設計》），因為所有服務都是圍繞領域來的；例如，要懂得如何應對大量服務的快速釋出，你需要去閱讀《持續交付》，再補充 Docker 相關的知識；例如，要學會如何保證大量服務互動時候的穩定性，你需要去閱讀《Release It!》；此外，常見的分散式知識，如負載均衡、CAP理論，如何使用快取，該學的你一樣都不能拉下；對了，你還得知道 DevOps 以及如何監控你的系統和服務（可惜未見比較好的關於監控的書籍，有朋友知道的話請推薦）。

書中的第4，5章是我覺得比較有原創性的內容，怎麼拆分一個巨型應用，第5章有很多切實的建議；而第4章告訴你，當你有一堆形狀各異的服務的時候，他們之間整合可能會遇到什麼麻煩，以及如何避免及應對。

不過，我不得不說，這書完全不適合程式設計新手閱讀，因此書中幾乎沒有什麼樣例程式碼可以拿去實踐的，而書中涉及了大量的開源工具，隨便拉一個如 Hystrix, Dropwizard's Metrics 都可以去研究好幾天，我是非常佩服作者的視野的。

沒打五星的另外一個原因是，我讀畢沒有感覺啊哈！意思就是，書的結構並沒有給我一個清晰的系統或者脈絡，我自認已經實踐過了書中六七成的內容，心中也沒有一個清晰的系統抽象，本來指望這本書能有所幫助，然而還是失望了。

如果你在維護巨型應用並瀕臨死亡，那麼還是應該走微服務這條活路的，但可以想象死而復生的道路比死亡本身難很多。