大家好，今天我們來比較一下單服務架構和微服務架構。
如果你在做網絡應用開發程序的話，你一定考慮過到底用單服務架構還是微服務架構。總的來說，不管你采用哪種架構，你都可以寫出非常完美的網絡應用程序來。
那么這兩種架構到底哪一個更好一些呢？回答這個問題之前，首先要看你網絡應用程序的功能需求。
【單服務架構開發速度快】
單服務架構是一直以來的傳統服務器架構， 它在一台服務器上運行，然后由單一的程序提供服務。
這種服務架構的好處，開發速度快，運行效率高。開始的時候你可以寫出最基礎的運行工作流程來，然后在以后的擴展中不斷的添加功能。
【單服務架構運行速度快】
單服務架構為什么比微服務架構快？那是因為單服務架構沒有多余的服務之間的通信。像微服務架構，里面有很多微服務，它們之間的通信都是通過HTTP來進行的，如果你用微服務系統的話，這是不可避免的。單服務架構則不需要這一部分額外的性能消耗。
簡單的講，就是單服務架構的程序是運行在一個程序空間里面的，程序里面的數據共享是在程序空間之內進行的。那當然速度就很快了。
具體來講，就是單服務架構會有一個統一的數據庫，每個功能模塊，比如說用戶驗證，訂單管理，產品管理等等，都會訪問一個數據庫。
因為是共用一個數據庫，那么它們就會裝在一台服務器上共享一套操作系統和文件系統。
【微服務架構系統的特點】
下面來看一下微服務架構系統。
微服務架構系統中，每一個服務都是一個單獨的程序空間，比如說用戶管理是一個單獨的程序空間，訂單管理也是一個單獨的程序空間，產品管理也是一個單獨的程序空間。這些程序空間可以有自己的獨有數據庫，甚至每個程序空間都可以跑在單獨的服務器上。
那么這些服務是怎么工作的呢？比如說，用戶在進入網站之前，首先要調用用戶管理服務，檢查是否登錄成功了。如果登錄成功以后就可以拿着獲得的token， 去訂單管理那邊拿數據，從而可以獲取自己的訂單，也可以進行下訂單等操作。這些服務之間的交互都是通過HTTP的通信方式來進行的。
通信的方式的載體一般是用json數據作為統一格式。
【單服務架構系統在容錯性的缺點】
那么我們來看一下單服務架構會有什么問題呢？單服務架構的主要問題就是作為一台服務器上跑着的一個程序空間，你在修改某個部分的時候需要通過完整測試，從而保證所有的程序模塊都可以安全的正常的運行。如果你的程序有某一部分寫的不是很好的話，可能會影響到整體的運行。
特別是當你的服務框架非常龐大，你的程序規模非常龐大的話。一點小小的改動，可能要重新編譯所有的程序，並且重新部署所有的程序，要知道單服務架構的整個程序空間是跑在一個進程里面的。
【微服務架構系統容錯性的優點】
那么微服務架構，是怎么做的呢？單服務架構系統，因為把所有的部分都分成單獨的程序空間，也就是單獨的進程。這樣可以把每一個部分部署到單獨的服務器上。
這樣你在修改一部分的時候，只需要部署這一部分，只會影響到你當前的這個程序空間，不會影響到其他的部分。
測試方面來說，微服務架構的每個單獨的服務是可以進行單獨測試的。
在運行的過程中，微服務架構中的某個服務，如果失敗了的話，還可以有替代品。這樣整個服務並不會失敗。如果沒有替代服務的話，直接返回，當前的頁面不存在就可以了。
但是在單服務架構系統中，如果某一部分失敗的話，會導致整個服務程序都無法運行了。因為單服務架構系統中只有一個進程，這個進程死掉了，當然所有的相關服務都不能運行了。
【微服務架構系統可擴展性和可重用性的優點】
用微服務的最大好處就是你可以無限的添加各種的服務， 可以無限的擴展你的程序。
還有一個好處就是微服務可重用性。可以把現有的服務模塊進行重新組合，再添加幾個新模塊做成一個新的程序應用來。
也就是說微服務架構的程序，重用起來的話，更容易一些，幾乎不需要改動現有的代碼了。
【開發模式不同】
開發模式上來說，單服務架構系統因為是一個程序，所以只能選一種技術來開發，如果你有足夠的人手，能夠很快的完成任務，保證項目質量是沒有問題的, 並且一定要解決好協同工作的問題。
微服務架構，因為每個服務都是比較獨立的，開發人員可以專門攻克某一個服務，可以用不同的技術來開發。當然對一個服務來說，只能用一種技術了。這種模式可以實現多個程序員同時並發的工作互不影響。每個程序員只需要負責某個服務的質量就可以了。
所以綜上所述，至於選哪一種架構取決於如下幾個因素：
你工程的規模怎么樣？
工程的進度是不是很趕？
多長時間想把這個項目做出來？
工程的預算有多少錢？
開發者的水平怎么樣？
后期的可擴展性是怎樣的要求？