Architecture design: communication between systems (2)-overview from "chat" to the next part

Architecture design: communication between systems (2)-overview from "chat" to the next part

(Continued from the previous article: "Architecture Design: Inter-System Communication (1)-Overview from "Chat" to the first article" )

4-3, NIO communication framework

There are many popular NIO frameworks. The following are the most discussed and used in forums and on the Internet:

  • Native JAVA NIO framework:
    JAVA NIO communication framework is based on the principle of multiplexing IO, we will explain its working principle in detail.

    is a network application framework, used to help users simply develop high-performance and high-scalability network applications. It provides an abstract event-driven asynchronous API on different transmissions such as TCP/IP and UDP/IP through Java NIO.

  • NETTY 4/5:
    Netty is a java open source framework provided by JBOSS. Netty provides asynchronous, event-driven network application frameworks and tools to quickly develop high-performance, high-reliability network server and client programs. We will explain how NETTY 4 works. Another sentence: The main author of MANA and NETTY is the same person, Trustin Lee.

  • Grizzly:
    Grizzly is an application framework that specializes in solving various problems when writing thousands of users to access the server. Use JAVA NIO as the foundation and hide the complexity of its programming.

In this series of blog posts, we will spend some time explaining the java native NIO framework (IO reuse mode) provided after java 5.0 to in-depth implementation principles, and then we will focus on the Netty 4.0.X framework as the line to explain. Mainly to let you understand the important position of Channel, Buffer, Selection (SelectableChannel, SelectionKey, Selecotor) in NIO thinking.

5. Communication method

We all speak through the vocal cords, and control the tone and volume through our mouth and tongue. The sound is transmitted to the other's ears, processed by the other's brain, and then transmitted to our ears through the other's voice, so our brains get the answer.

5-1. Use pure HTTP request directly

What is your understanding of "simplicity"? Fast development, fast deployment, fast understanding, or fast call speed and high concurrency support? No matter how you understand "succinctness", there is a fact that you cannot deny that a large part of companies use pure Http protocol (using standard WEB container) + JSON information format for communication between systems. This approach has several advantages:

  • Quick start: For companies that have a rich accumulation of web systems, there is no need to think about "is this interface for end users or for communication with another system", it can be provided to the interface between systems according to the gourd drawing.

  • Fast implementation: As mentioned above, regardless of the implementation details, any WEB system developer who has developed the task can take over this work, and the interface function can be implemented within minutes.

  • The speed is not too slow: Although few people compare the speed of RMI and HTTP, or the speed of Dubbo and HTTP calls, from various introductions, although the speed of the latter is not as fast as the former, the speed of the latter is still acceptable. of. And the concurrency problem can be solved by other solutions (Nginx or Haproxy, this related technology is described in the "Load Balancing Layer" technical solution series in the " Load Balancing Layer Technology ")

5-2. The problem of using HTTP calls directly

But using HTTP directly, there are still some problems:

  • Because it is based on HTTP and the WEB container designed for client interaction, its speed will be a problem after all. In the article " Architectural Layering of Standard Web Systems ", I have talked about the HTTP communication process in detail.

  • Although there are many ways in the HTTP protocol to optimize access speed. For example, use keep-alive to keep the connection reuse of Http Connection, and use gzip to compress the transmission data in the Body. However, the speed will be affected by the choice of WEB server and the characteristics of HTTP communication.

  • Poor management: The management mentioned here does not mean that hundreds of interfaces cannot be managed using word documents; rather, as the system continues to grow, the complexity of the interfaces will increase geometrically. The processing requested by the terminal client at one time is no longer processed by one system. Instead, multiple systems must be used to perform correlation calculations to get the result. So, what should I do at this time? Of course, if you have to say, how to call each system interactively and hand it over to the terminal client for processing, well, I'm speechless. . .

  • In fact, the implementation speed of calling the pure HTTP + JSON message format is really not the fastest. . . It may be because some teams have not used other calling techniques (in a production environment), so there is no way to compare them. Personally, I think: there is no best technology, only the most suitable technology, so there is nothing wrong with using pure HTTP + JSON information format technology between simple business systems .

5-2, RPC

Originally, I was planning this series of articles and pointed out that I did not plan to write specifically about the RPC call method, because the implementation of RPC is complicated in error, and it is impossible to make it clear in a few articles. For example: Among the articles that can be found, some people attribute protocol buffer to an implementation of RPC; more articles will directly link RPC and service governance; some articles regard RPC framework as a SOA (for SOA) The implementation of the service architecture) is described. Of course, the above statements are all based, and we will talk about them in detail later; (but I do not agree with the concepts of some articles, so we must know how to get rid of the false and keep the truth ^_^)

In fact, the reason why RPC technology is difficult to distinguish from other technologies/specifications is that in addition to the superficial phenomenon described above, the more important reason is that the current software that implements the RPC framework often combines various interlaced technical specifications/definitions. To implement integration, or to learn from some ideas in RPC . For example, Ali's RPC framework Dubbo, in addition to following RPC rules, important functions are also placed in the realization of service governance;

Several great gods told me that if you don't write RPC, then this series of blog posts called "inter-system communication" will become nameless or incorrect. Therefore, it must be written no matter what. My general writing idea is: first explain the concept, development and working principle of RPC. Then use the RPC implementation used in my actual work to explain the use. In addition to explaining the usage, we will also explain the performance comparison of several HTTP-RPC and non-HTTP-RPC. Of course, writing RPC is doomed to some of the points in this series, and will be pushed to the cusp of criticism for criticism, and you will just complain about it at will. In this series of blog posts, we will focus on special RPC services-JAVA RMI, Ali's RPC framework Dubbo (service governance will also be explained together), Apache Thift.

5-3, MQ

Message queue is another realization of communication between systems. There are currently many types of message queue specifications, with different scenarios and implementation performances. In this series of blog posts, we will spend a certain amount of space to introduce the two message queue protocols and implementations of JMS and AMQP (especially the AMQP protocol), then introduce the Kafka message queue and usage scenarios, and finally look forward to the current known as the fastest message queue ZMQ.

6. Integration means-ESB and service governance

6-1, ESB

ESB (Enterprise Service Bus) is a typical implementation of SOA. The common feature of various ESB software is: to centralize (manage, control, and coordinate) the services provided by various (access rights) systems, and the requestor only needs Access the ESB software, and then the ESB software accesses the designated service on its behalf, and finally returns the processing result. The functional feature of ESB is agency .

In this series of blog posts, we will spend a relatively large amount of space explaining the principles and use of Apache Camel, thereby indirectly explaining several important concepts in ESB (service order arrangement/definition, service realization isolation, multi-protocol support, protocol translation, forwarding proxy) , Transaction control, etc.). If there is more abundant time, we will explain a real project based on Apache Camel.

At present, there are many shared/commercial ESB software on the market, such as JBossESB, EOS, and ESB products from IBM and ORACLE. But again, understanding the principles and technical characteristics is the most critical.

6-2. Service Registration Center

The service registry is another implementation of SOA. The biggest difference from ESB is that the "service registry" mainly provides service registration, service governance, service isolation, and authority control for each atomic system. When the client makes a request, the "service management" will tell the client where to access the real service, and it does not provide service forwarding . Dubbo is a typical service governance framework.

6-3. Implement distributed call service by yourself

In this series of blog posts, we will implement a registration and management center based on zookeeper. It is of course a simple one, just to illustrate the working method of the service registry.

7. Introduction

In the next article, we will start with the introduction of "NIO, BIO communication framework".