Do you still manually record service (interface) invocation relationships between microservices

preface

Micro service is becoming more and more common in enterprises. While enterprises enjoy the advantages of micro services, they also bring problems. With the development of enterprise business, the number of corresponding application services keeps increasing, and the dependency relationship between application services becomes more and more complicated.

In enterprises that adopt microservice architecture, business can be better developed iteratively for decoupling between business modules. It is not unusual for the entire business to be divided into 10 modules. And as the business grows, the number of services and the number of interfaces in each service grows, and developers change. Imagine a network of 10 module services that depend on each other and call each other. Especially to the interface level, more complicated. If you rely on the brains of developers to remember, I am afraid that is not realistic. How to accurately know which services are called by a service and which services are called by a service is of great help to service stability, code maintenance, impact assessment, business iteration and so on.

/ / service @ RequestMapping money funds ("/getById ") public Dto getById (id) {User User. = userFeignClient getUserById (userId); / / call the user service return productFeignClient. GetById (userId); // call product service}Copy the code

The above code is common in enterprise Web applications, using Spring Cloud to implement inter-service invocation. So, with this code, do you think of the following scenarios?

The following dialogue is one that software developers often encounter. Scenario 1: Who is calling my interface

Xiao Zhang: Xiao Wang, which services use the getById() interface of the user service? Xiao Wang: I used to know it when there was not much business. Now the business is too complicated and there are too many callers for me to remember. Xiao Zhang: Well, I received a requirement that involves a change in the logic of the original interface, and the callers of the interface have to evaluate the impact plane. Xiao Wang: Then you have to ask each of your colleagues in charge of the service. Xiao Zhang: It's too troublesomeCopy the code

The RD spends precious time each day maintaining the invocation relationships between services and interfaces, and thus loses the energy to focus on more valuable business

Scenario 2: My services are tuned to which interfaces of whose services

Xiao Yao: Xiao Xiu, I took over a product service. In order to be familiar with it as much as possible, I need to know which services the service depends on and which interfaces are adjusted. Xiao Yao: YES, the latest update was one year ago. Xiao Yao: I'm afraid you have to look through the code. Xiao Yao: Look at the code line by line! , I am cryingCopy the code

The RD spends precious time maintaining the invocation relationship between services and interfaces, thus losing time to learn new technologies

The purpose of this project is to collect and show the invocation relationships of services, especially interfaces in services. The value brought by this is a good way to avoid having to remember only through the developer’s mind, knowing that memory will fade. Therefore, it is helpful to prepare and evaluate the impact areas involved in subsequent requirements development. Thus maintain the stability of project on-line and enhance service availability. Therefore, the microservice comb is intended to automatically clarify the call of the relationship between services under the microservice system

Business background

The popularity of microservices architecture has brought about great leaps in business separation, service reuse, agile development and so on. As business scenarios become richer and more extensive, the number of services becomes larger and larger. As a result, interservice invocations become more complex.

What does this project bring

The purpose of this project is to accurately know the caller information of the service and its interface. Through this project, you can accurately and real-time access to the service and its interface is called (use), so as to help you prepare to evaluate the workload of iteration requirements, timely statistics of the upstream service affected by the change, enhance the maintainability and stability of the service, improve the availability.

The core target

The purpose of this project is to provide a simple and quick tutorial to truly assist the service maintenance cost under the micro-service architecture mode, reduce the memory of the RD to the service interface transfer confusion, of course, also bid farewell to the big hole left by predecessors.

Architecture diagram

The component dependence

This project is implemented based on Spring Cloud OpenFeign (current version: 2.1.0.release)

Realize the principle of

This project is divided into three parts, one is to collect and send call information, the other is to receive and store call information, and the third is to show the micro-service call relationship in charts. The transfer of call information (sending and receiving) is based on the CQRS model

1. Call information collection and sending

This function is handled by the Microservice-comb-Infrastructure module. The specific principle of call information collection is dynamic proxy, through proxy LoadBalancerFeignClient class, so that there is an opportunity to collect call information when the service is called; And sends the call information to the receiver via Kafka. Collection of logic through custom InvocationHandler: LoadBalancerFeignClientInvocationHandler completed, send information through the MessageSender class is complete.

2. Receive and store the call information

This function is handled by the Microservice-comb-Server module. Use Kafka to receive call information, and then persist the information to the hard disk. At present, it is saved to the mysql database, and in the later stage, dynamic switching will be adopted, supporting mongodb and other ways.

3. Diagrams show microservice invocation relationships

This function is handled by the Microservice-comb-admin module. Js and other chart components are used to display the service invocation diagram. By retrieving the service name/interface name, we can know the caller information of interface A of service A, when it is invoked, and The Times of invocation within A period of time, etc. But because I am not familiar with the front-end technology, temporarily shelve this module.

The project structure

Special note:

Microservice-comb-example contains three modules. Microservice-comb-server-a simulates business side services, This module refers to microservice-comb-server-b-sdk microservice-comb-server-b simulates business side service microservice-comb-server-b-sdk simulates business side service SDK, This module references microservice-comb-InfrastructureCopy the code

Using the instance

use

It’s easy to use

There are two general steps:

• Resources to prepare
• Refer to the SDK

Resources to prepare

1. Kafka. Call messages sent and received using Kafka, so you need to be ready to run Kafka Server, and replace kafka configuration information with your kafka server information

2. Mysql. You need to have a mysql database. Database: server_info and create a table

CREATE TABLE 'server_Invocation' ('id 'BIGint (20) NOT NULL AUTO_INCREMENT COMMENT' ID, Increment ', 'from_application' varchar(100) NOT NULL DEFAULT COMMENT ', 'to_application' varchar(100) NOT NULL DEFAULT COMMENT ', 'from_path' varchar(100) NOT NULL DEFAULT COMMENT 'path', 'to_path' varchar(100) NOT NULL DEFAULT COMMENT 'id ', 'method' varchar(32) NOT NULL DEFAULT 'COMMENT' GET POST', `ctime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `utime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 'creator_id' bigint(20) NOT NULL DEFAULT '0' COMMENT 'id', 'create_name' varchar(32) NOT NULL DEFAULT COMMENT ', PRIMARY KEY (' id ')) ENGINE=InnoDB DEFAULT CHARSET= utf8MB4 COMMENT=' InnoDB ';Copy the code

3. eureka

This project is based on the Spring Cloud system, so Eureka is required

Refer to the SDK

After importing the source code, jar microservice-comb-Infrastructure with MVN and introduce it into the application project. Replace the original module or service that references Spring-Cloud-starter-OpenFeign with a reference to microservice-comb-Infrastructure as follows

<dependency> <groupId>com.skyler.cobweb</groupId> <artifactId>microservice-comb-infrastructure</artifactId> < version > 1.0.0 - the SNAPSHOT < / version > < / dependency >Copy the code

Simulation of actual combat

For ease of use and access. The microService-comb-Example module provides the simulation of microservice architecture patterns in real companies. Microservice-comb-example contains three sub-modules, and the overall relationship is

Microservice-comb-server-a relies on microservice-comb-server-b-sdk, Because microservice-comb-server-A needs to call the FEign interface of the SDK microservice-comb-server-B relies on microservice-comb-server-b-SDK, Because the Controller of MicroService-comb-server-B implements the FEign interface of the SDK microservice-comb-server-b-SDK relies on microService-comb-InfrastructureCopy the code

1. Run the service

Run the following services in sequence

microservice-comb-server-a
microservice-comb-server-b
microservice-comb-server
Copy the code

2. Access the Microservice-comb-server-A interface

Skyler @ 192 ~  curl -x GET 'localhost: 9090 / combo/getById? id=10'

3. Viewing database Data

As is shown in

Simulating enterprise practical application

The microservice-comb-admin function is responsible for displaying the inter-service invocation diagram of the database. Because I did not learn the front-end technology. The effect is temporarily displayed through query SQL

View invocation relationships between multiple services in microservices

• Query the services and interfaces invoked by microservice-comb-server-b

SELECT * FROM server_invocation WHERE from_application = 'microservice-comb-server-b' 
Copy the code

The result is shown below,

Note: Support to display accurate to the call method, conditional query is good

• Query which services and interfaces invoke microservice-comb-server-b

SELECT * FROM server_invocation WHERE to_application = 'microservice-comb-server-b' 
Copy the code

The result is shown below

Project address: MicroService-Comb