體系化認識微服務之二：如何實施微服務架構
作者：rhwayfun
來源：https://blog.csdn.net/u011116672
微服務作爲一種架構風格，其主要特點是由很多小的服務組成，且每個服務都是可獨立部署的，任何一個服務的升級部署都不會影響其他的服務。那麼在企業中如何實施微服務這種架構呢？
按業務組織團隊
康威法則：設計系統的組織，其產生的架構設計等價於族之間的溝通架構。
在以往傳統的軟件架構中，所有的功能都是在一個單體系統中完成的，每個團隊都可以在上面修改代碼，開發測試部署也比較方面。但是隨着業務的擴展和功能的不斷迭代，單體系統越來越難以維護，故障率不斷上升。
康威法則其實解決的是多團隊並行開發的痛點，不同的業務有不同的團隊維護，每個團隊維護他們自己的服務，團隊的邊界會更加清晰，開發效率也會大幅提升。
按業務組織團隊帶來的結果是，每個需求的開發都是按產品進行交付的。也就是說需求的開發是跨團隊的，這個團隊會有各個職能部門的同學，比如產品經理、工程師、測試、DBA、運維等角色。
微服務產品交付流程如下：
第一階段：產品經理會組織需求評審，明確這個產品要做什麼，如果需求比較會先進行可能性評審
第二階段：由於最終是以產品進行交付的，在實際開發中會明確一個項目負責人，他會給出這個產品的技術文檔，明確每個人要做什麼以及怎麼做的問題
第三階段：給出方案後，不同職能部門的人員各自進行開發
第四階段：開發完畢後，把產品（一般會有多個項目，每個項目不同的分支）交付給測試人員進行測試
第五階段：測試完後，把產品交付給運維進行構建部署
第六階段：運維構建部署後，開發人員發佈上線
第七階段：線上觀察反饋，驗證產品質量。如果有問題，產品重新提需求，進入一個閉環
服務拆分
單體應用要改成微服務架構的首要問題是，有哪些服務或者模塊是要拆分出去，並且哪些服務要歸屬到各個業務團隊；這些衆多的服務要怎麼拆分。
哪些服務要拆分
所有的服務按照業務維度可以分爲兩種：業務相關和業務無關的服務。
業務無關的服務包括存儲基礎服務、公共服務。存儲基礎服務又可以分爲數據庫、緩存。公共服務分爲短信服務、郵件服務、地圖服務等。
業務相關的包括領域服務、存儲領域服務。這裏存儲服務包括業務無關的服務，比如贈增刪改查，又包括特定條件查詢服務等和業務相關的存儲服務。
服務怎麼拆分
將需要拆分的服務梳理後還有一個問題要解決，這些服務怎麼拆分。我們按照從底層到上層的方法拆分不同的服務，從底層到上層分別爲：數據層服務、業務服務。
數據層服務是與業務無關的服務，把底層訪問數據的細節以服務的方式提供出去，例如我們拆分出了經緯度服務、地圖服務業務、城市服務等底層數據服務。業務服務是核心服務，把數據層服務+業務邏輯組合起來構成業務服務，業務服務把底層訪問數據層的服務屏蔽起來，調用方不用關心具體細節，例如我們把訂單和商家分爲兩個業務服務，按照業務的領域可以分爲更多的業務服務。
