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

你們好，今天咱們來比較一下單服務架構和微服務架構。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【開發模式不一樣】

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

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

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

你工程的規模怎麼樣？

工程的進度是否是很趕？

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

工程的預算有多少錢？

開發者的水平怎麼樣？

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