從數據閉環談微服務拆分

面試精選集，快快前往領取吧！ offer.liangsonghua.me/。關注微信公衆號：松花皮蛋的黑板報，獲取更多精彩！

數據閉環，並非說咱們要將全部的功能全包攬在身上，不依賴其餘業務方，也不依賴中臺。而是想強調一件事，那就是業務問題排查過程儘可能不要牽扯過多團隊，由於數據鏈路越長越亂處理問題時效性越差，服務性能每每也不盡人意。我先分享個案例給你，或許能幫助你理解和產生共鳴。

咱們有一個內容渠道是直播，渠道權限和建立直播間入口都是咱們來維護的，可是建立直播後的內容保存接口是直播團隊維護的，保存接口會校驗達人權限和等級，而校驗接口又是另一個團隊提供的，他們對咱們緩存進行了封裝。最近發現權限校驗異常頻發，緣由是緩存和數據庫狀態不一致。但是對於達人或者不知情的人來講，在達人創做平臺上碰到的問題就應該由創做端來負責，可真正出現問題的環節不在咱們這。

上面的例子暴露出了不少問題，好比業務不是獨立性的、其餘服務直接共享了緩存。沒有備忘錄，其餘同事根本不會知道還有這種隱藏的邏輯。這就比如一個枚舉類在這個系統上修改了，可是在另一個使用到它的系統卻沒有同步修改，災難每每就在不久的未來。想要避免這些問題，那就要作好服務拆分。業內推薦的微服務拆分通常有如下四種：

一、基於業務邏輯拆分

一個內容從達人生產到用戶能看到，須要通過不少中間過程。涉及到用戶成長體系、渠道權限管理、頻道樣式創做、內容機審人審質檢等等。若是中間環節都拆分紅單獨的業務，而各類樣式內容的站內站外分發交由各個頻道獨立處理，也就是內容從生產到審覈都是在閉環的，那案例中的隱藏的大坑就不復存在。每三個同事負責每幾個環節的微服務，哪一個環節出現問題那就讓負責這個環節的同事排查就能夠了，不須要多方同時介入，你們各司其職。

按照業務邏輯拆分後，不只能造成更穩定的接口，還能確保咱們可以更好的反映業務流程的變化。另外，每一個獨立部署的業務均可以使用特定的專業技能進行開發，好比內容推薦算法。每一個獨立部署的業務都有主要負責的研發，產品也就不須要搶研發資源來知足需求。

2.基於可擴展拆分

咱們部門負責京東內容生態的建設，服務業務方各類定製化需求，其餘事業羣好比國際站卻覺得咱們是技術中臺，而後要求咱們作一個國際化的達人創做平臺。不過說實在的，那怕小步慢跑也沒法知足他們的需求，由於內容這麼多環節都有可能涉及到兼容性問題，好比發現好貨中的商品信息上游是否兼容、內容安全校驗算法是否兼容等等。

由於咱們不是技術中臺，不必將功能以可擴展性爲目標進行組件化，實現整套開放賦能，畢竟組織架構影響着技術架構。在這件事情上，咱們只能分享經驗和體系架構，或者他們以爲某個功能能直接複用，咱們確定大大方方將其拆出來而後貢獻出去，讓其獨立演化，僅止而已。

3.基於可靠性拆分

MCN機構達人生產內容而後引導用戶購買商品所獲得的佣金是他們的命根子，若是出現計算不許確、提現異常的狀況，達人就會以爲有貓膩，產生不信任，就會主動離開。而內容因爲機器審覈異常致使短暫沒法正常進入人工審覈階段，是能夠接受。能夠看出咱們對佣金結算和審覈系統的可靠性容忍程度大相徑庭。

另外，佣金結算是一個長期不迭代的、穩定的業務，而審覈系統可能會常常引入新的校驗邏輯而須要變動上線，也就意味着後者的上線變動可能會直接影響到結算業務。由於代碼越是修改，引入不肯定性的風險越大。那咱們須要避免由於審覈系統需求上線變動致使佣金結算業務受到影響。最好的方式就是將他們拆開。

也就是說，一個服務故障發生時產生的影響面很大，它就算系統中很脆弱的部分，咱們必須將其拆分出去，將異常隔離。

4.基於性能拆分

咱們內容人工審覈是由外包團體承包的，時常收到他們反饋說，下午6點左右審覈頁面加載很慢，審覈經過按鈕須要點好幾下才能生效。咱們結合數據庫IO告警和數據庫慢查詢來看，那個時間段應該是有人在跑大數據調度任務，但是很難定位到具體的任務。不知道讀者有沒有體驗過這種由於數據源依賴致使個別業務性能受到影響，包括很難優化的數據庫慢查詢。所以，它們的數據源應該拆分掉，業務同理。

最後多說一點，無論採用何種方式拆分服務，或者何種組合拆分方式，都要注意數據流向，千萬不能出現循環依賴，包括使用MQ解藕，那也算一種隱層的依賴。

好，若是文章有幫助到你，歡迎轉發分享或者點個在看。

文章來源：www.liangsonghua.me

做者介紹：京東資深工程師-梁鬆華，在穩定性保障、敏捷開發、JAVA高級、微服務架構方面有深刻的理解

關注微信公衆號：松花皮蛋的黑板報，獲取更多精彩！