2014年，Martin Fowler 與 James Lewis 共同提出了微服務的概念，然後微服務就開始火遍大江南北，很多技術團隊和公司開始使用微服務架構，然而，誰用誰痛誰知道，“微服務”絕對不是銀彈。使用“微服務”架構一定要慎重！
什麼是“微服務”？
“微服務”並沒有嚴格意義上的定義和規範，借用一段維基百科上的描述：
微服務 (Microservices) 是一種軟體架構風格，它是以專注於單一責任與功能的小型功能區塊 (Small Building Blocks) 為基礎，利用模組化的方式組合出複雜的大型應用程式，各功能區塊使用與語言無關(Language-Independent/Language agnostic) 的 API集相互通訊。微服務架構運用於軟體架構風格的其中一項概念是甘露運算 (Dew Computing)，意指由許多的小露水(代表微服務的功能元件) 彙集而成的運算能力。
“微服務”架構的優點
哪位看官問，既然“微服務”架構能火遍大江南北，那它一定有它的優勢吧？是的，任何事物能夠存在甚至大熱，都不可能是無緣無故的，必有其道理所在。“微服務”架構自然也不例外！其優點如下：
- 獨立性，每個微服務都可以部署在獨立的物理機、虛擬機器或者Docker上，使其原生具備分散式的架構設計；
- 可擴充套件性，基於其獨立性，可以容易的根據業務或技術線對微服務架構進行水平或垂直擴充套件；
- 可升級性與易維護性，依然基於其獨立性，每個微服務都可獨立進行升級與維護
- 任意程式語言，每一個微服務都可以按照開發團隊自己熟悉的程式語言進行開發，然後按照REST協議或者RPC協議制定API來提供服務
一些團隊看到“微服務”架構的優點就像是找到了救命稻草一般，立即開始實施。結果，他們遇到的是，系統間、服務間的高耦合，導致團隊間協作大打折扣；測試進行整合測試時，需要遍歷整條業務線的多個微服務系統，導致測試用例指數攀升，而測試效果卻不太理想。有一定經驗的看官可能回想，這群人一定是在“微服務”架構劃分的時候做的不夠好，才會耦合度這麼高。可這麼多公司前仆後繼的掉進這個坑裡，你就不得不想這其中的必然性了。讓我們看看對於“微服務”架構的一些誤區。
“微服務”架構的誤區
-
“微服務”架構能夠讓系統結構看起來更清晰和簡潔：
一個簡單的事實，就算是單一系統，只要架構設計合理並嚴格執行程式碼的架構稽核，結構清晰和簡潔一樣很容易做到。一些團隊長期受到現有程式碼架構混亂的蹂躪，拿起“微服務”就來用，其實簡單的程式碼迭代重構在很多情況下是更加可控的選擇。 -
“微服務”架構很容易實現：
首先，“微服務”架構的解耦就夠你受的；其次，不可避免的會在一次請求中涉及多個服務，而多個服務有可能相互依賴，此時分佈在不同微服務的資料很可能是事務性的，這種分散式的事務處理，搞不好就會出大事。 -
“微服務”更快：
不可否認，論到單個微服務的優化，我們可以從減少單個微服務處理的業務型別，使其更加專一等手段來提升其執行效率，但是源自微服務的分散式架構，其網路I/O的代價必須考慮在內，這使得原來在單一系統中程式內部的資訊交換被搬到了網路層，一個不小心，程式效率降低妥妥的。 - 對程式設計師更簡單：
由於微服務往往更專注於一個單一的功能，因此開發人員在處理功能內部問題時，的確會更加簡單一些。但微服務的目的是在整合系統中承擔部分服務，不可避免的要與核心系統或系統的其它部分進行協作互動，而涉及到這方面的問題，不但需要開發人員對涉及的系統有所瞭解，涉及的多個團隊還需要進行同步協助來處理Bug，而可能遇到的一種情況是，人們對於這種Bug缺乏責任感，經常會想方設法的將bug推給其他團隊，溝通成本嚴重影響開發效率。另外，對於測試人員，一點小的改動就有可能需要多個服務的繼承測試，無論從測試用例的複雜度還是測試環境的搭建，都是一件不簡單的事情。
何時使用“微服務”架構
- 當你的系統已經具備很大的規模，整合了大量的服務，可以考慮部分使用“微服務”，千萬不要在專案初期就使用微服務，此時整個系統還很小，隨著系統和業務的不斷成長，系統架構會經歷大量的變更，如果在初期就使用微服務，很容易造成微服務間的強耦合。
- 當你對你的系統具備非常深刻的認識，並且能夠很輕易的劃分出各個功能、服務的邊界，此時可以嘗試考慮“微服務”架構
- “微服務”架構應該以業務劃分為主，業務與業務之間的耦合度可以輕易的看出，以業務進行劃分，系統的耦合度比較可控
- 最後，只有你能真正列出系統遷移到微服務架構的利與弊，並做好了應對之策時，才可以著手實施
如果你有任何問題或建議，可以掃描下方二維碼或者微信搜尋[phpjiagoushier]，關注我的微信公眾號[PHP架構]，參與互動交流。