開門見山，一圖勝千言，先來看看單體架構跟微服務架構的區別？
單體服務架構，將所有的功能模塊(service)打包到一起並放在一個web容器中運行。
微服務架構，就是將復雜臃腫的單體應用進行細粒度的服務拆分，每個微服務可以交給小的團隊進行開發和維護，拆分出來的服務各自獨立打包部署。
這兩種架構各有優缺點：
我之前工作過的幾個公司，基本都是單體架構，頂多加一個負載均衡。很多人都有疑問，我們公司的產品是不是適合微服務架構？我們有沒有能力把現在的單體架構重構為微服務架構？
我覺得，如果公司打算做一個新的產品，團隊有這個技術儲備，並且公司的業務量在短期內會有一個大的提升，那么嘗試微服務架構會是一個明智的選擇。
但是如果公司的業務已經積累了很多年，並且現在已經有很多獨立的業務系統。我們可以把這樣的架構叫做“煙囪式架構”，每個業務系統像煙囪一樣搞搞聳立，並且系統間的交互錯綜復雜，那么可以把單體架構改造成微服務架構嗎？如何做呢？
單體應用改造成微服務架構，需要各個功能模塊服務化，通俗地講，服務化，就是將傳統的單體應用中通過jar包依賴方法調用，改造成通過RPC接口遠程調用的方式。
如果已有的多個業務系統已經上線運行，那么改造起來確實需要費點力氣。從單體到微服務的拆分過程，拆分微服務先要把業務梳理清楚，做到心中有數，梳理清楚了那么業務的邊界自然清晰了，自然而然對應拆分哪些服務也出來了。新的需求自然放到拆分的微服務，老的邏輯，按照優先級和重要程度一個點一個點的從單體遷移微服務，服務化上線之后，漸漸取代老的單體，等全部拆分完畢，線上穩定之后，自然就可以下掉老的單體應用。
了解了微服務的概念后，我再提一個概念“中台服務架構”，中台服務架構的思想是伴隨着企業規模不斷擴大、業務多元化而形成的。我理解中台服務架構是微服務架構的升級。
如阿里巴巴將集團20多個核心業務中公共的、通用的業務以服務的方式沉淀到了共享業務事業部，這套共享服務體系為阿里巴巴集團的核心業務賦能，真正發揮服務重用的價值。
作為一種組織架構模式，“中台”突出的是規划控制和協調的能力，而“前台”強調的是創新和靈活多
變。同樣的，引申並運用到電商設計概念中，這是一種快速設計和迭代的方法。“中台”突出整個設計的總體和協調性，而“前端”強調設計的創新和適應性，又或者說差異化。