目錄
從15年開始接觸微服務，到現在20年，小編已經差不多做了4年多，如果算上加班時間的話，那就差不多有6年了。這幾年從剛開始的摸索，服務切分，說出來可能不行，剛開始我們嘗試過三層結構進行切分，但是不到一週就全部推翻，基於現在的領域設計來做切分，這幾年實踐起來也非常好。
但是，小編遇到的最大的問題並非技術上或者業務切分上，而是一個毫不起眼的東西，基礎數據模塊。
基礎數據模塊，並不複雜，無論是數據模型還是業務定向，都不復雜，我們一般設計爲獨立的模塊，用於存放那些基本上都不會動的數據，像國家，城市，數據字典等，但是就這些小東西，剛開始卻非常糾結。
第一：傳統系統設計
在傳統系統中，都是基於單體設計，一個系統加上一個數據庫，沒啥量的內部系統，就是業務複雜，這時候我們在設計的時候，會直接把基礎數據全部放在數據庫裏面，無論是取數據或者聯表查詢的時候，都非常方便，這時候不用考慮太多問題。
前臺頁面根據需要進行添加，刪除，更改即可。
第二：微服務中基礎數據痛點
微服務來了，這是個非常好的東西，小編不否認，同時也非常贊同。
在服務架構設計中，採用領域設計的思想，對業務進行切分，對鑑權進行分離，但是恰恰這個基礎數據，要如何設計？成了小編一時的難題，總結起來，需要解決下面4個問題
1、數據共享問題：在基礎數據的設計理念上，本質上就是要達到一個目的，基礎數據提供給所有的服務使用，數據要做到所有服務共享，如何做？
2、多服務共享問題：幾乎所有的企業，都會存在老系統，新系統共存的情況，那此時老系統上面的基礎數據如何與新系統實現共享？難道我需要維護很多系統的數據嗎？
3、聯表查詢問題：在基礎數據的設計中，存在一種情況，把基礎數據獨立出來，標準化的API出去給人使用，但此時出現個問題，很多系統在進行聯表查詢的時候，都需要join基礎數據，不同的庫，此時非常難。小編遇到過採用join兩個庫的情況，但是並不贊同，性能上很考驗人，那怎麼做？
4、前臺查詢問題：現在基本上都是前後端分離，在前端查詢的時候，一般都是經過網關，此時面對着前端上很多的基礎數據，有采用json文件做法，有采用直接調用後端服務的做法。
此時我們來分析一下，採用json文件，那此時跟數據庫層面的數據形成了兩套，維護量起來了，運維工程師要炸。
那採用直接調用後端的基礎數據服務呢？網絡請求是個問題，畢竟要經過網關，再到基礎數據服務，如果不考量網絡效能問題，可以考慮這種做法，前端文件做法也可以。
這裏小編贊同這兩種方法，但是有沒有更靈活一些的方式？儘可能的減少運維工程師的量，也儘可能減低手動出錯的概率？
第三：爲做到共享，我們這樣做
1、服務隔離數據設計：爲做到基礎數據共享，還是繼續考慮採用獨立的數據模塊設計，獨立數據庫加上獨立服務，對外提供標準化的AIP，不變。考慮到新老系統的基礎數據存在數據差異性，例如數據字段性別這個字段，新系統男是1，女是2；但是老系統剛好相反，男是2，女是1；針對這種情況，我們在設計上引入了服務ID這個隔離標記，這個服務ID是用來標記這些數據是對應哪個系統。
2、數據移動化設計：在上面的設計中，很多同學發現了，存在聯表查詢問題，這裏小編想起以前java剛開始興起的時候，有一句話：一次編譯，到處運行。那爲了解決這個問題，我們對數據的存量設計進行了優化，叫做數據移動化設計。
在互聯網設計中，經常會採用數據緩存，來儘可能避免join所帶來的性能損耗，這裏的思想一樣，用空間換時間，每一個業務數據庫都會存在不可更改的基礎數據表。這裏要強調，這些基礎數據表的作用：不可更改，只提供聯表查詢操作。
3、數據異步化維護：在採用了數據表緩存到各個業務庫後，維護成了一個大問題。這裏要藉助我們強大的MQ來實現。一個基礎數據服務建成後，除了對外提供標準化的API，還提供了一個基礎數據接收包。這個基礎數據接收包主要就是連接並監聽MQ的基礎信息，只要基礎數據庫的數據發生變化，所有業務數據庫上的基礎數據都會同步到，來避免數據不一致問題。
4、數據緩存化設計：現在前後端分離，前端只做頁面展示，最快的方式肯定是請求網絡，文件的方式雖然快，但運維是個問題，這時候，我們考慮的時候緩存化設計。在設計中，數據採用redis進行緩存，redis直接與nginx進行連接，這樣子，前端在進行請求的時候，直接請求的是redis上的數據，這樣子用來解決網絡效能問題。這裏的方案是默認前端部署在nginx上，如果部署在tomcat上，原理是一致的。
有關微服務的架構設計許多，小編相信架構是不斷演化的，不斷根據不同的業務進行改進的。也許今天這套很好，明天那套就更好。
天下合久必分，分久必合，軟件架構設計也是一樣，理想是美好的，但是現實是骨感的，小編始終相信會有更好的方案，歡迎關注 @溪雲閣 ，有什麼問題歡迎私信探討。
--END--
歡迎關注頭條號：@溪雲閣