幾分鐘給你講明白：單服務架構和MicroServices微服務架構的優缺點

大家好，今天我們來比較一下單服務架構和MicroServices微服務架構。

如果你在做網路應用開發程序的話，你一定考慮過到底用單服務架構還是微服務架構。總的來說，不管你採用哪種架構，你都可以寫出非常完美的網路應用程序來。

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

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

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

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

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

單服務架構為什麼比微服務架構快？那是因為單服務架構沒有多餘的服務之間的通信。像微服務架構，裡面有很多微服務，它們之間的通信都是通過HTTP來進行的，如果你用微服務系統的話，這是不可避免的。單服務架構則不需要這一部分額外的性能消耗。

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

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

因為是共用一個資料庫，那麼它們就會裝在一台伺服器上共享一套操作系統和文件系統。

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

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

微服務架構系統中，每一個服務都是一個單獨的程序空間，比如說用戶管理是一個單獨的程序空間，訂單管理也是一個單獨的程序空間，產品管理也是一個單獨的程序空間。這些程序空間可以有自己的獨有資料庫，甚至每個程序空間都可以跑在單獨的伺服器上。

那麼這些服務是怎麼工作的呢？比如說，用戶在進入網站之前，首先要調用用戶管理服務，檢查是否登錄成功了。如果登錄成功以後就可以拿著獲得的token， 去訂單管理那邊拿數據，從而可以獲取自己的訂單，也可以進行下訂單等操作。這些服務之間的交互都是通過HTTP的通信方式來進行的。

通信的方式的載體一般是用json數據作為統一格式。

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

那麼我們來看一下單服務架構會有什麼問題呢？單服務架構的主要問題就是作為一台伺服器上跑著的一個程序空間，你在修改某個部分的時候需要通過完整測試，從而保證所有的程序模塊都可以安全的正常的運行。如果你的程序有某一部分寫的不是很好的話，可能會影響到整體的運行。

特別是當你的服務框架非常龐大，你的程序規模非常龐大的話。一點小小的改動，可能要重新編譯所有的程序，並且重新部署所有的程序，要知道單服務架構的整個程序空間是跑在一個進程裡面的。

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

那麼微服務架構，是怎麼做的呢？單服務架構系統，因為把所有的部分都分成單獨的程序空間，也就是單獨的進程。這樣可以把每一個部分部署到單獨的伺服器上。

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

測試方面來說，微服務架構的每個單獨的服務是可以進行單獨測試的。

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

但是在單服務架構系統中，如果某一部分失敗的話，會導致整個服務程序都無法運行了。因為單服務架構系統中只有一個進程，這個進程死掉了，當然所有的相關服務都不能運行了。

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

用微服務的最大好處就是你可以無限的添加各種的服務， 可以無限的擴展你的程序。

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

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

【開發模式不同】

開發模式上來說，單服務架構系統因為是一個程序，所以只能選一種技術來開發，如果你有足夠的人手，能夠很快的完成任務，保證項目質量是沒有問題的, 並且一定要解決好協同工作的問題。

微服務架構，因為每個服務都是比較獨立的，開發人員可以專門攻克某一個服務，可以用不同的技術來開發。當然對一個服務來說，只能用一種技術了。這種模式可以實現多個程序員同時並發的工作互不影響。每個程序員只需要負責某個服務的質量就可以了。

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

你工程的規模怎麼樣？

工程的進度是不是很趕？

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

工程的預算有多少錢？

開發者的水平怎麼樣？

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

好了，這期就先說這些，這裡是丁哥開講，歡迎關注防止失聯。

推薦閱讀：