在人线AV无码免费高潮喷水,中文字幕免费看,91超级碰

高效落地中臺實踐中的特異性難題

時間：2021-12-16 瀏覽次數：260

在中臺建設歷程中，在MSS模型的指導下幫助我們完成了中臺服務中心的設計與建設后，下一步便進入中臺實施與運營的環節。

本篇文章我們來談談在中臺實施與運營中一個痛點問題“業務系統與中臺流程沖突”。

1、目標：特異性流程接入

中臺建設在解決了方案設計這一難題后，需要面對的另一大難題就是特異性問題的管理，這也是我們在中臺實施過程中必然會遇見的問題。

所謂特異性問題就是不管在之前業務模型怎么抽象，在中臺實施過程中一定還會發現存在由于中臺系統與業務系統在功能上存在差異而無法接入的的現象，從而導致與中臺的對接出現阻塞。

例如可能是因為這個業務線當年與你介紹的時候他沒有提到某個特殊流程，或者因為在中臺研發的時候，業務線系統同步在發展，導致有一些新的流程把以前的流程推翻了，那這個時候就會出現特異性問題，本質上這個問題的來源屬于業務的發展導致新業務場景與中臺原有設計不再匹配。

這里我想先問問此時正在閱讀的你，中臺系統和業務系統功能相沖突或違背，那這個時候我們應該怎么辦？

這里有幾個常見的做法供你選擇：

（1）第一種做法：選擇直接放棄，也就是不把該業務線的系統接入到中臺中，該業務系統游離于中臺體系外自己循環；

（2）第二種做法：中臺團隊根據該業務的現狀，去進行量身打造，由中臺給你進行定制化改造，適配你現在的流程；

（3）第三種做法：強制業務系統根據中臺定義出的流程進行兼容，也就是由業務系統去按中臺的流程進行開發改造。

那這三種模式各自有什么優缺點呢？

（1）第一種做法：由于業務特異性而放棄接入，在出現一例不接入中臺的先河后，又因為中臺的建設過程中是業務逆向感知的，也就是不僅沒有給業務帶來新的價值，反而還要占用大量的工時和工期，那這個時候業務是不買賬的。導致別的業務線聽到后，會說他不接入中臺，我也不接入，那這樣的情況下整個中臺就會在企業內部被邊緣化；

（2）第二種做法：為業務線量身定制，這樣做的背后存在巨大的項目風險，一般情況下需要定制往往是因為這些業務還不成熟，由于這是一個探索業務，很有可能在中臺改造完成之后或者改造過程中，這個業務就被下馬了。那這個時候我們的改造就浪費掉了，此外作為公司的基礎服務中臺，為了穩定性本身也不事宜頻繁變動；

（3）第三種做法：強制業務系統按照中臺流程改造，此時中臺反而成為了制約業務發展的瓶頸。

2、工具：服務中心插件

所以我們解決方案是什么呢？

在中臺實施過程中一個非常好的解決特異性問題的方案就是插件，通過插件讓特異性的業務部分接入到中臺中。

所謂插件也就是中臺開放一些對應的接口，允許業務方去插入一個自定義的代碼段，自定義代碼段可以去調用我們中臺的上層服務，去跳過部分場景。

從而實現在符合現有邏輯中臺邏輯的一個調用，然后在具體的業務層去替換這部分的含義，使它賦予新的業務含義，從而讓他接入到中臺中。

我舉個例子來說，我經歷過一個新孵化的業務想要調用客服服務中心的服務，但是由于新業務中人員較少，原有的客服流程較長，且每一步都有對應的單據，導致新業務的客服工作壓力巨大，此時我們就讓該業務線以插件的形式接入中臺，并在部分環節調用中臺接口自動產生單據，這樣就解決了新業務線的問題。

可以說插件可以幫助業務線既接入中臺，同時又去符合了新業務的特性，那么這就是插件帶來的意義。

假以時日等到這條業務線變得越來越健壯了之后，這個業務越來越成熟，越來越多業務線都需要該插件的功能后，我們再把這個插件拆掉，讓插件升級為中臺的一個能力，這樣的情況下是中臺最安全最節省成本的一種方式。

那這里我們還是以一個具體的案例來看，在L電商內部是怎么使用插件解決這個問題的。

3、案例：L電商公司中臺插件引入

在L公司中通過商戶全局商戶號與全局協議，我們實現了對商戶的唯一化管理，但是隨著業務的發展，特別是當我們與一些頭部客戶合作時，頭部的客戶對我們提出要求，要求我們在原有賬期到期后，在打款期間依舊能臨時使用我們的服務。

也就是需要我們在這段時間給予商戶一個授信額度，允許在規定賬期之外對我們進行賒賬。

但是這個時候，已經標準化了的整個商戶管理服務和支付中心不支持這樣的服務，在到達賬期后，商戶不進行結款，不會允許商戶進行使用。

面對這樣的業務需求，我們不得不跳過中臺所提供的部分功能，從而滿足這位客戶的個性化需求。

當時我們有兩種解法，第一種解法立即啟動中臺升級，在支付中心中增加授信模塊，但是這樣做等待時間比較長，無法及時響應客戶現在的需求。

第二種方法就是我們要去介紹的通用中臺特異性管理方法，由業務線提供個性化服務的代碼段來跳過中臺的限制，從而既不破壞中臺的要求，又能符合業務的新需求。

根據前面的介紹我們知道這個代碼段有它自己特殊的名稱，也就是中臺的插件，他的特征有如下兩個：

（1）符合現有邏輯的調用；

（2）在業務層替換的該部分業務含義；

具體落地到業務上來看，我們是這樣實現的，如圖所示

（1）1.0中臺中的計費不支持授信，此時我們使用插件；

（2）調用中臺還是商戶預充值服務：虛擬充值金額2萬，以此讓中臺認為該商戶已經完成還款充值，此處的還款充值額度就為給商戶開的授信額度；

（3）在插件中記錄2萬為授信額度，在月底的商戶賬單中自動沖銷2萬元，從而實現金額的閉環。

所以看到插件就是在滿足不影響底層業務的情況下的一個繞彎，當然之所以不把這個業務單獨拉出去去做，是因為目前我們只對接了一個客戶。該模式的規模化特征還不明顯，此時我們如果貿然的將它加入到中臺中來，只用一次的需求對于中臺來說，無疑是開發資源的巨大浪費。

所以我們會先選用插件的模式，從而快速復用中臺其他的邏輯，當賬期需求在多個業務線都出現，成規模化需求時，再進行中臺對應模塊的開發，由插件變為中臺內部的一個服務。

也就是當出現多個插件使用服務時：

（1）開始將該插件合并至中臺；

（2）由中臺進行統一維護；

綜上我們通過插件實現了中臺實施的特異性管理。