使用微服務架構模式的思想對目標系統進行拆分之前，我們需要先明白服務拆分起點和終點，以及需要考慮的因素與堅持的原則。所謂起點就是需要清楚拆分的是已有的項目還是新的項目，如果是已有的項目，那麽這個項目處於什麽樣的架構階段。而終點則是服務拆分後所需達到的架構階段，以及後續擴展性的考慮，畢竟好的架構不是一次性設計出來的，而是不斷進化來的。

不適合使用微服務的業務場景：

• 系統中包含很多很強事務場景的，分布式事務比較難處理，而且由於CAP定律的原因，也無法保證數據的強一致性
• 業務相對穩定，叠代周期長，大半年不需要更新一次版本的，使用微服務意義不大
• 訪問壓力不大，可用性要求不高，例如一些簡單的內部使用的系統

所以說微服務並不是放之四海而皆準的，而且在一些不適合的場景上使用微服務架構只會適得其反，所以我們在考慮架構的時候一定要根據實際的業務場景來設計，否則拋開需求談架構，不就是在耍流氓嗎

康威定律與微服務

微服務可以說是近兩年來非常火的新概念，大家都在追，也都覺得很對，但是似乎沒有很充足的理論基礎說明這是正確的，給人的感覺更多是不明覺厲 。但實際上微服務很多核心理念其實在半個世紀前的一篇文章中就被闡述過了，而且這篇文章中的很多論點在軟件開發飛速發展的這半個世紀中竟然一再被驗證，這就是康威定律（Conway‘s Law）

據說這篇文章最初投的哈佛商業評論，結果程序員屌絲的文章不入商業人士的法眼，無情被拒，康威就投到了一個編程相關的雜誌，所以被誤解為是針對軟件開發的。最初這篇文章顯然不敢自稱定律（law），只是描述了作者自己的發現和總結。後來，在Brooks Law著名的人月神話中，引用這個論點，並將其“吹捧”成了現在我們熟知“康威定律”。

談到康威定律，最經常被人擺出來的一句就是：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

中文大意：

任何組織在設計一套系統（廣義概念上的系統）時，所交付的設計方案在結構上都與該組織的溝通結構保持一致。

說白了就是，團隊在溝通時項目結構是怎麽樣的，那麽項目最終的結構就會是怎麽樣的，所以項目的結構與團隊的溝通是會相互影響的。

我們通過兩張圖片簡單的看一下兩種模式下的團隊結構：

1. 傳統架構模式下的團隊結構：
   

2. 微服務架構模式下的團隊結構：
   

更多關於康威定律的內容可以參考以下文章：

https://yq.aliyun.com/articles/8611

服務拆分分析

如果一個系統擁有買家端和賣家端，我們可以根據這一點拆分成兩個服務。也可以根據業務功能進行拆分，例如可以拆分為商品服務、訂單服務、用戶服務等，這樣拆分的粒度就更細一些。但是代入實際的開發中，如果目標項目比較小，或者團隊人數不多，項目叠代也很慢的話，那麽這種項目是不需要進行拆分的。

我們在拆分服務的時候，需要滿足幾個基本點：服務的高可用、可水平擴展以及功能解耦等等。那麽如何拆 “功能” 呢，可以參考以下幾點：

• 遵循單一職責、松耦合、高內聚原則
• 關註點分離
  • 按職責
  • 按通用性
  • 按粒度級別

如何拆 “數據” ：

• 每個微服務都有單獨的數據存儲
• 依據服務特點選擇不同結構的數據庫類型
• 難點在確定邊界
• 針對邊界設計API
• 依據邊界權衡數據冗余

可以參考擴展立方模型去進行拆分：

在微服務架構中，每個服務一般都會擁有各自的數據源，服務和數據的關系如下：

• 先考慮拆分業務功能，在考慮拆分業務對應的數據
• 無狀態服務，所謂狀態就是只一個數據需要被多個服務共享才能完成一個請求，那麽這個數據就可以被稱為狀態。而依賴這個狀態數據的服務被稱為有狀態服務，反之稱為無狀態服務
  

我們來通過一張圖片，直觀的看一下，服務拆分的前後對比：

論微服務拆分