微服務與無服務器知識大放送
- 作者：新網
- 來源：新網
- 瀏覽：100
- 2018-05-03 13:26:08
是分布式一體化還是微服務？
如今，大多數人想到單個微服務時，他們想到的是一個獨立的服務組件。在大多數情況下，微服務被構建為應用，專注于處理好一件事情。最重要的是，這種服務可以獨立于其他服務進行升級和部署。
是分布式一體化還是微服務?
<
div>如今，大多數人想到單個微服務時，他們想到的是一個獨立的服務組件。在大多數情況下，微服務被構建為應用，專注于處理好一件事情。最重要的是，這種服務可以獨立于其他服務進行升級和部署。
現在，如果說到傳統的CQRS實施，如果由于組件相互分離就稱之為微服務，似乎有些不妥。因此我們得問一句：可以將CQRS應用視為微服務嗎?或者換種說法，可以像某些開發人員那樣，開始稱之為分布式一體化嗎?對于這個問題，不同的人會有不同的答案。微服務主要是讓小型獨立團隊有能力持續交付功能，作為其他微服務組成的更大生態系統的一部分。
如果與大多數微服務部署相比，CQRS部署是十分復雜的。對于微服務團隊來說，能夠持續將功能交付至生產是目標。由于CQRS中分離的組件仍可以獨立部署，我們可以說每個部署單元仍可滿足獨立將功能交付至生產的最低要求。微服務的一個功能應該始終需要且最多一個可部署單元。當交付一項功能時需要同時協調部署多個單獨組件，就會產生所謂的分布式一體化。
無服務器也稱為FaaS(功能即服務)，可讓您在不需要設置或管理應用服務器或
容器的情況下，將代碼部署為功能。無服務器是一種新型架構風格，在構建和運行
云原生應用方面越來越受到關注。使用無
服務器功能的一個顯著優勢是，事件概念被優先處理。
有很多人以為，微服務和無服務器不兼容，彼此的架構風格完全不同。但是回想一下前面提到的CQRS你就會明白，這種想法是錯誤的。讓我們來看一個場景，你認為在此場景中微服務的邊界在哪里?
一種方法是認為微服務的邊界就是團隊的邊界。只要一個團隊可以獨立、連續地將特性部署為功能，那么微服務的邊界就只是負責為團隊擁有的特性提供支持的功能子集。
權衡
要采用微服務和無服務器相結合的方法，需要您仔細權衡多項內容，讓我們來看看需要注意的事項。
速度
對于微服務來說，速度就是目標。我們可以通過關注以下兩個問題來衡量速度，平均時間越低，團隊交付功能的速度就越快。：
開發人員改變一行代碼并將其安全地部署到生產中的速度有多快?
新開發人員快速上手并安全地更改代碼庫的速度有多快?
無服務器具有學習曲線，但有助于提高微服務的速度。它將大量工作流程管理從核心組件移出，放入獨立升級和部署的小型可組合功能中，從而提高速度。這在最大程度上縮短了開發人員了解單個功能的工作原理以及如何安全更改所需的時間。
無服務器功能也易于升級或部署，但可能會讓了解整體系統更加復雜。將數百個無服務器功能作為一個整體來管理，這聽起來就有點頭大。
復雜性
軟件中的復雜性無可避免，隨著代碼庫逐漸老化，復雜性也隨時間增加。當復雜性增加，或者當框架或語言過時的時候，一體化應用就變得笨重、難以改變。微服務器將這種復雜性分解到分布式系統中，其中的每個可部署單元都易于理解，易于由一小部分敏捷開發人員進行更改。
以上就是我們的今日分享。
京公網安備11030102000056號
京ICP備09061941號-4 
商品已成功加入購物車
