Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what is the core concept of MOSN". In daily operation, I believe many people have doubts about what the core concept of MOSN is. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubt of "what is the core concept of MOSN?" Next, please follow the editor to study!

Core concepts of MOSN

MOSN is mainly divided into the following modules, including the basic capabilities of network agents and cloud native capabilities such as xDS.

XDS (UDPA) support

MOSN supports cloud native unified data plane API (UDPA) and fully dynamic configuration updates.

XDS, a key concept created by Envoy, is a general term for a class of discovery services, which includes the following categories:

CDS:Cluster Discovery Service

EDS:Endpoint Discovery Service

SDS:Secret Discovery Service

RDS:Route Discovery Service

LDS:Listener Discovery Service

It is through the request to xDS that the Envoy configuration is updated dynamically, and there is also an ADS (Aggregated Discovery Service) that solves the update order problem of the above xDS through aggregation.

Business support

As a low-level high-performance secure network agent, MOSN supports business scenarios such as RPC, Messaging, Gateway and so on.

IO model

MOSN supports the following two IO models:

Golang classic netpoll model: goroutine-per-connection, suitable for situations where the number of connections is not a bottleneck.

RawEpoll model: that is, Reactor mode, I multiplexing O multiplexing + non-blocking I multiplexing O mode. For scenarios with a large number of long links between the access layer and the gateway, it is more suitable for the RawEpoll model.

Netpoll model

The netpoll model of MOSN is shown in the figure above. The number of collaborators is proportional to the number of links. In the case of a large number of links, the number of collaborators is too large, resulting in the following overhead:

Stack memory overhead

Read buffer overhead

Runtime scheduling overhead

RawEpoll model

The RawEpoll model is shown in the figure above. After the readable event is sensed by epoll, the process is assigned to it from the pool. The steps are as follows:

After the link is established, you want Epoll to register oneshot readable event listeners; and no co-programs are allowed to call conn.read at this time to avoid conflicts with runtime netpoll.

When the readable event arrives, pick a co-program from the goroutine pool to handle the read event; because you are using the oneshot mode, the subsequent readable event of the fd will not be triggered again.

In the process of request processing, the cooperative scheduling is consistent with the classical netpoll mode.

When the request processing is complete, the collaborator is returned to the protocol pool; the fd reproduction is added to the RawEpoll at the same time.

Cooperative process model

The collaborative process model of MOSN is shown in the following figure.

A TCP connection corresponds to a Read protocol, which performs packet receiving and protocol parsing.

A request corresponds to a worker protocol that performs business processing, proxy and Write logic

In the conventional model, a TCP connection will have two Read/Write co-programs. We cancel the separate Write co-programs and let the workerpool work co-programs instead, reducing scheduling latency and memory footprint.

Capacity extension protocol extension

MOSN provides the plugin mechanism of the protocol by using the same codec engine and codec core interface, including support for:

SOFARPC

HTTP1.x/HTTP2.0

Dubbo

NetworkFilter extension

MOSN implements the network filter extension mechanism by providing a Network filter registration mechanism and a unified packet read/write filter interface. Currently, it supports:

TCP proxy

Fault injection

StreamFilter extension

MOSN implements the Stream filter extension mechanism by providing stream filter registration mechanism and a unified stream send/receive filter interface, including support for:

Traffic mirroring

RBAC authentication

TLS secure link

Through the test, the TLS of the native Go has been optimized by a large number of assemblers. In terms of performance, it is 80% of the Go of Nginx (OpenSSL) (calling BoringSSL using cgo). Because of the performance problems of cgo, we finally choose to use the TLS of native Go. We believe that there will be more optimizations in the Go Runtime team, and we will also have some optimization plans.

The Go vs Nginx test results are shown in the following figure:

Go doesn't have much optimization on RSA, and go-boring (CGO) is twice as powerful as Go.

P256 is optimized by assembly on Go, and ECDSA is better than go-boring.

In AES-GCM symmetric encryption, Go is 20 times more powerful than go-boring.

HASH algorithms such as SHA and MD also have corresponding assembly optimizations.

In order to meet the security and compliance of financial scenarios, we also develop support for domestic passwords, which Go Runtime does not have. Although there is still some gap between the current performance and the international standard AES-GCM, about 50%, we already have some follow-up optimization plans, please look forward to it.

The performance test results supporting Guomi are shown below:

At this point, the study of "what is the core concept of MOSN" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.