體系化認識微服務之二:如何實施微服務架構

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

按業務組織團隊

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

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

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

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

服務拆分

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

哪些服務要拆分

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

服務怎麼拆分

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