Introduction to the

Soul-client is a soul-client

conclusion

An overview of

In the last two articles, we looked at HTTP and Apache Dubbo registrations as follows:

  • 1. Get the Bean (class)
  • 2. Use the annotations on the class to determine whether registration is required
  • 3. Register with Admin through HTTP

After a brief look at other Alibaba Dubbo, Sofa, Tars and SpringCloud, we find that they are basically similar and not special. Therefore, there is no need for further analysis. Here is a summary of this module

The soul-Client module registration process is as follows:

Let’s talk about it

Access to the Bean

The basic idea is to get beans (classes) using the mechanisms provided by Spring IOC, and there are two ways to get beans (classes) in the code:

  • 1. BeanPostProcessor: This method triggers execution after each Bean is generated
  • ApplicationListener: This method triggers execution after all beans have been generated

At first glance, the second method may be better, but when you think about it, it is almost the same. Basically, you need to iterate over the Bean once (I don’t know the details, here is a preliminary guess), and I feel that the two methods should be interchangeable, but it is more convenient to write, this feeling is not a problem

Registered judgment

Overview of all registration judgment, basically by judging whether there is a corresponding SoulXXX notes, if there is the idea of registration

Here SoulTarsClient, it’s a little bit special, by whether there is a SoulTarsService annotation, if there is, you can register, but there is no difference, just more intuitive

Registered to the Admin

Currently, registration is done through the HTTP interface that is invoked and then registered with Admin. Each Client has its own registration link

A later version may add the Zookeeper registration method, but it will feel much the same as HTTP, and the basic elements will remain the same

Soul Gateway source code parsing article list

The Denver nuggets

Understanding and preliminary operation

  • Soul Gateway source code parsing (a) overview
  • Soul gateway source code analysis (two) the initial operation of the code

Request processing flow parsing

  • Soul Gateway source code parsing (iii) request processing overview
  • Soul Gateway source code parsing (4) Dubbo request overview
  • Soul gateway source code analysis (five) request type exploration
  • Soul Gateway source code analysis (six) Sofa request processing overview
  • Soul gateway source code analysis (seven) limit the flow plug-in exploration
  • Soul gateway source code analysis (eight) route matching exploration
  • Soul gateway source code analysis (nine) plug-in configuration loading preliminary
  • Soul gateway source code analysis (ten) custom simple plug-in preparation
  • Soul gateway source code parsing (11) request processing summary

Data Synchronization parsing

  • Soul gateway source code analysis (12) data synchronization
  • Soul gateway source code parsing (thirteen) Websocket synchronization data -Bootstrap end
  • Soul Gateway source code parsing (fourteen) HTTP data synchronization -Bootstrap end
  • Zookeeper data synchronization -Bootstrap end
  • Soul gateway source code analysis (sixteen) Nacos data synchronization example run
  • Soul gateway source code parsing (seventeen) Nacos data synchronization parsing -Bootstrap end
  • Soul gateway source code parsing (18) Zookeeper data synchronization preliminary -Admin end
  • Soul Gateway source code parsing (19) Nacos data synchronization initialization fix -Admin end
  • Soul gateway source code parsing (20) Websocket data synchronization -Admin end
  • Soul Gateway source code parsing (21) HTTP long polling data synchronization -Admin end
  • Soul gateway source code analysis (22) data synchronization summary

Soul – the Client module

  • Soul gateway source code analysis (23) SoulSpringMvcClient annotations
  • Soul gateway source code analysis (24) SoulDubboClient notes

One day

  • HTTP parameter request error