微服務架構優缺點

以前轉載過一篇對 Martin Fowler 大師寫的微服務架構的說明文章:《微服務(Microservices)》。今天再轉載一篇對於這個架構的優缺點進行總結的文章。html

轉載自:《微服務,讓開發過程更簡單仍是更復雜?》、《有關微服務架構的爭論:更簡單仍是更復雜?》。數據庫

 


 

隨着DevOps、持續交付等理念的深刻人心,微服務架構開始走進咱們的視野。編程

那麼微服務是業界期待已久的解決方案麼?或者說微服務要比總體解決方案更加簡單?網絡

讓咱們先對微服務下個定義:架構

微服務是用一組小服務的方式來構建一個應用,服務獨立運行在不一樣的進程中,服務之間經過輕量的通信機制(如RESTful接口)來交互,而且服務能夠經過自動化部署方式獨立部署。正由於微服務架構中,服務之間是相互獨立的,因此不一樣的服務可使用不一樣的語言來開發,或者根據業務的需求使用不一樣類型的數據庫。運維

來自ThoughtWorks的James Lewis和Martin Fowler分享了他們對微服務架構的理解以及見解。文章中做者詳細介紹了微服務的特色以及相對於傳統架構的微服務架構的優點。異步

微服務的一些優點是顯而易見的:編程語言

  1. 服務簡單,只關注一個業務功能
    在James看來,傳統的總體風格的架構在構建部署和擴展伸縮方面有很大的侷限性,其服務端應用就像是一塊鐵板,笨重且不可拆分,系統中任何程序的改變都須要整個應用從新構建和部署新版本。在進行水平擴展時也只能整個系統擴展,而不能針對某一個功能模塊進行擴展。
    而微服務架構將系統以組件化的方式分解爲多個服務,服務之間相對獨立且鬆耦合,單一功能的改變只須要從新構建部署相應的服務便可。
  2. 每一個微服務可由不一樣團隊開發
    傳統的開發模式在分工時每每以技術爲單位,好比UI團隊、服務端團隊和數據庫團隊,這樣的分工可能會致使任何功能上的改變都須要跨團隊溝通和協調。而微服務則倡導圍繞服務來分工,不一樣的服務能夠採用不一樣的技術來實現,一個團隊中應該包含開發所需的全部技能,好比用戶體驗、數據庫、項目管理。
  3. 微服務是鬆散耦合的
    微服務架構拋棄了ESB複雜的業務規則編排、消息路由等功能,微服務架構中服務是高內聚的,每一個服務都會處理相應的業務,全部的業務邏輯應該儘可能在服務內部處理,且服務間的通訊儘量的輕量化,好比使用Restful的方式。
  4. 可用不一樣的編程語言與工具開發
    傳統的軟件開發中常常會使用同一個技術平臺來解決全部的問題,而經驗代表使用合適的工具作合適的事情會讓開發變得事半功倍。微服務架構天生就具備這樣的特性,咱們可使用Node.js來開發一個簡單的報表頁面,使用C++來編寫一個實時聊天組件。

微服務架構的引入爲多樣化持久保存數據提供可能,持久層可使用傳統關係數據庫和NoSQL。不一樣於傳統的應用,微服務架構中,咱們能夠爲每一個服務選擇一個新的適合業務邏輯的數據庫系統,好比MongoDB、PostgreSQL。這樣作的好處是顯而易見的,首先咱們能夠根據業務類型(讀多仍是寫多等)來決定使用哪一種類型的數據庫,其次這樣能夠減少單個數據庫的負載。
James的文章在社區引發了普遍的討論,Contino公司的CTO Benjamin Wootton撰文表示微服務並無想象中的那麼好,並建議開發者在選用此架構時必定要慎重。Benjamin認爲微服務架構時可能會面臨下面一些挑戰:分佈式

  1. 運維開銷
    更多的服務也就意味着更多的運維,產品團隊須要保證全部的相關服務都有完善的監控等基礎設施,傳統的架構開發者只須要保證一個應用正常運行,而如今卻須要保證幾十甚至上百道工序高效運轉,這是一個艱鉅的任務。
  2. DevOps要求
    使用微服務架構後,開發團隊須要保證一個Tomcat集羣可用,保證一個數據庫可用,這就意味着團隊須要高品質的DevOps和自動化技術。而如今,這樣的全棧式人才不多。
  3. 隱式接口
    服務和服務之間經過接口來「聯繫」,當某一個服務更改接口格式時,可能涉及到此接口的全部服務都須要作調整。
  4. 重複勞動
    在不少服務中可能都會使用到同一個功能,而這一功能點沒有足夠大到提供一個服務的程度,這個時候可能不一樣的服務團隊都會單獨開發這一功能,重複的業務邏輯,這違背了良好的軟件工程中的不少原則。
  5. 分佈式系統的複雜性
    微服務經過REST API或消息來將不一樣的服務聯繫起來,這在以前可能只是一個簡單的遠程過程調用。分佈式系統也就意味着開發者須要考慮網絡延遲、容錯、消息序列化、不可靠的網絡、異步、版本控制、負載等,而面對如此多的微服務都須要分佈式時,整個產品須要有一整套完整的機制來保證各個服務能夠正常運轉。
  6. 事務、異步、測試面臨挑戰
    跨進程之間的事務、大量的異步處理、多個微服務之間的總體測試都須要有一整套的解決方案,而如今看起來,這些技術並無成熟。

總而言之,微服務架構有不少吸引人的地方,不過在擁抱微服務以前要認清它所帶來的挑戰。而每一種架構都有其優缺點,咱們須要根據項目業務和團隊狀況來選擇合適的架構。微服務

相關文章
相關標籤/搜索