Architecture Design: Inter-system Communication (16)--Service governance and Dubbo Medium (preheating)

1. Pre-order

In the previous article ("Architecture Design: Communication between systems (15)-Service governance and Dubbo"), we explained the basic use of Ali Dubbo Service governance framework in the way of example. Starting from this section, we will explain the design principles of Dubbo's main modules to help readers understand how Dubbo works. (Because this chapter is more content, including the knowledge preparation, Dubbo Framework overview, Dubbo each module analysis, so I will cut the content into several articles)

2. Basic Knowledge Preparation

In order to give readers a better understanding of what is being explained below, we will introduce some basic knowledge before we begin to explain the main modules of the Dubbo framework. This basic knowledge will help readers to understand the technical analysis of the back more easily. These fundamentals include a javassist component that works in the Dubbo Framework agent layer, a creation pattern that is used extensively throughout the Dubbo framework: The factory method pattern, and several third-party frameworks used in the Dubbo layers.

2-1. Dynamic Programming: Javassist

Javassist is an open source class library for parsing, editing, and creating Java bytecode. It was created by Shigeru Chiba (Thousand Yezi) of the Department of Mathematics and Computer Science at the Tokyo Institute of Technology. It has joined the open source JBoss Application Server project to implement the dynamic "AOP" framework for JBoss by using javassist to bytecode operations. (Excerpt from Baidu Encyclopedia)

The word is: When a Java application runs, it dynamically generates the class and instantiates it as required . We all know that in the Java language we can load an already existing class file with a "reflection" mechanism while the Java application is running. However, there are two prerequisites: This class is already present at compile time, and the class is on a path that java-classloader can identify.

While the Javassist component gives us a new option, there is no need for this Java file to be present in the compilation period or to compile the good one class for this Java file. Instead, the runtime generates class. The following code examples are used:

Classpool pool = Classpool. Getdefault();Create a class named Foo ctclass cc = Pool. Makeclass("Foo");Create a method called ' Getinteger ' ctmethod mthd = Ctnewmethod. make("public Integer Getinteger () {return null;}", CC);Cc. Addmethod(MTHD);Create a property called I, whose type is ' int ' ctfield f = new Ctfield (ctclass. Inttype,"I", CC);Point. AddField(f);Instantiation of this class clazz = CC. Toclass(); Object Instance = Class. newinstance();

Let's guess, what do Dubbo do with it? Tip: The main Dubbo in the RPC module "agent layer" in use OH ~ ~

2-2. Design mode: Factory method mode

There is a creation model in design mode (23 design pattern, divided into three categories: Create model, structure model and behavior model), under this model, we create a-interface implementation in any particular environment through the factory Afactory interface of the A interface.

For example, we can define a router (routing service) and, through router's Routerfactory abstraction factory, unify the specific implementation of any kind of route (whether it is the route that the script implements, the route the configuration file implements, or the route that the dynamic condition implements). For external callers, it sees the interface service "Router". The following is a typical class diagram of a factory method pattern:

, the client class, in the Dubbo framework, represents the other modules within the framework. The advantage of the factory method pattern is that for some form of business implementation, there will be a specific object factory pointing to it, and when a new business implementation needs to be added, Just add another specific implementation of this business interface and a specific factory that points to this implementation: Now the RPC protocol layer supported by Dubbo supports Dubbo, Thrift, RMI, etc., they all have the corresponding creation factory; If the subsequent Dubbo framework needs to introduce a new RPC protocol layer support, simply create the specific implementation of this RPC protocol, and the corresponding create factory. The existing RPC protocol support is not affected by any of the other modules in the Dubbo framework that use this RPC protocol module, and because the Protocol interface is used, it does not feel any different.

Given the specific use of the client (pseudo-code, I write "fast", if I know you already understand the abstract factory model design Core):

null;if([conditionA]) {    newelseif([conditionB]) {    new ProductBFactory();}IProduct product = productFactory.getProduct();

Obviously if the client uses abstract factories to create a concrete iproduct implementation, there is a fallacy: the client must know that the current system environment is either Conditiona or CONDITIONB, It is also important to know that the Iproductfactory interface has two implementations, either Productafactory or Productbfactory.

To ensure that these details ' callers do not need to care ', one approach is to hide the implementation details of iproductfactory into the factory method model: Abstracting the factory interface and instantiating it internally with a singleton pattern:

public abstract class Abstractproductfactory { ...      ...  public static Abstractproductfactory Getnewinstance () {  ...  if  ([])        {productfactory = new productafactory (); } else  if  () {productfactory = new productbfactory ();    } return  productfactory; } public abstract iproduct getproduct ();}  

Depending on whether abstractproductfactory is creating productafactory or creating productbfactory conditional logic, it is not necessary for the caller of the module to be aware that the caller of the module will not know that there are two kinds of business implementations of IProduct. But Abstractproductfactory still did not escape the doom: in the new business environment, business implementation to join the module, the technician still need to rewrite the abstractproductfactory in the getnewinstance implementation. The essential reason here is that you always have to write your own ' new ' keyword, since you have to write the ' new ' keyword, you have to know all the details ;

So there is no way, let abstractproductfactory further please this bad luck (design structure more optimized)? The answer must be: Use Spring's dynamic agent technology to get rid of ' new ' completely:

public Class Client {    ......     @Autowired    private IProductFactory productFactory;    public void someMethod() {        IProduct product = productFactory.getProduct();        ......    }}

The following is the spring configuration information

id="productFactory"class=".......ProductAFactory"/>

2-3, RPC noun:

Now the industry mainstream RPC technology has been mentioned in the previous article. Here in order to facilitate everyone to find the rhythm, and then a general introduction (the following introduction from the Baidu Encyclopedia):

• Apache Thrift:thrift was originally developed by Facebook for RPC communication between languages in the system. entered the Apache incubator in May 08. Apache Thrift supports RPC communication between multiple languages via its own independent set of IDL languages.

• Rmi:rmi is a set of Java APIs that support the development of distributed applications. RMI defines a remote object using the Java language interface, which aggregates the Java serialization and Java Remote Method Protocol (Java Protocol). RMI has a typical function partition in RPC rules and is an RPC framework for remote invocation between systems built in the Java language.

• Hessian:hessian is a lightweight remoting onhttp tool that provides RMI functionality in an easy-to-use way. Simpler and faster than Webservice,hessian. The binary RPC protocol is used because the binary protocol is used, so it is well suited for sending binary data.

The core/minor structural elements of the RPC framework have been described in detail in one of my previous posts (architecture Design: Basic concepts of inter-system Communication (--RPC)).

Each of them is:

• Service Management layer/Registration Management layer (SELECTOR/PROCESSOR): exists on the RPC server side, due to the implementation of one of the RPC interfaces on the servers (it does not know that it is a service that will be called by RPC to a third-party system). Therefore, there should be a role in the RPC framework that is responsible for implementing RPC interface implementations. It is responsible for including: To manage the RPC interface registration, determine the client's request permissions, control the implementation of the interface implementation of the various types of work.

• Call Agent Layer (STUB/PROXY): RPC proxy exists in the client, because to implement the client to the RPC framework "transparent" call, then the client is not able to manage the message format itself, it is not possible to manage the network transport protocol itself, it is not possible to determine whether the call process is abnormal. All this work is done on the client side, which is given to the "agent" layer in the RPC framework.

• Message layer/Serialization layer (Message Protocol): The RPC message management layer specifically numbers and decodes the message information that is hosted on the network transport. The prevailing technology trend is that different RPC implementations have a set of (or a few sets) of proprietary message formats to enhance the efficiency of their own frameworks. Just like the RMI JRMP protocol described earlier, the Thrift Private Message Protocol, and so on.

• Transport management Layer (Transfer/network Protocol): The transport protocol layer is responsible for managing the network protocol, network IO model used by the RPC framework. For example, the transport protocol for Hessian is based on the HTTP (Application-layer protocol), while the Thrift Transport Protocol is based on the TCP (Transport-layer protocol). The transport layer also needs to unify the network IO model used by the RPC client and RPC server;

• IDL language: The fact that IDL (interface Definition Language) is not required in RPC implementations. But the RPC framework that requires cross-language is bound to have IDL parts. This is because you want to find a description of the message structure, the interface definition, that can be understood by various languages. If your RPC implementation does not consider cross-lingual, then the IDL section is not required.

2-4, network framework layer noun:

Part of the reader of Netty, MINA, grizzly This group of technical terms and thrift, RMI, Hessian This group of technical terms silly confused. The fundamental reason is that the basic principle of network communication is not clear, the former group of technology represents the Java language to the network IO Model encapsulation (see this series of article "Architecture Design: Inter-system Communication (3)--io communication model and Java Practice", "Architecture design: Inter-system Communication (4)-- IO communication model and Java practice Medium, Architecture Design: Inter-system Communication (5)--io communication model and Java practice in the next chapter).

• Network IO Model: The network IO model is a branch of the computer IO technology (disk IO model I will be detailed in the next series of blog post: Storage System, scheduled to be launched in the first half of next year after the end of this series blog). The currently included network IO models are: Blocking synchronous io, non-blocking synchronous io, multiplexed io, and asynchronous IO.

• Netty and Mina: The package components of the two network IO models are led by the same technician. One of the Netty is a Java open source framework provided by JBoss. Netty and Mina provide asynchronous, event-driven network application frameworks and tools (and not just this) for rapid development of high-performance, high-reliability network servers and client programs.

• Grizzly: from Grizzly official website (https://grizzly.java.net/)

  Writing Scalable server applications in the Java? Programming language have always been difficult. Before the advent of the Java New I/O API (NIO), thread management issues made it impossible for a server to thou Sands of users. The Grizzly NIO Framework has been designed to help developers to take advantage of the Java? NIO API. Grizzly ' s goal is-help developers to build scalable and robust servers using NIO as well as offering extended framework Components:web Framework (http/s), WebSocket, Comet, and more!

(next)

Schema design: Inter-system Communication (16)--Service governance and Dubbo Medium (preheating)