hi，這裡是桑小榆呀。 前面我們一起探討了一個微服務的概念瞭解，微服務，也稱為微服務架構，是一種架構風格，它將應用程式構建為服務的集合。集合里的每個服務具有高度可維護和可測試、松耦合效果、圍繞業務能力組織，由一個小團隊擁有。 我們知道，微服務架構是一種架構風格，所謂的架構風格就是一種抽象的結構，它由 ...
hi，這里是桑小榆呀。
前面我們一起探討了一個微服務的概念瞭解，微服務，也稱為微服務架構，是一種架構風格，它將應用程式構建為服務的集合。集合里的每個服務具有高度可維護和可測試、松耦合效果、圍繞業務能力組織，由一個小團隊擁有。
我們知道，微服務架構是一種架構風格，所謂的架構風格就是一種抽象的結構，它由軟件的各個組成部分和這些部分之間的依賴構成。或許看著概念有些抽象，但只要記住任何涉及抽象的設計，它的目的都是為了很好地適應大型業務應用，構建一個穩健的系統。
作為開發者就深有體會，一個應用初次開發完成了並不是真正的完成，它會伴隨著時間或者用戶的需求而不斷的更迭，隨著時間更迭就會存在人員因素和歷史系統設計的局限性，日常維護糟糕且不穩定的系統一定會讓人崩潰吧。這是每一位開發者都需考慮和面臨的問題。
那麼，假如你所負責的應用變得龐大，需要進行重構，我們採用微服務架構，對你現在的需求進行拆分設計，你會怎麼拆分呢？
▲圖/ 微服務架構策略圖，橙色為當前內容
微服務拆分策略
首先，我們需要考慮的是共用類庫的角色，也就是我們在開發過程中，習慣把一些通用的功能（幫助類）打包成一個公共類庫或者包中。其他服務需要使用直接引用調用即可，增加代碼的復用性。但是很可能存在隱患，這個公共類庫不斷地疊加導致出錯或者版本問題會影響到其他服務。
更好的做法就是努力使得這個共享庫都是一些不太可能改變的功能，同時由專
