松花皮蛋的黑板報
  • 分享在京東工作的技術感悟,還有JAVA技術和業內最佳實踐,大部分都是務實的、能看懂的、可復現的

掃一掃
關注公眾號

從數據閉環談微服務拆分

博客首頁文章列表 松花皮蛋me 2019-11-01 20:23

?數據閉環,并不是說我們要將所有的功能全包攬在身上,不依賴其他業務方,也不依賴中臺。而是想強調一件事,那就是業務問題排查過程盡量不要牽扯過多團隊,因為數據鏈路越長越亂處理問題時效性越差,服務性能往往也不盡人意。我先分享個案例給你,或許能幫助你理解和產生共鳴。


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


上面的例子暴露出了很多問題,比如業務不是獨立性的、其他服務直接共享了緩存。沒有備忘錄,其他同事根本不會知道還有這種隱藏的邏輯。這就好比一個枚舉類在這個系統上修改了,但是在另外一個使用到它的系統卻沒有同步修改,災難往往就在不久的將來。想要避免這些問題,那就要做好服務拆分。業內推薦的微服務拆分一般有以下四種:

1、基于業務邏輯拆分

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


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


2.?基于可擴展拆分

我們部門負責京東內容生態的建設,服務業務方各種定制化需求,其他事業群比如國際站卻以為我們是技術中臺,然后要求我們做一個國際化的達人創作平臺。不過說實在的,那怕小步慢跑也無法滿足他們的需求,因為內容這么多環節都有可能涉及到兼容性問題,比如發現好貨中的商品信息上游是否兼容、內容安全校驗算法是否兼容等等。


因為我們不是技術中臺,沒必要將功能以可擴展性為目標進行組件化,實現整套開放賦能,畢竟組織架構影響著技術架構。在這件事情上,我們只能分享經驗和體系架構,或者他們覺得某個功能能直接復用,我們肯定大大方方將其拆出來然后貢獻出去,讓其獨立演化,僅止而已。

3.?基于可靠性拆分

MCN機構達人生產內容然后引導用戶購買商品所得到的傭金是他們的命根子,如果出現計算不準確、提現異常的情況,達人就會覺得有貓膩,產生不信任,就會主動離開。而內容由于機器審核異常導致短暫無法正常進入人工審核階段,是可以接受。可以看出我們對傭金結算和審核系統的可靠性容忍程度截然不同。


另外,傭金結算是一個長期不迭代的、穩定的業務,而審核系統可能會經常引入新的校驗邏輯而需要變更上線,也就意味著后者的上線變更可能會直接影響到結算業務。因為代碼越是修改,引入不確定性的風險越大。那我們需要避免因為審核系統需求上線變更導致傭金結算業務受到影響。最好的方式就是將他們拆開。


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


4.?基于性能拆分

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

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

好,如果文章有幫助到你,歡迎轉發分享或者點個在看。

黑龙江6+1开奖结果查询