服務化，SOA，絕對是一個火熱了N年的詞，再加上各大網際網路公司在講各自的技術架構演進時，基本都會提到服務化，這個誘惑的很多人都想對系統做服務化的改造，但你真的需要服務化嗎？

所謂的服務化，是指根據業務的職責劃分為多個系統，系統之間的互動以服務的方式進行，這樣的好處看起來就是系統的職責變得非常清晰。

但其實呢，服務化並不僅僅是一個純粹的技術改造，服務化就意味著業務是由多個系統構成，這個時候首先會產生的第一個核心問題是需要有相應的人員來維護，在服務化之前，通常來說模式都是一個系統，所有的開發共同維護一個系統，而服務化拆成多個系統後，就不可能所有的開發再共同維護了，因此做服務化之前，首先要做的第一點是組織結構的調整要對應的準備好，所以其實如果開發人員不多的話，顯然是沒必要做服務化的，否則連開發的人都不夠分，Jeff Dean在有一次的topic上講到服務化帶來的一個好處：easier to have many engineering offices around the world.

另外，有很多想做服務化的原因是覺得服務化後職責清晰，開發效率更高，但事實上是，服務化後變成了多個系統，很多時候會出現為了實現一個需求，需要改多個系統（儘管服務化本來是希望能減少這種現象，但事實上很難做到），協調多個團隊，而在一個系統的情況下，通常是每個開發都為整個系統負責，所以在實現需求時是可以一個開發搞定，這樣的效率其實通常是更高的，所以其實我始終認為，服務化了以後整個開發效率是一定程度下降的，但好處是它可以支撐很大規模的開發團隊。

所以從上面大家可以看到，服務化是在發展到一定情況下才需要做的，我自己覺得觸發要做服務化的主要原因會是這三個：

1. 底層例如資料庫連線到達上限

系統共用的底層資源在隨著機器增加的越來越多時，一定會成為瓶頸，這種情況下服務化會帶來幫助，當系統邏輯變簡單的情況下，吞吐量自然也比較容易上升，這個時候使用底層資源的機器數自然可以大幅下降。

2. 開發人員規模龐大

當開發人員規模變大(100個左右)時，眾多人共同維護一個系統會變得不可行，這個時候服務化可以產生巨大幫助，也會成為必須做的事情。

3. 業務多元化，共享的業務邏輯多

當業務朝多元化方向發展時，各個業務可能會有很多共享的業務邏輯出現，這個時候服務化會帶來幫助，不過通常業務多元化也會自然帶來開發人員規模龐大，不過這個方式在逐步發展中也會出現一些問題，但總體來說這種情況下服務化還是必須做的。

服務化改造還會帶來其他一些問題，感興趣的可以參見我以前寫過的一篇《服務框架演變過程》，可點選閱讀原文檢視。

如果沒有上面的那些原因的話，我的建議都是能不做服務化的話還是儘量不要做。

所以一個架構師在做架構改造的決定時，最重要的是要考慮全面（各種平衡），很有可能架構改造並不僅僅是技術層面的事，並且需要判斷架構改造發生的合適時間點。