微服務作為一種架構風格，其主要特點是由很多小的服務組成，且每個服務都是可獨立部署的，任何 一個服務的升級部署都不會影響其他的服務。那麼在企業中如何實施 微服務這種架構呢？

按業務組織團隊

康威法則：設計系統的組織，其產生的架構設計等價於族之間的溝通架構。
在以往傳統的軟體架構中，所有的功能都是在一個單體系統中完成的，每個團隊都可以在上面修改程式碼，開發測試部署也比較方面。但是隨著業務的擴充套件和功能的不斷迭代，單體系統越來越難以維護，故障率不斷上升。

康威法則其實解決的是多團隊並行開發的痛點，不同的業務有不同的團隊維護，每個團隊維護他們自己的服務，團隊的邊界會更加清晰，開發效率也會大幅提升。

按業務組織團隊帶來的結果是，每個需求的開發都是按產品進行交付的。也就是說需求的開發是跨團隊的，這個團隊會有各個職能部門的同學，比如產品經理、工程師、測試、DBA、運維等角色。

微服務產品交付流程如下：

第一階段：產品經理會組織需求評審，明確這個產品要做什麼，如果需求比較會先進行可能性評審
第二階段：由於最終是以產品進行交付的，在實際開發中會明確一個專案負責人，他會給出這個產品的技術文件，明確每個人要做什麼以及怎麼做的問題
第三階段：給出方案後，不同職能部門的人員各自進行開發
第四階段：開發完畢後，把產品（一般會有多個專案，每個專案不同的分支）交付給測試人員進行測試
第五階段：測試完後，把產品交付給運維進行構建部署
第六階段：運維構建部署後，開發人員釋出上線
第七階段：線上觀察反饋，驗證產品質量。如果有問題，產品重新提需求，進入一個閉環

服務拆分

單體應用要改成微服務架構的首要問題是，有哪些服務或者模組是要拆分出去，並且哪些服務要歸屬到各個業務團隊；這些眾多的服務要怎麼拆分。

哪些服務要拆分

所有的服務按照業務維度可以分為兩種：業務相關和業務無關的服務。
業務無關的服務包括儲存基礎服務、公共服務。儲存基礎服務又可以分為資料庫、快取。公共服務分為簡訊服務、郵件服務、地圖服務等。
業務相關的包括領域服務、儲存領域服務。這裡儲存服務包括業務無關的服務，比如贈增刪改查，又包括特定條件查詢服務等和業務相關的儲存服務。

服務怎麼拆分

將需要拆分的服務梳理後還有一個問題要解決，這些服務怎麼拆分。我們按照從底層到上層的方法拆分不同的服務，從底層到上層分別為：資料層服務、業務服務。
資料層服務是與業務無關的服務，把底層訪問資料的細節以服務的方式提供出去，例如我們拆分出了經緯度服務、地圖服務業務、城市服務等底層資料服務。業務服務是核心服務，把資料層服務+業務邏輯組合起來構成業務服務，業務服務把底層訪問資料層的服務遮蔽起來，呼叫方不用關心具體細節，例如我們把訂單和商家分為兩個業務服務，按照業務的領域可以分為更多的業務服務。