微服務架構的特色

相對於單體式應用,微服務有以下優勢

技術異構性

在單體架構下,會很是依賴於項目一開始對技術的選擇,一旦選擇了個技術棧,以後幾年都會被綁定在這樣個技術棧下,很難應對變化。給咱們提供了一個更細粒度使用技術的可能在不一樣的服務裏可使用徹底不一樣的技術棧不一樣的語言、框架甚至數據庫,真正作到用最適合的技術解決最適合的問題,從而讓咱們能夠更加敏捷地響應需求和市場的變化提升了競爭力。數據庫

彈性

彈性彈性工程學的一個關鍵概念是艙壁。若是系統中的一個組件不可用了,但並無致使級聯故障,那麼系統的其餘部分還能夠正常運行。服務邊界就是一個很顯然的艙壁。在單塊系統中,若是服務不可用,那麼全部的功能都會不可用。對於單塊服務的系統而言,能夠經過將一樣的實例運行在不一樣的機器上來下降功能徹底不可用的機率,然而微服務系統自己就可以很好地處理服務不可用和功能降級問題。架構

擴展

龐大的單塊服務只能做爲一個總體進行擴展即便系統中只有一小部分存在性能問題,也須要對整個服務進行擴展。若是使用較小的多個服務,則能夠只對須要擴展的服務進行擴展,這樣就能夠把那些不須要擴展的服務運行在更小的、性能稍差的硬件上。框架

簡化部署

在有幾百萬行代碼的單塊應用程序中,即便只修改了一行代碼,也須要從新部署整個應用程序纔可以發佈該變動。這種部署的影響很大、風險很高,所以相關千系人不敢輕易作部署。因而在實際操做中,部署的頻率就會變得很低。這意味着在兩次發佈之間咱們對軟件作了不少功能加強,但直到最後一刻才把這些大量的變動一次性發布到生產環境中。這時,另一個問題就顯現出來了:兩次發佈之間的差別越大,出錯的可能性就更大在微服務架構中,各個服務的部署是獨立的這樣就能夠更快地對特定部分的代碼進行部署。若是真的出了問題,也只會影響一個服務,而且容易快速回滾,這也意味着客戶能夠更快地使用咱們開發的新功能。 Amazon和 Netflix等組織採用這種架構主要就是基於上述考慮。這種架構很好地清除了軟件發佈過程當中的種種障礙。微服務部署領域的技術在過去幾年時間裏發生了巨大的變化,第6章會對該話題作更深刻的討論。分佈式

與組織結構相匹配

咱們經歷過太多因爲團隊和代碼庫過大引發問題的狀況。當團隊是分佈式的時候,問題會更明顯。咱們也知道在小型代碼庫上工做的小團隊更加高效。微服務

可組合性/組件化

分佈式系統和麪向服務架構聲稱的主要好處是易於重用已有功能。而在微服務架構中,根據不一樣的目的,人們能夠經過不一樣的方式使用同一個功能,在考慮客戶如何使用該軟件時這一點尤爲重要。單純考慮桌面網站或者移動應用程序的時代已通過去了。如今咱們須要考慮的應用程序種類包括Web、原生應用、移動端Web、平板應用及可穿戴設備等,針對每一種都應該考慮如何對已有功能進行組合來實現這些應用。如今不少組織都在作總體考慮,拓展他們與客戶交互的渠道,同時也須要相應地調整架構來輔助這種變化的發生。在微服務架構中,系統會開放不少接縫供外部使用。當狀況發生改變時,可使用不一樣的方式構建應用,而總體化應用程序只能提供一個很是粗粒度的接縫供外部使用。若是想要獲得更有用的細化信息,你須要使用榔頭撬開它!第5章會討論如何將已有的單塊應用程序分解成爲多個微服務,而且達到可重用、可組合的目的。組件化

對可替代性的優化

若是你在一個大中型組織工做,極可能接觸過一些龐大而醜陋的遺留系統。這些系統無人敢碰,卻對公司業務的運營相當重要。更糟糕的是,這些程序是使用某種奇怪的Fortran變體編寫的,而且只能運行在25年前就應該被淘汰的硬件上。爲何這些系統直到如今尚未被取代?其實你很清楚答案工做量很大,並且風險很高。當使用多個小規模服務時,從新實現某一個服務或者是直接刪除該服務都是相對可操做的。想一想看,在單塊系統中你是否會在一天內刪掉上百行代碼,而且確信不會引起問題?微服務中的多個服務大小類似,因此重寫或移除一個或者多個服務的阻礙也很小。使用微服務架構的團隊能夠在須要時輕易地重寫服務,或者刪除再也不使用的服務。當個代碼庫只有幾百行時,人們也不會對它有太多感情上的依賴,因此很容易替換它。性能

其餘

  • 每一個微服務相對較小,開發者易於理解, IDE處理效率快,利於提升勞動生產率,Web容器壓力小,容器啓動速度快,易於提供勞動生產率和生產環境部署速度。
  • 每一個微服務均可以獨立部署,簡化了部署新服務版本的流程。
  • 於規模化開發,多個開發團隊能夠並行開發,每一個團隊負責一項服務。這意味着,對於開發這而言,僅須要瞭解本身負責的一部分業務邏輯便可,然而這對於開發者並不必定是好事情。
  • 改善故障隔離。一個服務宕機不會影響其餘的服務。

微服務架構的不足

  • 微服務強調了服務的大小,但實際上這並無一個贊成的標準。
  • 微服務架構帶來了分佈式數據庫事物,以及分佈式系統架構。分佈式系統相對於單體應用更加複雜。因爲CAP原理的約束,使得咱們不得不放棄傳統的強一致性,而是轉而追求最終一致性。
  • 微服務架構對測試也帶了很大的挑戰。測試人員須要構建部署複雜的分佈式應用進行測試。
相關文章
相關標籤/搜索