TYPESDK Hand Tour Aggregation SDK Service-side design ideas and Architecture: Application Scenario Analysis

TYPESDK one of the design ideas and architectures of the service end: Application Scenario Analysis

As a Channel SDK Unified access framework, TYPESDK from the beginning, the face of the demand scenario is a variety of games, through a unified SDK server, can simultaneously access dozens of or even hundreds of different channels of the SDK. and the specific access fields and access logic for these channel interfaces can vary from month to week, either large or small. In such a complex scenario, how should we design an SDK server that is strong enough and flexible enough?

First we need to clarify the location of the TYPESDK in the entire application scenario, and the core functions it needs to implement.

Figure 1

As shown in 1, TYPESDK server is the interface of communication between the game server and the TYPESDK server, and the communication interface between the channel server and the TYPESDK server. Take the login process as an example, the authentication result that the game service side initiates to the TYPESDK server to authenticate the user request and the channel service to the TYPESDK service side, and in the case of the payment process, is the payment completion callback initiated by the channel service to the TYPESDK server and the TYPESDK service-initiated shipment request to the game server.

Below we analyze these two main processes separately:

Figure 2

Process description

1. When the user clicks the login button, the game client calls the TYPESDK login interface, detailed call method and parameter description please refer to the Client interface documentation
2. TYPESDK client calls the API login of the Channel Client SDK
3. Channel Client SDK self-mechanism request channel service side
4. Channel Client SDK Gets the validation parameters returned by the server
5. TYPESDK client obtains parameters and wraps the Channel Client SDK
6. Game client gets the parameters after wrapping
7. The game client transmits the wrapper parameters to the game server using its own mechanism.
8. The game server accesses the user session authentication interface on the TYPESDK server. Pass the parameters obtained in Process 6 to the TYPESDK server.
9. TYPESDK the user authentication interface on the service side of the channel server to authenticate the login
10. Channel Return validation Results
11. The TYPESDK server wraps the verification result of the channel return, and returns to the game server to inform the game client whether the login is successful or not, according to the channel verification result.

From the above process can be analyzed, in the login process, the TYPESDK service side needs to complete the work is to complete a packaging action. The standard parameters provided by the game server are packaged separately according to the requirements of the channel, so that the data conforms to the demand of the channel service, which is then submitted to the Channel server. Then the various channels returned by the strange verification of the results of the analysis to distinguish, and then notify the game server, for the game logic to use.

Figure 3

Process description

1. After the top-up order is credited, the channel service side asynchronously notifies the TYPESDK server
2. Type server notification Game Service side issue
3. After the game server receives the shipment request, it first saves the request, immediately returns to the TYPESDK service side, indicating that the shipment request has been received.
4. TYPESDK return to channel service side
5. The game server asynchronously processes the shipping logic. and notify the game client

Look at the recharge to the account process, in this simplified version of the top-up to the account process, we can see that the work done by the TYPESDK service is also a simple packaging action, will be a variety of different channels callback request packaging standard data format, notify the game server, for the game processing delivery.

Based on the above analysis, we have cleared the position and main work of TYPESDK service in the whole process. In the following article, we analyze the specific, how to design, in order to make it better adapt to the flexible application scenarios, to deal with the major risks. And how to connect the service-side SDK of the major channels into our unified framework.

TYPESDK Hand Tour Aggregation SDK Service-side design ideas and Architecture: Application Scenario Analysis