序
本文主要研究一下admin服務的幾種架構模式
分類
一般而言，一個服務提供的介面有的是C端用的，有的是給B端用的，還有的是給admin用的，對於admin服務該不該訪問業務服務的資料庫，這裡通常會有很多分歧和實踐模式。這裡給admin服務的定義就是給admin後臺系統的前端提供http介面的服務。
模式1: admin服務不能訪問業務資料庫
按微服模式的話，每個業務微服務都有獨立的資料庫，因而admin服務是不能訪問業務微服務的資料庫的，它只能是透過rpc的形式去編排和組裝資料給到admin前端，具體示意如下：
模式2: admin服務訪問業務資料庫
這種模式的話，賦予了admin服務訪問業務資料庫的許可權，其整體架構模式變成如下：
關於這種方式，有幾種實現形式：
- 形式1：admin與業務服務各自實現對資料庫和service的訪問
- 形式2：把共用的dao和service抽取到common包，由admin及業務服務透過jar包依賴去共享
admin服務形式
不管是模式1還是模式2，這裡的admin服務可能有幾種形式
- 形式1，是一個大的單體，即所有業務領域的admin介面都在這個單體裡頭
- 形式2，每個業務領域都有自己的admin介面，最後透過閘道器統一提供給前端，對於前端來講，使用跟形式1沒有區別
模式1的形式2
模式2的形式2
在不是太複雜的業務場景或者是團隊規模不大的場景，形式1是用的比較多的方式；而在比較複雜的業務以及大規模的團隊裡頭，一般是形式2的方式，這樣子可以避免多個團隊的人在同一個工程去修改程式碼
點評
模式1和模式2在很多公司裡頭都有用
模式1優缺點
pros：微服務就是需要業務領域閉環，避免單體相互影響，而admin服務能訪問業務領域的資料庫就不太合理；
若admin服務形式2的方式，由每個領域服務自己提供admin介面，那麼資料庫訪問就相對可用了，還會有問題嗎？
- cons：這種方式即把領域能力從領域服務分離出去了，涉及到業務邏輯程式碼的洩露，有的會說如果我透過dao和service來共享呢，就不會造成分離，也不會造成程式碼重複，這種方式看起來是很巧妙，但是實際問題比較大，它的問題就是把包含業務邏輯的service透過jar共享出去了，其實本質上就是退回到單體服務了，很容易造成邊界不清晰，程式碼其實也不太可讀，一般jar包這種依賴是比較適合工具類或者框架層面的東西，比如spring security，而service這種它跟工具類或者框架類本質上不一樣，它涉及到業務邏輯，會變更到業務資料，所以我們會比較關心哪些地方對它進行了呼叫，怎麼呼叫，場景是怎麼樣，這些都是由領域服務自己控制，共享出去就失控了
模式2優缺點
- pros：admin服務與C端介面服務不一樣，分開的話，可以分開迭代，還可以進行隔離，即admin服務出問題(
當然資料庫慢查詢等除外)不影響C端服務，可以保證C端服務的穩定性。 - cons：如果admin服務採用的是形式2，但是還是造成領域邏輯分開到了不同服務，當然在某些場景是合適的，特別是C端服務與B端服務邏輯差異性太大，他們程式碼複用程度低，說到底其實是有潛在分化為不同子域的趨勢。但如果是簡單的業務場景，複製程式碼也是可以接受，但是共享service這個是不可取的，實際是倒退到了大單體大泥球
小結
模式1主要是從微服務開發的角度去考慮的，考慮領域邏輯閉環；模式2從服務部署及穩定性的角度去考慮的，是沒錯，但是具體做法有些會破壞微服務開發的原則，特別是service共用這種方式，假設是dao共享也是把資料庫修改的權力擴散出去了，如果是每個微服務獨立一個admin服務這種形式，影響還相對小一點，但是也存在領域邏輯可能擴散的問題，不好在同一地方維護，相當於得維護領域服務，還得維護領域admin服務的邏輯。
有沒有更好的方式呢，綜合模式1和模式2，有的，模式1和2的出發點都對，只是模式2的實現方式有點問題，我們期望的是領域邏輯閉環，而不同場景下領域服務能夠隔離，其真實模式2應該從部署層面去解決問題，而不是在微服務架構上去處理，也就是說其實我們可以對同一個微服務做不同場景的隔離部署，就解決問題了，比如對於C端、admin端的都是同一個領域服務提供能力，他們分開部署，也就解決了穩定性和隔離的問題，而程式碼層面，領域層面的能力是統一的。