如何進行微服務的拆分
在前面介紹了基于Spring Boot來快速實作一個“天氣預報”應用。雖然沒有使用太多的代碼，但已經實作了資料采集、資料緩存、提供天氣查詢等諸多的功能，這也是Spring Boot是快速實作企業級應用開發的利器的原因。Spring Boot讓企業級應用開發變得不再困難!
很顯然，這個“天氣預報”應用是一個單塊架構的應用。它表面看上去很強大(內建了資料采集、資料緩存、提供天氣查詢等功能)，但從另外一個角度看，它缺乏業務上的有效隔離。例如，如果第三方采集的接口協定變更怎麼辦?緩存服務失效怎麼辦?其中任何一個問題的發生，都勢必會影響整個應用的可用性。
微服務拆分的意義
把所有雞蛋放在一個籃子裡所帶來的風險是顯而易見的——一損俱損。微服務架構正是通過分而自治的理念來降低服務故障的風險，進而實作服務的可行性。
1.微服務易于實作
更小的服務意味着更少的代碼。更小的服務意味着不必考慮太多整體的技術架構或一站式的解決方案。隻需要拿上趁手的兵器(開發工具和語言)，奮勇開疆即可!
在實作微服務時，配以Spring Boot類開箱即用的工具，可以使自己更加有信心趕超進度。
2.微服務易于維護
更小的服務意味着更少的代碼、更少的業務需求，也就容易被開發人員所了解，包括開發者和維護者。對于軟體設計來講，一個非常大的品質名額，就是軟體是否可維護。更小、更内聚的微服務更加易于維護。
3.微服務易于部署
微服務往往采用輕量級的技術來實作，如内嵌容器的方式，這樣，它更容易将其自身及所依賴的運作環境打成一個包來進行分發，進而避免了不同的部署導緻的環境不一緻的問題。再配合Docker等容器技術，可以進一步降低部署的複雜性。
4.微服務易于更新
微服務更容易被維護和修改，再加上每個微服務都是獨立部署的，這樣替換單個服務，并不會影響整體的軟體功能。是以，微服務可以擁有對單塊架構更加頻繁的更新頻率。
越頻繁地更新，意味着越早将使用者的需求回報給使用者﹔使用者越早使用産品，越能發現程式的問題，這樣就能及早地提出變更需求，進而形成了一個如圖6-7所示的正向的回報閉環。
拆分的原則
拆分微服務—般遵循如下原則。
1.單一職責原則
單一職責原則(Single Responsibility Principle，SRP)又稱單一功能原則，是面向對象的五大基本原則(SOLID ) 之一。一個類隻能有一個引起它變化的原因，因為它應該隻有一個職責。每一個職責都是變化的一個軸線，如果一個類有一個以上的職責，這些職責就耦合在了一起。這會導緻脆弱的設計。當一個職責發生變化時，可能會影響其他的職責。另外，多個職責耦合在一起，會影響複用性。
在架構設計中，業界普遍采用的是分層架構。分層的原則之一就是每一層都是專注于自己所處的那一層的業務功能，即遵守單一職責的原則。劃分微服務時也要遵循單—職責原則，每個微服務隻專注于解決一個業務功能。通過DDD的指導，可以更加清楚地劃清不同業務之間的界限。
組織團隊也要遵循單一職責原則，這樣才能很好地管理團隊成員的時間，提高效率。一個人專注做一件事情的效率遠高于同時關注多件事情。同樣一個人一直管理和維護同一份代碼要比多人同時維護多份代碼的效率高得多。這樣就能充分發揮每一個人的個性，專注于每個人所擅長的事，這樣做起事情來就會事半功倍，整個團隊效率也會提高。
⒉.高内聚
内聚性又稱塊内聯系，是指子產品功能強度的度量，即一個子產品内部各個元素彼此結合的緊密程度的一種度量。若一個子產品内各元素聯系得越緊密，則它的内聚性就越高。
程式員希望把相關的行為都聚集在一起，把不相幹的行為放到其他地方。這樣，當他們要修改某個行為的時候，隻需要在一個地方修改即可，然後就能對該修改及早地進行釋出。如果要在很多不同的地方做修改，那麼就需要同時釋出多個微服務才能傳遞這個功能。在多個不同的地方進行修改會很慢，同時也引入了很多測試的工作量，而且部署多個服務的風險也更加高。這兩者都是開發人員想要避免的。
是以，确定問題域的邊界，保證相關的行為能夠放置在相同的地方，并且確定它們與其他邊界以盡量低耦合的方式進行通信。
3.低耦合
耦合性也稱塊間聯系，是指軟體系統結構中各子產品間互相聯系緊密程度的一種度量。子產品之間聯系越緊密，其耦合性就越強，子產品的獨立性則越差。子產品間耦合程度的高低取決于子產品間接口的複雜性、調用的方式及傳遞的資訊。
能夠獨立地修改及部署單個服務，而不需要修改系統的其他服務組成。
一個低耦合的服務，應盡可能少地了解其他服務的資訊。這同時意味着，兩個服務之間需要限制不同調用形式的數量,因為除了潛在的性能問題以外,過度的通信往往是造成緊密耦合的“原罪”。
4.恰當的“微”
服務間的低耦合是指修改一個服務，就不需要修改另一個服務。使用微服務最重要的一點就是，微服務到底多微才算“微”，這個業界也沒有一定的标準。微服務也不是越小越好。服務越小，微服務架構的優點和缺點也就會越來越明顯。服務越小，微服務的獨立性就會越高，但同時，微服務的數量也會激增，管理這些大批量的服務也将會是一個挑戰。是以服務的拆分也要考慮場景。例如，當開發人員認為自己的代碼庫過大時，往往就是拆分的最佳時機。代碼庫過大意味着業務過于複雜，明顯已經超出了開發人員了解的範圍，是以也是需要考慮進行拆分的。當然，代碼庫的大小不能簡單地以代碼量來評價，畢竟複雜業務功能的代碼量，肯定比簡單業務的代碼量要高。同樣地，一個服務，其功能本身的複雜性不同，代碼量也截然不同。
5.擁抱變化
好的系統架構都不是一蹴而就的，而是通過不斷地完善、不斷地演進而來。在建構微服務架構時也是如此，應該是一個循序漸進的過程，允許架構在适當的時候做出調整，做出改變。在項目初始階段，團隊的隊員之間肯定需要一個磨合，大家對于微服務的了解肯定也是各有差異，在建構微服務的過程中，往往也會出現劃分服務不恰當的問題。此時，最重要的是能夠容忍并改正錯誤，應清醒地認識到，錯誤是不可避免的，發現問題并努力去解決問題才是“王道”。在這之中，最關鍵的是團隊要始終保持一個“擁抱變化”的心态。
拆分的方法
根據上面提到的拆分原則，拆分微服務主要有下面幾種方法。
1.橫向拆分
橫向拆分，即按照不同的業務功能，拆分成不同的微服務，如天氣資料采集、資料存儲、天氣查詢等服務，形成獨立的業務領域微服務叢集，如圖6-8所示。
2.縱向拆分
縱向拆分，即把一個業務功能裡的不同子產品或元件進行拆分。例如,把公共元件拆分成獨立的基礎設施，下沉到底層，形成相對獨立的基礎設施層，如圖6-9所示。
圖6-9是一個縱向拆分的例子，其中各層次的職責如下。
- 使用者界面層(User Interface):也稱為使用者接口層或表示層(Presentation Layer)，負責向使用者顯示資訊或解釋使用者指令。這裡的使用者可以是另外一個計算機系統，而不一定是一個使用使用者界面的人。
- 應用層(Application Layer):定義軟體要完成的任務，并且指揮表達領域概念的對象來解決問題。該層主要負責的工作對于業務來說意義重大，也是與其他系統的應用層進行互動的必要管道。應用層應該盡量簡單，不包括業務規則或隻是為下一層中的領域對象協調任務、配置設定工作，使它們互相協作。它沒有反映業務情況的狀态，但卻可以具有另外—種狀态，為使用者或程式顯示某個進度。
- 領域層(Domain Layer):或稱模型層(Model Layer)，主要負責表達業務概念、業務狀态資訊及業務規則。盡管儲存業務狀态的技術細節是由基礎設施層實作的，但是反映業務情況的狀态是由本層控制并且使用的。領域層是業務軟體的核心。
- 基礎設施層(Infrastructure Layer):為上面各層提供通用的技術能力，如為應用層傳遞消息、為領域層提供資料通路及持久化機制、為使用者界面層繪制螢幕元件等。基礎設施層還能夠通過架構架構來支援這4個層次間的互動。
3.使用DDD
一個微服務，應該能反映出某個業務的領域模型。使用DDD，不但可以減少微服務環境中通用語言的複雜性，而且可以幫助團隊搞清楚領域的邊界，理清上下文邊界。
建議将每個微服務都設計成一個DDD限界上下文(Bounded Context)。這為系統内的微服務提供了一個邏輯邊界，無論是在功能還是在通用語言上。每個獨立的團隊負責一個邏輯上定義好的系統切片。最終，團隊開發出的代碼會更易于了解和維護。
本篇文章給大家講的内容是如何進行微服務的拆分
- 下篇文章給大家講解領域驅動設計與業務模組化；
- 覺得文章不錯的朋友可以轉發此文關注小編；
- 感謝大家的支援！！