單體架構&微服務架構&中臺服務架構

開門見山，一圖勝千言，先來看看單體架構跟微服務架構的區別？

單體服務架構，將所有的功能模組(service)打包到一起並放在一個web容器中執行。
微服務架構，就是將複雜臃腫的單體應用進行細粒度的服務拆分，每個微服務可以交給小的團隊進行開發和維護，拆分出來的服務各自獨立打包部署。

這兩種架構各有優缺點：

我之前工作過的幾個公司，基本都是單體架構，頂多加一個負載均衡。很多人都有疑問，我們公司的產品是不是適合微服務架構？我們有沒有能力把現在的單體架構重構為微服務架構？

我覺得，如果公司打算做一個新的產品，團隊有這個技術儲備，並且公司的業務量在短期內會有一個大的提升，那麼嘗試微服務架構會是一個明智的選擇。

但是如果公司的業務已經積累了很多年，並且現在已經有很多獨立的業務系統。我們可以把這樣的架構叫做“煙囪式架構”，每個業務系統像煙囪一樣搞搞聳立，並且系統間的互動錯綜複雜，那麼可以把單體架構改造成微服務架構嗎？如何做呢？

單體應用改造成微服務架構，需要各個功能模組服務化，通俗地講，服務化，就是將傳統的單體應用中通過jar包依賴方法呼叫，改造成通過RPC介面遠端呼叫的方式。

如果已有的多個業務系統已經上線執行，那麼改造起來確實需要費點力氣。從單體到微服務的拆分過程，拆分微服務先要把業務梳理清楚，做到心中有數，梳理清楚了那麼業務的邊界自然清晰了，自然而然對應拆分哪些服務也出來了。新的需求自然放到拆分的微服務，老的邏輯按照優先順序和重要程度一個點一個點的從單體遷移微服務，服務化上線之後，漸漸取代老的單體，等全部拆分完畢，線上穩定之後，自然就可以下掉老的單體應用。

瞭解了微服務的概念後，我再提一個概念“中臺服務架構”，中臺服務架構的思想是伴隨著企業規模不斷擴大、業務多元化而形成的。我理解中臺服務架構是微服務架構的升級。

如阿里巴巴將集團20多個核心業務中公共的、通用的業務以服務的方式沉澱到了共享業務事業部，這套共享服務體系為阿里巴巴集團的核心業務賦能，真正發揮服務重用的價值。

作為一種組織架構模式，“中臺”突出的是規劃控制和協調的能力，而“前臺”強調的是創新和靈活多變。同樣的，引申並運用到電商設計概念中，這是一種快速設計和迭代的方法。“中臺”突出整個設計的總體和協調性，而“前端”強調設計的創新和適應性，又或者說差異化。

---

我在微信訂閱號等你！