背景

在全公司針對業(yè)務(wù)效率提升有嚴(yán)格要求的背景下，游戲技術(shù)中臺一直在思考，如何提高全球發(fā)行效率？

在游戲技術(shù)中臺的眾多產(chǎn)品當(dāng)中，SDK是賦能游戲研發(fā)的核心產(chǎn)品之一，其核心能力包括賬號、交易、合規(guī)（實名、防沉迷），以及社交、營銷等能力。現(xiàn)有的SDK群存在22種類型，在過往的高速發(fā)展和歷史慣性中，SDK群劃分的維度主要有3個：

• 發(fā)行品牌：bilibili、白板、D、海外bilibili、海外白板、K；（出于發(fā)行品牌隔離保護(hù)需要，下文以代號D/K分別代表國內(nèi)和海外被保護(hù)的發(fā)行品牌）
• 發(fā)行地區(qū)：中國大陸、港澳臺（中國）、韓國、東南亞、歐美等；
• 設(shè)備類型：iOS、安卓、PC。

不同發(fā)行品牌、地區(qū)、設(shè)備，存在相同定位的API，但是定義和標(biāo)準(zhǔn)不同，導(dǎo)致在不同合作模式（主要分為：獨(dú)家代理、聯(lián)合運(yùn)營；獨(dú)家代理簡稱獨(dú)代，聯(lián)合運(yùn)營分為兩種，聯(lián)運(yùn)和UO，UO為Union Operation的縮寫特指在獨(dú)代的前提下，主動與第三方下載渠道合作；聯(lián)運(yùn)特指在沒有獨(dú)家代理的前提下，第三方與bilibili的合作。），研發(fā)需要重復(fù)對接多種類型SDK和服務(wù)端API；

圖片

藍(lán)色部分表示游戲研發(fā)需要感知的SDK和服務(wù)端API類型。

另一方面，發(fā)行技術(shù)中臺建設(shè)早期秉承業(yè)務(wù)優(yōu)先思維，專注于各領(lǐng)域基礎(chǔ)能力建設(shè)，各系統(tǒng)間缺少聯(lián)動依賴運(yùn)營 SOP 銜接，伴隨發(fā)行游戲數(shù)量增多，效率問題逐步呈現(xiàn)。為解決這些問題，優(yōu)化全球發(fā)行效率，我們期望為研發(fā)提供一站化體驗，從聯(lián)動性、易用性、自動化等多角度優(yōu)化當(dāng)前 SDK 與后臺系統(tǒng)，故啟動了 ONE SDK / API 項目。

成果

當(dāng)我們完成ONE SDK/API項目后，以游戲《Kenny: 和平衛(wèi)士》發(fā)行計劃為例，從以下3個維度：“全球發(fā)行平均接入時間”、“游戲研發(fā)的認(rèn)知范圍”、“游戲研發(fā)重復(fù)開發(fā)次數(shù)”，取得的工作成果現(xiàn)展示如下：

圖片

用5組數(shù)據(jù)度量，以對比ONE SDK/API價值

圖片

1、全球發(fā)行平均接入時間：從優(yōu)化前的60天縮短為15天，效率提升了4倍；

2、游戲研發(fā)的認(rèn)知范圍：從游戲研發(fā)需要認(rèn)知的參數(shù)數(shù)量，以及實際需要管理參數(shù)兩個維度度量，其概念認(rèn)知規(guī)模至少降低了90%；

3、游戲研發(fā)重復(fù)開發(fā)次數(shù)：從SDK API接入次數(shù)和服務(wù)端API接入次數(shù)度量，其重復(fù)勞動規(guī)模至少降低了75%。

分析

基于以上背景描述，本節(jié)重點(diǎn)描述，我們對于全球發(fā)行的理解，以及對于目標(biāo)和行動路線的思考過程。

API標(biāo)準(zhǔn)未統(tǒng)一和孤島系統(tǒng)是全球發(fā)行過程中，比較容易識別的兩個痛點(diǎn)。圍繞業(yè)務(wù)效率提升這個大目標(biāo)，從增效這個角度切入，在本次升級和實踐的行動路線應(yīng)該是什么樣的？結(jié)合本次實踐，我們還可以挖掘的內(nèi)容還有哪些？值得在項目初期認(rèn)真思考。

在整體的思考過程中，我們基于SimonO.Sinek的黃金圈法則模型來拆解目標(biāo)，基于目標(biāo)尋找方法，建立行動路線。首先，簡單介紹一下黃金圈法則。

圖片

黃金圈法則是一個輔助思考和決策的方法，其思考過程主要包括三個層次：為什么（Why）、方法（How）和行動（What）。

1. 目標(biāo)（Why）：這一層次是最基礎(chǔ)和核心的層次，它代表著行動的動機(jī)和意義所在。在思考問題時，我們首先需要明確問題的根本動機(jī)、價值和意義。如果我們只關(guān)注做什么，而忽略了為什么做，那么很容易失去目標(biāo)、方向和動力。
2. 方法（How）：這一層次代表著問題的解決方案和實現(xiàn)途徑。在明確了為什么之后，我們需要思考如何實現(xiàn)目標(biāo)。這個過程包括了解問題域相關(guān)知識、分析解決方案的可行性、確定執(zhí)行計劃和資源等。
3. 行動（What）：這一層次是行動和執(zhí)行層次，代表著具體的行動和操作。在明確了為何和如何之后，我們需要根據(jù)具體情況和實際需求，確定具體的操作步驟和行動方案。

Why：提升效率的方向

在確定以增效為大目標(biāo)的前提下，我們側(cè)重通過架構(gòu)設(shè)計的優(yōu)化，流程調(diào)整，兩個方面去提升全球發(fā)行過程效率。參考阿里巴巴對于研發(fā)效能的定義公式：個體效率 x 協(xié)同效率 x 價值 = 研發(fā)效能。MBA知識庫，對于效能和效率的定義有很大的區(qū)別，本文重點(diǎn)把”效“論述為效率。能夠提升研發(fā)效能的影響變量有三個，其中價值這一選項，更多的是由業(yè)務(wù)能力范圍決定，本次實踐中并無業(yè)務(wù)增量，因此不是重點(diǎn)分析討論的方向?；诠剿季S，本次實踐的目標(biāo)可以拆解為兩個突破方向，提升個體效率和協(xié)同效率。

How：如何提升效率

接下來需要思考影響個體效率和協(xié)同效率的方法，即黃金圈法則How的問題。

個體效率

分析個體效率，首先需要明確個體的指向是誰？參與全球發(fā)行這個過程的主要個體，主要包括3類：游戲研發(fā)、發(fā)行平臺運(yùn)營、發(fā)行平臺技術(shù)。這三類個體的在發(fā)行過程中，影響其個體效率的主要因素如下：

1. 游戲研發(fā)：領(lǐng)域知識的認(rèn)知成本，SDK重復(fù)接入（背景提到的問題），文檔的可讀性，復(fù)雜的接入?yún)?shù)管理；
2. 平臺運(yùn)營：領(lǐng)域知識的認(rèn)知和解釋成本，復(fù)雜的接入?yún)?shù)管理；
3. 平臺技術(shù)：領(lǐng)域知識的認(rèn)知和解釋成本，架構(gòu)設(shè)計存在職責(zé)模糊，能力復(fù)用不夠，變更的影響面偏大；

基于以上三類主要個體效率影響分析，其中共性部分在于領(lǐng)域知識的認(rèn)知和解釋成本，其次是架構(gòu)設(shè)計的些許問題，比如參數(shù)管理分散，導(dǎo)致的不必要復(fù)雜度暴露。這些問題經(jīng)過整合，發(fā)現(xiàn)本質(zhì)是軟件工程領(lǐng)域的大型軟件系統(tǒng)的復(fù)雜度管理難題。

著名的計算機(jī)科學(xué)家Fred Brooks在《人月神話》中將軟件服務(wù)復(fù)雜度分為兩個大類：

1. 內(nèi)在復(fù)雜度：是由于軟件本身的復(fù)雜性而導(dǎo)致的。例如，業(yè)務(wù)領(lǐng)域知識、算法、數(shù)據(jù)結(jié)構(gòu)、接口設(shè)計等都屬于內(nèi)在復(fù)雜度。內(nèi)在復(fù)雜度表示的是系統(tǒng)本身的復(fù)雜度。
2. 外在復(fù)雜度：是由于軟件開發(fā)環(huán)境的復(fù)雜性而導(dǎo)致的。例如，多人協(xié)作、進(jìn)度安排、分布式系統(tǒng)等都屬于外在復(fù)雜度。

相對來說，全球發(fā)行基礎(chǔ)的業(yè)務(wù)能力，比如賬號、交易、合規(guī)、營銷等，可理解為在接入過程中的內(nèi)在復(fù)雜度，對這些領(lǐng)域知識的學(xué)習(xí)是必要的認(rèn)知成本。對于領(lǐng)域知識的組織和定義方式、文檔設(shè)計、架構(gòu)設(shè)計，可理解為系統(tǒng)的外在復(fù)雜度。針對軟件復(fù)雜度管理的課題，眾多軟件工程領(lǐng)域的大師以及行業(yè)前輩有過精彩的論述，在本節(jié)不做拓展說明。基于復(fù)雜度管理的常見策略，經(jīng)過分析后，我們決定從以下幾個方面著手控制全球發(fā)行的復(fù)雜度，試圖提升個體效率。

1. 業(yè)務(wù)領(lǐng)域知識對齊，明確領(lǐng)域模型術(shù)語，核心概念在溝通、設(shè)計和實現(xiàn)的保持一致。對齊重要性可參考DDD對于通用語言（UBIQUITOUS LANGUAGE）的論述；
2. 客戶端架構(gòu)升級，通過依賴反轉(zhuǎn)和適配器模式，建立全球發(fā)行統(tǒng)一的SDK API標(biāo)準(zhǔn)，屏蔽SDK群的接口差異，降低全球發(fā)行過程中開發(fā)的認(rèn)知負(fù)擔(dān)。
3. 服務(wù)端明確服務(wù)應(yīng)用邊界，能力復(fù)用；
4. 統(tǒng)一管理全球發(fā)行服務(wù)端API，避免長期迭代導(dǎo)致的標(biāo)準(zhǔn)丟失；

協(xié)同效率

針對協(xié)同效率，我們重點(diǎn)從參與全球發(fā)行過程中3類個體，以及關(guān)聯(lián)個體的系統(tǒng)和流程處分析可優(yōu)化空間。

圖片

1、游戲研發(fā)與發(fā)行技術(shù)：二者交互連接的產(chǎn)品是對接文檔、SDK、API，以上產(chǎn)品作為發(fā)行領(lǐng)域知識的展示窗口，一定程度上影響游戲研發(fā)的接入效率。核心領(lǐng)域術(shù)語的對齊對于溝通效率的價值是顯而易見的。其次、現(xiàn)有的文檔主次和業(yè)務(wù)邏輯表達(dá)不夠清晰直觀，也會影響研發(fā)對于SDK和API的理解，這會帶來多次溝通確認(rèn)，影響效率的同時，也影響了工作體驗和游戲發(fā)行技術(shù)品牌。

2、平臺技術(shù)與平臺運(yùn)營之間，在全球發(fā)行過程中的連接產(chǎn)品主要集中在3個方面，全球發(fā)行后臺游戲入庫、研發(fā)母包到渠道打包系統(tǒng)、接入?yún)?shù)管理。首先游戲入庫是一個復(fù)雜的過程，這一塊的自動化還有提升空間。其次、在發(fā)行過程中全球發(fā)行后臺與渠道打包系統(tǒng)并未完全融合，會導(dǎo)致存在部分能力的重復(fù)建設(shè)，以及人為連接帶來的工作量。

3、游戲研發(fā)與發(fā)行平臺運(yùn)營之間，主要的連接部分在于接入?yún)?shù)管理、接入答疑、以及項目管理?，F(xiàn)階段接入?yún)?shù)類型眾多，在不同的地區(qū)、合規(guī)政策、依賴資源等各種背景疊加下，經(jīng)過整理后，一款待全球發(fā)行的接入?yún)?shù)可能多大300+，這些紛繁復(fù)雜參數(shù)背后的都是基于人力管理。其次、接入過程答疑的主要影響因素在于對接文檔、SDK、API的設(shè)計，這也是可以優(yōu)化的方向。

基于以上分析，我們決定從以下幾個方面著手，提升協(xié)同效率：

• 建立全球發(fā)行SDK統(tǒng)一接入層ONE SDK，讓游戲研發(fā)實現(xiàn)一次接入，
• 全球發(fā)行。
•  全球發(fā)行系統(tǒng)建設(shè)

a. 多套舊版發(fā)行管理系統(tǒng)聚合統(tǒng)一，基于全球發(fā)行游戲項目與發(fā)行計劃建設(shè)統(tǒng)一的全球發(fā)行管理系統(tǒng)。

b. 基于全球發(fā)行管理系統(tǒng)，統(tǒng)一、規(guī)范管理發(fā)行計劃的各類參數(shù)/配置項；

c. 渠道打包系統(tǒng)架構(gòu)升級，依托參數(shù)統(tǒng)一管理支持Android全球渠道打包，不僅局限于自研游戲在大陸安卓渠道的聯(lián)運(yùn)業(yè)務(wù)。

• 工具支持，自動接入自檢、測試；
• 梳理接入流程。

What：提升效率的行動路線

基于黃金圈法則Why和How的分析，最后我們拆解制定的行動路線如下：

圖片

挑戰(zhàn)

基于以上背景和目標(biāo)，整體項目挑戰(zhàn)將來源于以下4個方面：

1、標(biāo)準(zhǔn)化：多套異構(gòu)API，如何統(tǒng)一規(guī)格，并降低研發(fā)的理解成本，同時對外又保持較高的水準(zhǔn)；

2、自動化：如何屏蔽不同地區(qū)、設(shè)備、合作模式下的接入復(fù)雜度，提高接入效率；

3、兼容性：游戲業(yè)務(wù)在過去幾年的高速發(fā)展中，發(fā)行業(yè)務(wù)逐漸搭建了一套功能完善且復(fù)雜度較高的平臺級應(yīng)用架構(gòu)。隨著組織的擴(kuò)張與分工的精細(xì)化，對當(dāng)前平臺架構(gòu)具有全盤把握者較少，如何做到整體提效的同時，兼容現(xiàn)有架構(gòu)本身，其難度巨大。

4、影響面：游戲底層模型的變更，幾乎牽涉到發(fā)行技術(shù)中臺所有的技術(shù)團(tuán)隊和發(fā)行業(yè)務(wù)團(tuán)隊；部分新概念的提出，需要達(dá)成平臺級的概念共識。

實踐

1、個體效率

1.1、復(fù)雜度管理

1.1.1、統(tǒng)一領(lǐng)域核心術(shù)語

bilibili多年以來全球發(fā)行的業(yè)務(wù)經(jīng)驗，產(chǎn)生了較多的的領(lǐng)域名詞和術(shù)語。如果在發(fā)行平臺內(nèi)部不能做到核心術(shù)語的統(tǒng)一，這其中的溝通和設(shè)計復(fù)雜度可想而知，更何況大多數(shù)時候，我們需要向游戲研發(fā)傳達(dá)相關(guān)概念和設(shè)計細(xì)節(jié)。即使對于一個在bilibili國內(nèi)發(fā)行平臺有不少工作經(jīng)驗的業(yè)務(wù)研發(fā)同學(xué)，理解什么是”無標(biāo)“和”賬號域“已是難事，更何況各種概念之間的關(guān)系。因此，整理領(lǐng)域核心術(shù)語，及其之間的邏輯關(guān)系是執(zhí)行的基礎(chǔ)。經(jīng)整理設(shè)計后的核心概念分層如下圖：

圖片

常見核心概念主要分為4層：

發(fā)行地區(qū)

常見的劃分方式是以物理地區(qū)劃分為主，主要區(qū)為國內(nèi)大陸地區(qū)、港澳臺（中國）、東南亞、歐美等等；

發(fā)行品牌

中國大陸地區(qū)常用品牌為bilibili、白板、代號D，港澳臺和海外常用品牌為代號K、bilibili、以及白板（也稱“無標(biāo)”）；

下載渠道

全球發(fā)行過程中提供下載能力的渠道，比如：國內(nèi)bilibili提供安卓游戲下載，Apple Store 提供IOS游戲下載，國內(nèi)的UO渠道目前有70+，海外重點(diǎn)Google Play，Apple Store，Mycard，One Store等等；

賬號域

海外架構(gòu)中依賴的概念，賬號域決定了應(yīng)用部署、數(shù)據(jù)隔離等需求場景，通常和發(fā)行地區(qū)的法律法規(guī)相關(guān)。

1.1.2、統(tǒng)一業(yè)務(wù)詞匯/命名風(fēng)格

Martin Flower在他的演講和著作中，多次強(qiáng)調(diào)命名的重要性，認(rèn)為好的命名是編寫高質(zhì)量軟件的關(guān)鍵因素之一。他認(rèn)為好的命名實踐應(yīng)該具備的特質(zhì)是：清晰直觀、目的明確、風(fēng)格統(tǒng)一。有些同學(xué)可能會認(rèn)為這是自然而然的事情，但是對于一個演進(jìn)了多年的大型系統(tǒng)來說這絕非必然。統(tǒng)一且直觀命名，符合直覺和經(jīng)驗對于學(xué)習(xí)效率的價值是巨大的。

圖片

基于以上實踐特質(zhì)，結(jié)合統(tǒng)一的領(lǐng)域術(shù)語和詞匯，我們建立的URL PATH命名約束簡潔示意如下：

圖片

最終我們的PATH如下：/one/user/session.verify、/one/trade/order.query、/one/security/censor

1.2、架構(gòu)升級/優(yōu)化

1.2.1、全球發(fā)行整體架構(gòu)如下

圖片

1.2.2、服務(wù)端架構(gòu)優(yōu)化（ONE API）

1、明確應(yīng)用邊界：基于領(lǐng)域驅(qū)動應(yīng)用分層模型，將原有各子領(lǐng)域單獨(dú)對外提供服務(wù)的API，統(tǒng)一收斂到領(lǐng)域服務(wù)，對外通過應(yīng)用服務(wù)暴露API與游戲研發(fā)交互，統(tǒng)一收口。同時解決部分業(yè)務(wù)需求評審?fù)瓿珊?，代碼寫在哪里的問題。

2、統(tǒng)一管理ONE API：統(tǒng)一的ONE API代碼倉庫，對于接口的定義，直接依賴Jar包，防止在后續(xù)長期迭代過程中的”走樣“。

1.2.3、ONE SDK設(shè)計與實現(xiàn)

ONE SDK設(shè)計遵循依賴反轉(zhuǎn)（Dependency inversion principle）原則，通過ONE SDK抽象定義全球發(fā)行背景下的API接口。

ONE SDK通過適配層兼容現(xiàn)有的SDK群，達(dá)成能力復(fù)用，同時實現(xiàn)ONE SDK與SDK群在過渡期的共存。

1.2.3.1、ONE SDK 分包策略

圖片

1、ONE Android SDK以aar架包，ONE iOS SDK以framework的形式提供給游戲研發(fā)。

2、Android按照各個業(yè)務(wù)差別劃分為7個子aar。其中ONE SDK Main Lib和ONE SDK BaseLib為核心組件，包含核心登錄和支付功能，游戲必須接入。剩余的5個的AAR為選接項。

3、iOS按照業(yè)務(wù)區(qū)別以拆分頭文件的形式將功能劃分為5個模塊，同樣的ONE SDK Main Lib作為核心組件，包含核心登錄和支付功能，游戲必須接入。其他為選接項。

4、ONE SDK以多aar和多頭文件形式提供，避免游戲接入冗余業(yè)務(wù)組件，降低了SDK項目耦合性，提高了游戲代碼的效率。

5、在實際使用過程中，游戲可根據(jù)自己的發(fā)行計劃和實際需要使用的業(yè)務(wù)功能，選擇接入對應(yīng)的aar和iOS頭文件到游戲中。

舉個例子：a 游戲只發(fā)行國內(nèi)B服渠道且只有登錄和支付功能。則只需接入ONE SDK Main Lib和ONE SDK BaseLib兩個aar包即可實現(xiàn)發(fā)行需求。其余的aar則不需要接入項目。b 游戲發(fā)行渠道為國內(nèi)B服渠道和海外Google渠道。需要使用登錄和支付功能、谷歌積分兌換功能，則需接入ONE SDK Main Lib和ONE SDK BaseLib、ONE SDK Google Ext 3個aar包。其余的aar不需要接入項目。

1.2.3.2、整體架構(gòu)設(shè)計

圖片

1、ONE SDK在現(xiàn)有海外發(fā)行SDK、渠道發(fā)行SDK、B服發(fā)行SDK基礎(chǔ)上，對現(xiàn)有的業(yè)務(wù)進(jìn)行了規(guī)劃與統(tǒng)一，形成了統(tǒng)一的全球發(fā)行業(yè)務(wù)接口。全球發(fā)行業(yè)務(wù)接口主要分為2部分。

      a、各個發(fā)行SDK的獨(dú)有的業(yè)務(wù)，如海外Google渠道的商品積分兌換業(yè)務(wù)、B服發(fā)行SDK的獲取B站好友關(guān)系業(yè)務(wù)等，保留了原有的接口形式對外提供，降低cp接入時的理解難度和接入復(fù)雜度。

      b、各個發(fā)行SDK的共有的業(yè)務(wù)，如登錄、支付等，在現(xiàn)有業(yè)務(wù)SDK接口基礎(chǔ)上對接口參數(shù)取并集，抽象出涵蓋所有渠道的業(yè)務(wù)需求的全球發(fā)行業(yè)務(wù)接口，抹平各個渠道的業(yè)務(wù)差異性，保證cp一次接入全球通用發(fā)行。

2、根據(jù)發(fā)行計劃的不同，游戲的使用場景不同。將統(tǒng)一的全球發(fā)行業(yè)務(wù)接口對外提供形式上進(jìn)行了包體拆分。見上文1.2.3.1、ONE SDK 分包策略。提供了 “聚合標(biāo)準(zhǔn)發(fā)行模型 + 支持高自由度擴(kuò)展”的接入模式。

3、ONE SDK通過對外的標(biāo)準(zhǔn)接口aar、iOS頭文件和Adapter適配器，將游戲的意圖轉(zhuǎn)發(fā)到具體的業(yè)務(wù)渠道SDK。

      a、ONE SDK抽象定義并對外提供了全球發(fā)行各個業(yè)務(wù)接口，并且只是業(yè)務(wù)接口，不包含任何具體的業(yè)務(wù)實現(xiàn)。隔離了游戲和具體業(yè)務(wù)渠道間的耦合。

      b、Adapter適配器能夠?qū)⒂螒蛲ㄟ^標(biāo)準(zhǔn)業(yè)務(wù)接口發(fā)出業(yè)務(wù)意圖轉(zhuǎn)發(fā)給各個具體的業(yè)務(wù)渠道SDK。起到了承上啟下的作用。完美的適配并支持了所有的現(xiàn)有發(fā)行渠道SDK。

      c、游戲只需要調(diào)用對應(yīng)的業(yè)務(wù)接口，就可以實現(xiàn)對應(yīng)的業(yè)務(wù)功能。游戲無需關(guān)心各業(yè)務(wù)在各渠道上的差異，具體的業(yè)務(wù)功能實現(xiàn)由Adapter適配器轉(zhuǎn)發(fā)給具體的發(fā)行渠道SDK，并由具體的發(fā)行渠道SDK完成業(yè)務(wù)功能。

2、協(xié)同效率

2.1、全球發(fā)行系統(tǒng)

2.1.1、  老系統(tǒng)的困境

困境1：

一個自研游戲或者獨(dú)家代理的外部游戲要進(jìn)行全球發(fā)行，和發(fā)行平臺第一個協(xié)作就是平臺接入。全球發(fā)行工作接入階段需要涉及的老版發(fā)行管理系統(tǒng)就有4個，分別國內(nèi)游戲發(fā)行管理系統(tǒng)(主要負(fù)責(zé)B站游戲中心渠道、iOS渠道發(fā)行管理)、渠道發(fā)行管理系統(tǒng)(國內(nèi)安卓渠道發(fā)行管理,例如華為、小米、OPPO）、海外BILI游戲發(fā)行管理系統(tǒng)(海外發(fā)行管理,海外Google/iOS、Mycard、ONEStore)，海外K品牌游戲發(fā)行管理系統(tǒng)。而其他在非接入階段大大小小的管理系統(tǒng)，甚至多達(dá)十幾個，包括渠道打包、BI系統(tǒng)、活動系統(tǒng)、包管理等等。

由于歷史上各個管理系統(tǒng)可能由不同的團(tuán)隊負(fù)責(zé)，沒有統(tǒng)籌治理，導(dǎo)致系統(tǒng)間一些相同相似業(yè)務(wù)模型概念對不齊，業(yè)務(wù)同學(xué)理解使用成本高，最終結(jié)果是很多管理系統(tǒng)只有技術(shù)人員才會才敢使用。

困境2：

同一款游戲在接入安卓和iOS時，需要感知的是兩套接入?yún)?shù)，即兩個game_id。在獨(dú)代游戲情況下，如果存在聯(lián)運(yùn)的業(yè)務(wù)，其所感知的游戲參數(shù)需要三套及以上，隨著發(fā)行品牌和地區(qū)的擴(kuò)展，研發(fā)需要感知的發(fā)行參數(shù)呈指數(shù)遞增。在各種對接過程中，特別是同時對接多SDK甚至多地區(qū)的游戲，多套game_id接入?yún)?shù)差異導(dǎo)致的接入問題對CP和平臺技術(shù)有很大困擾，需要花費(fèi)不少的時間精力去排查問題。

既然是同一個游戲，同一個CP，同一個發(fā)行平臺，能否實現(xiàn)一套參數(shù)、一個后臺、一次接入的小目標(biāo)？

困境3：

由于渠道多、功能模塊多，接入過程中涉及的大量接入?yún)?shù)/配置項管理也是一個難題。

以海外Google包為例，內(nèi)部包含Google/iOS登錄，多個社交分享(facebook/twitter等)、多套市場歸因營銷相關(guān)服務(wù)（firebase/appsflyer/adjust）、AIHELP客服等眾多模塊，單包涉及的相關(guān)參數(shù)超過40+。這些參數(shù)來源多個平臺，由平臺運(yùn)營發(fā)出申請，由市場、項管、客服等多個部門去對應(yīng)平臺生成，最終可能分多次提供給研發(fā)。其中存在大量的secret/key相關(guān)參數(shù)名，無論是平臺運(yùn)營還是研發(fā)理解心智成本非常大。

圖片

而目前僅一些核心的后端賬號支付模塊參數(shù)才會在統(tǒng)一在后臺管理，大量僅客戶端依賴的參數(shù)，還在依賴人力管理。參數(shù)的流轉(zhuǎn)仍然在依賴傳統(tǒng)的郵件流，流轉(zhuǎn)過程中可能會產(chǎn)生多個副本，一旦發(fā)生變更，需要多方確認(rèn)調(diào)整。

整套參數(shù)管理流程不僅影響接入溝通效率，還存在很大規(guī)范問題與安全隱患。

2.1.2、 全球發(fā)行系統(tǒng)

那全球發(fā)行系統(tǒng)如何打破以往僵局？

首先很自然的想法是進(jìn)行多系統(tǒng)聚合。這些發(fā)行系統(tǒng)核心的職責(zé)，本質(zhì)就是安全合規(guī)的將游戲分發(fā)到不同地區(qū)不同渠道。不管是國內(nèi)BILI游戲中發(fā)行、iOS發(fā)行、國內(nèi)渠道發(fā)行、海外發(fā)行本質(zhì)做的是一致的業(yè)務(wù)，但是分散的系統(tǒng)必然會出現(xiàn)業(yè)務(wù)概念的分歧。

那這些系統(tǒng)本質(zhì)區(qū)別在哪里呢？核心點(diǎn)在于支持的【游戲、地區(qū)、品牌、渠道】不同?！镜貐^(qū)】【品牌】【渠道】是前面【統(tǒng)一領(lǐng)域核心術(shù)語】提到的重要但是卻也是非常簡單、直觀的概念。而【游戲】模型的定義是一個難點(diǎn)。

2.1.2.1 老發(fā)行系統(tǒng)中的‘游戲’模型

嗶哩嗶哩游戲業(yè)務(wù)，以最開始的聯(lián)運(yùn)業(yè)務(wù)開始，隨著發(fā)展的壯大，逐漸搭建出多地區(qū)、多品牌的全球發(fā)行模型。在業(yè)務(wù)底層的建模上，對于游戲的定義主要分為兩層。

1、game：最底層承擔(dān)的職責(zé)主要包括：游戲?qū)拥腟DK信息、接入秘鑰、支付參數(shù)、渠道上架、APP合規(guī)、運(yùn)營控制等等。每個game_id對應(yīng)研發(fā)需要感知的接入?yún)?shù)。

2、game_base：基于game之上，構(gòu)建的抽象實體，其職責(zé)是承接游戲?qū)τ谄放?、地區(qū)的定義。

其層次和主要職責(zé)示意如下：

圖片

2.1.2.2 全球發(fā)行'游戲'模型：GlobalGame

在現(xiàn)有的架構(gòu)設(shè)計中，對于一款游戲的實際定義，是基于對接的SDK來區(qū)分的，每套SDK對應(yīng)一套參數(shù)。隨著多品牌、多地區(qū)的發(fā)行策略的落地，研發(fā)需要感知的發(fā)行參數(shù)呈幾何遞增。

實現(xiàn)“一次接入，全球發(fā)行”，需要囊括所有的品牌和地區(qū)，因此在現(xiàn)有的架構(gòu)定義中，不管是現(xiàn)有的game_id，還是抽象的game_base_id都無法承擔(dān)全球游戲項目的邏輯職責(zé)。

對外，要實現(xiàn)“一次接入，全球發(fā)行”的目標(biāo)，勢必不能再將多套參數(shù)的復(fù)雜度暴露。對內(nèi)，由于舊游戲模型已經(jīng)應(yīng)用到游戲發(fā)行技術(shù)中的各個團(tuán)隊和項目，如果調(diào)整現(xiàn)有架構(gòu)中對于游戲的定義方式，勢必影響面巨大，其范圍牽涉整個游戲發(fā)行技術(shù)中臺，大面積的變更甚至導(dǎo)致業(yè)務(wù)迭代阻塞。

因此，基于開閉原則，我們在原有游戲模型基礎(chǔ)上做了一些拓展，引入的全球游戲項目GlobalGame的概念，基本不修改原有模型。

圖片

對外，游戲研發(fā)對于全球接入?yún)?shù)的感知，將以全球游戲項目(global_game)為基準(zhǔn)，而不是每個game_id一套；對內(nèi)，各業(yè)務(wù)部門仍然現(xiàn)有邏輯基本無需改造，當(dāng)然也可以在合適的時機(jī)去適配全球游戲發(fā)行項目。

2.1.2.3  發(fā)行計劃

當(dāng)我們決定以global_game_id為首，解決全球發(fā)行過程中游戲研發(fā)對于一次接入的參數(shù)問題，接下來需要面對的問題是：如何讓發(fā)行技術(shù)平臺對于游戲的定義從game_id無縫切換到global_game_id，實現(xiàn)低成本的平滑過渡？

在這個問題上，我們的思考方向有兩個：

其一、SDK到發(fā)行平臺服務(wù)端，游戲在架構(gòu)初期就設(shè)計了ONE SDK到SDK群的適配層，在適配層實現(xiàn)global_game_id到game_id的映射，因此極大的簡化了現(xiàn)有SDK群到服務(wù)端的工作量 ，同時保證了在未來研發(fā)繼續(xù)使用現(xiàn)有SDK和使用ONE SDK同時對接的可能。

其二、游戲研發(fā)服務(wù)端到發(fā)行平臺服務(wù)端（包含：發(fā)行服務(wù)端、數(shù)據(jù)、社區(qū)、營銷），在無法感知game_id的情況下，與發(fā)行平臺服務(wù)端對接的過程中，使用以全球游戲項目Id為首的接入?yún)?shù)與平臺服務(wù)端對接?；诜謱蛹軜?gòu)，應(yīng)用服務(wù)層（ONE API BFF）接收到全球游戲項目Id為首的請求參數(shù)后，無法實現(xiàn)對于下游領(lǐng)域服務(wù)的路由調(diào)用。比如：手游、端游、聯(lián)運(yùn)各自的發(fā)行領(lǐng)域服務(wù)，在原本基于業(yè)務(wù)做了領(lǐng)域服務(wù)垂直拆分的情況下，ONE API BFF如何與下游領(lǐng)域服務(wù)“交互”，變成了平臺服務(wù)端架構(gòu)兼容的直接問題。同時，這個問題在其他的發(fā)行業(yè)務(wù)團(tuán)隊同樣會面臨，比如交易、數(shù)據(jù)、廣告、游戲中心、活動營銷等。

分析第二個細(xì)分問題，其本質(zhì)是原來粒度較細(xì)的游戲定義方式（簡稱game_id）在優(yōu)化后的對接過程中，被收斂為全球游戲項目Id之后，該怎么與現(xiàn)有的發(fā)行平臺架構(gòu)兼容的問題。我們將這個問題用公式表達(dá)如下：游戲接入Id（game_id） = 全球游戲項目Id (global_game_id) + 其他？

在這個環(huán)節(jié)我們一開始想到的解決方式有如下三個，下文簡單歸納對比方案影響面和優(yōu)缺點(diǎn)，以及我們最終在方案選型中的一些思考。

圖片

經(jīng)過分析討論，方案一最終被選擇的主要原因在于概念的統(tǒng)一和明確，基于上文的核心術(shù)語并未再做擴(kuò)展。理解成本在這次討論中被用作重要的參考維度，其主要原因也是由于業(yè)務(wù)屬性所決定，在全球發(fā)行過程中，鏈路較長，涉及領(lǐng)域知識很多，在沒有必要的情況下，我們奉行的原則是Less is more。做到不違反直覺，降低外在系統(tǒng)復(fù)雜度，其本身也是一種架構(gòu)設(shè)計應(yīng)該要具備的利他心理，這也是我們排除方案二和方案三的原因。

基于方案一的 全球游戲項目GlobalGame，結(jié)合【地區(qū)】【品牌】【渠道】，我們再往上再抽象一層，于是有了【發(fā)行計劃】的概念，比如全球游戲項目【FGO】計劃在【中國大陸】使用【bilibili】品牌上架【BILI游戲中心】這就是一個發(fā)行計劃。

圖片

基于全球游戲項目【GlobalGame】【發(fā)行計劃】，很自然可以將原本的多套發(fā)行管理系統(tǒng)統(tǒng)一聚合起來，去實現(xiàn)一套真正的【全球發(fā)行管理系統(tǒng)】。

圖片

2.1.3、參數(shù)管理

參數(shù)管理是接入過程中對效率影響比較大的一個部分，主要是以下3個痛點(diǎn)

• 內(nèi)外部理解成本大
• 缺少系統(tǒng)化管理
• 研發(fā)接入?yún)?shù)多，接入成本高

問題明確，接下來就是全球發(fā)行系統(tǒng)有針對性去解決。

參數(shù)多且雜，只能靠笨辦法解決。

我們從參數(shù)歸屬的功能模塊（是什么，what）、參數(shù)來源(誰負(fù)責(zé)在哪生成，from)、參數(shù)使用（誰使用  to）以及額外生成、使用文檔這些方面去全面梳理了各個渠道各個模塊需要的參數(shù)，并落到系統(tǒng)使用手冊。

下面是港澳臺Google渠道相關(guān)參數(shù)梳理列表。

圖片

參數(shù)梳理完成，自然要在全球發(fā)行系統(tǒng)統(tǒng)一管理。

參數(shù)負(fù)責(zé)人員在對應(yīng)平臺生產(chǎn)參數(shù)后，確認(rèn)歸屬的游戲和對應(yīng)發(fā)行計劃，即可根據(jù)功能模塊分類錄入進(jìn)全球發(fā)行系統(tǒng)。

統(tǒng)一權(quán)限系統(tǒng)來保障數(shù)據(jù)安全，統(tǒng)一日志平臺則負(fù)責(zé)記錄每一次變更與查詢。

圖片

如何解決研發(fā)接入?yún)?shù)配置項多的問題？

研發(fā)接入BILI發(fā)行平臺，真的需要感知這么多SDK內(nèi)部細(xì)節(jié)么？

其實不需要。我們參考了接入Google、Firebase等平臺的接入方式，接入物料只需要一個google-services.json/firebase.json文件，而不必感知被接入服務(wù)過多細(xì)節(jié)。

圖片

那我們?nèi)虬l(fā)行系統(tǒng)就可以根據(jù)配置的參數(shù)生成一個客戶端SDK需要的配置文件(sdk-service.json)，里面包含各個模塊相關(guān)配置，交付研發(fā)后，研發(fā)只需要將文件放在指定位置，SDK即可獲取需要的相關(guān)參數(shù)。這個過程中，研發(fā)無需感知具體模塊相關(guān)參數(shù)。

圖片

參數(shù)治理，參數(shù)封裝是簡化研發(fā)在對接過程中非常重要的一部分。完成參數(shù)治理后，全球發(fā)行系統(tǒng)還可以通過內(nèi)部API為全球打包系統(tǒng)的提供渠道打包需要的所有參數(shù)配置，以前大部分耗時耗力的人工配置流程都可以在此基礎(chǔ)通過自動化得到解決。

2.2、全球發(fā)行打包系統(tǒng)

2.2.1 、ONE SDK渠道業(yè)務(wù)融合替換

圖片

1、游戲集成ONE SDK默認(rèn)要求接入B服渠道業(yè)務(wù)（國內(nèi)bili渠道），方便游戲研發(fā)進(jìn)行接入結(jié)果驗證。完成了ONE SDK的集成，游戲產(chǎn)物APK和IAP即可發(fā)布在國內(nèi)Bili渠道和國內(nèi)蘋果渠道上。

2、Android端：游戲產(chǎn)物APK稱之為"母包"。母包通過多渠道打包系統(tǒng)，結(jié)合反編譯&回編技術(shù)，將具體的業(yè)務(wù)實現(xiàn)（國內(nèi)bili渠道）移除，融合進(jìn)其他業(yè)務(wù)渠道代碼，回編生成具體的業(yè)務(wù)渠道APK。

3、iOS端：無法使用反編譯技術(shù)， 打包系統(tǒng)通過腳本修改游戲原始Xcode工程，實現(xiàn)業(yè)務(wù)渠道切入

4、通過打包系統(tǒng)，即可實現(xiàn)游戲一次接入，多渠道多品牌發(fā)行。包括但不限于國內(nèi)B服、Apple、小米、華為、OV、360、應(yīng)用寶、海外Goolge、海外OneStore、海外Mycard等。

2.2.2、Android 全球渠道打包系統(tǒng)

2.2.2.1、打包能力整合

原全球各渠道的接入、打包流程如下圖：

圖片

由于主體不同，上架渠道不同，每個主體和渠道都有自己的sdk，因此通常情況都是由游戲自行接入需要上架渠道的sdk，如B服，海外渠道的打包流程。

但是對于我們的獨(dú)代游戲，我們需要幫助游戲發(fā)行到所有的渠道上，這些渠道多達(dá)幾十個；我們不可能讓渠道接入幾十個sdk并且自行出包，在這個業(yè)務(wù)場景下，渠道發(fā)行設(shè)計了UOSDK，游戲只需要接入一次UOSDK，然后通過我們的渠道打包系統(tǒng)就能完成所有渠道的出包。具體的游戲渠道打包原理和方案可以參考《渠道發(fā)行的Android多渠道打包實踐》。

如果要統(tǒng)一全球的出包動作，那么就要基于現(xiàn)有的渠道打包系統(tǒng)，并且兼容ONE SDK的邏輯設(shè)計一套新的打包流程，讓CP可以只接入一個SDK就能完成所有渠道的打包任務(wù)。

2.2.2.2、原國內(nèi)渠道打包系統(tǒng)

由于之前游戲業(yè)務(wù)系統(tǒng)眾多，國內(nèi)渠道打包系統(tǒng)的數(shù)據(jù)管理采用本地創(chuàng)建、管理的方式，有新游戲接入先在打包系統(tǒng)創(chuàng)建游戲、渠道以及游戲-渠道關(guān)系數(shù)據(jù)。在打包的時候通過讀取本地數(shù)據(jù)庫來獲取待出包游戲的渠道列表，提供給用戶選擇、出包。

具體的打包流程如下圖所示：

圖片

2.2.2.3、基于ONE的全球打包系統(tǒng)

多系統(tǒng)打通之后，全球發(fā)行的游戲在所有渠道上的的參數(shù)和配置統(tǒng)一收口，在打包的環(huán)節(jié)可以通過統(tǒng)一的地方獲取到全球所有渠道的參數(shù)以及配置，通過腳本自動化生成本地的打包配置，解決的數(shù)據(jù)分散的問題和人工創(chuàng)建配置的成本。

改造后的打包流程如下圖所示：

圖片

2.2.3、iOS  全球渠道打包系統(tǒng)

為了在游戲開發(fā)中接入或替換其他渠道的SDK，通常需要完成以下步驟：

1. 導(dǎo)入SDK資源：將SDK的資源文件導(dǎo)入到項目中，例如靜態(tài)庫、源代碼、配置文件等。
2. 接入SDK接口并填寫SDK入?yún)ⅲ赫{(diào)用SDK提供的API接口，并根據(jù)SDK的要求填寫必要的參數(shù)，以便實現(xiàn)對應(yīng)的功能。
3. 配置工程相關(guān)參數(shù)：根據(jù)SDK文檔中的要求配置項目相關(guān)參數(shù)，例如編譯選項、鏈接選項、Build Settings等。
4. 配置SDK依賴項：如果SDK需要依賴其他庫或框架，需要將這些依賴項添加到項目中，并設(shè)置正確的路徑和編譯選項。
5. 配置開發(fā)者證書，并導(dǎo)出IPA包：將項目打包成IPA包，并使用正確的開發(fā)者證書簽名，以便在設(shè)備上安裝和運(yùn)行。

為了簡化研發(fā)流程，我們可以使用打包工具自動引入或替換渠道SDK，生成參數(shù)文件，并幫助游戲自動修改項目配置和依賴項。這樣，研發(fā)同學(xué)只需要關(guān)注SDK接口接入和證書選擇等操作，即可通過一鍵配置工具快速集成SDK，并導(dǎo)出可用的IPA包，從而大大提高研發(fā)效率，同時也能幫助規(guī)避接入過程中的常見問題。

圖片

3、方案兼容

3.1、 管理系統(tǒng)兼容

未來兩套系統(tǒng)也還會并存一段較長的時間，如何過渡與兼容也是在設(shè)計之初就考慮的一個問題。我們期望全球發(fā)行系統(tǒng)的設(shè)計本質(zhì)上是基于老系統(tǒng)的重新組織、定義、拓展，并非打破重來。

兼容的基本原則：入口層統(tǒng)一，概念統(tǒng)一，數(shù)據(jù)存儲層不做更改，只做少量拓展。

由于底層數(shù)據(jù)的互通，新老系統(tǒng)本質(zhì)上只需要做一下流程映射即可，相互映射的流程理論上完全對等，數(shù)據(jù)互通，不管在新系統(tǒng)老系統(tǒng)只需要執(zhí)行一遍即可。技術(shù)同學(xué)在新系統(tǒng)開發(fā)過程，基于流程映射表，則需要保障老流程也正常運(yùn)行。

通過這種方式保障兼容性，業(yè)務(wù)同學(xué)可以獲得比較好的過度體驗，畢竟新系統(tǒng)推廣與建設(shè)也需要逐步進(jìn)行。

下面是新老系統(tǒng)部分流程映射表，

圖片

3.2、 低成本遷移全球發(fā)行系統(tǒng)

老系統(tǒng)中一個游戲國內(nèi)、海外各品牌發(fā)行，分別屬于不同的基礎(chǔ)游戲（GameBase），沒有關(guān)聯(lián)，遷移到新系統(tǒng)后需要將本質(zhì)上同一個游戲不同地區(qū)品牌對應(yīng)的【基礎(chǔ)游戲GameBase】信息的發(fā)行 歸屬到【全球游戲項目（ GlobalGame）】下，系統(tǒng)會基于原有的發(fā)行數(shù)據(jù)自動生成發(fā)行計劃。

圖片

如果準(zhǔn)備將出包流程也遷移到全球打包系統(tǒng)，只需要將老系統(tǒng)中客戶端出包依賴但是仍未進(jìn)行系統(tǒng)管理的參數(shù)補(bǔ)充完善即可。

參考

1、《How great leaders inspire action》 https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action/c

2、《人月神話》FrederickP.Brooks.Jr.

3、《Application Boundary》 https://martinfowler.com/bliki/ApplicationBoundary.html

4、《領(lǐng)域驅(qū)動設(shè)計 軟件核心復(fù)雜性應(yīng)對之道》Eric Evans

5、《渠道發(fā)行的Android多渠道打包實踐》嗶哩嗶哩技術(shù) Claud. https://mp.weixin.qq.com/s/0zOFNpdaCmghBSyuJ6DKuQ

6、《從效能公式解構(gòu)研發(fā)效能》 https://developer.aliyun.com/article/1120300

7、《對抗軟件復(fù)雜度的戰(zhàn)爭》 https://mp.weixin.qq.com/s/Dil5Ual1aI_7dsGKV0f6Ig

本期作者

豐富 嗶哩嗶哩資深開發(fā)工程師

孫鵬 嗶哩嗶哩資深開發(fā)工程師

陳震炳 嗶哩嗶哩資深開發(fā)工程師

嚴(yán)林紅 嗶哩嗶哩資深開發(fā)工程師