Before the text begins, let's take a look at a daily life scene, a coffee vending machine:
In the first row, there are four options: American, latte, mocha, white coffee;
The second row, the unit is ml, represents the amount of coffee produced;
The third row, whether to add sugar;
The fourth row, whether to add milk.
After entering the above four parameters, the automatic vending coffee machine will provide the required coffee as required. Of course, the vending machine will still determine the operator's identity information based on the operator's face or scan code, and make corresponding deductions, or pay first and then operate. This is the service provided by a coffee machine. Instructions for operation are provided on the fuselage. Enter the type, taste and other information according to the prompts to create the corresponding coffee.
Microservices and APIs
The coffee machine provides life services, and our topic: "microservices" provides software services. The use of a software service requires input parameters: for example, the first parameter represents the type, the second parameter represents the returned quantity, the third and fourth parameters represent whether certain rules need to be added; at the same time, the identity is also required. Information: such as adding the consumer name to the header, adding authentication information, etc.; of course, there needs to be a return, that is, the return of the result of calculation or processing. This is the capability provided by the software service, and it is also the API of the software service.
Before the microservice architecture was proposed, the first thing in the industry was service-oriented. After all, the encapsulation and self-operation of service capabilities are much faster and cheaper than their own coding. Microservices are created on the basis of servitization, which is to construct an application as a set of loosely coupled services based on servitization.
Therefore, microservices provide service capabilities based on APIs, and are also the rules and methods of consumption between services. The information identifies the authentication method, the type of parameter transmission, and the format return method, which are all defined by the API.
API
The definition of API is the application programming interface, and in the service-oriented scenario, the API is the access interface between applications, that is, the behavior contract provided by the service. Then in the microservice scenario, the API is the contract between microservices to obtain information .
The calling relationship between services in the microservice architecture is complex, and the service capabilities provided by the program can be consumed and used by any other service, which is also an advantage of building microservices. The reuse of service capabilities can be consumed in a certain business area, or relied on by services outside the network area, or the ability of the entire enterprise to be opened to the outside world.
Of course, there are also the information authentication in the call, the control of call permission/deny, the flow control when dealing with large traffic, the circuit breaker control, the batch method, etc., all of which are API management content. With such detailed control, API monitoring is also particularly important, because a lot of control data comes from monitoring records.
Therefore, API is the core management object in microservice construction , and from the perspective of overall microservice construction, API management needs to be paid attention to in development, operation and maintenance, and operation.
Development state: API management
I mentioned the construction of microservices before. From a horizontal perspective, it spans the development state, operation and maintenance state, and operation state of microservices. In the development state, API design precedes service development, so API management should already be in the development state. Start recording and debugging.
API includes request methods (GET, POST, etc.), request parameters (request header, request body), response content and other information. For the management of API interface documents, it should be regarded as a contract between microservices, and in service calls, it guides consumption use of the service.
API management may have different applications in different stages. In the development stage, it can help developers to quickly design and adjust the API, in the testing stage, it is convenient for testers to view the usage of the API, and it is also more conducive to knowledge transfer and work handover; During the runtime phase, the description of the API will also facilitate other applications or systems to call the service.
Operational state: API changes
In the context of microservices, agility is the first priority. Therefore, services may be frequently upgraded and changed, and API changes and changes are inevitable. Since the API is a contract between microservices, changes to the API, like changes to the contract, will affect all consumers.
Therefore, API changes need to be cautious, and after the change, a detailed change description is required for consumers to refer to, and even a fixed process approval is required.
Of course, there is also a requirement for API management, which is to support multi-version management to meet continuous integration, continuous release, and change information .
Running State: API Governance
In the running state, the governance of the API is a fine-grained microservice governance. After all, the construction of microservices is the first step in the construction of enterprise service-oriented middle-end platforms, and it is not just as simple as adjusting the microservice framework.
In the future, service capabilities will be provided in the form of APIs, and all management granularities will be API interfaces. Therefore, API governance is the focus of microservice governance , such as API granularity access control, API granularity current limiting, downgrade, and circuit breaker, API level performance monitoring information, and API call dependencies. API link node information, etc.
Of course, in addition to the API governance between services, the API gateway, which has gradually entered people's attention with microservices, is also the management and control of north-south API calls. API Gateway provides unified external capability output of API. In the real environment, it is not only external capabilities, but also in cross-network domains, compatibility with heterogeneous frameworks, etc., but it is all for API granularity control and observation.
Summarize
The core object of the management of microservices is APIs that are more fine-grained than services. The management content includes the management of API interface information, the impact of changes, operation monitoring, and traffic control.
Of course, the existing business systems have not been mentioned, because the interfaces provided by the non-microservice architecture are also non-standard protocols. Such systems are also provided in the form of API interfaces, and the conversion of protocols and messages is done in appropriate places. The compatibility of the old system in stock will be introduced and shared in detail in the next article.