就這麼說吧，第一，你一個微服務掛掉了，對整個系統影響比較小。第二，開發的時候，一個人可以單獨負責一個服務。 這是非常明顯的兩個優點，在應對非常複雜的業務的時候，非常適合。所以這種架構適合很龐大的一個系統，當你業務很簡單的時候，就根本不需要考慮那麼多東西了。

先簡單說下從傳統的系統模式到服務化的演進。最早開發一個系統是單體的應用，也就是不管你的系統有多麼複雜，功能有多麼龐大，我們只會開發一個獨立應用。但慢慢發現當系統開發團隊逐漸變大，系統需求不斷增加和變化時，這種方法不論是在專案管理還是在後期擴充套件和運維時都會帶來很多麻煩。比如開發時不同模組的開發人員如何協作，需求變更帶來的程式碼臃腫和晦澀，運維時一個小修改可能帶來重啟的巨大風險等等。

後來架構設計師們就在考慮業務拆分和系統拆分。這就是最初服務化的原型。最直接的拆分肯定是模組的拆分。但是拆分後的系統肯定需要相互依賴和呼叫，所以就延展出了一些介面技術，如Web Service，Restful。但這又進一步帶來了新的問題，由於不同模組可能部署在不用伺服器上，如果伺服器或網路出現問題，可能使相互依賴的系統無法訪問，最終造成雪崩效應，服務徹底癱瘓。

這時SOA架構產生，最早的ESB，後來的分散式，微服務都是慢慢衍生出來的系統架構。首先它進一步拓展了服務化的理念將業務進一步拆分成更小的服務單元，以避免單服務出現問題可能造成的癱瘓風險。其次由於服務分拆的較細，如何進行服務治理，發現註冊服務、解決服務單點故障便成為分散式架構要解決的首要問題。緊接著服務熔斷機制、服務配置中心、服務閘道器路由、服務訊息匯流排以及服務日誌跟蹤等問題逐一得到解決。這也使得整個服務架構更加最佳化和完善，分散式系統已發展成熟並自成體系。

最後說明一下不管是服務化、SOA、分散式，這些系統架構一定不要因為流行而使用，如何使用，使用哪些和使用程度都要取決於你的需求、受眾、使用場景等一系列因素。再好的技術也要用到正確的地方才會發揮更大的作用。

首先要表明一個觀點：脫離業務實際情況的架構都是耍流氓，所以不是所有系統都必須服務化，也不要為了服務化而服務化。

在瞭解服務化的好處之前，讓我們先看看傳統的系統架構是什麼樣的，當了解傳統架構的缺點之後，再去看看為什麼要做服務化，就容易理解了。

在單體服務的時代，我們是一臺應用伺服器，後面掛一臺資料庫。當訪問量增多的時候，會引入負載均衡、資料庫讀寫分離、分庫分表等技術，系統的一個整體的架構大概是這個樣子的：

這種架構，會有什麼樣的痛點呢？我總結了一下，系統在不斷髮展的過程中，可能會遇到下面幾種情況：

資料到處都有：舉個最簡單的例子，如果一個公司對外的系統很多，每個系統都提供使用者註冊的功能，註冊後用戶資訊儲存到自己的系統，當公司內這樣的系統越來越多，問題就會凸顯；

程式碼到處複製：如果資料庫統一了，使用者資訊都儲存到一個數據庫中，開放給各個業務系統操作（事實上幾乎沒有公司會這樣做），這樣帶來的一個問題就是，相同邏輯的程式碼，會分佈在多個系統中；更嚴重的是，程式碼與資料庫的耦合度太高，不易於擴充套件。

程式碼質量無法保障，系統之間相互影響：假如A系統寫了SQL導致全表掃描，資料庫的CPU飆到100%或造成鎖表，那麼影響的不只是一個系統。

這個服務化的過程其實也非常簡單，在例子中，說白了就是把使用者相關的功能單獨做一個系統，並且把對使用者資訊的操作透過介面的方式暴露出來，那麼服務化有什麼好處，到底解決了哪些問題呢？我總結有這麼幾點：

資料統一儲存，業務邏輯集中；

呼叫方很方便，一個功能，只需要呼叫一個介面；如果是RPC的方式實現，就像呼叫本地的一個方法一樣；具體業務邏輯是如何實現的，呼叫方不需要關心；

遮蔽了底層複雜度：用不用快取，資料庫是否需要分庫分表，對呼叫方來說，都是黑盒；

業務邏輯集中，意味著程式碼只有這麼一份，那麼效率和穩定性才有可能得到保證；

當資料被集中在了一起，才能做下一步的處理、分析、預測，才能發揮出資料的價值；

當然，服務化有好處也有壞處，就比如..如果使用者中心掛了，那麼會影響到所有依賴於使用者中心的系統（高可能的要求非常高）。

其實所謂的服務化並不是說一定搞微服務或者雲服務，微服務只是一種架構思維，而是一個目前大部分軟體公司在做的概念:“SaaS”，意思是軟體即服務。

簡單點說，就是軟體開發商並不是賣軟體，而是賣軟體從開發實施到後期執行維護的一整套服務，作為客戶的傳統公司可以不需要僱傭數量大的IT人員就可以享受自己的企業轉向數字化管理。這就是SaaS，軟體不再是賣出去就結束，而是一直賣服務。

當然，服務化從技術層面上可以走微服務，畢竟傳統架構已經滿足不了分散式和高複用性的需求。

這種方式最大的好處是作為賣服務的軟體供應商，可以持續不斷得進行交付，進行收款，盈利比較持續穩定。

對於買服務的企業 可以把重心放在自己企業的核心業務上，不用花過多精力去招聘研發等IT人員去開發維護系統，這也給很多傳統企業數字化轉型提供了非常大的幫助。

因此SaaS算是一種雙贏的存在，也是目前很多軟體公司正在做的事情。

但是實際上，很多企業的SaaS之路並不順利，都在產品化的路上漸行漸遠然後不斷跌倒爬起。

中國各行業資訊化水平參差不齊、差異巨大，但對於大型企業來說，很多資訊化建設已經到了一個轉折期，雖然支撐核心生產、運營、管理、決策的應用系統基本都有了，但是系統間的資訊孤島、資料孤島、業務孤島的情況還是很嚴重的，很多大型企業都在統籌考慮資訊化的治理與最佳化，包括IT治理、資料治理、服務治理、SOA綜合整合等。應用系統間的互聯互通是普遍的需求、也是大勢所趨，對於各業務系統而言就需要對自己的各業務模組提供標準的服務，以保障跟其他相關業務系統的對接，這樣就需要實現資料提供、資料同步、資料分發、資料接收等標準服務介面。

另外一方面，各行業、企業多渠道營銷、產業生態鏈聯動，需要越來越多、越來越快、越來越高頻地跟外部的應用系統接入、聯動，這樣需要眾多靈活多變的功能頁面，如果對每套前端頁面都提供一套後端功能，工作量巨大、且難以及時滿足變化需求。這樣前後端分離的開發模式也是新應用系統開發技術架構的常規選擇，而這種模式直接要求著應用系統的採用服務化模式來開發。

綜上，服務化一方面為了敏捷整合，側重企業IT架構宏觀層面，用於實現IT治理、資料治理、應用整合；另一方面是為了敏捷開發，主要側重應用系統的技術開發架構，實現內外部應用系統快速接入、上下游供應鏈/生態鏈結合。