微服務架構的特點

在單體架構下,會非常依賴於專案一開始對技術的選擇,一旦選擇了個技術棧,之後幾年都會被繫結在這樣個技術棧下,很難應對變化。給我們提供了乙個更細粒度使用技術的可能在不同的服務裡可以使用完全不同的技術棧不同的語言、框架甚至資料庫,真正做到用最適合的技術解決最適合的問題,從而讓我們可以更加敏捷地響應需求和市場的變化提高了競爭力。

彈性彈性工程學的乙個關鍵概念是艙壁。如果系統中的乙個元件不可用了,但並沒有導致級聯故障,那麼系統的其他部分還可以正常執行。服務邊界就是乙個很顯然的艙壁。在單塊系統中,如果服務不可用,那麼所有的功能都會不可用。對於單塊服務的系統而言,可以通過將同樣的例項執行在不同的機器上來降低功能完全不可用的概率,然而微服務系統本身就能夠很好地處理服務不可用和功能降級問題。

龐大的單塊服務只能作為乙個整體進行擴充套件即使系統中只有一小部分存在效能問題,也需要對整個服務進行擴充套件。如果使用較小的多個服務,則可以只對需要擴充套件的服務進行擴充套件,這樣就可以把那些不需要擴充套件的服務執行在更小的、效能稍差的硬體上。

在有幾百萬行**的單塊應用程式中，即使只修改了一行**,也需要重新部署整個應用程式才能夠發布該變更。這種部署的影響很大、風險很高,因此相關千系人不敢輕易做部署。於是在實際操作中,部署的頻率就會變得很低。這意味著在兩次發布之間我們對軟體做了很多功能增強,但直到最後一刻才把這些大量的變更一次性發布到生產環境中。這時,另外乙個問題就顯現出來了:兩次發布之間的差異越大,出錯的可能性就更大在微服務架構中,各個服務的部署是獨立的這樣就可以更快地對特定部分的**進行部署。如果真的出了問題,也只會影響乙個服務,並且容易快速回滾,這也意味著客戶可以更快地使用我們開發的新功能。 amazon和 netflix等組織採用這種架構主要就是基於上述考慮。這種架構很好地清除了軟體發布過程中的種種障礙。微服務部署領域的技術在過去幾年時間裡發生了巨大的變化,第6章會對該話題做更深入的討論。

我們經歷過太多由於團隊和**庫過大引起問題的情況。當團隊是分布式的時候,問題會更明顯。我們也知道在小型**庫上工作的小團隊更加高效。

分布式系統和面向服務架構聲稱的主要好處是易於重用已有功能。而在微服務架構中,根據不同的目的,人們可以通過不同的方式使用同乙個功能,在考慮客戶如何使用該軟體時這一點尤其重要。單純考慮桌面**或者移動應用程式的時代已經過去了。現在我們需要考慮的應用程式種類包括web、原生應用、移動端web、平板應用及可穿戴裝置等,針對每一種都應該考慮如何對已有功能進行組合來實現這些應用。現在很多組織都在做整體考慮,拓展他們與客戶互動的渠道,同時也需要相應地調整架構來輔助這種變化的發生。在微服務架構中,系統會開放很多接縫供外部使用。當情況發生改變時,可以使用不同的方式構建應用,而整體化應用程式只能提供乙個非常粗粒度的接縫供外部使用。如果想要得到更有用的細化資訊,你需要使用榔頭撬開它!第5章會討論如何將已有的單塊應用程式分解成為多個微服務,並且達到可重用、可組合的目的。

如果你在乙個大中型組織工作,很可能接觸過一些龐大而醜陋的遺留系統。這些系統無人敢碰,卻對公司業務的運營至關重要。更糟糕的是,這些程式是使用某種奇怪的fortran變體編寫的,並且只能執行在25年前就應該被淘汰的硬體上。為什麼這些系統直到現在還沒有被取代?其實你很清楚答案工作量很大,而且風險很高。當使用多個小規模服務時,重新實現某乙個服務或者是直接刪除該服務都是相對可操作的。想想看,在單塊系統中你是否會在一天內刪掉上百行**,並且確信不會引發問題?微服務中的多個服務大小相似,所以重寫或移除乙個或者多個服務的阻礙也很小。使用微服務架構的團隊可以在需要時輕易地重寫服務,或者刪除不再使用的服務。當個**庫只有幾百行時,人們也不會對它有太多感情上的依賴,所以很容易替換它。

微服務架構的特點

微服務與微服務架構

微服務架構

微服務架構

相關推薦