takeaway
In building enterprise project, vivid content aggregation of the online service API design in the process, because of its customization features, the conventional restful development mode, usually leads to a lot of the same API iterative development, this paper introduces a GraphQL query language + gateway choreography combined practice, the problem of a large number of repeat custom.
Early and depot in the process of cooperation, based on the gold of the existing data, engine power, and some of the more important related CP services (such as car parks, gas stations, weather, etc.), to form the online service collaboration mode is based on customer requirements, using a REST API provides for each factory, each project and each terminal to provide different API implementation, However, there are actually more than ten kinds of independent data core services. However, due to the long maintenance cycle and many customizations of the train line business, the scale of API has reached hundreds in 2-3 years, and the continuous growth of divergence, which brings no small challenge to the continuous development and maintenance.
Decomposition business development process, no more than two types of work, business needs ability of data acquisition and non-business appeal but essential generalization ability, such as authentication, the current view, the two problems are actually almost all business team has to deal with a problem, so the solution is also similar, such as service aggregation, process choreography, API gateway, etc.
This paper briefly introduces some practices of transforming the old structure of the online service of car network.
Related to the noun
-
GraphQL: GraphQL is both a query language for apis and a runtime for data queries. GraphQL provides an easy-to-understand set of complete descriptions of the data in the API, enabling a client to get exactly what it needs without any redundancy, making it easier for the API to evolve over time, and for building powerful developer tools.
-
DSL: A computer language that focuses on an application domain. Also translated as domain specific language. Unlike the generic Cross-domain General Purpose Computer Language (GPL), domain-specific languages are used only in specific domains. Such as HTML, used to display web pages, and Emac LISP, the language used by Emacs.
-
API Gateway: THE API gateway is a server that is a unique entry point to the system. From an object-oriented design perspective, it is similar to the appearance pattern. The API gateway encapsulates the internal architecture of the system and provides a custom API for each client. It may also have other responsibilities, such as authentication, monitoring, load balancing, caching, request sharding and management, and static response processing.
Existing problems
The old structure of the online service is as follows:
Faced with the following problems:
To improve the
In view of the above problems, mainly from the following aspects to consider improvement:
-
Atomization of service capability: the goal is to stabilize and let the upper layer achieve business requirements through combination;
-
Build query engine: support powerful query combination ability, realize arbitrary aggregation and customization of atomic service ability;
-
API gateway: Abstracting the requirements of non-business data capabilities to provide plug-ins and realize plug-in choreography.
The following are introduced respectively.
Achieve stable, independent evolution of atomic capability services
The existing services are sorted out and different core capabilities that should be independently developed and deployed evolve are abstracted. There is no work for engine capabilities, and the focus is on some external CP with historical docking, mainly achieving the following objectives:
-
Provide stable interfaces upward and shield underlying complexity (data access, multi-source differences) downward;
-
Organic integration centered on location to build a complete set of atomic capabilities.
This part of the work is mainly to solve the problems of unreasonable service combination left over from history and excessive customization of services.
Custom code development translates into defining query statements
The main purpose here is to convert the original code development required by service aggregation, customization logic and so on into the way of writing query language, and only need to write declarative query statements to complete the service release. The features are as follows:
-
Provide a standardized query language up
-
Implement atomic capability combinations down
-
Summarize the common business, refine the customization mode, improve reuse
In this paper, GraphQL is chosen as the basis of the query language. However, there are two major problems to be solved by directly using GraphQL:
-
Data query N+1 magnification problem, directly using Fackbook proposed dataloader to solve, the principle is batch caching;
-
Limitations of the GraphQL specification make some customizations difficult to implement, such as:
-
Input parameter customization: such as parameter association, type conversion, etc.
-
Output format: display form of fields, such as time, latitude and longitude, etc.
-
Configuration table customization: Some service logic needs to be customized according to the configuration table, such as depth return fields.
-
Model connection: Atomic capability services are as independent as possible, and model relations cannot be enumerated and defined. However, customized business requirements require a large number of association leakage to reduce business requests and delay. Therefore, the ability of model free association is necessary. So the incomprehensibility of not associating degrees of freedom is not a problem.
It needs to be implemented by embedding a simple DSL:
-
Built-in and custom functions;
-
Model dynamic associated query, context parameter acquisition;
-
Custom functions can be easily extended.
The embedding of DSL needs to be controlled, because if the DSL is too complex, the user or publisher cannot write queries quickly, the efficiency will be reduced compared to writing code, and the original value will be lost. Therefore, the basic principle is simple and extensible.
Business-independent functions are configured through the API gateway plug-in
Since before every API custom development basic all functions are mixed together, can reuse part is to provide a decorator, conventional response format customization provides some utility functions, any requirement change, need to change the code, release process, with the first step on the transformation, this step is expected to abstract the non-business data part of the custom function processing chain, Each processing node provides multiple implementations (both generic and custom), choreography through a database store plug-in chain.
The authentication mode of cabling business needs to be customized according to customers, so there is diversity. In terms of implementation, various authentication plug-ins are implemented through Web middleware:
-
HTTP signature, refer to here: mainly for ToB (car factory background, partner) request;
-
JWT certification: mainly for vehicles, mobile phones and other terminals;
-
API Key.
For THE API gateway, these authentication plug-ins are not different, but the project needs to deal with some customized scenarios, such as JWK management refresh strategy for different automakers, JWT authentication strategy, etc. Specific needs to abstract modeling according to business demands, through plug-in attributes to achieve configuration control.
In addition, the gateway also implements some converters, which are mainly used to transform GraphQL output into REST API interface. On the one hand, some old interfaces need to be compatible and supported. On the other hand, under the background of global architecture of some key clients, the interface style has been completely defined by themselves.
-
Input parameter transformation: Fill the GraphQL query template with REST API parameters;
-
Header transformation: mainly used to adapt to different customer specifications;
-
JSON transformation, using the following scenarios:
-
Reusable standard interfaces, but different customer response structure specifications are inconsistent
-
To customize the non-standard interface, you need to transform the GraphQL output
And the use of plug-in through the console or API to achieve plug-in configuration information stored in the database for management, according to the request characteristics extracted from the DB and cached for use.
The new structure is as follows:
summary
Through the above transformation, the development mode of online service of Internet of vehicles is upgraded to realize the dynamic release of API console and greatly improve the efficiency of customized development:
- Improved development: Normalized atomic capability choreography, replacing custom code development with lightweight definitions:
-
Custom development is down 60%;
-
Single interface development from 2-3 people per day to 2-3 people per day.
- Protocol compatibility: A hybrid REST solution that provides standard protocols and supports adaptive protocols.
