Question1: Talk about service registration and service discovery?

Answer1：

Service registration is to maintain a register, which manages all service addresses in the system. When the new service is started, it will confess its address information to the register. The relying party of the service directly asks for the Service Provider address from the register. There are many tools for service registration, such as ZooKeeper, Consul, Etcd, and eureka from Netflix. There are two forms of service registration: client registration and third-party registration.

Client registration (zookeeper)
Client registration is the service itself responsible for registration and cancellation. When the service starts, register itself with the registration center, and deregister yourself when the service goes offline. During this period, you still need to keep a heartbeat with the registration center. The heartbeat does not have to be done by the client, but can also be handled by the registration center (this process is called Tanhuo). The disadvantage of this method is that the registration work is coupled with the service, and different languages must implement a set of registration logic.

The client registration is shown below:
Insert picture description here

For the explanation above:
the service that needs to register, Sevice, directly deals with the Service Register Service Register. There are three methods between the two, including register register (), heartbeat (), unregister / unregister (). The registration service needs to be coupled with the registration center, which does not meet the design concept of low coupling, and depends on the third-party registration (independent service Register).

Third-party registration (independent service Registrar)
An independent service Registrar is responsible for registration and cancellation. When the service is started, Registrar is notified in some way, and then Registrar is responsible for initiating the registration work with the registry. At the same time, the registration center should maintain the heartbeat with the service. When the service is unavailable, the service will be cancelled to the registration center. The disadvantage of this method is that Registrar must be a highly available system, otherwise the registration work cannot progress.

The third-party registration is shown below:
Insert picture description here

For the explanation of the above figure:
the service that needs to be registered, Sevice, interacts with the independent third-party service Registrar. When the service is started, the Registrar is notified in a certain way. During this period, the Registrar sends a heartbeat check to the service Service at a fixed time.
In this way, the service Service can go to its own business logic, without additional registration, additional cancellation, real-time heartbeat notification service registration center.
The independent service Registrar directly interacts with the service register Service Register. There are three methods between the two, including register register (), heartbeat (), and unregister / unregister (). When the service is started, Registrar is notified, and the Registrar registers the service with the service registration center; after the service is started, the Registrar performs heartbeat check on the service at intervals. If the service survives, it calls heartbeat () to report to the service registration center. If the service does not survive, Call unregsister () to cancel the service to the service registration center.
Summary: The third-party registration uses an independent service, Registrar, to separate the registration service from the registration center, which is in line with the design concept of low coupling. Of course, this method requires an additional highly available Registrar system compared to client registration.

Client discovery
Client discovery means that the client is responsible for querying available service addresses and load balancing. This method is the most convenient and direct, and it is also convenient for load balancing. Furthermore, once a service is found to be unavailable, it is immediately changed to another one, which is very straightforward. The disadvantage is also the repeated work in multiple languages, each language implements the same logic.

The client discovery is shown below:
Insert picture description here

For the explanation of the above figure: The
running service Sevice acts as a client Client, directly uses the http request to deal with the server, and directly queries the available service address, which is used to achieve load balancing work. The design is simple in this way, but the client service and the server are coupled together, which does not meet the design concept of low coupling, and depends on the server registration.

Server discovery
Server discovery requires additional Router services. Requests are sent to the Router first, and then the Router is responsible for querying services and load balancing. Although this method does not have the shortcomings discovered by the client, its shortcoming is to ensure the high availability of the Router.

The server discovery is shown below:
Insert picture description here

For the explanation of the above figure: The
running service Sevice acts as a client Client, and communicates with the Router by using request requests. The Router is responsible for querying services and load balancing.
Summary: Server registration, router query instead of client query server, reduce the burden on the client Service, of course, this method requires an additional highly available Router system compared to client discovery.

Question2: What about "API Gateway / API Gateway"?

Answer2：

API Gateway is a server, and it can also be said to be the only node that enters the system. This is similar to the Facade pattern in the object-oriented design pattern. The API Gateway encapsulates the internal system architecture and provides APIs to various clients. It may also have other functions, such as authorization, monitoring, load balancing, caching, request sharding and management, and static response processing. The following figure shows an API Gateway that adapts to the current architecture.
Insert picture description here

The above figure shows that the API gateway should monitor almost all other business modules, shopping cart service shopping cart service, shopping service shopping service, inventory service inventory list service, recommendation service recommendation service, order service order service, review service review service, product catalog service product type service.

API Gateway is responsible for request forwarding, synthesis and protocol conversion. All requests from the client must first go through the API Gateway, and then route these requests to the corresponding microservices. API Gateway will often call multiple microservices to process a request and aggregate the results of multiple services. It can convert between web protocols and non-web friendly protocols used internally, such as HTTP protocol and WebSocket protocol.

Request forwarding
Service forwarding is mainly to forward the load of the client's request to install microservices to different services.

Response Merge Merges
the work that needs to call multiple service interfaces in the business into a single call to provide unified services to the outside world.

Protocol conversion The
focus is to support the protocol conversion between SOAP, JMS, and Rest.

Data conversion
focuses on supporting message format conversion capabilities between XML and Json (optional).

safety certificate

Token-based client access control and security strategy
Transmission data and message encryption, decryption to the server, you need to have a separate SDK agent package on the client
Https-based transmission encryption, client and server digital certificate support
Service security authentication based on OAuth2.0 (authorization code, client, password mode, etc.)

Question3: Briefly introduce the microservice architecture configuration center?

Answer3：

The configuration center is generally used as the parameter configuration of the system. It needs to meet the following requirements: efficient acquisition, real-time awareness, and distributed access.

Example:
The architecture diagram implemented by the zookeeper configuration center is shown below. The method of loading data into memory is used to solve the problem of efficient acquisition, and the real-time perception is realized by using the zookeeper node monitoring mechanism.
Insert picture description here

The above figure shows that the zookeeper of the configuration center will observe any changes in the information by the observer watcher, and then notify the business logic layer and then the access layer.

Configuration center data classification
Insert picture description here

The above figure shows that the configuration center (conf center, full name configuration center) includes service configuration, various switches, and business configuration.
Service configuration includes database service configuration, queue service configuration, cache service configuration, etc .;
various types of switches include various functional switches, various types of business switches, and various types of service switches;
business configuration as shown above, including module A application src A (app src A1 + app src A2), module B application src B (app src B1 + app src B2), etc.

Question4: Briefly describe the event scheduling (kafka)?

Answer4：

Unified scheduling of message services and events, commonly used kafka, activemq, etc.

Question5: A brief introduction to service tracking (starter-sleuth)?

Answer5：

As the number of microservices continues to grow, it is necessary to track the propagation of a request from one microservice to the next microservice. SpringCloud Sleuth solves this problem by introducing a unique ID in the log to ensure consistency between microservice calls Sex, so you can track how a request is passed from one microservice to the next.

In order to achieve request tracking, when the request is sent to the entrance endpoint of the distributed system, only the service tracking framework needs to create a unique tracking identifier for the request, and the framework always keeps passing the unique identifier when circulating within the distributed system. Until returned to the requester, this unique identifier is the Trace ID mentioned earlier. Through the record of Trace ID, we can correlate all the request process logs.
In order to count the time delay of each processing unit, when the request reaches each service component, or when the processing logic reaches a certain state, its start, specific process, and end are also marked by a unique identifier. This identifier is mentioned in our previous article. For each Span, the Span ID must have two nodes: start and end. By recording the time stamp of the start Span and the end Span, the time delay of the Span can be counted. In addition to the time stamp record, It can also contain some other metadata, such as: event name, request information, etc.
In the quick start example, we easily implemented log-level tracking information access, thanks to the implementation of the spring-cloud-starter-sleuth component. In the Spring Boot application, after introducing the spring-cloud-starter-sleuth dependency in the project, it will automatically build a tracking mechanism for each communication channel for the current application, such as:
(1) Through such as RabbitMQ, Kafka (or other Any message middleware implemented by any Spring Cloud Stream binder).
(2) The request passed through the Zuul agent.
(3) Request initiated through RestTemplate.

Question6: What is the service fuse (Hystrix)?

Answer6：

There are usually multiple service layer calls in the microservice architecture. The failure of the basic service may lead to a cascading failure, which in turn causes the entire system to be unavailable. This phenomenon is called the service avalanche effect. The service avalanche effect is a process in which the "service consumer" becomes unavailable due to the unavailability of the "service provider" and gradually enlarges the unavailability.

The principle of the fuse is very simple, just like a power overload protector. It can achieve rapid failure. If it detects many similar errors in a period of time, it will force its subsequent multiple calls to fail quickly and no longer access the remote server, thus preventing the application from continuously trying to perform operations that may fail. , So that the application can continue to execute without waiting for the error to be corrected, or waste CPU time to wait for a long timeout. The fuse can also enable the application to diagnose whether the error has been corrected. If it has been corrected, the application will try to call the operation again.

Insert picture description here
The Hystrix circuit breaker mechanism
circuit breaker is well understood. When the number of Hystrix Command request back-end service failures exceeds a certain percentage (default 50%), the circuit breaker will switch to the open state (Open). At this time, all requests will directly fail and will not be sent. To the back-end service. After the circuit breaker stays in the open state for a period of time (default 5 seconds), it automatically switches to the half-open state (HALF-OPEN). At this time, the return status of the next request will be judged. If the request is successful, the circuit breaker is switched off. Return to closed state (CLOSED), otherwise switch back to open state (OPEN). The circuit breaker of Hystrix is like a fuse in our home circuit. Once the back-end service is unavailable, the circuit breaker will directly cut off the request chain to avoid sending a large number of invalid requests Affects system throughput, and the circuit breaker has the ability to self-detect and recover.