慎用「微服務」架構

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架構]，參與互動交流。