Passport SDK的設(shè)計(jì)與技術(shù)細(xì)節(jié)實(shí)例分析

　　58 趕集集團(tuán)旗下?lián)碛卸鄠€(gè) App，且全部使用同一套賬號(hào)體系，通過 Passport 部門提供的接口進(jìn)行通信。經(jīng)過多年迭代，各個(gè) App 中關(guān)于 Passport 的功能均出現(xiàn)了一些流程和接口上的差異。為了提高賬號(hào)安全，統(tǒng)一服務(wù)接口和流程，提高用戶體驗(yàn)，由此決定開發(fā)了一個(gè) Passport SDK，以集成 Passport 的相關(guān)功能，并提供給集團(tuán)內(nèi)各業(yè)務(wù) App 使用。

　　在項(xiàng)目開始之初，我們?cè)?a target='_blank' class='arckwlink_none'>公司內(nèi)經(jīng)過調(diào)研發(fā)現(xiàn)在使用 SDK 時(shí)，大家最關(guān)心的問題就是 SDK 使用起來是否簡(jiǎn)單，即接口是否簡(jiǎn)單、調(diào)用流程是否簡(jiǎn)單、迭代升級(jí)是否簡(jiǎn)單?；谶@幾個(gè)關(guān)鍵問題，我們把設(shè)計(jì)目標(biāo)定為：將原本 Passport 功能中繁瑣的流程變成 Passport SDK 中簡(jiǎn)單的功能調(diào)用和結(jié)果處理，讓使用 Passport 功能的開發(fā)者不再需要關(guān)心那些數(shù)量龐大而又無關(guān)緊要的部分，取而代之的是享有一個(gè)非常良好的開發(fā)體驗(yàn)。由此，我們將設(shè)計(jì)原則定為：

　　接口要精簡(jiǎn)；

　　服務(wù)的流程要黑盒；

　　無感知的迭代升級(jí)。

　　確定了設(shè)計(jì)原則后，下一步就是明確核心需求。Passport SDK 旨在為 58 同城賬號(hào)體系下的用戶提供通用的登錄相關(guān)服務(wù)頁面和接口。所以我們的 SDK 核心需求是提供服務(wù)，即通用服務(wù)頁面和通用服務(wù)接口，并在用戶調(diào)用服務(wù)后返回其結(jié)果。

　　設(shè)計(jì)簡(jiǎn)單且有效的接口

　　首先我們從需求上明確接口有哪些？答案是數(shù)據(jù)接口與服務(wù)接口，具體如下：

　　數(shù)據(jù)接口是一些零散的數(shù)據(jù)存取操作，實(shí)際上無法做出太多的精簡(jiǎn)。

　　服務(wù)接口包括各種服務(wù)頁面的調(diào)起和服務(wù)接口的調(diào)用：在服務(wù)頁面中，App 用戶與服務(wù)頁面的交互會(huì)觸發(fā)對(duì)應(yīng)的業(yè)務(wù)事件；在服務(wù)接口中，會(huì)直接觸發(fā)對(duì)應(yīng)的業(yè)務(wù)事件。

　　它們有一些共同點(diǎn)，比如都是主動(dòng)發(fā)起的服務(wù)，都有各自的回調(diào)方法，大部分都需要可選或必選參數(shù)。

　　按照正常的設(shè)計(jì)模式，每個(gè)服務(wù)頁面和服務(wù)接口都可以設(shè)計(jì)為單獨(dú)的一個(gè)接口。但是因?yàn)?Passport 提供了數(shù)量眾多的服務(wù)，這種設(shè)計(jì)會(huì)造成大量接口的出現(xiàn)，從而增加 SDK 的接入與維護(hù)成本。因此在接口的設(shè)計(jì)上，必須做減法。

　　Passport SDK 的服務(wù)接口采用了集中式接口，我們把所有的服務(wù)頁面和服務(wù)接口抽象成服務(wù)類型。其中，每個(gè)服務(wù)類型代表一種服務(wù)，有自己的參數(shù)傳遞規(guī)則，有對(duì)應(yīng)的回調(diào)方法。

　　如圖 1 所示，我們使用了接口路由的方法，在接口模塊內(nèi)置了一個(gè)路由表，決定服務(wù)類型和對(duì)應(yīng)服務(wù)（通用服務(wù)頁面和通用服務(wù)接口）的映射。

　　圖 1 Passport SDK 服務(wù)接口設(shè)置

　　用戶只需在這個(gè)服務(wù)接口里傳入服務(wù)類型和符合規(guī)則的參數(shù)即可調(diào)用對(duì)應(yīng)服務(wù)。服務(wù)完成后，會(huì)通過服務(wù)類型對(duì)應(yīng)的回調(diào)方法傳遞結(jié)果：

　　簡(jiǎn)單的接口設(shè)計(jì)會(huì)降低接入工作的成本，并使用戶獲得極好的接入體驗(yàn)。

　　58 趕集集團(tuán)旗下?lián)碛卸鄠€(gè) App，且全部使用同一套賬號(hào)體系，通過 Passport 部門提供的接口進(jìn)行通信。經(jīng)過多年迭代，各個(gè) App 中關(guān)于 Passport 的功能均出現(xiàn)了一些流程和接口上的差異。為了提高賬號(hào)安全，統(tǒng)一服務(wù)接口和流程，提高用戶體驗(yàn)，由此決定開發(fā)了一個(gè) Passport SDK，以集成 Passport 的相關(guān)功能，并提供給集團(tuán)內(nèi)各業(yè)務(wù) App 使用。

　　在項(xiàng)目開始之初，我們?cè)诠緝?nèi)經(jīng)過調(diào)研發(fā)現(xiàn)在使用 SDK 時(shí)，大家最關(guān)心的問題就是 SDK 使用起來是否簡(jiǎn)單，即接口是否簡(jiǎn)單、調(diào)用流程是否簡(jiǎn)單、迭代升級(jí)是否簡(jiǎn)單。基于這幾個(gè)關(guān)鍵問題，我們把設(shè)計(jì)目標(biāo)定為：將原本 Passport 功能中繁瑣的流程變成 Passport SDK 中簡(jiǎn)單的功能調(diào)用和結(jié)果處理，讓使用 Passport 功能的開發(fā)者不再需要關(guān)心那些數(shù)量龐大而又無關(guān)緊要的部分，取而代之的是享有一個(gè)非常良好的開發(fā)體驗(yàn)。由此，我們將設(shè)計(jì)原則定為：

　　接口要精簡(jiǎn)；

　　服務(wù)的流程要黑盒；

　　無感知的迭代升級(jí)。

　　確定了設(shè)計(jì)原則后，下一步就是明確核心需求。Passport SDK 旨在為 58 同城賬號(hào)體系下的用戶提供通用的登錄相關(guān)服務(wù)頁面和接口。所以我們的 SDK 核心需求是提供服務(wù)，即通用服務(wù)頁面和通用服務(wù)接口，并在用戶調(diào)用服務(wù)后返回其結(jié)果。

　　設(shè)計(jì)簡(jiǎn)單且有效的接口

　　首先我們從需求上明確接口有哪些？答案是數(shù)據(jù)接口與服務(wù)接口，具體如下：

　　數(shù)據(jù)接口是一些零散的數(shù)據(jù)存取操作，實(shí)際上無法做出太多的精簡(jiǎn)。

　　服務(wù)接口包括各種服務(wù)頁面的調(diào)起和服務(wù)接口的調(diào)用：在服務(wù)頁面中，App 用戶與服務(wù)頁面的交互會(huì)觸發(fā)對(duì)應(yīng)的業(yè)務(wù)事件；在服務(wù)接口中，會(huì)直接觸發(fā)對(duì)應(yīng)的業(yè)務(wù)事件。

　　它們有一些共同點(diǎn)，比如都是主動(dòng)發(fā)起的服務(wù)，都有各自的回調(diào)方法，大部分都需要可選或必選參數(shù)。

　　按照正常的設(shè)計(jì)模式，每個(gè)服務(wù)頁面和服務(wù)接口都可以設(shè)計(jì)為單獨(dú)的一個(gè)接口。但是因?yàn)?Passport 提供了數(shù)量眾多的服務(wù)，這種設(shè)計(jì)會(huì)造成大量接口的出現(xiàn)，從而增加 SDK 的接入與維護(hù)成本。因此在接口的設(shè)計(jì)上，必須做減法。

　　Passport SDK 的服務(wù)接口采用了集中式接口，我們把所有的服務(wù)頁面和服務(wù)接口抽象成服務(wù)類型。其中，每個(gè)服務(wù)類型代表一種服務(wù)，有自己的參數(shù)傳遞規(guī)則，有對(duì)應(yīng)的回調(diào)方法。

　　如圖 1 所示，我們使用了接口路由的方法，在接口模塊內(nèi)置了一個(gè)路由表，決定服務(wù)類型和對(duì)應(yīng)服務(wù)（通用服務(wù)頁面和通用服務(wù)接口）的映射。

　　圖 1 Passport SDK 服務(wù)接口設(shè)置

　　用戶只需在這個(gè)服務(wù)接口里傳入服務(wù)類型和符合規(guī)則的參數(shù)即可調(diào)用對(duì)應(yīng)服務(wù)。服務(wù)完成后，會(huì)通過服務(wù)類型對(duì)應(yīng)的回調(diào)方法傳遞結(jié)果：

　　簡(jiǎn)單的接口設(shè)計(jì)會(huì)降低接入工作的成本，并使用戶獲得極好的接入體驗(yàn)。