Several implementations of dynamic routing for PaaS 7 layer

This is a creation in Article, where the information may have evolved or changed.

absrtact: with the advent of Docker, PaaS, CaaS (Container as A Service), and even DCOs (DataCenter OS) present an explosive development. In PAAs, because instances generally default to dynamic IPs, for 7-layer calls (such as HTTP requests), 7-tier dynamic routing is required to obtain the mapping of the application domain name (or virtual IP) and back-end instances to provide 7-tier services, and for 4-layer calls (such as RPC calls), you can use dynamic LVS or name services ( or a service registration and Discovery tool based on implementations such as ZOOKEEPER/ETCD).

With the advent of Docker, PaaS, CaaS (Container as A Service), and even DCOs (DataCenter OS) presented an explosive development. In PAAs, because instances generally default to dynamic IPs, for 7-layer calls (such as HTTP requests), 7-tier dynamic routing is required to obtain the mapping of the application domain name (or virtual IP) and back-end instances to provide 7-tier services, and for 4-layer calls (such as RPC calls), you can use dynamic LVS or name services ( or a service registration and Discovery tool based on implementations such as ZOOKEEPER/ETCD).

For example, the developer creates an app in the PAAs that contains several instances and then binds a domain name to the app. The user makes a request to the app and needs to be processed by the backend instance to return correctly. Then, as a 7-tier dynamic routing, the core is to obtain the domain name (or virtual IP) and back-end instances of the corresponding relationship and as a reverse proxy to complete the request forwarding.

A few implementations of the 7-tier dynamic routing are briefly discussed here. Because Nginx is a high-performance reverse proxy server, in order to implement 7-tier dynamic routing based on Nginx, these implementations can be divided into two major categories.

The first class, do not rely on Nginx, the project itself to achieve the function of reverse proxy.

Cloudfoundry can be said to be the first generation of the open source PAAs project, its module gorouter is a dynamic routing implementation (supporting both 4-and 7-tier). Take Cloudfoundry (release v164) as an example, use Nats as the message bus to decouple the module calls and message passing. You can take a look at the code of Gorouter (tag 45ca951297) and implement the corresponding logic code in REGISTRY/REGISTRY.GO to get the correspondence between the domain name and the backend instance. The approximate process is:

After the instance is started, the message is published to Nats, and Gorouter subscribes to these messages to obtain the corresponding relationship between the application domain name and the backend instance, while Gorouter uses Goroutine for high-performance request processing and forwarding, supporting 4-layer and 7-layer calls.

Docker-based lightweight PAAs emerges, and you may store instance information (such as IP information) in Redis (or other data stores). Open Source Project DINP Basically this implementation, Dinp-router fork from Cloudfoundry gorouter (tag 45ca951297), changed part of the code to get the application domain name and Redis stored in the back-end instance of the corresponding relationship, The function of 7 layer dynamic routing is realized.

Similarly, DotCloud's Hipache uses Nodejs's HTTP library for request forwarding, while backend instance information can be stored in Redis.

Of course, many engineers in the 7-layer selection on the more reliable nginx, after all, nginx in performance, stability, scalability is the perfect choice. Based on Nginx to achieve 7-layer dynamic routing, there are probably two ways to realize the idea.

First, based on the name Service (or service registration and Discovery tool based on ZOOKEEPER/ETCD), the registered backend instance is updated to the upstream of the Nginx configuration file through watch or timed scheduling, thus realizing the real-time change of the backend. This is also like CONFD and other open source tools. CONFD based on the Golang template Library, the Nginx configuration files as templates, support Consul/etcd/redis/zookeeper and many other back-end storage, through watch or scheduled scheduling from these back-end to obtain instance information, and update to Nginx profile template, so as to achieve (quasi) real-time 7-tier dynamic routing. This implementation logic is simple, high stability, but in large-scale applications, Nginx may be more frequent reload.

Second, based on Nginx-lua implementation. Each time a user request arrives at the appropriate upstream, the back-end instance information is obtained through Nginx-lua from the data store such as Redis, enabling the request to be forwarded. Nginx acquisition of REDIS data requires a network request, the same time delay in the same room is generally millisecond, but there may be some problems in large traffic, so you can use Lua-shared-dict as the system cache.

Reference:

Https://github.com/openresty/lua-nginx-module

http://segmentfault.com/a/1190000004128807?luicode=10000359&luicode=10000359

This article transferred from D1net (reprint)

If you find content in the community that is suspected of plagiarism, please send an email to: yqgroup@service.aliyun.com to report, and provide relevant evidence, once verified, the community will immediately delete the allegedly infringing content.

Original link