Passport SDK的设计与技术细节实例分析

　　58 赶集集团旗下拥有多个 App，且全部使用同一套账号体系，通过 Passport 部门提供的接口进行通信。经过多年迭代，各个 App 中关于 Passport 的功能均出现了一些流程和接口上的差异。为了提高账号安全，统一服务接口和流程，提高用户体验，由此决定开发了一个 Passport SDK，以集成 Passport 的相关功能，并提供给集团内各业务 App 使用。

　　在项目开始之初，我们在公司内经过调研发现在使用 SDK 时，大家最关心的问题就是 SDK 使用起来是否简单，即接口是否简单、调用流程是否简单、迭代升级是否简单。基于这几个关键问题，我们把设计目标定为：将原本 Passport 功能中繁琐的流程变成 Passport SDK 中简单的功能调用和结果处理，让使用 Passport 功能的开发者不再需要关心那些数量庞大而又无关紧要的部分，取而代之的是享有一个非常良好的开发体验。由此，我们将设计原则定为：

　　接口要精简；

　　服务的流程要黑盒；

　　无感知的迭代升级。

　　确定了设计原则后，下一步就是明确核心需求。Passport SDK 旨在为 58 同城账号体系下的用户提供通用的登录相关服务页面和接口。所以我们的 SDK 核心需求是提供服务，即通用服务页面和通用服务接口，并在用户调用服务后返回其结果。

　　设计简单且有效的接口

　　首先我们从需求上明确接口有哪些？答案是数据接口与服务接口，具体如下：

　　数据接口是一些零散的数据存取操作，实际上无法做出太多的精简。

　　服务接口包括各种服务页面的调起和服务接口的调用：在服务页面中，App 用户与服务页面的交互会触发对应的业务事件；在服务接口中，会直接触发对应的业务事件。

　　它们有一些共同点，比如都是主动发起的服务，都有各自的回调方法，大部分都需要可选或必选参数。

　　按照正常的设计模式，每个服务页面和服务接口都可以设计为单独的一个接口。但是因为 Passport 提供了数量众多的服务，这种设计会造成大量接口的出现，从而增加 SDK 的接入与维护成本。因此在接口的设计上，必须做减法。

　　Passport SDK 的服务接口采用了集中式接口，我们把所有的服务页面和服务接口抽象成服务类型。其中，每个服务类型代表一种服务，有自己的参数传递规则，有对应的回调方法。

　　如图 1 所示，我们使用了接口路由的方法，在接口模块内置了一个路由表，决定服务类型和对应服务（通用服务页面和通用服务接口）的映射。

　　图 1 Passport SDK 服务接口设置

　　用户只需在这个服务接口里传入服务类型和符合规则的参数即可调用对应服务。服务完成后，会通过服务类型对应的回调方法传递结果：

　　简单的接口设计会降低接入工作的成本，并使用户获得极好的接入体验。

　　58 赶集集团旗下拥有多个 App，且全部使用同一套账号体系，通过 Passport 部门提供的接口进行通信。经过多年迭代，各个 App 中关于 Passport 的功能均出现了一些流程和接口上的差异。为了提高账号安全，统一服务接口和流程，提高用户体验，由此决定开发了一个 Passport SDK，以集成 Passport 的相关功能，并提供给集团内各业务 App 使用。

　　在项目开始之初，我们在公司内经过调研发现在使用 SDK 时，大家最关心的问题就是 SDK 使用起来是否简单，即接口是否简单、调用流程是否简单、迭代升级是否简单。基于这几个关键问题，我们把设计目标定为：将原本 Passport 功能中繁琐的流程变成 Passport SDK 中简单的功能调用和结果处理，让使用 Passport 功能的开发者不再需要关心那些数量庞大而又无关紧要的部分，取而代之的是享有一个非常良好的开发体验。由此，我们将设计原则定为：

　　接口要精简；

　　服务的流程要黑盒；

　　无感知的迭代升级。

　　确定了设计原则后，下一步就是明确核心需求。Passport SDK 旨在为 58 同城账号体系下的用户提供通用的登录相关服务页面和接口。所以我们的 SDK 核心需求是提供服务，即通用服务页面和通用服务接口，并在用户调用服务后返回其结果。

　　设计简单且有效的接口

　　首先我们从需求上明确接口有哪些？答案是数据接口与服务接口，具体如下：

　　数据接口是一些零散的数据存取操作，实际上无法做出太多的精简。

　　服务接口包括各种服务页面的调起和服务接口的调用：在服务页面中，App 用户与服务页面的交互会触发对应的业务事件；在服务接口中，会直接触发对应的业务事件。

　　它们有一些共同点，比如都是主动发起的服务，都有各自的回调方法，大部分都需要可选或必选参数。

　　按照正常的设计模式，每个服务页面和服务接口都可以设计为单独的一个接口。但是因为 Passport 提供了数量众多的服务，这种设计会造成大量接口的出现，从而增加 SDK 的接入与维护成本。因此在接口的设计上，必须做减法。

　　Passport SDK 的服务接口采用了集中式接口，我们把所有的服务页面和服务接口抽象成服务类型。其中，每个服务类型代表一种服务，有自己的参数传递规则，有对应的回调方法。

　　如图 1 所示，我们使用了接口路由的方法，在接口模块内置了一个路由表，决定服务类型和对应服务（通用服务页面和通用服务接口）的映射。

　　图 1 Passport SDK 服务接口设置

　　用户只需在这个服务接口里传入服务类型和符合规则的参数即可调用对应服务。服务完成后，会通过服务类型对应的回调方法传递结果：

　　简单的接口设计会降低接入工作的成本，并使用户获得极好的接入体验。