天天看點

「商業移動端」系統架構演進

作者:閃念基因

引言

「商業移動端」後續會推出一系列技術文章,我們不妨把商業移動端系統看作一棟建築,我們将針對如何把這棟建築打造完善,進行交流。

— 建築架構設計:「系統架構演進」

— 樣闆間:「開屏重構」

— 建築品質保證:「面向錯誤程式設計理念」

— 治安監控:「大前端玩轉Grafana」

背景

商業系統建設初期,重心主要集中在業務的高速疊代,快速增長上。

由于廣告業務的特殊性,技術實作上、、。技術層面上沒有系統思考和長遠規劃,必定會陷入深度耦合,品質失控,拖累各個業務線,積重難返,于工程體系而言是災難性的。

目前商廣用戶端系統正處于這個階段,是以符合商業系統定位的,契合跨業務開發規範的架構演進勢在必行。

場景

業務場景:

背負公司營收名額,基于平台多元流量,提供商業變現能力及其衍生能力的用戶端系統。

服務對象:

業務上,面向品牌、效果、知+等業務提供服務;面向廣告主提供「售後」服務。

技術上,面向平台多元流量所在的業務線,提供變現服務。

關注名額:

營收名額,轉化漏鬥名額(請求→下發→曝光→可見→點選→轉化),性能名額,品質名額。

業務架構圖:

「商業移動端」系統架構演進

可見商業系統,在業務上獨立性弱,多數場景需要與其他業務線配合以達成目标。

舊技術架構圖(藍色方框代表元件):

「商業移動端」系統架構演進

對外,定義為頂層業務元件,元件間耦合嚴重,代碼大量侵入其他業務線,依賴混亂重複。

對内,架構扁平臃腫,縱深不足,頭重腳輕,對外不設防,缺乏權限控制。

洞察

業務方/使用方,目前的痛點是什麼

業務方(商業産品)痛點:

1、提需求開發周期長、由于架構上職責不單一,跨BU團隊開發場景多(效率低),品質風險高。

2、産品方案靈活度低,因為耦合其他業務線,是以受制于其他業務線規則,ko難度大。

3、回報問題,排查問題,周期長,難度高。

使用方(其他業務線接廣告)痛點:

1、耦合商業邏輯,維護成本高,品質風險高。

2、抽象不好,邊界不清,重構優化自身子產品時,心智成本高,阻力大,難度高。

3、不清楚商業邏輯,不經意間會造成影響商業的擾動,造成損失,戰戰兢兢。

一直以來,商業在,、、等問題上飽受诟病。

跨業務需求,方案設計随性妥協,無原則指導,無優秀架構限制,導緻了後續維護困難,品質失控。

上面的種種現象,單純的不定期解耦、重構解決不了根本問題。

需要想明白的是:

  • 工程上商業系統的本質和定位
  • 前瞻商業系統的最佳形态
  • 商業協作的最佳實踐

這些将是商業系統新架構的基石。這些将是商業研發人員的視野。

優秀的研發人員是需要具備「視野」的。

如:我們需要建造一扇門,我們需要知道這扇門要安裝在什麼建築上,以後的用途是什麼,怎麼和砌牆勞工配合。有如此視野,才能不留隐患的完美完成工作。

延展

,這裡不再贅述。

Q:

A:商業系統,在工程的角度,本質上來說是賦予平台的多元流量以變現能力的基礎設施。

Q:

A:獨立的商業SDK,隻開發、維護SDK的抽象商業能力,供其他業務線自行接入,可提供技術支援,不再聚焦業務線具體邏輯。

Q:

A:商廣團隊的職責應該是,将商業業務場景抽象成通用商業能力的過程,而不是深入各個業務線的邏輯泥沼,與不熟悉的代碼肉搏,完成産品需求的過程。

Q:

A:研發設計能力級别:面向産品需求設計(ugly)--->面向Api設計(normal)--->

面向通用能力設計(good)-→面向服務設計(excellent)

Q:

A:将若幹具有相關性的通用能力,進行系統性整合與抽象,使其成為高可用的獨立的子系統。比如:商業系統,提供變現服務。

Q:

推導:

「商業移動端」系統架構演進

結論:

業務部門抽象,建設通用能力(是對現有能力的補充或更新,并非隻是為了商業需求開發)+ 商業部門抽象,建設通用能力,兩部分能力對接,配合以達成目的。

歸納

1、在設計理念上完成由「面向産品需求設計」到「面向服務設計」的跨越。

2、在架構縱深上完成由「業務元件」到「基礎元件」的下沉,以契合商業系統在工程上的本質和定位,強化邊界。

3、在部門協作上完成由「面向具體API建設」到「面向獨立能力建設」的轉變。

新架構圖

「商業移動端」系統架構演進

诠釋

Ad-Api中間件,消除Ad元件的直接依賴,實作代碼隔離、解耦。

Ad業務層,隻承載商業業務相關邏輯,可依賴其他業務線api中間件。

獨立商業能力層,業務無關、抽象、獨立維護、獨立運作。可由商業業務層、其他業務線、多App直接引用。

AdBase基礎層,包含商業基礎服務,可依賴其他基礎元件。

新架構收益

實作代碼隔離,商業與其他業務線完全解耦,消除循環依賴。

元件下沉,利用「基礎元件不可依賴業務元件」的規則,反向限制研發人員遵守協作模型。

去煙囪化,實作「普通開屏」、「超級首映」等多套相似邏輯的統一。

顆粒化,外元件可直接依賴商業獨立能力,而不是整個商業元件。

通用化,提供業務無關的,抽象良好的,獨立商業能力,便于各業務線,多app使用。

作者:知乎商業移動端團隊-于铠瑞

出處:https://zhuanlan.zhihu.com/p/592991822

繼續閱讀