近年來，微服務是備受關注的概念。有人主張微服務是一種革命性的技術創新，也有人認為微服務並沒有什麼新鮮的，只不過是對SOA（面向服務架構）的優化重塑。我不想爭論這些，因為無論是支持還是反對，都無法阻擋微服務在敏捷開發和複雜的企業級應用開發中的優勢。
通過微服務，我們在應用開發和部署方面取得了顯著的進步。將應用開發或者重構成微服務以分離服務，通過 API 以明確的方式來相互“對話”。例如，每個微服務都是自包含（self-contained），各自維護自己的數據存儲（這非常有意義），可以獨立更新其服務。
使用基於微服務的方式使得應用程序開發變得更快更容易管理，它只需要較少的人力就能實現更多的功能，可以更快更容易地部署。把應用程序設計成一套微服務，更加容易在多臺具有負載均衡的服務器上運行，使其能夠輕鬆應對需求高峰、由於時間推移而平穩增長的需求和由於硬件或者軟件問題導致的宕機事故。
微服務的最大進步在於改變了我們的工作方式。敏捷軟件開發技術、應用遷移雲端、DevOps 文化、持續集成與持續部署（CI/CD）和容器應用都使用了微服務來革新應用開發與交付。
我們先來看微服務的發展史。
從最原始的單體應用開始：
單體應用的噩夢
假設你要開發一個類似滴滴的打車應用。在單體應用的架構下，你可能這樣設計
在架構核心，設計了乘客管理，司機管理。行程管理，支付，消息通知等核心模塊。
圍繞核心模塊，我們再設計各種接口適配器，如同數據庫對接，同移動端的api接口，web頁面，對其他外部組織對接接口等等。
然後我們就可以打成一個包，進行部署。
在項目的早期，這沒有太大問題。我們還可以通過負載均衡器在做多個實例的負載均衡。
然而，成功的應用有一個趨勢，隨著時間推移而變得越來越臃腫。
首先，在業務快速發展的階段，開發人員每天有大量業務變更需要開發，在996已經不能保證完成工作的情況下，要開發人員保證應用架構的乾淨是強人所難。
在業務代碼變得足夠複雜之後，團隊中很快就沒有人能完全理清所有業務，只能負責自己的一小塊。
最終，正確修復bug和開發新功能都變得越來越困難，只能不斷的打補丁。最終單體應用會變成一個無人可以理解的超大型亂碼。
最後的結果是：你不要嘗試去重構，就讓他這樣跑著吧。
同時伴隨而來的是，單體應用的部署時間越來越長。一個單體應用對服務器的要求也越來越高。
單體應用的另一個問題是可靠性。因為所有模塊都運行在同一進程中。任何模塊的一個 bug，比如內存洩漏，可能會拖垮整個進程。此外，由於應用程序的所有實例都是相同的，該錯誤將影響到整個應用的可用性。
總結：
所以，一個成功的應用最終會變成只有少數人能維護的巨大單體。使用著陳舊的技術，很難找到合格的新開發人員。
部署困難，重啟耗時極長，可靠性也得不到保障。無法重構，或者重構的代價極大，必須同時重構整個單體。
微服務破局
對單體應用問題的探索，誕生了微服務架構。我們將核心業務的幾大業務模塊，拆分為獨立的迷你應用。他們都有自己獨立的核心邏輯和對外相互對接的接口。
每個迷你應用都對外暴露REST服務API。各後端服務可以相互調用。一些 REST API 也暴露給移動端應用使用。然而，前端應用不能直接訪問後端服務。前端對後端的服務調用要通過API網關。API 網關統一負責負載均衡、緩存、訪問控制、API 計量和監控。
微服務架構模式明顯影響到了應用程序與數據庫之間的關係，在單體應用中，所有業務共享一個數據庫。然而現在，微服務建議其每一個服務都有自己的數據庫。這樣做的缺點是可能導致部分數據冗餘。但是，從微服務架構的角度去理解，業務A的數據庫本就不該存業務B的數據，所有的關於業務B的數據，從應該由業務B的微服務對外提供。
另外，在這種架構下，我們可以為業務選擇合適的數據庫。比如對某些業務，我們需要選擇支持高效地理位置查詢的數據庫。
總結：
微服務的優點：
1，拆分了複雜的單體應用。降低了代碼的服務度，規定了微服務的業務邊界。使業務代碼能夠容易的開發和修改
2，微服務架構使每個業務模塊有一個團隊專門負責。技術團隊可以根據業務的需要做出更合適的技術選型。同時因為單個微服務代碼體量的減小，使代碼重構成為可能。
3，部署更快捷和方便。
優點司空見慣，我們其實更應該關注下微服務的缺點
微服務的缺點：
1，整體複雜度更高。微服務根本上說是一個分佈式系統。開發者需要選擇和實現基於消息或者 RPC 的進程間通信機制。雖然這個有很多框架可供選擇，並不需要從頭實現。但是整體上的代碼複雜度是提高了。
2，事務。如上面所說，微服務架構上每個業務有自己的數據庫。以前在單體應用中很好解決的事務問題，現在變得很困難。在基於微服務的應用程序中，需要更新不同服務所用的數據庫。通常不會選擇分佈式事務，不僅僅是因為 CAP 定理。他們根本不支持如今高度可擴展的 NoSQL 數據庫和消息代理。最後不得不使用基於最終一致性的方法，這對於開發人員來說更具挑戰性。
3，測試微服務應用程序也很複雜。例如，使用 Spring Boot，我只需要編寫一個測試類來啟動一個單體 web 應用程序並測試其 REST API。相比之下，一個類似的測試類對於微服務來說需要啟動該服務及其所依賴的所有服務，或者至少要做服務mock，雖然這不是一件高深的事情，但不要低估了這多出來的工作量和複雜度。