單服務架構與微服務架構優缺點

你們好,今天咱們來比較一下單服務架構和微服務架構。程序員

若是你在作網絡應用開發程序的話,你必定考慮過到底用單服務架構仍是微服務架構。總的來講,無論你採用哪一種架構,你均可以寫出很是完美的網絡應用程序來。數據庫

那麼這兩種架構到底哪個更好一些呢?回答這個問題以前,首先要看你網絡應用程序的功能需求。json

【單服務架構開發速度快】安全

單服務架構是一直以來的傳統服務器架構, 它在一臺服務器上運行,而後由單一的程序提供服務。服務器

這種服務架構的好處,開發速度快,運行效率高。開始的時候你能夠寫出最基礎的運行工做流程來,而後在之後的擴展中不斷的添加功能。網絡

【單服務架構運行速度快】架構

單服務架構爲何比微服務架構快?那是由於單服務架構沒有多餘的服務之間的通訊。像微服務架構,裏面有不少微服務,它們之間的通訊都是經過HTTP來進行的,若是你用微服務系統的話,這是不可避免的。單服務架構則不須要這一部分額外的性能消耗。併發

簡單的講,就是單服務架構的程序是運行在一個程序空間裏面的,程序裏面的數據共享是在程序空間以內進行的。那固然速度就很快了。框架

具體來說,就是單服務架構會有一個統一的數據庫,每一個功能模塊,好比說用戶驗證,訂單管理,產品管理等等,都會訪問一個數據庫。微服務

由於是共用一個數據庫,那麼它們就會裝在一臺服務器上共享一套操做系統和文件系統。

【微服務架構系統的特色】

下面來看一下微服務架構系統。

微服務架構系統中,每個服務都是一個單獨的程序空間,好比說用戶管理是一個單獨的程序空間,訂單管理也是一個單獨的程序空間,產品管理也是一個單獨的程序空間。這些程序空間能夠有本身的獨有數據庫,甚至每一個程序空間均可以跑在單獨的服務器上。

那麼這些服務是怎麼工做的呢?好比說,用戶在進入網站以前,首先要調用用戶管理服務,檢查是否登陸成功了。若是登陸成功之後就能夠拿着得到的token, 去訂單管理那邊拿數據,從而能夠獲取本身的訂單,也能夠進行下訂單等操做。這些服務之間的交互都是經過HTTP的通訊方式來進行的。

通訊的方式的載體通常是用json數據做爲統一格式。

【單服務架構系統在容錯性的缺點】

那麼咱們來看一下單服務架構會有什麼問題呢?單服務架構的主要問題就是做爲一臺服務器上跑着的一個程序空間,你在修改某個部分的時候須要經過完整測試,從而保證全部的程序模塊均可以安全的正常的運行。若是你的程序有某一部分寫的不是很好的話,可能會影響到總體的運行。

特別是當你的服務框架很是龐大,你的程序規模很是龐大的話。一點小小的改動,可能要從新編譯全部的程序,而且從新部署全部的程序,要知道單服務架構的整個程序空間是跑在一個進程裏面的。

【微服務架構系統容錯性的優勢】

那麼微服務架構,是怎麼作的呢?單服務架構系統,由於把全部的部分都分紅單獨的程序空間,也就是單獨的進程。這樣能夠把每個部分部署到單獨的服務器上。

這樣你在修改一部分的時候,只須要部署這一部分,只會影響到你當前的這個程序空間,不會影響到其餘的部分。

測試方面來講,微服務架構的每一個單獨的服務是能夠進行單獨測試的。

在運行的過程當中,微服務架構中的某個服務,若是失敗了的話,還能夠有替代品。這樣整個服務並不會失敗。若是沒有替代服務的話,直接返回,當前的頁面不存在就能夠了。

可是在單服務架構系統中,若是某一部分失敗的話,會致使整個服務程序都沒法運行了。由於單服務架構系統中只有一個進程,這個進程死掉了,固然全部的相關服務都不能運行了。

【微服務架構系統可擴展性和可重用性的優勢】

用微服務的最大好處就是你能夠無限的添加各類的服務, 能夠無限的擴展你的程序。

還有一個好處就是微服務可重用性。能夠把現有的服務模塊進行從新組合,再添加幾個新模塊作成一個新的程序應用來。

也就是說微服務架構的程序,重用起來的話,更容易一些,幾乎不須要改動現有的代碼了。

【開發模式不一樣】

開發模式上來講,單服務架構系統由於是一個程序,因此只能選一種技術來開發,若是你有足夠的人手,可以很快的完成任務,保證項目質量是沒有問題的, 而且必定要解決好協同工做的問題。

微服務架構,由於每一個服務都是比較獨立的,開發人員能夠專門攻克某一個服務,能夠用不一樣的技術來開發。固然對一個服務來講,只能用一種技術了。這種模式能夠實現多個程序員同時併發的工做互不影響。每一個程序員只須要負責某個服務的質量就能夠了。

因此綜上所述,至於選哪種架構取決於以下幾個因素:

你工程的規模怎麼樣?

工程的進度是否是很趕?

多長時間想把這個項目作出來?

工程的預算有多少錢?

開發者的水平怎麼樣?

後期的可擴展性是怎樣的要求?

相關文章
相關標籤/搜索