從數據閉環談微服務拆分
- 2019 年 11 月 2 日
- 筆記
數據閉環，並不是說我們要將所有的功能全包攬在身上，不依賴其他業務方，也不依賴中台。而是想強調一件事，那就是業務問題排查過程盡量不要牽扯過多團隊，因為數據鏈路越長越亂處理問題時效性越差，服務性能往往也不盡人意。我先分享個案例給你，或許能幫助你理解和產生共鳴。
我們有一個內容渠道是直播，渠道許可權和創建直播間入口都是我們來維護的，但是創建直播後的內容保存介面是直播團隊維護的，保存介面會校驗達人許可權和等級，而校驗介面又是另外一個團隊提供的，他們對我們快取進行了封裝。最近發現許可權校驗異常頻發，原因是快取和資料庫狀態不一致。可是對於達人或者不知情的人來說，在達人創作平台上碰到的問題就應該由創作端來負責，可真正出現問題的環節不在我們這。
上面的例子暴露出了很多問題，比如業務不是獨立性的、其他服務直接共享了快取。沒有備忘錄，其他同事根本不會知道還有這種隱藏的邏輯。這就好比一個枚舉類在這個系統上修改了，但是在另外一個使用到它的系統卻沒有同步修改，災難往往就在不久的將來。想要避免這些問題，那就要做好服務拆分。業內推薦的微服務拆分一般有以下四種：
1、基於業務邏輯拆分
一個內容從達人生產到用戶能看到，需要經過很多中間過程。涉及到用戶成長體系、渠道許可權管理、頻道樣式創作、內容機審人審質檢等等。如果中間環節都拆分成單獨的業務，而各種樣式內容的站內站外分發交由各個頻道獨立處理，也就是內容從生產到審核都是在閉環的，那案例中的隱藏的大坑就不復存在。每三個同事負責每幾個環節的微服務，哪個環節出現問題那就讓負責這個環節的同事排查就可以了，不需要多方同時介入，大家各司其職。
按照業務邏輯拆分後，不僅能形成更穩定的介面，還能確保我們能夠更好的反映業務流程的變化。另外，每個獨立部署的業務都可以使用特定的專業技能進行開發，比如內容推薦演算法。每個獨立部署的業務都有主要負責的研發，產品也就不需要搶研發資源來滿足需求。
2.基於可擴展拆分
我們部門負責京東內容生態的建設，服務業務方各種訂製化需求，其他事業群比如國際站卻以為我們是技術中台，然後要求我們做一個國際化的達人創作平台。不過說實在的，那怕小步慢跑也無法滿足他們的需求，因為內容這麼多環節都有可能涉及到兼容性問題，比如發現好貨中的商品資訊上游是否兼容、內容安全校驗演算法是否兼容等等。
因為我們不是技術中台，沒必要將功能以可擴展性為目標進行組件化，實現整套開放賦能，畢竟組織架構影響著技術架構。在這件事情上，我們只能分享經驗和體系架構，或者他們覺得某個功能能直接復用，我們肯定大大方方將其拆出來然後貢獻出去，讓其獨立演化，僅止而已。
3.基於可靠性拆分
MCN機構達人生產內容然後引導用戶購買商品所得到的傭金是他們的命根子，如果出現計算不準確、提現異常的情況，達人就會覺得有貓膩，產生不信任，就會主動離開。而內容由於機器審核異常導致短暫無法正常進入人工審核階段，是可以接受。可以看出我們對傭金結算和審核系統的可靠性容忍程度截然不同。
另外，傭金結算是一個長期不迭代的、穩定的業務，而審核系統可能會經常引入新的校驗邏輯而需要變更上線，也就意味著後者的上線變更可能會直接影響到結算業務。因為程式碼越是修改，引入不確定性的風險越大。那我們需要避免因為審核系統需求上線變更導致傭金結算業務受到影響。最好的方式就是將他們拆開。
也就是說，一個服務故障發生時產生的影響面很大，它就算系統中很脆弱的部分，我們必須將其拆分出去，將異常隔離。
4.基於性能拆分
我們內容人工審核是由外包團體承包的，時常收到他們回饋說，下午6點左右審核頁面載入很慢，審核通過按鈕需要點好幾下才能生效。我們結合資料庫IO告警和資料庫慢查詢來看，那個時間段應該是有人在跑大數據調度任務，可是很難定位到具體的任務。不知道讀者有沒有體驗過這種因為數據源依賴導致個別業務性能受到影響，包括很難優化的資料庫慢查詢。因此，它們的數據源應該拆分掉，業務同理。
最後多說一點，不管採用何種方式拆分服務，或者何種組合拆分方式，都要注意數據流向，千萬不能出現循環依賴，包括使用MQ解藕，那也算一種隱層的依賴。
好，如果文章有幫助到你，歡迎轉發分享或者點個在看。
文章來源：www.liangsonghua.me
作者介紹：京東資深工程師-梁松華，在穩定性保障、敏捷開發、JAVA高級、微服務架構方面有深入的理解
關注微信公眾號：松花皮蛋的黑板報，獲取更多精彩！
