Telematics service non-RESTful architecture Transformation Practice

REVIEW

In the process of building business-oriented projects, many-fold content aggregation class online service API design, because of its customization features, the use of conventional development model of restful, usually leads to a lot of duplication of development API similar dilemma, this paper presents a GraphQL query language + gateway choreography joint practice, to solve the problem of a large number of repeat custom.

Early depot and the process of cooperation, based on high moral existing data, engine capacity and some of the more important and relevant CP services (such as parking lots, gas stations, weather, etc.), an online service collaboration model form is for customer demand, the use of REST API provides provides a different API implementation for each depot, each project and each terminal, but the core data services independent fact there are more than ten kinds, but because the car line maintenance business cycle is long, and more customization, 2--3 years down , API has reached the scale of hundreds, and continued divergent growth level, which gives the continued development and maintenance is not a small challenge.

Decomposition business development process, nothing more than two types of work, business needs access to data and the ability to non-business aspirations but essential capabilities such as authentication and other general, the current point of view, in fact, these two issues are almost all business team will encounter problem, the solution is also substantially similar to the service aggregator, orchestration, the API gateway.

This article briefly describes the transformation of some of the online service and get off networking practices of the old architecture.

Related terms

• GraphQL: GraphQL is both an API for query language is also a running data queries satisfied. GraphQL Data API provides a complete description of a set of easy-to-understand, so that the client can accurately obtain the data it needs, and there is no redundancy, but also make the API easier to evolve over time, but also with to build a strong developer tools.

• DSL: refers to the focus on an application in the field of computer language. Also translated as domain-specific language. Unlike ordinary general-purpose cross-cutting computer language (GPL), domain-specific language used only in certain areas. For example, to display HTML pages, as well as Emac LISP language used Emacs.

• Gateway API: API Gateway is a server, is the only entrance system. From the perspective of object-oriented design, it is similar to the appearance model. API Gateway encapsulates the internal system architecture that provides a custom API for each client. It may also have other functions, such as authentication, monitoring, load balancing, caching, and fragment management request, the static response processing.

Problems

Old car line of business online services architecture as follows:

Face the following problems:

 

Improve

In response to these problems, major improvements to think from the following aspects:

• Service capabilities atomization: the goal is so steady, so that the upper achieved through a combination of business needs;

• Build a query engine: Supports powerful query capabilities combined to achieve any aggregation service capacity atom and custom;

• API gateway: the ability for non-business data needs abstraction provides plug-in, plug-ins to achieve choreography.

The following were introduced.

Stable, independent evolution of atomic capacity services

The existing service to sort out different abstract should be independent of the development, deployment, core competence evolution, there is no work for the engine capacity, focusing on some of history's external docking CP, mainly to achieve the following objectives:

• Up to provide a stable interface, backward masking complexity (data access, multi-source difference) substrate;

• Location-centric organic integration, build a comprehensive set of capabilities atoms.

This work is mainly a combination of some of the services to address the historical legacy of the unreasonable, excessive follow custom business problems.

Custom code development is converted to defined query

The main purpose here is to service aggregation, such as custom logic requires the original code development converted to write the query language of ways, only need to write a declarative query complete service release, the following features:

• Offers up a standardized query language

• The ability to achieve a combination of downward atoms

• Business induction common, refining customized model to enhance reuse

This article select GraphQL as a query language base, however, the direct use of such GraphQL two main issues need to be addressed:

• Data query N + 1 zoom, which directly employ dataloader Fackbook put forward to solve, is the principle batch add cache;

• GraphQL specification limits, some customization is difficult to achieve, such as:

1. The custom parameters: The parameters associated with the type of conversion;

2. Output format: Field presentation form, such as the time, longitude and latitude;

3. Custom configuration table: The main part of the business logic requires customized according to the configuration table, such as the depth of field returns the like;

4. Model connection: Atomic ability to serve as independent as possible, but also unable to enumerate defined model of the relationship, but custom business needs requires a lot of correlation revealed, reduce service request to reduce latency, so the model is the ability to free association is necessary, as the final program query internal control, external exposure REST API, and therefore not difficult to understand the relevance of freedom is not a problem caused.

The need to achieve by embedding a simple DSL:

• Built-in functions and custom functions;

• Dynamic correlation model query context parameter acquisition;

• It can be easily extended custom function.

 

Embed a need to control the degree of DSL, because DSL if too complex, then the user or publisher can not write fast queries, then write code to mention contrast effect will be discounted, deviate from the original value, so the basic principle is simple, scalable .

Business-related functions through the API Gateway plug-in configuration of

Since before the custom development for each of the basic API functions all mixed together, can provide the decorator with a complex part is the authentication routine response format to provide some tools to customize functions, any demand for change will need to change the code, take the publishing process, there is the first step in the transformation of the above, this step is desirable to customization service data portion of the non-abstract processing chain, each processing node to provide multiple implementations (comprising common and custom), achieved through orchestration database memory card chain.

 

Because of the way the authentication car line business according to customer needs, so there is diversity, the implementation is achieved through a variety of authentication plug-ins Web Middleware:

• HTTP signature reference herein: mainly for ToB (depot background, partners) request;

• JWT Certification: mainly for cars, mobile phones and other terminals;

• API Key。

For API Gateway, these authentication plug-in and there is nothing different, just to deal with some custom engineering scenarios, such as for JWK manage different depot refresh policy, JWT verification strategies, according to the specific needs of abstract modeling business demands by plug-in properties to achieve configuration control.

In addition, the gateway also implements some converters, mainly for the GraphQL the output into revealing REST API interfaces, in this regard due to some old compatible interfaces do support, in addition, some key customers in the global architecture background they have fully defined our interface style, mainly achieved:

• Transformation into the reference: using the REST API parameters filled GraphQL query template;

• Header Transformation: mainly used to adapt the customer specifications;

• JSON conversion, using the following scenarios:

1. Reusable standard interfaces, but in response to different customer specifications inconsistent structure

2. Customized non-standard interfaces, you need to convert the output of GraphQL

And using the plug is achieved through the console or the widget API manages configuration information stored in the database, extracting feature when used according to a request from the DB cache and used together.

After transformation, the new structure is as follows:

 

 

summary

Through the above transformation, the car online networking service development model has been upgraded to achieve dynamic publishing API console, significantly increasing the efficiency of custom development:

• Improving Efficiency Development: orthogonalization capabilities arrangement atoms, substituted by a lightweight custom code defined Development:

1. Customized development share declined 60%;

2. Single interface development time from 2-3 man-days → 2-3 people.

• Protocol compatible: Mixed REST program, provide external standard protocol to support both adaptation protocol.

 

Germany focus on high technology, professional content to find more technical field trips