index.json

[{"body":"MOSN (Modular Open Smart Network) is a cloud-native network proxy written in Go language. It is open sourced by Ant Group and verified by hundreds of thousands of production containers in 11.11 global shopping festival. MOSN provides the capabilities of multiple protocol, modularity, intelligent and security. It integrates a large number of cloud-native components, and also integrates a Envoy network library, which is high-performance and easy to expand. MOSN and Istio can be integrated to build Service Mesh, and can also be used as independent L4/L7 load balancers, API gateways, cloud native Ingress, and etc.\nQuick start For details, see Quick start.\nCore capabilities  Istio integration  Integrates Istio 1.10 to run in full dynamic resource configuration mode   Core forwarding  Supports a self-contained server Supports the TCP proxy Supports the UDP proxy Supports transparent traffic hijack mode   Multi-protocol  Supports HTTP/1.1 and HTTP/2 Supports protocol extension based on XProtocol framework Supports protocol automatic identification Supports gRPC   Core routing  Supports virtual host-based routing Supports headers/URL/prefix/variable/dsl routing Supports redirect/direct response/traffic mirror routing Supports host metadata-based subset routing Supports weighted routing. Supports retries and timeout configuration Supports request and response headers to add/remove   Back-end management \u0026amp; load balancing  Supports connection pools Supports persistent connection\u0026rsquo;s heart beat handling Supports circuit breaker Supports active back-end health check Supports load balancing policies: random/rr/wrr/edf Supports host metadata-based subset load balancing policies Supports different cluster types: original dst/dns/simple Supports cluster type extension   Observability  Support trace module extension Integrates jaeger/skywalking Support metrics with prometheus style Support configurable access log Support admin API extension Integrates Holmes to automatic trigger pprof   TLS  Support multiple certificates matches, and TLS inspector mode. Support SDS for certificate get and update Support extensible certificate get, update and verify Support CGo-based cipher suites: SM3/SM4   Process management  Supports hot upgrades Supports graceful shutdown   Extension capabilities  Supports go-plugin based extension Supports process based extension Supports WASM based extension Supports custom extensions configuration Supports custom extensions at the TCP I/O layer and protocol layer    MOSN Community The MOSN open-source community is developing rapidly and expecting continuous improvements. You are all welcome to join us.\nFor a more detailed description of the MOSN community check out the mosn/community repo, if you have any questions, submit issues.\n","excerpt":"MOSN (Modular Open Smart Network) is a cloud-native network proxy written in Go language. It is open …","ref":"https://mosn.io/en/docs/overview/","title":"MOSN overview"},{"body":"This topic is intended to help developers who are new to MOSN projects quickly set up a development environment for building, testing, packaging, and running the sample code.\nPrepare the running environment  If you want to run MOSN with docker, install docker first. If you are using a local machine, set up a Unix-like environment. Install the compilation environment of Go.  Obtain the code Code for MOSN projects is hosted at Github. Run the following command to obtain the code.\ngo get -u mosn.io/mosn If the go get command fails, manually create a project.\n# Access the src directory under GOPATH. cd $GOPATH/src # Create the mosn.io directory. mkdir -p mosn.io cd mosn.io # Clone MOSN code. git clone git@github.com:mosn/mosn.git cd mosn The MOSN source code is finally saved to $GOPATH/src/mosn.io/mosn.\nImport the MOSN source code into the IDE Import $GOPATH/src/mosn.io/mosn into your preferred Go IDE (Goland is recommended).\nCompile the code In the project\u0026rsquo;s root directory, compile the binary file of MOSN by running the following commands, depending on your machine type and the environment in which you want to execute the binary file.\nIstio version switch MOSN support xDS v2 and xDS v3, which are represented by Istio 1.5.2 and Istio 1.10.6 respectively. It can be switched between different versions according to needs. The default version is 1.10.6.\nSwitch to Istio 1.5.2 (xDS v2)\nmake istio-1.5.2 Switch to Istio 1.10.6 (xDS v3)\nmake istio-1.10.6 Compilation with a docker image make build // Compile a Linux 64-bit executable binary file. Local compilation Run the following command to compile a local executable binary file.\nmake build-local Find the compiled binary file in build/bundles/${version}/binary.\nRun tests Run the following command in the project\u0026rsquo;s root directory to start the unit test.\nmake unit-test Run the following command in the project\u0026rsquo;s root directory to start the integration test (which takes some time).\nmake integrate make integrate-new Start MOSN from the configuration file Run the following command to start MOSN from the configuration file.\n./mosn start -c \u0026#39;$CONFIG_FILE\u0026#39; Run MOSN samples Refer to the example projects in the examples directory to run samples.\nBuild the Service Mesh platform with MOSN For more information, see the Istio integration.\n","excerpt":"This topic is intended to help developers who are new to MOSN projects quickly set up a development …","ref":"https://mosn.io/en/docs/quick-start/proxy/","title":"Quick start"},{"body":"This topic describes the SkyWalking configurations of MOSN.\nCurrently, support HTTP1 protocol.\nThe SkyWalking configuration structure is shown as follows.\n{ \u0026#34;tracing\u0026#34;: { \u0026#34;enable\u0026#34;: true, \u0026#34;driver\u0026#34;: \u0026#34;SkyWalking\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;reporter\u0026#34;: \u0026#34;gRPC\u0026#34;, \u0026#34;backend_service\u0026#34;: \u0026#34;127.0.0.1:11800\u0026#34;, \u0026#34;service_name\u0026#34;: \u0026#34;mosn\u0026#34;, \u0026#34;max_send_queue_size\u0026#34;: 30000, \u0026#34;authentication\u0026#34;: \u0026#34;mosn\u0026#34;, \u0026#34;tls\u0026#34;: { \u0026#34;cert_file\u0026#34;: \u0026#34;cert.crt\u0026#34;, \u0026#34;server_name_override\u0026#34;: \u0026#34;mosn.io\u0026#34; } } } } reporter Reporter mode, support log (only test) and gRPC.\n If this field is left empty, log by default.  backend_service SkyWalking backend service address, used only if the reporter is gRCP.\n eg: 127.0.0.1:11800.  service_name To register the service name to SkyWalking, used only if the reporter is gRCP.\n If this field is left empty, mosn by default.  max_send_queue_size Trace data cache queue size, used only if the reporter is gRCP.\n If this field is left empty, 30000 by default.  authentication gRPC authentication, used only if the reporter is gRCP.\n If the field is not empty, this parameter is used for authentication when establishing a connection with the SkyWalking backend service.  tls Used only if the reporter is gRCP.\n If the field is not empty, TLS will be used to connect to the SkyWalking backend service.  cert_file TLS client certificate.\nserver_name_override Service name.\n","excerpt":"This topic describes the SkyWalking configurations of MOSN.\nCurrently, support HTTP1 protocol.\nThe …","ref":"https://mosn.io/en/docs/configuration/trace/skywalking/","title":"SkyWalking configurations"},{"body":"To contribute to MOSN\u0026rsquo;s documentation, you need to:\n Create a GitHub account.  This documentation is published in compliance with Apache 2.0 license.\nHow to contribute You can contribute to MOSN\u0026rsquo;s documentation in the following three ways:\n To edit an existing topic, open the page with your browser, click Edit This Page on the upper-right side, edit the GitHub page that appears, and submit the modifications. To make general edits, follow the procedure in Add content. To review an existing pull request (PR), follow the procedure in the Review PRs.  PRs are immediately displayed on https://mosn.io after being merged.\nAdd content To add content, you need to create a repository branch and submit a PR to the mater repository from the branch. Perform the following steps:\n Access the MOSN repository at GitHub https://github.com/mosn/mosn.io. Click Fork in the upper-right corner to fork a copy of the MOSN repository to your GitHub account. Clone your fork to your computer and make modifications as required. Upload the modifications to your fork repository when you are ready to submit them to us. Go to the index page of your fork repository and click New pull request to submit a PR.  Review PRs You can directly comment on a PR. To add detailed comments, perform the following steps:\n Add detailed comments to the PR. If possible, directly add comments to the corresponding files and file lines. Provide suggestions to the PR authors and contributors in the comments as appropriate. Publish and share your comments with the PR contributors. Merge the PR after publishing the comments and reaching an agreement with the contributors.  Preview PRs You can preview your PR online or run Hugo on your computer to access the MOSN website for real-time preview.\nOnline preview After you submit a PR, a series of check items are displayed on the corresponding PR page at GitHub. The deploy/netlify step generates the preview page on the MOSN official website. You can click Details to go to the preview page. A preview page is constructed each time you submit the same PR.\nThis temporary website ensures normal page display after the PR is merged.\nLocal preview In addition to online preview, you can also preview your PR with Hugo (the v0.55.5 extended version is recommended). You can run hugo server at the root directory of your code repository and then access http://localhost:1313 with your browser.\n","excerpt":"To contribute to MOSN\u0026rsquo;s documentation, you need to:\n Create a GitHub account.  This …","ref":"https://mosn.io/en/docs/contribute/github/","title":"Documentation contribution guide"},{"body":"This topic describes the FilterChain configurations of MOSN.\nFilterChain configurations are core logic configurations for MOSN listeners. Different FilterChain configurations describe how a listener handles requests.\nCurrently, a MOSN listener supports only one FilterChain.\nThe FilterChain configuration structure is shown as follows.\n{ \u0026#34;tls_context\u0026#34;: {}, \u0026#34;tls_context_set\u0026#34;: [], \u0026#34;filters\u0026#34;: [] } tls_context_set  Settings for a group of tls_context. MOSN uses tls_context_set to describe the TLS certificate information of a listener by default. A listener supports multiple TLS certificates simultaneously.  tls_context  Setting a single tls_context instead of tls_context_set is required for backward compatibility of MOSN (for earlier versions that support configuring only one certificate). This setting method will be gradually abandoned. For details about the tls_context configuration, see the tls_context.  filters Settings of a group of network filters.\nnetwork filter network filter specifies how MOSN processes connection data at layer 4 after a connection is established.\n{ \u0026#34;type\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;config\u0026#34;: {} }  type is a string that describes the filter type. config can be any json values that describe configurations of different filters. network filter supports custom extensions. The following types are supported by default: proxy, tcp proxy, and connection_manager.  connection_manager is a special filter used with proxy. It describes the router configurations of proxy and may be modified subsequently as a compatibility configuration.    ","excerpt":"This topic describes the FilterChain configurations of MOSN.\nFilterChain configurations are core …","ref":"https://mosn.io/en/docs/configuration/listener/filter-chain/","title":"FilterChain"},{"body":"proxy is the most common network filter in MOSN and is configured in the following format:\n{ \u0026#34;downstream_protocol\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;upstream_protocol\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;router_config_name\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;extend_config\u0026#34;:{} }  downstream_protocol: The request protocol that the proxy expects to receive. When receiving data from a connection, MOSN uses this protocol to parse and forward packets. If the received packet protocol does not comply with the configuration, MOSN closes the connection. upstream_protocol: The protocol used by the proxy to forward data. Usually, this field needs to be consistent with downstream_protocol. Protocol conversion is performed only in special scenarios. router_config_name: The router configuration index of the proxy. Usually, this field is consistent with router_config_name configured in connection_manager of the listener. extend_config: The extension configuration, used only in XProtocol of MOSN currently.  ","excerpt":"proxy is the most common network filter in MOSN and is configured in the following format:\n{ …","ref":"https://mosn.io/en/docs/configuration/listener/network-filter/proxy/","title":"proxy"},{"body":"Modular Open Smart Network (MOSN) mainly comprises the following modules. It provides basic network proxy features, and cloud-native services such as xDS.\nxDS (UDPA) support MOSN supports cloud-native Universal Data Plane APIs (UDPAs) and fully dynamic configuration updates.\nxDS is a key concept proposed by Envoy. It represents a set of discovery services:\n CDS: Cluster Discovery Service EDS: Endpoint Discovery Service SDS: Secret Discovery Service RDS: Route Discovery Service LDS: Listener Discovery Service  Envoy configurations are dynamically updated through xDS requests. The Aggregated Discovery Service (ADS) determines the xDS update order through aggregation.\nBusiness support As an underlying high-performance security network proxy, MOSN supports a variety of business scenarios, such as remote procedure calls (RPCs), messaging, gateways.\nI/O model MOSN supports the following two I/O models:\n  Golang\u0026rsquo;s classic netpoll model: a goroutine-per-connection model applicable when the number of connections is not a bottleneck.\n  RawEpoll model: also known as the Reactor model, is an I/O multiplexing + non-blocking I/O model. The RawEpoll model is more suitable for scenarios with a large number of persistent connections at the access layer and gateways.\n  netpoll model The MOSN netpoll model is shown in the above figure. The number of goroutines is proportional to that of connections. A large number of connections indicates a large number of goroutines and high overheads, including:\n Stack memory overhead Read buffer overhead Runtime scheduling overhead  RawEpoll model The RawEpoll model is shown in the above figure. After a readable event is detected by epoll, a goroutine is allocated from the goroutine pool to process the event. The procedure is as follows:\n After a connection is established, MOSN registers a oneshot readable event listener with epoll. To avoid conflict with the runtime netpoll, no goroutine is allowed to call conn.read at this time. After a readable event is detected, MOSN selects a goroutine from the goroutine pool to handle the event. No subsequent readable event will be triggered for the file descriptor (FD) again because the oneshot mode is used. During request handling, the goroutine scheduling process is consistent with that of the classic netpool model. After the request handling is complete, the goroutine is returned to the goroutine pool, and the FD is added back to RawEpoll.  Goroutine model The MOSN goroutine model is shown in the following figure.\n One TCP connection corresponds to one read goroutine, for receiving packets and parsing protocols. One request corresponds to one worker goroutine, for handling business and executing the proxy and write logic.  In the conventional model, one TCP connection corresponds to two goroutines: read and write. We have replaced the separate write goroutine with a workerpool goroutine, to reduce scheduling latency and memory usage.\nCapability extension Protocol extension MOSN implements a protocol plugin mechanism by using a unified codec engine and core codec APIs, providing support for:\n SOFARPC HTTP1.x/HTTP2.0 Dubbo  NetworkFilter extension MOSN implements a NetworkFilter extension mechanism by using a NetworkFilter registration mechanism and unified packet read/write filter APIs, providing support for:\n TCP proxy Fault injection  StreamFilter extension MOSN implements a StreamFilter extension mechanism by using a StreamFilter registration mechanism and unified stream send/receive filter APIs, providing support for:\n Traffic mirroring RBAC authentication  TLS connections Based on tests, the Go-native TLS, after a lot of assembly optimization, has improved its performance to 80% of that of NGINX (OpenSSL). go-boring (which calls BoringSSL by using CGO) shows no advantage, because it is restricted by the performance of CGO. Therefore, we chose the Go-native TLS at last. We believe that the Go Runtime team will continue the optimization. We have some optimization plans, too.\nThe following figure shows the comparison between the test results of Go and NGINX.\n Go is not optimized much for RSA encryption, and go-boring (CGO) performs twice as good as Go in this regard. Go has been assembly-optimized for ECDSA P256, and it performs better than go-boring in this respect. Go performs 20 times as good as go-boring in terms of AES-GCM symmetric encryption. Go has also been assembly-optimized for hashing algorithms such as SHA and MD.  To ensure security compliance in financial scenarios, we also support development based on Chinese encryption algorithms, which is not supported by Go Runtime. Currently, the performance of Chinese encryption algorithms is only 50% of that of the international standard AES-GCM encryption algorithms. We have some plans to improve their performance. Please stay tuned.\nPerformance test results for Chinese encryption algorithms are shown in the following figure.\n","excerpt":"Modular Open Smart Network (MOSN) mainly comprises the following modules. It provides basic network …","ref":"https://mosn.io/en/docs/concept/core-concept/","title":"Core concepts of MOSN"},{"body":"bin/init.sh\n-WASM_RELEASE_DIR=${ISTIO_ENVOY_LINUX_RELEASE_DIR} -for plugin in stats metadata_exchange -do - FILTER_WASM_URL=\u0026#34;${ISTIO_ENVOY_BASE_URL}/${plugin}-${ISTIO_ENVOY_VERSION}.wasm\u0026#34; - download_wasm_if_necessary \u0026#34;${FILTER_WASM_URL}\u0026#34; \u0026#34;${WASM_RELEASE_DIR}\u0026#34;/\u0026#34;${plugin//_/-}\u0026#34;-filter.wasm - FILTER_WASM_URL=\u0026#34;${ISTIO_ENVOY_BASE_URL}/${plugin}-${ISTIO_ENVOY_VERSION}.compiled.wasm\u0026#34; - download_wasm_if_necessary \u0026#34;${FILTER_WASM_URL}\u0026#34; \u0026#34;${WASM_RELEASE_DIR}\u0026#34;/\u0026#34;${plugin//_/-}\u0026#34;-filter.compiled.wasm -done +#WASM_RELEASE_DIR=${ISTIO_ENVOY_LINUX_RELEASE_DIR} +#for plugin in stats metadata_exchange +#do +# FILTER_WASM_URL=\u0026#34;${ISTIO_ENVOY_BASE_URL}/${plugin}-${ISTIO_ENVOY_VERSION}.wasm\u0026#34; +# download_wasm_if_necessary \u0026#34;${FILTER_WASM_URL}\u0026#34; \u0026#34;${WASM_RELEASE_DIR}\u0026#34;/\u0026#34;${plugin//_/-}\u0026#34;-filter.wasm +# FILTER_WASM_URL=\u0026#34;${ISTIO_ENVOY_BASE_URL}/${plugin}-${ISTIO_ENVOY_VERSION}.compiled.wasm\u0026#34; +# download_wasm_if_necessary \u0026#34;${FILTER_WASM_URL}\u0026#34; \u0026#34;${WASM_RELEASE_DIR}\u0026#34;/\u0026#34;${plugin//_/-}\u0026#34;-filter.compiled.wasm +#done bin/update_proxy.sh\n-WASM_URL=${ISTIO_ENVOY_BASE_URL}/${plugin}-${ISTIO_ENVOY_VERSION}.wasm -printf \u0026#34;Verifying %s is available\\n\u0026#34; \u0026#34;$WASM_URL\u0026#34; -until curl --output /dev/null --silent --head --fail \u0026#34;$WASM_URL\u0026#34;; do - printf \u0026#39;.\u0026#39; - sleep $SLEEP_TIME -done +#WASM_URL=${ISTIO_ENVOY_BASE_URL}/${plugin}-${ISTIO_ENVOY_VERSION}.wasm +#printf \u0026#34;Verifying %s is available\\n\u0026#34; \u0026#34;$WASM_URL\u0026#34; +#until curl --output /dev/null --silent --head --fail \u0026#34;$WASM_URL\u0026#34;; do +# printf \u0026#39;.\u0026#39; +# sleep $SLEEP_TIME +#done pilot/docker/Dockerfile.proxyv2\n-COPY stats-filter.wasm /etc/istio/extensions/stats-filter.wasm -COPY stats-filter.compiled.wasm /etc/istio/extensions/stats-filter.compiled.wasm -COPY metadata-exchange-filter.wasm /etc/istio/extensions/metadata-exchange-filter.wasm -COPY metadata-exchange-filter.compiled.wasm /etc/istio/extensions/metadata-exchange-filter.compiled.wasm +#COPY stats-filter.wasm /etc/istio/extensions/stats-filter.wasm +#COPY stats-filter.compiled.wasm /etc/istio/extensions/stats-filter.compiled.wasm +#COPY metadata-exchange-filter.wasm /etc/istio/extensions/metadata-exchange-filter.wasm +#COPY metadata-exchange-filter.compiled.wasm /etc/istio/extensions/metadata-exchange-filter.compiled.wasm tools/istio-docker.mk\n# rule for wasm extensions. -$(ISTIO_ENVOY_LINUX_RELEASE_DIR)/stats-filter.wasm: init -$(ISTIO_ENVOY_LINUX_RELEASE_DIR)/stats-filter.compiled.wasm: init -$(ISTIO_ENVOY_LINUX_RELEASE_DIR)/metadata-exchange-filter.wasm: init -$(ISTIO_ENVOY_LINUX_RELEASE_DIR)/metadata-exchange-filter.compiled.wasm: init +#$(ISTIO_ENVOY_LINUX_RELEASE_DIR)/stats-filter.wasm: init +#$(ISTIO_ENVOY_LINUX_RELEASE_DIR)/stats-filter.compiled.wasm: init +#$(ISTIO_ENVOY_LINUX_RELEASE_DIR)/metadata-exchange-filter.wasm: init +#$(ISTIO_ENVOY_LINUX_RELEASE_DIR)/metadata-exchange-filter.compiled.wasm: init  -docker.proxyv2: $(ISTIO_ENVOY_LINUX_RELEASE_DIR)/stats-filter.wasm -docker.proxyv2: $(ISTIO_ENVOY_LINUX_RELEASE_DIR)/stats-filter.compiled.wasm -docker.proxyv2: $(ISTIO_ENVOY_LINUX_RELEASE_DIR)/metadata-exchange-filter.wasm -docker.proxyv2: $(ISTIO_ENVOY_LINUX_RELEASE_DIR)/metadata-exchange-filter.compiled.wasm +#docker.proxyv2: $(ISTIO_ENVOY_LINUX_RELEASE_DIR)/stats-filter.wasm +#docker.proxyv2: $(ISTIO_ENVOY_LINUX_RELEASE_DIR)/stats-filter.compiled.wasm +#docker.proxyv2: $(ISTIO_ENVOY_LINUX_RELEASE_DIR)/metadata-exchange-filter.wasm +#docker.proxyv2: $(ISTIO_ENVOY_LINUX_RELEASE_DIR)/metadata-exchange-filter.compiled.wasm pkg/config/constants/constants.go\n- BinaryPathFilename = \u0026#34;/usr/local/bin/envoy\u0026#34; + BinaryPathFilename = \u0026#34;/usr/local/bin/mosn\u0026#34; ","excerpt":"bin/init.sh\n-WASM_RELEASE_DIR=${ISTIO_ENVOY_LINUX_RELEASE_DIR} -for plugin in stats …","ref":"https://mosn.io/en/docs/quick-start/istio/istio-diff/","title":""},{"body":" MOSN v1.0.0 succeeded in the Bookinfo test for Istio 1.10.6. For more information about the support from the latest version of Istio, see MOSN Istio WG.\n This topic covers the following content:\n Relationship between MOSN and Istio Instructions on how to build the Istio proxyv2 image with MOSN Istio deployment with MOSN Bookinfo test  Relationship between MOSN and Istio As described in the MOSN overview, MOSN is a service mesh data plane proxy developed in Golang.\nThe following figure shows the operating principle of MOSN in Istio.\n Instructions on how to build the Istio proxyv2 image with MOSN The operating system described in this topic is MacOS, and the Istio version is 1.10.6. If you are using anither OS, there may be some differences. If only the MOSN code changes, you can also use the MOSN-only update method to build the proxyv2 image. Usually, you do not need to build a proxyv2 image, use the image provided by us is ok. mosnio/proxyv2:${MOSN VERSION}-${ISTIO VERSION}, for example, docker pull mosnio/proxyv2:v1.0.0-1.10.6.\nBuild proxyv2 image with source code. (On MacOS and Istio 1.10.6)  Download the istio source code, and checkout to the target version.  git clone git@github.com:istio/istio.git cd istio git checkout 1.10.6  Istio will load wasm by default. To simplify, we need to comment out this part of the code. see details in istio-diff\n  Build a MOSN binary. You can use the make command provided by MOSN project to build a binary on linux. As the same time, since we are using MacOS, we also need to compile a MacOS binary.\n  Tar the binary compiled by the step 2, the file path should be usr/local/bin.\n  cd ${MOSNProject Path} mkdir -p usr/local/bin make build # build mosn binary on linux cp build/bundles/${MOSNVERSION}/binary/mosn usr/local/bin tar -zcvf mosn.tar.gz usr/local/bin/mosn cp mosn.tar.gz mosn-centos.tar.gz # copy a renamed tar.gz file make build-local # build mosn binary on macos cp build/bundles/${MOSNVERSION}/binary/mosn usr/local/bin tar -zcvf mosn-macos.tar.gz usr/local/bin/mosn Upload the mosn-macos.tar.gz mosn-centos.tar.gz mosn.tar.gz to a store serivce that can be accessed, if you do not have one, you can use Go to build a simple service in your local system.  func main() { address := \u0026#34;\u0026#34; // an address can be reached when proxyv2 image build. for example, 0.0.0.0:8080  filespath := \u0026#34;\u0026#34; // where the .tar.gz files stored.  http.ListenAndServe(address, http.FileServer(http.Dir(filespath))) } Build proxyv2 images, with some ENV  address=$1 # your download service address export ISTIO_ENVOY_VERSION=$2 # MOSN Version, can be any value. export ISTIO_ENVOY_RELEASE_URL=http://$address/mosn.tar.gz export ISTIO_ENVOY_CENTOS_RELEASE_URL=http://$address/mosn-centos.tar.gz export ISTIO_ENVOY_MACOS_RELEASE_URL=http://$address/mosn-macos.tar.gz export ISTIO_ENVOY_MACOS_RELEASE_NAME=mosn-$2 # can be any value export SIDECAR=mosn make clean # clean the cache make docker.proxyv2 \\  SIDECAR=$SIDECAR \\  ISTIO_ENVOY_VERSION=$ISTIO_ENVOY_VERSION \\  ISTIO_ENVOY_RELEASE_URL=$ISTIO_ENVOY_RELEASE_URL \\  ISTIO_ENVOY_CENTOS_RELEASE_URL=$ISTIO_ENVOY_CENTOS_RELEASE_URL \\  ISTIO_ENVOY_MACOS_RELEASE_URL=$ISTIO_ENVOY_MACOS_RELEASE_URL \\  ISTIO_ENVOY_MACOS_RELEASE_NAME=$ISTIO_ENVOY_MACOS_RELEASE_NAME Retag the new image, and push it to your docker hub.  Update MOSN binary in the proxyv2 image.  Build the MOSN binary  cd ${MOSNProject Path} make build # build mosn binary on linux Write a DOCKERFILE, and build a new image  FROMmosnio/proxyv2:v1.0.0-1.10.6COPY build/bundles/${MOSNVERSION}/binary/mosn /usr/local/bin/mosndocker build --no-cache --rm -t ${yourimage tag} Push the new image to your docker hub.  Istio deployment with MOSN Install kubectl kubectl is the Kubernetes command-line tool, allows you to run commands against Kubernetes clusters. How to install it, see details in kubectl install.\nInstall Kubernetes Platform How to prepare various Kubernetes platforms before installing Istio, see details in Platform Setup. We use minikube later.\nInstall Istio, use MOSN as sidecar  Download istio release version, you can find it in Istio release, or use bash command  VERSION=1.10.6 # istio version export ISTIO_VERSION=$VERSION \u0026amp;\u0026amp; curl -L https://istio.io/downloadIstio | sh - Checkout to the path, add the istioctl to PATH environment variable.  cd istio-$ISTIO_VERSION/ export PATH=$PATH:$(pwd)/bin create istio namespace, set MOSN proxyv2 image as sidecar image  kubectl create namespace istio-system istioctl manifest apply --set .values.global.proxy.image=${MOSNIMAGE} --set meshConfig.defaultConfig.binaryPath=\u0026#34;/usr/local/bin/mosn\u0026#34; Verify the installation  kubectl get pod -n istio-system NAME READY STATUS RESTARTS AGE istio-ingressgateway-6b7fb88874-rgmrj 1/1 Running 0 102s istiod-65c9767c55-vjppv 1/1 Running 0 109s If all pods in the istio-system namespace are running, the deployment succeeds.\nBookinfo test MOSN v1.0.0 succeeded in the Bookinfo test for Istio 1.10.6. You can alsoe use MOSN with Istio to run the Bookinfo test. More test cases see Istio [Example]((https://istio.io/latest/docs/examples). If you have any questions, please contact us issue, code contributions are welcome too.\nBookinfo introduction The application displays information about a book, similar to a single catalog entry of an online book store. Displayed on the page is a description of the book, book details (ISBN, number of pages, and so on), and a few book reviews. The Bookinfo application is broken into four separate microservices:\n productpage. The productpage microservice calls the details and reviews microservices to populate the page. details. The details microservice contains book information. reviews. The reviews microservice contains book reviews. It also calls the ratings microservice. ratings. The ratings microservice contains book ranking information that accompanies a book review.   Deploy Bookinfo and inject MOSN  For details, go to https://istio.io/docs/examples/bookinfo/.\n Use kube-inject way to inject MOSN\nistioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo.yaml \u0026gt; bookinfo.yaml # sed -i \u0026#39;\u0026#39; is the MacOS command, if you are in linux, use sed -i instead. sed -i \u0026#39;\u0026#39; \u0026#34;s/\\/usr\\/local\\/bin\\/envoy/\\/usr\\/local\\/bin\\/mosn/g\u0026#34; ./bookinfo.yaml Deploy Bookinfo app:\n$ kubectl apply -f bookinfo.yaml Verify whether the deployment succeeds\n$ kubectl get services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE details ClusterIP 192.168.248.118 \u0026lt;none\u0026gt; 9080/TCP 5m7s kubernetes ClusterIP 192.168.0.1 \u0026lt;none\u0026gt; 443/TCP 25h productpage ClusterIP 192.168.204.255 \u0026lt;none\u0026gt; 9080/TCP 5m6s ratings ClusterIP 192.168.227.164 \u0026lt;none\u0026gt; 9080/TCP 5m7s reviews ClusterIP 192.168.181.16 \u0026lt;none\u0026gt; 9080/TCP 5m6s Wait until all pods are running\n$ kubectl get pods NAME READY STATUS RESTARTS AGE details-v1-77497b4899-67gfn 2/2 Running 0 98s productpage-v1-68d9cf459d-mv7rh 2/2 Running 0 97s ratings-v1-65f97fc6c5-npcrz 2/2 Running 0 98s reviews-v1-6bf4444fcc-9cfrw 2/2 Running 0 97s reviews-v2-54d95c5444-5jtxp 2/2 Running 0 97s reviews-v3-dffc77d75-jd8cr 2/2 Running 0 97s Check Bookinfo is working properly\nkubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath=\u0026#39;{.items[0].metadata.name}\u0026#39;) -c ratings -- curl productpage:9080/productpage | grep -o \u0026#34;\u0026lt;title\u0026gt;.*\u0026lt;/title\u0026gt;\u0026#34; Access Bookinfo services Enable the gateway mode.\n$ kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml $ kubectl get gateway NAME AGE bookinfo-gateway 6s Set GATEWAY_URL. For details, go to doc\n$ export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath=\u0026#39;{.spec.ports[?(@.name==\u0026#34;http2\u0026#34;)].nodePort}\u0026#39;) $ export INGRESS_HOST=$(minikube ip) $ export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT Check whether the gateway takes effect.\n$ curl -o /dev/null -s -w \u0026#34;%{http_code}\\n\u0026#34; http://$GATEWAY_URL/productpage 200 View the page\nGo to http://$GATEWAY_URL/productpage (replace $GATEWAY_URL with your address). The Bookinfo page is shown as follows after you refresh it. Three versions of Book Reviews are available. The three versions will be displayed in turn when you refresh the page. For more information, go to samples/bookinfo/platform/kube/bookinfo.yaml.\nPage v1\nPage v2\nPage v3\nVerify routing by version in MOSN Create a series of destination rules for Bookinfo services.\n$ kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml Specify access to only v1 of the Book Reviews service.\n$ kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml Go to http://$GATEWAY_URL/productpage. You will find that book reviews are now fixed to be displayed on page v1.\nVerify routing by weight in MOSN Allocate 50% of the traffic to v1 and v3 each.\n$ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml Go to http://$GATEWAY_URL/productpage. You will find that page v1 and page v3 are displayed with a possibility of 50% each.\nVerify routing by specific header in MOSN The Bookinfo page provides a login entry in the upper-right corner. After you log in, your request will carry the end-user custom field, the value of which is the user name. MOSN supports routing by the value of this header. For example, route user Jason to v2 and others to v1. (The username and password are both jason. For the reason of using this user account, check the corresponding YAML file).\n$ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml When you go to http://$GATEWAY_URL/productpage:\nPage v2 will be displayed if you log in as Jason.\nPage v1 will be displayed if you log in as other users.\nUninstall Bookinfo $ sh samples/bookinfo/platform/kube/cleanup.sh Make sure Bookinfo is uninstalled\n$ kubectl get virtualservices #-- there should be no virtual services $ kubectl get destinationrules #-- there should be no destination rules $ kubectl get gateway #-- there should be no gateway $ kubectl get pods #-- the Bookinfo pods should be deleted Uninstall Istio $ istioctl manifest generate | kubectl delete -f - Make sure Istio is uninstalled\n$ kubectl get namespace istio-system ","excerpt":"MOSN v1.0.0 succeeded in the Bookinfo test for Istio 1.10.6. For more information about the support …","ref":"https://mosn.io/en/docs/quick-start/istio/","title":"Use MOSN as an Istio data plane"},{"body":"FeatureGate overview When using MOSN, you may want to enable some features at startup and disable those that you do not need. To meet this requirement, MOSN provides a feature switch: FeatureGate.\nFeatureGate specifies a pair of states (enabled/disabled) for features in MOSN. Each feature has its own default state. Different MOSN versions support different features and default states. FeatureGate describes features and their states in a string in the form of ${feature}=${bool}. Multiple features and states are separated by a comma.\n// General template ./mosn start -c ${configpath} -f ${featuregates description} // Example ./mosn start -c mosn_config.json -f \u0026#34;auto_config=true,XdsMtlsEnable=true\u0026#34; FeatureGate supports not only feature switching, but also extensible development. During MOSN-based secondary development, you can use the following FeatureGate capabilities:\n Feature switching. You can use FeatureGate to enable/disable a specific feature. Feature dependency management. This includes startup sequence and enabled/disabled state dependencies between features.  For example, we have two features A and B implemented in MOSN. Initialization of Feature B depends on the initialization result of Feature A. That is to say Feature B depends on Feature A. When Feature A is disabled, Feature B is disabled or downgraded accordingly. FeatureGate provides a simple mechanism to help you focus on feature development, without being distracted by the management of startup items and dependencies.    FeatureGate is mainly intended for secondary development of different features in MOSN.\nFeatureGate-based development Implementation of Featuregate FeatureGate provides the following APIs:\n// Returns the current status of a feature, where \u0026#34;true\u0026#34; indicates \u0026#34;enabled\u0026#34;, and \u0026#34;false\u0026#34; indicates \u0026#34;disabled\u0026#34;. func Enabled(key Feature) bool // Subscribes to a feature and returns its status after subscription finishes. // Returns whether the subscribed feature is enabled after it is initialized. // Returns \u0026#34;false\u0026#34; if the subscribed feature is disabled; returns a subscription timeout error if // the initialization is still not finished after the subscription times out. If the timeout value is less than or equal to 0, no subscription timeout error is returned. func Subscribe(key Feature, timeout time.Duration) (bool, error) // Sets the state of FeatureGate. \u0026#34;value\u0026#34; is a complete FeatureGate description. func Set(value string) error // Sets the state of FeatureGate. \u0026#34;key\u0026#34; of \u0026#34;map\u0026#34; is the key of the feature, and \u0026#34;value\u0026#34; is the expected state of the feature. func SetFromMap(m map[string]bool) error // Registers a new feature with FeatureGate. func AddFeatureSpec(key Feature, spec FeatureSpec) error // Sets the state of a feature. func SetFeatureState(key Feature, enable bool) error // Enables feature initialization. func StartInit() // Waits for the initialization of all features to finish. func WaitInitFinsh() error StartInit and WaitInitFinsh are called by MOSN and can be ignored during secondary development based on MOSN. Generally, Set and SetFromMap can also be ignored. All the above APIs are exposed by the default non-exportable global FeatureGate object. You can use the default FeatureGate object without creating a new one, unless otherwise required in special cases (for example, when writing unit tests).\nThe following example shows how FeatureGate is implemented.\ntype knownFeatureSpec struct { FeatureSpec once sync.Once channel chan struct{} } type Feature string type FeatureGate struct { // lock guards writes to known, enabled, and reads/writes of closed  lock sync.Mutex known map[Feature]*knownFeatureSpec // inited is set to true when StartInit is called.  inited bool wg sync.WaitGroup once sync.Once } FeatureGate consists of the following member variables:\n map: records all supported features; inited: a status indicator that indicates whether FeatureGate has been initialized; once: used to ensure that FeatureGate is initialized only once; WaitGroup: used to synchronize the feature initialization result; Mutex: used for concurrency control.  According to the design of FeatureGate, you can add new features by calling the Add method, and modify their states by calling the Set method. However, initialization of all features is uniformly implemented by executing the Init function. After Init is executed, no feature can be added, and no feature state can be modified. That is why we need the inited status indicator to record the initialization action. knownFeatureSpec is a non-exportable structure that specifies FeatureSpec of different features. Both once and channel are used for subscription and initialization in FeatureGate, and are not detailed here. The following describes the definition of FeatureSpec, which is the core data structure for FeatureGate-based development.\ntype prerelease string const ( // Values for PreRelease.  Alpha = prerelease(\u0026#34;ALPHA\u0026#34;) Beta = prerelease(\u0026#34;BETA\u0026#34;) GA = prerelease(\u0026#34;\u0026#34;) ) type FeatureSpec interface { // Default is the default enablement state for the feature  Default() bool // LockToDefault indicates that the feature is locked to its default and cannot be changed  LockToDefault() bool // SetState sets the enablement state for the feature  SetState(enable bool) // State indicates the feature enablement  State() bool // InitFunc used to init process when StartInit is invoked  InitFunc() // PreRelease indicates the maturity level of the feature  PreRelease() prerelease }  prerelease refers to a non-exportable type. There are only three conventional exportable variables whose type is prerelease. It is equivalent to the Enum type in conventional languages and is used to describe feature information. The role of prerelease is currently not clear. FeatureSpec can be implemented with your own code. Generally, you can use BaseFeatureSpec provided by the framework or implement a new one based on BaseFeatureSpec. As described in the following comments, you generally only need to encapsulate an additional InitFunc function to implement this API.  // BaseFeatureSpec is a basic implementation of FeatureSpec. // Usually, a feature spec just need an init func. type BaseFeatureSpec struct { // Default state.  DefaultValue bool // Specifies whether the state can be modified, where \u0026#34;true\u0026#34; indicates that the feature can only remain in the default state.  // Generally, when it is set to \u0026#34;true\u0026#34; here, the default state is also \u0026#34;true\u0026#34;.  // This feature is mainly used as a \u0026#34;base dependency\u0026#34; for other features.  IsLockedDefault bool PreReleaseValue prerelease stateValue bool // stateValue shoule be setted by SetState  inited int32 // inited cannot be setted } Usage After understanding the basic implementation of FeatureGate, you can use it for basic extended programming. The following describes several usage scenarios of FeatureGate and methods for writing features.\n1. Basic global switch In feature switching, the most basic usage scenario of FeatureGate, FeatureGate works like a global variable. if conditional judgement is used to execute different logic here. This allows FeatureGate to integrate all feature switching control parameters into the startup parameters.\nvar featureName featuregate.Feature = \u0026#34;simple_feature\u0026#34; func init() { fs := \u0026amp;featuregate.BaseFeatureSpec{ DefaultValue: true } featuregate.AddFeatureSpec(featureName,fs) } func myfunc() { if featuregate.Enable(featureName) { dosth() } else { dosth2() } } 2. Initialization operation The InitFunc function enables related initialization procedures to be uniformly performed when MOSN starts. If a feature is disabled, it will not be executed by InitFunc.\nvar featureName featuregate.Feature = \u0026#34;init_feature\u0026#34; type MyFeature struct { *BaseFeatureSpec } func (f *MyFeature) InitFunc() { doInit() } // The rest are similar to the code example provided in 1. Basic global switch. 3. Feature dependency management This is the most important capability of FeatureGate. It easily solves the following problem.\n Assume that we have four independent features: A, B, C, and D. B and C depend on A, which means we must enable A before we can enable B and C. D depends on B, which means we must enable B before we can enable D. If A is not enabled, B cannot be enabled, but C can still work in downgrade mode. The four features can be implemented separately in FeatureGate as follows.  var FeatureA featuregate.Feature = \u0026#34;A\u0026#34; func init() { fs := \u0026amp;featuregate.BaseFeatureSpec{ DefaultValue: true } featuregate.AddFeatureSpec(FeatureA,fs) } var FeatureB featuregate.Feature = \u0026#34;B\u0026#34; type FB struct { *BaseFeatureSpec } func (f *FB) InitFunc() { enabled, err := featuregate.Subscribe(FeatureA, 5 * time.Second) if err != nil || !enabled { f.SetState(false) // If feature A is not enabled, feature B will not be enabled.  } } var FeatureC featuregate.Feature = \u0026#34;C\u0026#34; type FC struct { *BaseFeatureSpec mode int32 } func (f *FC) InitFunc() { enabled, err := featuregate.Subscribe(FeatureA, 5 * time.Second) if err != nil || !enabled { f.mode = -1 // Downgrade mode.  return } if enabled { f.mode = 1 // Normal mode.  } } func (f *FC) MyFunc() { if f.mode == 1 { dosth() } else if f.mode == -1 { dosth2() } } type FeatureD featuregate.Feature = \u0026#34;D\u0026#34; type FD struct { *BaseFeatureSpec } func (f *FD) InitFunc() { enabled, err := featuregate.Subscribe(FeatureB, 0) // No timeout. Waits until B is enabled.  if err != nil || !enabled { return } f.Start() } func (f *FD) Start() { } FAQ Why is FeatureGate used instead of configuration files?  Unlike configuration files that must be parsed first, FeatureGate is more efficient in implementing advanced features. Decision needs to be made on some features earlier than parsing of the configuration files, and may even affect the parsing logic.  ","excerpt":"FeatureGate overview When using MOSN, you may want to enable some features at startup and disable …","ref":"https://mosn.io/en/docs/dev/featuregate-introduce/","title":"FeatureGate overview"},{"body":"router: Specifies the router configurations of MOSN and is usually used with proxy.\n{ \u0026#34;router_config_name\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;virtual_hosts\u0026#34;: [ ] }  router_config_name: The unique router configuration ID, which corresponds to the field configured in proxy. virtual_hosts: Specifies the specific routing rules.  VirtualHost { \u0026#34;name\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;domains\u0026#34;:[], \u0026#34;routers\u0026#34;:[] }  name: String. The unique ID of a virtual host. domains: String array. Indicates a group of domains that match the virtual host. Wildcard characters are supported. The matching priorities of domains are as follows:  First, exact match, for example, www.foo.com. Second, wildcard match with the longest suffix. For example, *-bar.foo.com is a preferred match for the domain foo-bar.foo.com between *.foo.com and *-bar.foo.com. At last, wildcard match for any domains, that is, *.   routers: A group of specific router rules.  Router { \u0026#34;match\u0026#34;:{}, \u0026#34;route\u0026#34;:{}, \u0026#34;per_filter_config\u0026#34;:{} }  match: The route match parameter. route: The routing behavior. Specifies the upstream information of a request to be routed. per_filter_config: The filter configuration in the key: json format. The key needs to match a type of the stream filter, and the json corresponding to the key is the value configured for the stream filter.  When this field is configured, the configurations indicated by this field can be used to overwrite the original configurations of some stream filters (depending on specific filters), to generate stream filter configurations at the router match level.    match { \u0026#34;prefix\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;regex\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;headers\u0026#34;: [] }  Path match  prefix: Indicates that the router will match the path prefix. This configuration has a higher priority than path and regex. If this field is configured, the path prefix of the request needs to first comply with this configuration. path: Indicates that the router will match the exact path. This configuration has a higher priority than regex. If this field is configured, the path of the request needs to first comply with this configuration. regex: Indicates that the router will match the path based on a regular expression. If this field is configured, the path of the request needs to first comply with this configuration. When multiple path match configurations are available, only the one with a higher priority takes effect.   Header match  headers: The group of headers that the request needs to match. The match succeeds only when the request meets all header configuration conditions.    header { \u0026#34;name\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;value\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;regex\u0026#34;:\u0026#34;\u0026#34; }  name: The key of the header. value: The value of the header key. regex: Boolean. Specifies whether the value can be matched by a regular expression. Default values: True and False.  route { \u0026quot;cluster_name\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;metadata_match\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;timeout\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;retry_policy\u0026quot;:{} }  cluster_name: The upstream cluster to which the request is to be routed. metadata_match: The [metadata](.. /../custom#metadata) configuration. If this field is configured, the router will match against the subset of the upstream cluster based on the metadata. timeout: The [Duration String](.. /../custom#duration-string) configuration. Indicates the default forwarding timeout value of the request. If the timeout value is specified in the request, this configuration will be ignored. retry_policy: The retry configuration, which indicates the retry policy applied when the request encounters a specific error. If this field is left unconfigured, no retry will be performed by default.  retry_policy { \u0026#34;retry_on\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;retry_timeout\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;num_retries\u0026#34;:\u0026#34;\u0026#34; }  retry_on: Boolean. Specifies whether to enable retry. retry_timeout: The [Duration String](.. /../custom#duration-string) configuration. Indicates the timeout value for each retry. When retry_timeout exceeds the timeout value specified in the route field or request, this configuration is invalid. num_retries: Indicates the maximum number of retries supported.  ","excerpt":"router: Specifies the router configurations of MOSN and is usually used with proxy.\n{ …","ref":"https://mosn.io/en/docs/configuration/server/router/","title":"Router configurations"},{"body":"Prerequisites Before you start to write a MOSN document, create a MOSN document repository and be familiar with the MOSN document structure.\nPage types Documentation The documentation that systematically describe how to use MOSN are maintained by the MOSN team.\nBlogs The periodically published MOSN blogs are contributed by the community.\nNews The news about the MOSN community.\nReleases Release notes about new versions of MOSN.\nTopic structure All topics of the MOSN documentation are saved under the content directory: content/zh for Chinese topics, and content/en for English topics. To create a topic under an existing one, you need to first create a directory and comply with the following naming rules:\n Name all topics without sub-directories as index.md. Name all topics with sub-directories as _index.md.  Topic metadata Each topic has its metadata, which is separated by three hyphens (\u0026quot;-\u0026quot;) between two YAML blocks. The following metadata is required:\ntitle=\u0026#34;Title\u0026#34;linkTitle:\u0026#34;Title\u0026#34;date:2020-02-11weight:1description:\u0026gt; The brief description of the page. Details are described as follows:\n title: The title of the topic. linkTitle: The topic title displayed in the left-side content pane, which is usually consistent with title. date: The date when the topic was created, in the YYYY-MM-dd format. weight: Among topics of the same level, the one with the smallest weight is displayed at the top in the left-side content pane. description: The brief description of the document.  Author information is required for blogs, releases notes, and news articles:\nauthor:\u0026#34;Author information\u0026#34;Note: The value of author can be edited in the Markdown format.\nNaming conventions The URL of a document is determined based on the level of its directory. Document directories are named according to the following conventions:\n Use English names Connect words with hyphens Avoid punctuation marks Minimize the name  ","excerpt":"Prerequisites Before you start to write a MOSN document, create a MOSN document repository and be …","ref":"https://mosn.io/en/docs/contribute/creating-pages/","title":"Create a page"},{"body":"Format standard  Edit the document body in the Markdown format. Start with Heading 2 in the document body. Use local images, save them to the same directory as that of the index.md file, and use relative paths for references. Specify the languages for all code. Use ordered and unordered lists separately, to avoid format confusion. Enclose a separate URL with \u0026lt;URL\u0026gt;. Enclose uncommon terms and code phrases with grave accents (`).  ","excerpt":"Format standard  Edit the document body in the Markdown format. Start with Heading 2 in the document …","ref":"https://mosn.io/en/docs/contribute/style-guide/","title":"Format guide"},{"body":"connection_manager specifies the router configurations of MOSN and is usually used with proxy.\n{ \u0026quot;router_config_name\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;virtual_hosts\u0026quot;: [ ] }  router_config_name: The unique router configuration ID, which corresponds to the field configured in proxy. virtual_hosts: specifies the specific routing rules.  VirtualHost { \u0026#34;name\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;domains\u0026#34;:[], \u0026#34;routers\u0026#34;:[] }  name: String. The unique ID of a virtual host. domains: String array. Indicates a group of domains that match the virtual host. Wildcard characters are supported. The matching priorities of domains are as follows:  First, exact match, for example, www.foo.com. Second, wildcard match with the longest suffix. For example, *-bar.foo.com is a preferred match for the domain foo-bar.foo.com between *.foo.com and *-bar.foo.com. At last, wildcard match for any domains, that is, *.   routers: A group of specific router rules.  Router { \u0026#34;match\u0026#34;:{}, \u0026#34;route\u0026#34;:{}, \u0026#34;per_filter_config\u0026#34;:{} }  match: The router match parameter. route: The routing behavior. Specifies the upstream information of a request to be routed. per_filter_config: The filter configuration in the key: json format.  The key needs to match the type of a stream filter, and the json corresponding to the key is the the value configured for the stream filter. When this field is configured, the configurations indicated by this field can be used to overwrite the original configurations of some stream filters (depending on specific filters), to generate stream filter configurations at the router match level.    match { \u0026#34;prefix\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;regex\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;headers\u0026#34;: [] }  Path match  prefix: Indicates that the router will match the path prefix. This configuration has a higher priority than path and regex. If this field is configured, the path prefix of the request needs to first comply with this configuration. path: Indicates that the router will perform exact match the path. This configuration has a higher priority than regex. If this field is configured, the path of the request needs to first comply with this configuration. regex: Indicates that the router will match the path based on a regular expression. If this field is configured, the path of the request needs to first comply with this configuration. When multiple path match configurations are available, only the one with a higher priority takes effect.   Header match  headers: The group of headers that the request needs to match. The match succeeds only when the request meets all header configuration conditions.    header { \u0026#34;name\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;value\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;regex\u0026#34;:\u0026#34;\u0026#34; }  name: The key of the header. value: The value of the header key. regex: Boolean. Specifies whether the value can be matched by a regular expression. Default values: True and False.  route { \u0026quot;cluster_name\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;metadata_match\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;timeout\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;retry_policy\u0026quot;:{} }  cluster_name: The upstream cluster to which the request is to be routed. metadata_match: The metadata configuration. If this field is configured, the router will match the subset of the upstream cluster based on the metadata. timeout: Thee Duration String configuration. Indicates the default forwarding timeout value of the request. If the timeout value is specified in the request, this configuration will be ignored. retry_policy: The retry configuration, which indicates the retry policy applied when the request encounters a specific error. If this field is left unconfigured, no retry will be performed by default.  retry_policy { \u0026#34;retry_on\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;retry_timeout\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;num_retries\u0026#34;:\u0026#34;\u0026#34; }  retry_on: Boolean. Specifies whether to enable retry. retry_timeout: The Duration String configuration. Indicates the timeout value for each retry. When retry_timeout exceeds the timeout value specified in the route field or request, this configuration is invalid. num_retries: Indicates the maximum number of retries supported.  ","excerpt":"connection_manager specifies the router configurations of MOSN and is usually used with proxy.\n{ …","ref":"https://mosn.io/en/docs/configuration/listener/network-filter/connection-manager/","title":"connection_manager"},{"body":"","excerpt":"","ref":"https://mosn.io/en/docs/quick-start/","title":"Get started"},{"body":"This topic describes the listener configurations of MOSN.\n You can specify the ports on which MOSN listens upon startup and the specific logic corresponding to the ports in listener configurations. You can supplement or modify listener configurations through dynamic listener APIs.  { \u0026#34;name\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;address\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;bind_port\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;use_original_dst\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;access_logs\u0026#34;:[], \u0026#34;filter_chains\u0026#34;:[], \u0026#34;stream_filters\u0026#34;:[], \u0026#34;inspector\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;connection_idle_timeout\u0026#34;:\u0026#34;\u0026#34; } name The name of a listener that is used to uniquely distinguish it from other listeners. If this parameter is left empty, a UUID will be generated by the system as a name by default. When you dynamically upgrade a listener by using its name as the index, a new listener is added if the name does not exist. If the name exists, the listener is updated.\ntype The type of the listener. Valid values ingress and egress. Different types of listeners generate different trace logs.\naddress The string in the IP:Port format. This is the unique address to which the listener listens.\nbind_port Boolean. Specifies whether the listener will occupy the address specified for the address parameter. Set this parameter to True in most cases.\nuse_original_dst Boolean. Used for transparent proxying.\naccess_logs Settings for a group of access logs.\nfilter_chains Settings for a group of filter chains. However, MOSN only supports one filter_chain currently.\nstream_filters Settings for a group of stream_filters. Currently, this parameter is valid only when the filter configured in filter_chain contains proxy.\ninspector Boolean. Specifies whether to allow the listener to handle non-TLS requests even when TLS listener is enabled in filter_chain. Valid values: True and False.\nconnection_idle_timeout The duration string, which specifies the timeout value of an idle string. MOSN closes a connection of a listener when its idle duration exceeds the configured idle connection timeout value.\n","excerpt":"This topic describes the listener configurations of MOSN.\n You can specify the ports on which MOSN …","ref":"https://mosn.io/en/docs/configuration/listener/","title":"Listener configurations"},{"body":"","excerpt":"","ref":"https://mosn.io/en/docs/configuration/listener/network-filter/","title":"Network Filter"},{"body":"This topic describes server configurations of MOSN.\nIn the configuration structure of MOSN, servers indicates a server array, but only one server is supported currently.\nserver describes the following basic global parameters of MOSN.\n{ \u0026quot;default_log_path\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;default_log_level\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;global_log_roller\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;graceful_timeout\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;processor\u0026quot;:\u0026quot;\u0026quot;, \u0026quot;listeners\u0026quot;:[] } default_log_path The default error log path, which supports a complete log path, stdout, and stderr.\n If this field is left empty, logs are output to stderr by default.  default_log_level The default error log level. Valid values: DEBUG, INFO, WARN, ERROR, and FATAL.\n Default value: INFO.  global_log_roller  The log roller configuration, which is valid for all logs, for example, tracelog, accesslog, and defaultlog. The string type, which supports two modes: rolling by time and rolling by log size. Only one mode is valid at a time. Rolling by log size  size: The log size threshold (in MB) to start rolling. age: The number of days during which the logs will be saved. keep: The maximum number of logs to be saved. compress: Specifies whether to compress logs. Valid values: on and off.    \u0026quot;global_log_roller\u0026quot;: \u0026quot;size=100 age=10 keep=10 compress=off\u0026quot;  Rolling by time  time: The time interval (hours) for rolling.    \u0026quot;global_log_roller\u0026quot;:\u0026quot;time=1\u0026quot; graceful_timeout  The Duration String configuration. Indicates the maximum waiting time for disabling a connection in a hot upgrade of MOSN. Default value: 30s.  processor The number of GOMAXPROCS used by MOSN.\n Default value: the number of CPUs. If it is not set or is set to 0, the default value is used.  Listeners Settings for a group of Listeners.\n","excerpt":"This topic describes server configurations of MOSN.\nIn the configuration structure of MOSN, servers …","ref":"https://mosn.io/en/docs/configuration/server/","title":"Server configurations"},{"body":"The sidecar pattern is commonly used in service mesh. It is a container design pattern that came into being earlier than service mesh did. This topic will help you have a general idea about the sidecar pattern.\nWhat is the sidecar pattern? In the sidecar pattern, features of applications are separated as processes. As shown in the following figure, the sidecar pattern allows you to add more features alongside every application container, without configuring third-party components or modifying the application code.\nSimilar to a sidecar mounted to a three-wheeled motorcycle, in a software architecture, a sidecar is connected to a primary application and adds extension or advanced features to it. Sidecar applications and primary applications are loosely coupled. This pattern can cover the difference between programming languages, and unify microservice features such as observability, monitoring, logging, configuration, and circuit breaker.\nBenefits Benefits of using the sidecar pattern are as follows:\n  Moves features unrelated to the application business logic into the common infrastructure. This reduces code complexity of microservices.\n  Avoids repeatedly writing configuration files and code for third-party components. This reduces duplicated code in the microservice architecture.\n  Loosens the coupling between the application code and the underlying platform.\n  How does the sidecar pattern work? Sidecar is a container widely used in service mesh. For details, see Service Mesh Architectures. That blog describes the node agent and sidecar service mesh architectures in detail.\nYou can deploy a sidecar service mesh without having to run a new agent on every node, but you will be running multiple copies of an identical sidecar. In sidecar deployments, you have one adjacent container deployed for every application container. This container is a sidecar. The sidecar handles all the network traffic in and out of the application container. In a Kubernetes pod, a sidecar container is deployed alongside the original application container. These two containers share resources such as storage and network. If we take the pod that runs the sidecar container and the application container as a host, these two containers share all host resources.\n","excerpt":"The sidecar pattern is commonly used in service mesh. It is a container design pattern that came …","ref":"https://mosn.io/en/docs/concept/sidecar-pattern/","title":"Sidecar pattern"},{"body":"This topic describes trace configurations of MOSN.\ntrace describes the following basic global parameters of MOSN.\n{ \u0026quot;tracing\u0026quot;: { \u0026quot;enable\u0026quot;: true, \u0026quot;driver\u0026quot;: \u0026quot;\u0026quot;, \u0026quot;config\u0026quot;: { } } } enable Boolean. Enable or disable trace.\ndriver Currently, supports SOFATracer and SkyWalking.\n","excerpt":"This topic describes trace configurations of MOSN.\ntrace describes the following basic global …","ref":"https://mosn.io/en/docs/configuration/trace/","title":"Trace configurations"},{"body":"This topic describes custom configurations of MOSN.\nDuration String  A string that consists of a decimal digit and a time unit suffix. Valid time units: ns, us (or µs), ms, s, m, and h. For example, 1 h, 3s, and 500 ms.  metadata metadata is used for matching MOSN routes and cluster hosts.\n{ \u0026#34;filter_metadata\u0026#34;:{ \u0026#34;mosn.lb\u0026#34;:{} } } mosn.lb corresponds to any string-string content.\ntls_context { \u0026#34;status\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;server_name\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;ca_cert\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;cert_chain\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;private_key\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;verify_client\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;require_client_cert\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;insecure_skip\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;cipher_suites\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;ecdh_curves\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;min_version\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;max_version\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;alpn\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;fall_back\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;extend_verify\u0026#34;:\u0026#34;\u0026#34;, \u0026#34;sds_source\u0026#34;:{} }  status: Boolean. Indicates whether TLS is enabled. Default value: false. type: String. Specifies the type of tls_context. tls_context supports extension implementation. Different types correspond to different implementation methods. Default value:\u0026quot;\u0026quot; (empty string). server_name: Used to verify the hostname of the certificate returned by the server when insecure_skip is not configured. Valid when configured at a cluster. ca_cert: The root certificate issued by a trusted certificate authority (CA). cert_chain: The TLS certificate chain. private_key: The private key of a certificate. verify_client: Boolean. Specifies whether to verify a client certificate. Valid when configured at a listener. require_client_cert: Boolean. Specifies whether the client certificate is required. insecure_skip: Boolean. Specifies whether to skip server certificate verification. Valid when configured at a cluster. cipher_suites: Specifies the cipher suites to be supported by TLS connections. If this parameter is specified, TLS connections support only the specified cipher suites and use them according to the order of how they are specified. Separate different cipher suites with a comma. Valid values:  ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-AES256-CBC-SHA ECDHE-RSA-AES128-CBC-SHA ECDHE-ECDSA-AES256-CBC-SHA ECDHE-ECDSA-AES128-CBC-SHA RSA-AES256-CBC-SHA RSA-AES128-CBC-SHA ECDHE-RSA-3DES-EDE-CBC-SHA RSA-3DES-EDE-CBC-SHA ECDHE-RSA-SM4-SM3 ECDHE-ECDSA-SM4-SM3   ecdh_curves: If this parameter is used, TLS connections support only the specified curves.\n   Valid values: x25519, p256, p384, and p521.    min_version: The earliest TLS version supported.\n   Valid values: TLS1.0, TLS1.1, and TLS1.2. Default value: TLS1.0. Available TLS versions will be automatically identified by default.    max_version: The latest TLS version supported.\n   Valid values: TLS1.0, TLS1.1, and TLS1.2. Default value: TLS1.2. Available TLS versions will be automatically identified by default.    alpn: Specifies the protocol supported by ALPN on TLS connections.\n   Valid values: H2, HTTP/1.1, and SOFA.    fall_back: Boolean. Specifies whether to fall back when certificate verification fails, without returning an error. This is equivalent to the case when TLS is not enabled. Valid values: True and False.\n  extend_verify: JSON. Specifies the extension of tls_context when type is not empty.\n  sds_source: Specifies parameters required for accessing the SDS API. If sds_source is configured, the ca_cert, cert_chain, and private_key parameters will be ignored, but other configurations will remain valid.\n  sds_source { \u0026#34;CertificateConfig\u0026#34;:{}, \u0026#34;ValidationConfig\u0026#34;:{} }  CertificateConfig: Specifies how to obtain the values of cert_chain and private_key. ValidationConfig: Specifies how to obtain the value of ca_cert. For details about the configurations, see envoy: sds_secret_config.  ","excerpt":"This topic describes custom configurations of MOSN.\nDuration String  A string that consists of a …","ref":"https://mosn.io/en/docs/configuration/custom/","title":"Custom configurations"},{"body":"This topic describes the traffic hijacking solution when MOSN is used as a sidecar.\nWhen MOSN is deployed as a sidecar in the same pod as that of the business application container, both inbound and outbound service requests of the business application must be handled by the sidecar. UUnlike the Istio community that uses iptables for transparent traffic hijacking, MOSN currently uses a traffic takeover solution and is actively exploring a transparent hijacking solution for large amounts of traffic.\nTraffic takeover MOSN uses the following traffic takeover solution, instead of the iptables-based traffic hijacking solution used by the Istio community:\n Assume that the server runs on a machine with an IP address of 1.2.3.4 and listens on port 20880. The server will first send a service registration request to its sidecar, to notify it of the service to be registered, as well as the IP address and port number (1.2.3.4:20880). The server\u0026rsquo;s sidecar will send a service registration request to the service registry (for example, SOFA Registry), to notify it of the service to be registered as well as the IP address and port number. Note that the port to be registered is not the port (20880) of the business application. Instead, it should be the port (for example, 20881) on which the sidecar listens. The caller sends a service subscription request to its own sidecar, to notify it of the service to be subscribed to. The caller\u0026rsquo;s sidecar then pushes the service endpoint to the caller. Note that the service endpoint here is the local IP address of the caller and the port (for example, 20882) on which the caller\u0026rsquo;s sidecar listens. The caller\u0026rsquo;s sidecar sends a service subscription request to the service registry (for example, SOFA Registry), to notify it of the service to be subscribed to. The service registry (for example, SOFA Registry) pushes the service endpoint (1.2.3.4:20881) to the caller\u0026rsquo;s sidecar.  Service call procedure After going through the above service discovery procedure, the traffic forwarding procedure is quite easy to understand:\n The caller receives the so called \u0026ldquo;service endpoint\u0026rdquo; 127.0.0.1:20882, and then sends a service call to this endpoint. After receiving the request from the caller, the caller\u0026rsquo;s sidecar parses the request header to identify the service to be called. Then the sidecar retrieves the endpoint previously returned by the service registry, and then sends a real call to this endpoint: 1.2.3.4:20881. After receiving the request from the caller\u0026rsquo;s sidecar, the server\u0026rsquo;s sidecar processes the request and then sends the request to the server:127.0.0.1:20880.  Transparent hijacking In the above service registration procedure, the server endpoint is replaced with the local sidecar endpoint to implement lightweight \u0026ldquo;traffic hijacking\u0026rdquo;. This mode works well in scenarios where a service registry is available and both the caller and the server use the same SDK. Traffic hijacking is not possible unless both conditions are met. To solve this problem, we introduced transparent hijacking.\niptables-based traffic hijacking iptables redirect traffic by using the REDIRECT action of the NAT table. A new connection will be triggered at the netfilter layer through the SYN packet. When subsequent packets arrive at the netfilter layer, netfilter looks for the corresponding connections, and modifies the destination addresses and ports. The original destination address is recorded when the new connection is being established, and the application can obtain the real destination addresses of the packets through SOL_IP and SO_ORIGINAL_DST.\nThe following figure shows the principle of iptables-based traffic hijacking.\nDrawbacks of iptables-based traffic hijacking Currently, iptables-based traffic hijacking used by Istio has the following drawbacks:\n Connections need to be tracked by the conntrack module. When there are a large number of connections, the resource consumption will be high, and the track table may become full. To address this problem, some industry practitioners, such as Alibaba, have disabled the conntrack module. iptables is a common module that takes effect globally, and related modifications cannot be explicitly prohibited, resulting in poor controllability. iptables-based traffic redirection is essentially data exchange through loopback. The outbound traffic progresses through the stack twice, degrading the forwarding performance in high-concurrency scenarios.  The above drawbacks do not exist in every scenario. For example, iptables is a simple and desirable solution for scenarios where the number of connections is small and no NAT table is used. To adapt to more scenarios, transparent hijacking needs to be optimized to eliminate the above drawbacks.\nOptimization for transparent hijacking Use TProxy to handle inbound traffic\nTProxy can be used to redirect inbound traffic without modifying the destination IP address/port number in messages. No connection needs to be tracked, and the conntrack module does not need to create large numbers of connections. TProxy is not suitable for handling outbound traffic due to the limit of the kernel version. Currently, Istio supports using TProxy to handle inbound traffic.\nUse hook connect to handle outbound traffic\nTo adapt to more application scenarios, hook connect is used to handle outbound traffic. The implementation principle is as follows:\nRegardless of which transparent hijacking solution is adopted, the real destination IP address/port number needs to be identified. In the iptables solution, the destination address is identified by calling the getsockopt function. TProxy can directly read the address. In the hook connect solution, the sidecar can also read the original IP/port number by calling the getsockopt function.\nAfter implementing transparent hijacking, if the kernel version meets the requirement (4.16 or later), we can use sockmap to shorten the message processing path, and improve the forwarding performance in the outbound direction.\nSummary An application can hijack traffic in combination with the registry when publishing/subscribing to services through the registry. In transparent hijacking scenarios, we can use iptables to redirect traffic under low performance pressure. TProxy and hook connect can be used under high concurrency pressure.\n","excerpt":"This topic describes the traffic hijacking solution when MOSN is used as a sidecar.\nWhen MOSN is …","ref":"https://mosn.io/en/docs/concept/traffic-hijack/","title":"Traffic hijacking"},{"body":"","excerpt":"","ref":"https://mosn.io/en/docs/concept/","title":"Architecture and principle"},{"body":"The MOSN configuration file comprises the following four parts:\n Server configurations: Currently, only one server can be configured. The server supports some basic configurations and corresponding listener configurations. ClusterManager configurations: This part supports configuring detailed upstream information of MOSN. xDS configurations for connecting to the control plane (Pilot) Other configurations  Configurations for Trace, Metrics, Debug, and Admin API Extension configurations: the custom extension configurations    Configuration file overview\nThe basic configurations of MOSN are shown as follows.\n{ \u0026#34;servers\u0026#34;: [], \u0026#34;cluster_manager\u0026#34;: {}, \u0026#34;dynamic_resources\u0026#34;: {}, \u0026#34;static_resources\u0026#34;: {}, \u0026#34;admin\u0026#34;:{}, \u0026#34;pprof\u0026#34;:{}, \u0026#34;tracing\u0026#34;:{}, \u0026#34;metrics\u0026#34;:{} } Configuration modes MOSN supports the following configuration modes:\n Static configuration Dynamic configuration Hybrid configuration  Static configuration  In the static configuration mode, MOSN starts without connecting to Pilot of the control plane. This mode applies to some relatively fixed and simple scenarios (for example, demonstration of MOSN). Even if MOSN starts in the static configuration mode, you can use the extension code to call the dynamic configuration update API to dynamically modify the configuration. To start MOSN in the static configuration mode, one server and at least one cluster are required.  Dynamic configuration   In the dynamic configuration mode, MOSN starts with only configurations for accessing the control plane, but no configuration for running.\n  After starting in dynamic configuration mode, MOSN will request the control plane to provide configurations required for running. The control plane can also push configuration updates when MOSN is running.\n  To start MOSN in the dynamic configuration mode, the DynamicResources and StaticResources configurations are required.\n  Hybrid configuration MOSN can start in a hybrid mode with both static and dynamic configurations. In this mode, MOSN first completes initialization in the static configuration mode and then obtains configuration updates from the control plane.\nConfiguration examples Static configuration example The example of static configuration is as follows.\n{ \u0026#34;servers\u0026#34;: [ { \u0026#34;default_log_path\u0026#34;: \u0026#34;/home/admin/logs/mosn/default.log\u0026#34;, \u0026#34;default_log_level\u0026#34;: \u0026#34;DEBUG\u0026#34;, \u0026#34;processor\u0026#34;: 4, \u0026#34;listeners\u0026#34;: [ { \u0026#34;address\u0026#34;: \u0026#34;0.0.0.0:12220\u0026#34;, \u0026#34;bind_port\u0026#34;: true, \u0026#34;filter_chains\u0026#34;: [ { \u0026#34;filters\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;proxy\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;downstream_protocol\u0026#34;: \u0026#34;SofaRpc\u0026#34;, \u0026#34;upstream_protocol\u0026#34;: \u0026#34;SofaRpc\u0026#34;, \u0026#34;router_config_name\u0026#34;: \u0026#34;test_router\u0026#34; } }, { \u0026#34;type\u0026#34;: \u0026#34;connection_manager\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;router_config_name\u0026#34;: \u0026#34;test_router\u0026#34;, \u0026#34;virtual_hosts\u0026#34;: [] } } ] } ] } ] } ], \u0026#34;cluster_manager\u0026#34;: { \u0026#34;clusters\u0026#34;: [ { \u0026#34;name\u0026#34;:\u0026#34;example\u0026#34;, \u0026#34;lb_type\u0026#34;: \u0026#34;LB_ROUNDROBIN\u0026#34;, \u0026#34;hosts\u0026#34;: [ {\u0026#34;address\u0026#34;: \u0026#34;127.0.0.1:12200\u0026#34;} ] } ] } } Dynamic configuration example The example of dynamic configuration is as follows.\n{ \u0026#34;servers\u0026#34;: [ { \u0026#34;default_log_path\u0026#34;: \u0026#34;stdout\u0026#34;, \u0026#34;default_log_level\u0026#34;: \u0026#34;DEBUG\u0026#34; } ], \u0026#34;static_resources\u0026#34;: { \u0026#34;clusters\u0026#34;: [ { \u0026#34;connect_timeout\u0026#34;: \u0026#34;1s\u0026#34;, \u0026#34;load_assignment\u0026#34;: { \u0026#34;cluster_name\u0026#34;: \u0026#34;xds_cluster\u0026#34;, \u0026#34;endpoints\u0026#34;: [ { \u0026#34;lb_endpoints\u0026#34;: [ { \u0026#34;endpoint\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;socket_address\u0026#34;: { \u0026#34;address\u0026#34;: \u0026#34;127.0.0.1\u0026#34;, \u0026#34;port_value\u0026#34;: 9002 } } } } ] } ] }, \u0026#34;http2_protocol_options\u0026#34;: {}, \u0026#34;name\u0026#34;: \u0026#34;xds_cluster\u0026#34; } ] }, \u0026#34;dynamic_resources\u0026#34;: { \u0026#34;ads_config\u0026#34;: { \u0026#34;api_type\u0026#34;: \u0026#34;GRPC\u0026#34;, \u0026#34;transport_api_version\u0026#34;: \u0026#34;V3\u0026#34;, \u0026#34;grpc_services\u0026#34;: [ { \u0026#34;envoy_grpc\u0026#34;: { \u0026#34;cluster_name\u0026#34;: \u0026#34;xds_cluster\u0026#34; } } ], \u0026#34;set_node_on_first_message_only\u0026#34;: true }, \u0026#34;cds_config\u0026#34;: { \u0026#34;resource_api_version\u0026#34;: \u0026#34;V3\u0026#34;, \u0026#34;api_config_source\u0026#34;: { \u0026#34;api_type\u0026#34;: \u0026#34;GRPC\u0026#34;, \u0026#34;transport_api_version\u0026#34;: \u0026#34;V3\u0026#34;, \u0026#34;grpc_services\u0026#34;: [ { \u0026#34;envoy_grpc\u0026#34;: { \u0026#34;cluster_name\u0026#34;: \u0026#34;xds_cluster\u0026#34; } } ], \u0026#34;set_node_on_first_message_only\u0026#34;: true } }, \u0026#34;lds_config\u0026#34;: { \u0026#34;resource_api_version\u0026#34;: \u0026#34;V3\u0026#34;, \u0026#34;api_config_source\u0026#34;: { \u0026#34;api_type\u0026#34;: \u0026#34;GRPC\u0026#34;, \u0026#34;transport_api_version\u0026#34;: \u0026#34;V3\u0026#34;, \u0026#34;grpc_services\u0026#34;: [ { \u0026#34;envoy_grpc\u0026#34;: { \u0026#34;cluster_name\u0026#34;: \u0026#34;xds_cluster\u0026#34; } } ], \u0026#34;set_node_on_first_message_only\u0026#34;: true } } }, \u0026#34;node\u0026#34;: { \u0026#34;cluster\u0026#34;: \u0026#34;test-cluster\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;test-id\u0026#34; }, \u0026#34;layered_runtime\u0026#34;: { \u0026#34;layers\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;runtime-0\u0026#34;, \u0026#34;rtds_layer\u0026#34;: { \u0026#34;rtds_config\u0026#34;: { \u0026#34;resource_api_version\u0026#34;: \u0026#34;V3\u0026#34;, \u0026#34;api_config_source\u0026#34;: { \u0026#34;transport_api_version\u0026#34;: \u0026#34;V3\u0026#34;, \u0026#34;api_type\u0026#34;: \u0026#34;GRPC\u0026#34;, \u0026#34;grpc_services\u0026#34;: { \u0026#34;envoy_grpc\u0026#34;: { \u0026#34;cluster_name\u0026#34;: \u0026#34;xds_cluster\u0026#34; } } } }, \u0026#34;name\u0026#34;: \u0026#34;runtime-0\u0026#34; } } ] }, \u0026#34;admin\u0026#34;: { \u0026#34;access_log_path\u0026#34;: \u0026#34;/dev/null\u0026#34;, \u0026#34;address\u0026#34;: { \u0026#34;socket_address\u0026#34;: { \u0026#34;address\u0026#34;: \u0026#34;127.0.0.1\u0026#34;, \u0026#34;port_value\u0026#34;: 9003 } } } } ","excerpt":"The MOSN configuration file comprises the following four parts:\n Server configurations: Currently, …","ref":"https://mosn.io/en/docs/configuration/","title":"Configuration overview"},{"body":"This topic describes the example projects of MOSN.\nUse MOSN as an HTTP proxy For more information, see the example project at http-sample.\nUse MOSN as a SOFARPC proxy For more information, see the example project at sofarpc-sample.\nUse MOSN as a TCP proxy For more information, see the example project at tcpproxy-sample.\nUse SkyWalking as a Trace implementation For more information, see the example project at skywalking-sample.\n","excerpt":"This topic describes the example projects of MOSN.\nUse MOSN as an HTTP proxy For more information, …","ref":"https://mosn.io/en/docs/samples/","title":"Example projects"},{"body":"This topic describes the TLS security capability of MOSN.\nCertificate solution MOSN provides a certificate issuance solution based on Istio Citadel. It configures Sidecar certificates by using the Secret Discovery Service (SDS) of the Istio community. Dynamic certificate discovery and hot updates are supported. To provide advanced security capabilities, MOSN obtains certificates by connecting to the internal Key Management Service (KMS) system, without relying on the self-certificate issuance capability of Citadel. MOSN also supports certificate caching, pushing, and updates.\nThe following figure shows the architecture of the MOSN\u0026rsquo;s certificate solution.\nRoles of the components are described as follows:\n Pilot: sends policies and SDS configurations (not shown in the figure for brevity). Citadel: acts as the Certificate Provider as well as the MCP Server to provide resources to the Citadel Agent such as Pods and custom resources (CRs). Citadel Agent: provides SDS Server services and sends certificates and CRs for MOSN, DB Sidecar, and Security Sidecar. KMS: issues certificates.  Certificate acquisition procedure After having a general idea about the overall architecture, we can break down the certificate acquisition procedure for the sidecar as shown in the following figure.\nEach step in the figure is described as follows:\n Citadel synchronizes Pod and CR information with the Citadel Agent (nodeagent) through the Mesh Configuration Protocol (MCP). This avoids overload of the API Server caused by direct requests from the Citadel Agent to the API Server. MOSN sends an SDS request to the Citadel Agent by using the Unix Domain Socket. The Citadel Agent performs tamper-proof verification and extracts the appkey. The Citadel Agent uses the appkey to request Citadel to issue a certificate. Citadel checks whether a certificate has been cached. If a valid certificate is cached, Citadel directly returns the cached certificate. If no certificate is cached, Citadel constructs a certificate issuance request and requests the KMS to issue a certificate. The KMS returns a certificate to Citadel. The KMS also generates certificate expiration and rotation notifications. After receiving the certificate, Citadel transfers it to the corresponding Citadel Agent. After receiving the certificate, the Citadel Agent caches it in memory and sends it to MOSN.  ","excerpt":"This topic describes the TLS security capability of MOSN.\nCertificate solution MOSN provides a …","ref":"https://mosn.io/en/docs/concept/tls/","title":"TLS connections"},{"body":"Sidecar O\u0026amp;M is always challenging for a service mesh, while sidecar upgrades are common at the data plane. This topic describes how to upgrade the sidecar (MOSN) without affecting the business and how to migrate existing persistent connections.\nBackground This topic describes why and how MOSN supports hot upgrade. For details about the basic concepts of hot upgrade, see the NGINX vs Envoy vs MOSN hot upgrade.\nFirst, why don\u0026rsquo;t NGINX and Envoy require a connection-lossless migration solution like MOSN does? This depends on their business scenarios. NGINX and Envoy mainly support the HTTP1 and HTTP2 protocols. The connection: Close request/response header in HTTP1 and GOAWAY frame in HTTP2 allow a client to actively close a connection and establish a new one to a new process. However, common multiplexing protocols such as Dubbo and SOFARPC do not provide control frames, and a request will fail if the connection to the old process is closed.\nA common upgrade approach is to: cut off the application\u0026rsquo;s traffic, for example, by unpublishing the service; upgrade MOSN when no new request is received; and then publish the service again. This process takes a rather long time, and the service is unavailable during this period of time. In addition, the application usage also needs to be considered. Achieving a balance between service availability and the upgrade in a large-scale scenario is difficult. To adapt to business scenarios of MOSN, a persistent-connection migration solution is developed to migrate persistent connections to new processes. The entire procedure is transparent to the client, and no connection needs to be re-established, implementing a request-lossless hot upgrade.\nNormal procedure  A client sends a request to MOSN. MOSN forwards the request to a server. The server returns a response to MOSN. MOSN returns the response to the client.  The preceding figure briefly shows a normal request procedure. Next, we need to migrate TCP1 connections between the client and MOSN. TCP2 connections between MOSN and the server do not need to be migrated, because the server accessed by MOSN is selected through load balancing. The connection/disconnection with the server is not our concern.\nHot upgrade procedure Trigger conditions We can trigger a hot upgrade through either of the following methods:\n Register a SIGHUP event listener with MOSN, and send a SIGHUP signal to the MOSN process to call ForkExec to generate a new MOSN process. Directly start a new MOSN process.  Why do we provide two methods? In the beginning, only the first method was supported, which is used by NGINX and Envoy. In this method, we can replace the old MOSN binary file in a virtual machine or container for an upgrade. However, our scenarios require cross-container upgrades. We need to start a new container (a new MOSN process) to implement a hot upgrade. That is why the second method is provided. Cross-container upgrades also require support from operators, but this will not be discussed in detail here.\nInteraction procedure The old MOSN process will start a goroutine to run the ReconfigureHandler() function to listen to a domain socket (reconfig.sock) in the last stage. This operation enables the new MOSN process to detect whether an old MOSN process exists.\nfunc ReconfigureHandler() { l, err := net.Listen(\u0026#34;unix\u0026#34;, types.ReconfigureDomainSocket) for { uc, err := ul.AcceptUnix() _, err = uc.Write([]byte{0}) reconfigure(false) } } Both hot upgrade triggering methods start a new MOSN process at last. The new MOSN process will then successively call the GetInheritListeners() and isReconfigure() functions to verify whether an old MOSN process exists (whether the reconfig.sock listener exists). If yes, MOSN starts the migration procedure; otherwise, MOSN starts a normal startup procedure.\n// The core procedure is kept. func GetInheritListeners() ([]net.Listener, net.Conn, error) { if !isReconfigure() { return nil, nil, nil } l, err := net.Listen(\u0026#34;unix\u0026#34;, types.TransferListenDomainSocket) uc, err := ul.AcceptUnix() _, oobn, _, _, err := uc.ReadMsgUnix(buf, oob) file := os.NewFile(fd, \u0026#34;\u0026#34;) fileListener, err := net.FileListener(file) return listeners, uc, nil } If the migration procedure starts, the new MOSN process will listen to a new domain socket (listen.sock). This ensures that the old MOSN process can transfer the listen FD to the new MOSN process. sendMsg and recvMsg are used to transfer the listen FD. After receiving the listen FD, the new MOSN process calls the net.FileListener() function to generate a listener. In this case, the new and old MOSN processes have the same listen socket.\n// FileListener returns a copy of the network listener corresponding // to the open file f. // It is the caller\u0026#39;s responsibility to close ln when finished. // Closing ln does not affect f, and closing f does not affect ln. func FileListener(f *os.File) (ln Listener, err error) { ln, err = fileListener(f) if err != nil { err = \u0026amp;OpError{Op: \u0026#34;file\u0026#34;, Net: \u0026#34;file+net\u0026#34;, Source: nil, Addr: fileAddr(f.Name()), Err: err} } return } The migration procedure of MOSN is different from that of NGINX. In NGINX, after the forking is done, the child process automatically inherits the listen FD. However, MOSN starts a new process that is independent from the old one, without a parent-child relationship. Therefore, sendMsg is required for transferring the listen FD.\nA total of two domain sockets are used to start the migration and transfer the listen FD.\n reconfig.sock is the old MOSN listener used by the new MOSN process to verify whether an old MOSN process exists. listen.sock is the new MOSN listener used by the old MOSN process to transfer the listen FD.  These two sockets are actually interchangeable. For example, reconfig.sock can also be used for transferring the listen FD. These two sockets are used for some historical reasons. They can be merged into one later on, to make the code simpler and easier to read.\nLet us take a look at the handling procedure of the old MOSN process. After receiving the notification from the new MOSN process, the old MOSN process starts the reconfigure(false) procedure. It first calls sendInheritListeners() to transfer the listen FD to the new MOSN process as described above, and then calls WaitConnectionsDone() to migrate existing persistent connections.\n// The core procedure is kept. func reconfigure(start bool) { if start { startNewMosn() return } // transfer listen fd  if notify, err = sendInheritListeners(); err != nil { return } // Wait for all connections to be finished  WaitConnectionsDone(GracefulTimeout) os.Exit(0) } After receiving the listen FD, the new MOSN process starts the migration process based on the configurations. Then the new MOSN process starts a goroutine to run TransferServer() to listen to a new domain socket (conn.sock), for receiving persistent connections from the old MOSN process subsequently. The migration function is transferHandler().\nfunc TransferServer(handler types.ConnectionHandler) { l, err := net.Listen(\u0026#34;unix\u0026#34;, types.TransferConnDomainSocket) utils.GoWithRecover(func() { for { c, err := l.Accept() go transferHandler(c, handler, \u0026amp;transferMap) } }, nil) } The old MOSN process starts persistent-connection migration through transferRead() and transferWrite(). This is analyzed as follows.\nPersistent-connection migration procedure First, let us take a look at the migration procedure of a new request.\n A client sends a request to MOSN. MOSN (the old MOSN process) sends the FD and connection status data of TCP1 to New MOSN (the new MOSN process). New MOSN receives the FD and request data, creates a new connection structure, and sends the connection ID to the MOSN. At this time, New MOSN has a copy of the TCP1 connection. New MOSN selects a new server by using the load balancer, establishes a TCP3 connection, and forwards the request to the server. The server returns a response to New MOSN. New MOSN returns a response to the client based on the copy of TCP1 connection transferred from MOSN.  In the original WaitConnectionsDone() function, s.stopChan has been disabled. In ReadLoop of the connection, a [TransferTimeout, 2 * TransferTimeout] random time interval will be set for the migration procedure. The random interval is intended to discretize the migration time for TCP connections of each client, to ensure smooth migration.\nfunc (c *connection) startReadLoop() { var transferTime time.Time for { select { case \u0026lt;-c.stopChan: if transferTime.IsZero() { if c.transferCallbacks != nil \u0026amp;\u0026amp; c.transferCallbacks() { randTime := time.Duration(rand.Intn(int(TransferTimeout.Nanoseconds()))) transferTime = time.Now().Add(TransferTimeout).Add(randTime) log.DefaultLogger.Infof(\u0026#34;[network] [read loop] transferTime: Wait %d Second\u0026#34;, (TransferTimeout+randTime)/1e9) } else { // set a long time, not transfer connection, wait mosn exit.  transferTime = time.Now().Add(10 * TransferTimeout) log.DefaultLogger.Infof(\u0026#34;[network] [read loop] not support transfer connection, Connection = %d, Local Address = %+v, Remote Address = %+v\u0026#34;, c.id, c.rawConnection.LocalAddr(), c.RemoteAddr()) } } else { if transferTime.Before(time.Now()) { c.transfer() return } } After one random interval elapses, the c.transfer() function is called. c.notifyTransfer() is used for suspending write operations. No write operation is allowed during migration of read operations, because data confusion will occur if write operations are performed simultaneously in the old and new MOSN processes.\nfunc (c *connection) transfer() { c.notifyTransfer() id, _ := transferRead(c) c.transferWrite(id) } Then the transferRead() function is called to transfer the FD and status data of a connection to New MOSN through conn.sock. Similar to migrating the listen FD, New MOSN returns an ID after successful processing. This ID identifies the new connection established by New MOSN and will be used later.\n// old mosn transfer readloop func transferRead(c *connection) (uint64, error) { unixConn, err := net.Dial(\u0026#34;unix\u0026#34;, types.TransferConnDomainSocket) file, tlsConn, err := transferGetFile(c) uc := unixConn.(*net.UnixConn) // send type and TCP FD  err = transferSendType(uc, file) // send header + buffer + TLS  err = transferReadSendData(uc, tlsConn, c.readBuffer, log.DefaultLogger) // recv ID  id := transferRecvID(uc) return id, nil } We constructed a simple read transfer protocol, which mainly involves the length of the TCP raw data, the length of the TLS data, the TCP raw data, and the TLS data.\n/** * transfer read protocol * header (8 bytes) + (readBuffer data) + TLS * * 0 4 8 * +-----+-----+-----+-----+-----+-----+-----+-----+ * | data length | TLS length | * +-----+-----+-----+-----+-----+-----+-----+-----+ * | data | * +-----+-----+-----+-----+-----+-----+-----+-----+ * | TLS | * +-----+-----+-----+-----+-----+-----+-----+-----+ * Now, let us take a look at the handling procedure of the new MOSN process. After receiving migration requests, the new MOSN process starts a goroutine for each migration request to run the transferHandler() function. The function distinguishes read and write transfer requests based on the protocol read. Read transfer is described first. The new MOSN process calls transferNewConn to generate a new connection structure based on the FD and packets transferred from the old MOSN process. Then the new MOSN process transfers the new connection ID to the old MOSN process.\nThe new MOSN process starts to read data from the new TCP connection, and proceeds with a normal business request procedure.\nfunc transferHandler(c net.Conn, handler types.ConnectionHandler, transferMap *sync.Map) { // recv type  conn, err := transferRecvType(uc) if err != nil { log.DefaultLogger.Errorf(\u0026#34;[network] [transfer] [handler] transferRecvType error :%v\u0026#34;, err) return } if conn != nil { // transfer read  // recv header + buffer  dataBuf, tlsBuf, err := transferReadRecvData(uc) if err != nil { log.DefaultLogger.Errorf(\u0026#34;[network] [transfer] [handler] transferRecvData error :%v\u0026#34;, err) return } connection := transferNewConn(conn, dataBuf, tlsBuf, handler, transferMap) if connection != nil { transferSendID(uc, connection.id) } else { transferSendID(uc, transferErr) } } else { // transfer write  // recv header + buffer  id, buf, err := transferWriteRecvData(uc) if err != nil { log.DefaultLogger.Errorf(\u0026#34;[network] [transfer] [handler] transferRecvData error :%v\u0026#34;, err) } connection := transferFindConnection(transferMap, uint64(id)) if connection == nil { log.DefaultLogger.Errorf(\u0026#34;[network] [transfer] [handler] transferFindConnection failed, id = %d\u0026#34;, id) return } err = transferWriteBuffer(connection, buf) if err != nil { log.DefaultLogger.Errorf(\u0026#34;[network] [transfer] [handler] transferWriteBuffer error :%v\u0026#34;, err) return } } } Then the new MOSN process replaces the old MOSN process, to read data from the TCP1 connection and process the data. For the new request, the entire migration procedure is completed.\nResidual-response migration procedure Why is a residual-response migration procedure required? Because of the multiplexing protocol, during the previous migration of read connections, residual responses for TCP2 connections are waiting to be returned to the client. The data may go out of order if both the old and new MOSN processes simultaneously write data to TCP1 connections. Therefore, we want the new MOSN process to uniformly handle the residual responses for TCP2 connections.\n The server returns a residual response to MOSN. MOSN transfers the connection ID and response data previously obtained from New MOSN back to New MOSN through domain socket (conn.sock). New MOSN queries the TCP1 connection based on the ID and returns the response to the client.  After the transferRead() (the read transfer) ends, the transferWrite() (the write transfer) starts. In this stage, packets to be written and the connection ID previously obtained from New MOSN are sent to New MOSN.\n// old mosn transfer writeloop func transferWrite(c *connection, id uint64) error { unixConn, err := net.Dial(\u0026#34;unix\u0026#34;, types.TransferConnDomainSocket) uc := unixConn.(*net.UnixConn) err = transferSendType(uc, nil) // build net.Buffers to IoBuffer  buf := transferBuildIoBuffer(c) // send header + buffer  err = transferWriteSendData(uc, int(id), buf) if err != nil { log.DefaultLogger.Errorf(\u0026#34;[network] [transfer] [write] transferWrite failed: %v\u0026#34;, err) return err } return nil } We constructed a simple write transfer protocol, which mainly involves the length of the TCP raw data, the connection ID, and the TCP raw data.\n/* * transfer write protocol * header (8 bytes) + (writeBuffer data) * * 0 4 8 * +-----+-----+-----+-----+-----+-----+-----+-----+ * | data length | connection ID | * +-----+-----+-----+-----+-----+-----+-----+-----+ * | data | * +-----+-----+-----+-----+-----+-----+-----+-----+ * **/ The new MOSN process calls the transferHandler() function to identify the write transfer protocol. Then the new MOSN process calls the transferFindConnection() function to locate the TCP1 connection based on the connection ID, and directly write the data.\nNote that new requests are now forwarded to the server through TCP3 connections, and only responses to previous requests will be returned through TCP2 connections. If no response is returned within 2 * TransferTimeout during the entire migration, the requests will time out and fail.\nConnection status data During the connection migration, both the TCP FD and the connection status are migrated so that the new MOSN process knows how to initialize the new connection.\nThe following status data is involved:\nRead buffer\nThe data that has been read from TCP but has not been processed at the application layer during migration.\nWrite data\nThe response data received by MOSN after migration.\nTLS status data migration\nIn case of a TLS encrypted request, the following TLS status data must to be migrated:\n Encryption key Sequence Read buffer data (encrypted/unencrypted) Cipher type TLS version  type TransferTLSInfo struct { Vers uint16 CipherSuite uint16 MasterSecret []byte ClientRandom []byte ServerRandom []byte InSeq [8]byte OutSeq [8]byte RawInput []byte Input []byte } Summary FD migration is a common operation for persistent connection migration, and can be performed through either sendMsg or connection repair.\nThe most challenging part in the entire procedure is the migration of the application layer data. The general idea is to migrate all data structures of the application layer to the new process, for example, structures such as protocol headers that have been read. However, this increases the migration complexity, because each protocol needs to be handled separately.\nTo address this problem, MOSN moves migration to the I/O layer, regardless of the protocols used at the application layer. The original TCP packets are migrated, and then the new MOSN process encodes/decodes the packets to assemble the header and other structures. This is a standard procedure that enables migration without parsing protocols. This migration framework can automatically support any stateless protocols.\nYou may doubt about the residual-response migration procedure. Why don\u0026rsquo;t we start migration after all responses are returned? This procedure seems to be unnecessary. The reason is that when we use a multiplexing protocol, requests are being sent all the time. You cannot always find a time point when all responses are returned.\nFeedback For more information about discussions on this issue, go to Github Issue at MOSN smooth upgrade problem #866.\n","excerpt":"Sidecar O\u0026amp;M is always challenging for a service mesh, while sidecar upgrades are common at the …","ref":"https://mosn.io/en/docs/concept/smooth-upgrade/","title":"MOSN hot upgrade"},{"body":"","excerpt":"","ref":"https://mosn.io/en/docs/contribute/","title":"Document contribution"},{"body":"The official MOSN documentation.\n","excerpt":"The official MOSN documentation.","ref":"https://mosn.io/en/docs/","title":"Documentation"},{"body":"","excerpt":"","ref":"https://mosn.io/en/blog/releases/","title":"Release"},{"body":"We are happy to announce the release of MOSN v1.2.0.\nv1.2.0 New Features  Support for configuring HTTP retry status codes (#2097) @dengqian Add dev container build configuration and instructions (#2108) @keqingyuan Support connpool_binding GoAway (#2115) @EraserTime Support for configuring the listener defaultReadBufferSize (#2133) @3062 Support Proxy-Wasm v2 ABI (#2089) @lawrshen Support transparent proxy based on iptables tproxy (#2142) @3062  Refactoring  Remove MOSN\u0026rsquo;s extended context framework and use the variable mechanism instead. Migrate the variable mechanism and memory reuse framework to mosn.io/pkg (#2055) @nejisama Migrating the metrics interface to mosn.io/api (#2124) @YIDWang  Bug fixes  Fix some missing log parameters (#2141) @lawrshen Determine if the obtained cookie exists by error (#2136) @greedying  ","excerpt":"We are happy to announce the release of MOSN v1.2.0.\nv1.2.0 New Features  Support for configuring …","ref":"https://mosn.io/en/blog/releases/v1.2.0/","title":"Announcing MOSN v1.2.0"},{"body":"We are happy to announce the release of MOSN v1.3.0.\nv1.3.0 Refactoring  Moves to consolidated Proxy-Wasm implementation and enables wazero by default (#2172) @Crypt Keeper  Optimization  Optimized parsing xDS transparent proxy configuration: add pass-through configuration for unrecognized addresses (#2171) @3062 Optimized the golangci execution flow in CI testing (#2166) @taoyuanyuan (#2167) @taoyuanyuan Add integrated benchmarks for Proxy-Wasm (#2164) @Crypt Keeper (#2169) @Crypt Keeper Upgrade the minimum version of Go supported by MOSN to 1.17 (#2160) @Crypt Keeper Fix some problems in the README.md (#2161) @liaolinrong Add benchmark (#2173) @3062 subsetLoadBalancer reuse subset entry to optimze alloc/inuse memory (#2119) @dzdx (#2188) @liwu  Bug fixes  Fix a panic problem with connpool_binging when connecting to upstream timeout (#2180) @EraserTime Fix the problem that retryTime is 0 when cluster LB algorithm is LB_ORIGINAL_DST (#2170) @3062 Fix smooth upgrade failed (#2129) @Bryce-Huang (#2193) @3062 Modify the way xDS Listener logs are parsed (#2182) @3062 Fix example print error (#2190) @liaolinrong  ","excerpt":"We are happy to announce the release of MOSN v1.3.0.\nv1.3.0 Refactoring  Moves to consolidated …","ref":"https://mosn.io/en/blog/releases/v1.3.0/","title":"Announcing MOSN v1.3.0"},{"body":"We are happy to announce the release of MOSN v1.1.0.\nv1.1.0 New Features  TraceLog support for zipkin (#2014) @fibbery Support cloud edge interconnection (#1640) @CodingSinger, details can be found in blog Trace supports plugin extension in the form of Driver, using SkyWalking as trace implementation (#2047) @YIDWang Support Parsing Extended xDS Stream Filter (#2095) @Bryce-huang stream filter: ipaccess extension implements xDS parsing logic (#2095) @Bryce-huang Add package tar command to MakeFile (#1968) @doujiang24  Changes  Adjust connection read timeout from buffer.ConnReadTimeout to types.DefaultConnReadTimeout (#2051) @fibbery Fix typo in documentation (#2056) (#2057)@threestoneliu (#2070) @chenzhiguo Update the configuration file of license-checker.yml (#2071) @kezhenxu94 New interface for traversing SubsetLB (#2059) (#2061) @nejisama Add SetConfig interface for tls.Conn (#2088) @antJack Add Example of xds-server as MOSN control plane (#2075) @Bryce-huang Add error log when HTTP request parsing fails (#2085) @taoyuanyuan (#2066) @fibbery Load balancing skips the last selected host on retry (#2077) @dengqian Access logs support printing traceID, connectionID and UpstreamConnectionID (#2107) @Bryce-huang  Refactoring  Refactor how HostSet is used (#2036) @dzdx Change the connection write data to only support synchronous write mode (#2087) @taoyuanyuan  Optimization  Optimize the algorithm for creating subset load balancing to reduce memory usage (#2010) @dzdx Support scalable cluster update method operation (#2048) @nejisama Optimize multi-certificate matching logic: match servername first, and match ALPN only after all servernames are unmatched (#2053) @MengJiapeng  Bug fixes  Fix the latest image version in the wasm example to be a fixed version (#2033) @antJack Adjust the order of log closing execution when MOSN exits, and fix the problem that some exit logs cannot be output correctly (#2034) @doujiang24 Fix the problem that OriginalDst was not properly processed after matching successfully (#2058) @threestoneliu Fix the problem that the protocol conversion scene does not handle exceptions correctly, and add the protocol conversion implementation specification (#2062) @YIDWang Fix stream proxy not properly handling exception events such as connection write timeout/disconnect (#2080) @dengqian Fix the panic problem that may be caused by the wrong timing of connection event listening (#2082) @dengqian Avoid closing event before event listener connection (#2098) @dengqian HTTP1/HTTP2 protocol save protocol information in context when processing (#2035) @yidwang Fix possible concurrency issues when pushing xDS (#2101) @yzj0911 If the upstream address variable is not found, it no longer returns null and returns ValidNotFound (#2049) @songzhibin97 Fix health check does not support xDS (#2084) @Bryce-huang Fix the method of judging the upstream address (#2093) @dengqian  ","excerpt":"We are happy to announce the release of MOSN v1.1.0.\nv1.1.0 New Features  TraceLog support for …","ref":"https://mosn.io/en/blog/releases/v1.1.0/","title":"Announcing MOSN v1.1.0"},{"body":"We are happy to announce the release of MOSN v0.26.0.\nv0.26.0 Incompatible Change For implementing new protocols more nature, XProtocol is no longer as a protocol and no subprotocol any more. XProtocol is a framework to implement protocol easier now. So, the old existing code for implementing new protocols need some changes, please see this doc(In Chinese) for changing the old existing code suit for the new release.\nNew Features  Added the ip_access new filter to manage access control based on IP (#1797). @Bryce-huang Support admin api extends auth functions (#1834). @nejisama The transcode filter module support dynamic phase (#1815). @YIDWang Added the SetConnectionState method for tls connection in pkg/mtls/crypto/tls.Conn (#1804). @antJack Added the after-start and after-stop two new stages, and allow to register handler during these stages. @doujiang24 Support specify the unix domain socket directory by adding the new \u0026ldquo;uds_dir\u0026rdquo; configuration (#1829). @dengqian Support choose dynamic protocol convert dynamically and allow register transcoder through go-plugin. @Tanc010 Added more HTTP protocol method to make protocol matcher work properly (#1870). @XIEZHENGYAO Support to set upstream protocol dynamically (#1808). @YIDWang Support set default HTTP stream config #1886. @nejisama  Changes  Change the default max header size to 8KB (#1837). @nejisama Refactory default HTTP1 and HTTP2 convert, remove the proxy convert, use transcoder filter instead. @nejisama transcoder filter: changed to register trancoder factory instead trancoder (#1879). @YIDWang  Bug fixes  Fix a HTTP buffer reuse related bug that may leads to nil panics in high concurrency case. @nejisama Fix: get the proper value of variable response_flag, (#1814). @lemonlinger Fix: prefix_write not work with \u0026ldquo;/\u0026rdquo; (#1826). @Bryce-huang Fix: the reconfig.sock file may be removed unexpectly when killed the old MOSN manually during smoothly upgrade, (#1820). @XIEZHENGYAO Fix the bug in doretry: should not set setupRetry to false directly, since the old response should be skip when the new upstream request has been sent out (#1807). @taoyuanyuan Should set the inherit config back to the MOSN instance (#1819). @XIEZHENGYAO Should send resetStreamFrame to upstream when cancel grpc context at client side, otherwise server side context won\u0026rsquo;t be done. @XIEZHENGYAO Should set the resetReason before closing the stream connection, otherwise, may unable to get the real reason (#1828). @wangfakang Should use the listener that best match when found multi listeners, otherwise, may got 400 error code. @MengJiapeng Fixed panic due to concurrent map iteration and map write during process setting broadcast in HTTP2 protocol. @XIEZHENGYAO Fix memory leak occurred in the binding connpool of XProtocol (#1821). @Dennis8274 Should close logger at the end, otherwise, may lost log during close MOSN instance (#1845). @doujiang24 Fix panic due to codecClient is nil when got connect timeout event from XProtocol PingPong connection pool (#1849). @cuiweixie Health checker not work when the unhealthyThreshold is an empty value (#1853). @Bryce-huang WRR may leads dead recursion in unweightChooseHost #1860. @alpha-baby Fix direct response, send hijack should not transcode. @nejisama Fix EDF wrr lb cannot choose a healthy host when there\u0026rsquo;s a unhealthy host with a high weight. @lemonlinger Got the wrong CACert filename when converting the listen filter from Istio LDS, MOSN may not listen success (#1893). @doujiang24 The goroutine for resolving hosts in STRICT_DNS_CLUSTER cannot be stopped #1894 @bincherry  ","excerpt":"We are happy to announce the release of MOSN v0.26.0.\nv0.26.0 Incompatible Change For implementing …","ref":"https://mosn.io/en/blog/releases/v0.26.0/","title":"Announcing MOSN v0.26.0"},{"body":"We are happy to announce the release of MOSN v0.25.0.\nv0.25.0 New Features  Routing configuration supports remove request headers. @wangfakang Support WASM Reload. @zu1k Integrated SEATA TCC mode, support HTTP protocol. [@dk-lockdown]((https://github.com/dk-lockdown) Support boltv2 protocol tracelog. @nejisama New metrics stream filter for gRPC framework. @wenxuwan Support DNS related configuration in xDS cluster config. @antJack  Refactoring  Decouple MOSN core and Istio related xDS code. @nejisama Upgrade proxy-wasm-go-host version. @zhenjunMa Refactor networkfilter configuration parse functions, support AddOrUpdate and Get. @antJack  Optimization  Use mod vendor instead of GO111MODULE=off in Makefile. @scaat Move some archived repo code into mosn.io/pkg. @nejisama Optimize EDF loadbalancer: random pick host at the first select time. @alpha-baby Optimize EDF loadbalancer performance. @alpha-baby Optimize boltv2 protocol heartbeat\u0026rsquo;s trigger and reply. @nejisama Optimize HTTP2 retry processing in stream mode, optimize HTTP2 unary request processing in stream mode. @XIEZHENGYAO Ignore CPU numbers limit when use environment variable to set GOMAXPROCS. @wangfakang Reduce memory alloc when create subset loadbalancer. @dzdx Support different listener can independent run same name gRPC Server. @nejisama  Bug fixes  Fix MOSN hangs up when host is empty when retry. @XIEZHENGYAO Fix connections in msgconnpool cannot handle connect event. @RayneHwang Fix MOSN panic when tracer driver is not inited and someone calls tracer Enable. @nejisama Fix boltv2 protocol constructs hijack response version wrong. @nejisama Fix HTTP2 handle connection termination event. @XIEZHENGYAO Fix typo. @jxd134 @yannsun Fix ResponseFlag outputs in RequestInfo. @wangfakang Fix bolt/boltv2 protocol not recalculated the empty data\u0026rsquo;s length. @hui-cha  ","excerpt":"We are happy to announce the release of MOSN v0.25.0.\nv0.25.0 New Features  Routing configuration …","ref":"https://mosn.io/en/blog/releases/v0.25.0/","title":"Announcing MOSN v0.25.0"},{"body":"We are happy to announce the release of MOSN v0.24.0, congratulations to Jianhao Fu(@alpha-baby) on becoming a MOSN Committer and thanks for his contribution to the MOSN community.\nv0.24.0 New Features  Support jaeger to collect OpenTracing message @Roger Routing configuration new variable configuration mode, you can modify the routing results by modifying the variable @wangfakang Routing virtualhost matching supports port matching mode @jiebin Impl envoy filter: header_to_metadata @antJack Support graceful for uds @taoyuanyuan New subset load balancing logic to use the full list of machines for load balancing in scenarios where there is no metadata matching @nejisama MOSN\u0026rsquo;s grpc framework supports graceful stop @alpha-baby  Optimization  Optimize health check update mode for Cluster configuration updates @alpha-baby Add OnConnectionEvent interface in api.Connection @CodingSinger Weighted roundrobin loadbalancer underwriting policy adjusted to normal roundrobin load balancer @alpha-baby Enhance interface value in mosn variable model @antJack Subset also follows the same underwriting strategy when determining the number of machines and whether they exist @antJack  Bug fixes  Dubbo stream filter supports automatic protocol recognition @Thiswang Fix roundrobin loadbalancer result exception in case of concurrency @alpha-baby Fix unix address resolution exception @taoyuanyuan Fix the exception that HTTP short connection cannot take effect @taoyuanyuan Fix a memory leak in the TLS over SM3 suite after disconnection @ZengKe HTTP2 support doretry when connection reset by peer or broken pipe @taoyuanyuan Fix the host information error from the connection pool @Sharember Fix data race bug when choose weighted cluster @alpha-baby Return invalid host if host is unhealthy in EdfLoadBalancer @alpha-baby Fix the problem that XProtocol routing configuration timeout is invalid @nejisama  ","excerpt":"We are happy to announce the release of MOSN v0.24.0, congratulations to Jianhao Fu(@alpha-baby) on …","ref":"https://mosn.io/en/blog/releases/v0.24.0/","title":"Announcing MOSN v0.24.0"},{"body":"We are happy to announce the release of MOSN v0.23.0\nv0.23.0 New Features  Add new networkfilter:grpc. A grpc server can be extended by networkfilter and implemented in the MOSN, reuse MOSN capabilities. @nejisama @zhenjunMa Add a new extended function for traversal calls in the StreamFilterChain. @wangfakang Add HTTP 403 status code mapping in the bolt protocol. @pxzero Add the ability to shutdown the upstream connections. @nejisama  Optimization  Optimize the networkfilter configuration parsed. @nejisama Support extend proxy config by protocol, optimize the proxy configuration parse timing. @nejisama Add tls conenction\u0026rsquo;s certificate cache, reduce the memory usage. @nejisama Optimize Quick Start Sample. @nobodyiam Reuse context when router handler check available. @alpha-baby Modify the NewSubsetLoadBalancer\u0026rsquo;s input parameter to interface instead of the determined structure. @alpha-baby Add an example of using so plugin to implement a protocol. @yichouchou   Optimize the method of get environment variable GOPATH in the MAKEFILE. @bincherry Support darwin \u0026amp; aarch64 architecture. @nejisama   Optimize the logger file flag. @taoyuanyuan  Bug fixes  Fix the bug of HTTP1 URL encoding. @morefreeze Fix the bug of HTTP1 URL case-sensitive process. @GLYASAI Fix the bug of memory leak in error handling when the tls cipher suite is SM4. @william-zk  ","excerpt":"We are happy to announce the release of MOSN v0.23.0\nv0.23.0 New Features  Add new …","ref":"https://mosn.io/en/blog/releases/v0.23.0/","title":"Announcing MOSN v0.23.0"},{"body":"We are happy to announce the release of MOSN v0.22.0\nv0.22.0 New Features  Add Wasm extension framework @antJack Add x-bolt sub-protocol to allow wasm-based codec for XProtocol @zonghaishang Support fallback through SO_ORIGINAL_DST when protocol auto-matching got failed @antJack Support Go Plugin mode for XProtocol @fdingiit Support for network extension @wangfakang Update to Istio xDS v3 API @champly Branch: istio-1.7.7  Optimization  Remove redundant file path clean when resolving StreamFilter configs @eliasyaoyc Allow setting a unified callback handler for the StreamFilterChain @antJack Support multi-stage execution and remove state lock for the FeatureGate @nejisama Add trace support for HTTP2 @OrezzerO  Refactoring  Add StageManger to divide the bootstrap procedure of MOSN into four configurable stages @nejisama Unify the type definitions of XProtocol and move into mosn.io/api package @fdingiit Add GetTimeout method for XProtocol to replace the variable getter @nejisama  Bug fixes  Fix concurrent read and write for RequestInfo in Proxy @nejisama Fix the safety bug when forwarding the request URI @antJack Fix concurrent slice read and write for Router configurations when doing persistence @nejisama  ","excerpt":"We are happy to announce the release of MOSN v0.22.0\nv0.22.0 New Features  Add Wasm extension …","ref":"https://mosn.io/en/blog/releases/v0.22.0/","title":"Announcing MOSN v0.22.0"},{"body":"We are happy to announce the release of MOSN v0.21.0, congratulations to Zechao Zheng(@CodingSinger) on becoming a MOSN Committer and thanks for his contribution to the MOSN community.\nv0.21.0 Optimization  Upgrade sentinel version to v1.0.2 @ansiz Shrink the read buffer of tls when read timeout, reduce tls memory consumption @cch123 Add comments and simplify the implementation of the xprotocol protocol connpool @cch123 Update the mosn registry version @cadeeper @cch123  Refactoring  Optimize header matching logic when routing, support general RPC routing matching implementation @nejisama Delete some of the original constants and add constants used to describe the mechanism of variables @nejisama Refactor flow control module, support custom callback extension, realize the ability to customize filter conditions and modify context information, etc @ansiz  Bug fixes  Fix metrics statistics error when request is abnormal @cch123 Fix the bug that the URL is not escaping before forwarding HTTP request @antJack Fix the variable injection errors in HTTP protocol, Fix the bug that routing rewrite is not supported in the HTTP2 protocol @nejisama  New Features  Support Domain-Specific Language route implementation @CodingSinger StreamFilter supports the dynamic link libraries written in Go @CodingSinger VirtualHost supports per_filter_config configuration in routing configuration @machine3 Xprotocol supports dubbo thrift protocol @cadeeper  ","excerpt":"We are happy to announce the release of MOSN v0.21.0, congratulations to Zechao Zheng(@CodingSinger) …","ref":"https://mosn.io/en/blog/releases/v0.21.0/","title":"Announcing MOSN v0.21.0"},{"body":"We are happy to announce the release of MOSN v0.20.0, congratulations to Huang Runhao(@GLYASAI) on becoming a MOSN Committer and thanks for his contribution to the MOSN community.\nv0.20.0 Optimization  Add UDS address prefix check before UDS resolution when TCP address resolution fails @wangfakang Optimized the retrial interval for connection pool acquisition @nejisama Add global switch for write loop mode @nejisama Optimize auto protocol matching and add test cases @taoyuanyuan Replace the headers with more efficient variables @CodingSinger Pool the writeBufferChan timer to reduce overhead @cch123 Add MOSN failure detail info into TraceLog @nejisama New read done channel in HTTP protocol processing @alpha-baby Enhance logger rotator @nejisama  Refactoring  Upgrade to golang 1.14.13 @nejisama Refactor router chain extension mode to the route handler extension mode, support different router handler configuration @nejisama Refactor MOSN extended configuration, support load config according to configuration order @nejisama  Bug fixes  Fix the bug no provider available occurred after dubbo2.7.3 @cadeeper Fix the bug that UDS connections were treated as TCP connections in netpoll mode @wangfakang Fix the problem that the HTTP Header cannot be obtained correctly when it is set to an empty value @ianwoolf  New Features  Support old Mosn transfer configuration to new Mosn through UDS to solve the issue that Mosn in XDS mode cannot be smoothly upgraded @alpha-baby Automatic protocol identification supports the identification of XProtocol @cadeeper Support configuration of the keepalive parameters for XProtocol @cch123 Support more detailed time tracking @nejisama Support metrics lazy registration to optimize metrics memory when number of service in cluster is too large @champly Add setter function for default XProtocol multiplex connection pool size @cch123 Support netpoll @cch123 Support broadcast @dengqian Support get tls configurations from LDS response @wZH-CN Add ACK response for SDS @wZH-CN  ","excerpt":"We are happy to announce the release of MOSN v0.20.0, congratulations to Huang Runhao(@GLYASAI) on …","ref":"https://mosn.io/en/blog/releases/v0.20.0/","title":"Announcing MOSN v0.20.0"},{"body":"We are happy to announce the release of MOSN v0.19.0.\nv0.19.0 Optimization  Use the latest TLS memory optimization scheme @cch123 Proxy log optimization to reduce memory escape @taoyuanyuan Increase the maximum number of connections limit @champly When AccessLog fails to obtain variables, use \u0026ldquo;-\u0026rdquo; instead @champly MaxProcs supports configuring automatic recognition based on CPU usage limits @champly Allow specifying network for cluster @champly  Refactoring  Refactored the StreamFilter framework. The network filter can reuse the stream filter framework @antJack  Bug fixes  Fix HTTP Trace get URL error @wzshiming Fix the ConnectTimeout parameter of xDS cluster is not converted @dengqian Fix the upstreamHostGetter method gets the wrong hostname @dengqian Fix tcp proxy close the connection abnormally @dengqian Fix the lack of default configuration of mixer filter, resulting in a nil pointer reference @glyasai Fix HTTP2 direct response not setting Content-length correctly @wangfakang Fix the nil pointer reference in getAPISourceEndpoint @dylandee Fix memory increase caused by too many Timer applications when Write is piled up @champly Fix the problem of missing stats when Dubbo Filter receives an illegal response @champly  ","excerpt":"We are happy to announce the release of MOSN v0.19.0.\nv0.19.0 Optimization  Use the latest TLS …","ref":"https://mosn.io/en/blog/releases/v0.19.0/","title":"Announcing MOSN v0.19.0"},{"body":"We are happy to announce the release of MOSN v0.18.0.\nv0.18.0 New Features  Add MOSN configure extension @nejisama Add MOSN configuration tool mosn/configure, improve user configure experience @cch123  Optimization  Avoid copying http response body @wangfakang Upgrade github.com/TarsCloud/TarsGo package, to v1.1.4 @champly Add test for various connpool @cch123 Use sync.Pool to reduce memory cost by TLS connection outBuf @cch123 Reduce xprotocol lock area @cch123 Remove useless parameter of network.NewClientConnection method, remove ALPN detection in Dispatch method of struct streamConn @nejisama Add TerminateStream API to StreamReceiverFilterHandler, with which stream can be reset during handling @nejisama Add client TLS fallback @nejisama Fix TLS HashValue in host @nejisama Fix disable_log admin api typo @nejisama  Bug fixes  Fix go mod tidy failing @champly Fix ResourceExhausted: grpc: received message larger than max when MOSN receive \u0026gt; 4M XDS messages @champly Fix fault tolerance unit-test @wangfakang Fix MOSN reconfig fails when MOSNConfig.servers[].listeners[].bind_port is false @alpha-baby Set timeout for local write buffer send, avoid goroutine leak @cch123 Fix deadloop when TLS timeout @nejisama Fix data isn\u0026rsquo;t modified by SetData method in dubbo.Frame struct @lxd5866  ","excerpt":"We are happy to announce the release of MOSN v0.18.0.\nv0.18.0 New Features  Add MOSN configure …","ref":"https://mosn.io/en/blog/releases/v0.18.0/","title":"Announcing MOSN v0.18.0"},{"body":"We are happy to announce the release of MOSN v0.17.0.\nv0.17.0 New Features  Add header max size configuration option. @wangfakang Add protocol impement choice whether need workerpool mode. And support workerpool mode concurrent configuration. @cch123 Add UDS feature for listener. @CodingSinger Add dubbo protocol use xDS httproute config filter. @champly  Optimization  Optimiza http situation buffer malloc. @wangfakang Optimize RWMutex for SDS StreamClient. @nejisama Update hessian2 v1.7.0 lib. @cch123 Modify NewStream interface, use callback replace direct. @cch123 Refactor XProtocol connect pool, support pingpong mode, mutiplex mode and bind mode. @cch123 Optimize XProtocol mutiplex mode, support Host max connect configuration. @cch123 Optimize route regex config avoid dump unuse config. @wangfakang  Bug fixes  Fix README ant logo invalid address. @wangfakang Fix header override content when set a longer header to request header. @cch123 Fix Dubbo protocol analysis attachment maybe panic. @champly  ","excerpt":"We are happy to announce the release of MOSN v0.17.0.\nv0.17.0 New Features  Add header max size …","ref":"https://mosn.io/en/blog/releases/v0.17.0/","title":"Announcing MOSN v0.17.0"},{"body":"We are happy to announce the release of MOSN v0.16.0.\nv0.16.0 Optimization  Logger Roller supports the custom Roller. @wenxuwan Add a SendHijackReplyWithBody API for streamFilter. @wenxuwan The configuration adds option of turning off the smooth upgrade. If the smooth upgrade is turned off, different instances of MOSN can be started on the same machine. @cch123+ Optimize the MOSN integration test framework and add more unit test cases. @nejisama @wangfakang @taoyuanyuan DirectResponse route configuration supports the update mode of XDS. @wangfakang Add a new field of TLSContext for clusterManager configuration. @nejisama  Bug fixes  Fix the bug that UDP connection timeout during the smooth upgrade will cause an endless loop. @dengqian Fix the bug that call DirectResponse in the SendFilter will cause an endless loop. @taoyuanyuan Fix concurrency conflicts in HTTP2 stream counting. @wenxuwan Fix the bug that UDP connection read timeout cause data loss. @dengqian Fix the bug that the response StatusCode cannot be recorded correctly due to the loss of the protocol flag when doing a retry. @dengqian Fix the protocol boltv2 decode error. @nejisama Fix the bug that listener cannot be restarted automatically when listener panic. @alpha-baby Fix the bug that NoCache flag is invalid in variable. @wangfakang Fix concurrency conflicts in SDS reconnect. @nejisama  ","excerpt":"We are happy to announce the release of MOSN v0.16.0.\nv0.16.0 Optimization  Logger Roller supports …","ref":"https://mosn.io/en/blog/releases/v0.16.0/","title":"Announcing MOSN v0.16.0"},{"body":"We are happy to announce the release of MOSN v0.15.0, congratulations to Deng Qian (@dengqian) on becoming a MOSN Committer and thanks for her contribution to the MOSN community.\nv0.15.0 New Features  Routing Path Rewrite supports configuring the content of Rewrite by regular expression @liangyuanpeng Configure new fields: Extended configuration fields, you can start the configuration by extending the configuration fields; Dubbo service discovery configuration via extended configuration fields @cch123 New DSL feature for easy control of request processing behavior @wangfakang Extended implementation of StreamFilter with new traffic mirroring function @champly Listener configuration adds UDP support @dengqian Configuration format support YAML format parsing @GLYASAI Routing support for HTTP redirect configuration @knight42  Optimization  Istio\u0026rsquo;s stats filter for personalizing metrics based on matching criteria @wzshiming Metrics configuration support to configure the output percentage of the Histogram @champly StreamFilter New state for aborting requests directly and not responding to clients @taoyuanyuan XProtocol hijack response support carry body @champly Apache SkyWalking upgrade to version 0.5.0 arugal Upstream Connection TLS State Determination Modification to support the determination of whether a connection needs to be re-established via a TLS-configured Hash @nejisama Optimize DNS cache logic to prevent DNS flooding issues that can be caused when DNS fails @wangfakang  Bug fixes  Fix the bug that XProtocol protocols determine protocol errors in scenarios with multiple protocols when TLS encryption is enabled @nejisama Fix bug in AccessLog where variables of prefix match type don\u0026rsquo;t work @dengqian Fix bug where Listener configuration parsing is not handled correctly @nejisama Fix Router/Cluster bug that fails to save when the Name field contains a path separator in the file persistence configuration type @nejisama  ","excerpt":"We are happy to announce the release of MOSN v0.15.0, congratulations to Deng Qian (@dengqian) on …","ref":"https://mosn.io/en/blog/releases/v0.15.0/","title":"Announcing MOSN v0.15.0"},{"body":"We are happy to announce the release of MOSN v0.14.0. Congratulations to Changyu Yao (@trainyao) for becoming a MOSN Committer and thank him for his contribution to the MOSN community.\nv0.14.0 New Features  Support for Istio 1.5.X @wangfakang @trainyao @champly  go-control-plane upgrade to version 0.9.4 xDS support for ACK, new Metrics for xDS. Istio sourceLabels filtering support probe interface with pilot-agent support support for more startup parameters, adapting to Istio agent startup scenarios gzip, strict-dns, original-dst support for xDS updates. Remove Xproxy Logic   Maglev Load Balancing Algorithm Support @trainyao New connection pool implementation for supporting message class requests @cch123 New Metrics for TLS Connection Switching @nejisama Metrics for adding HTTP StatusCode @dengqian Add Metrics Admin API output @dengqian New interface to query the number of current requests for proxy @zonghaishang Support for HostRewrite Header @liangyuanpeng  Optimization  Upgrade tars dependencies to fix compilation issues with higher versions of Golang @wangfakang xDS Configuration Analysis Upgrade Adaptation Istio 1.5.x @wangfakang Optimize log output from proxy @wenxuwan DNS Cache default time changed to 15s @wangfakang HTTP Parameter Route Matching Optimization @wangfakang Upgrade the fasthttp library @wangfakang Optimizing Dubbo Request Forwarding Encoding @zonghaishang Request max body configurable for HTTP support @wangfakang  Bug fixes  Fix Dubbo Decode bug that fails to parse attachment @champly Fix bug where streams could be created before HTTP2 connection is established @dunjut Fix HTTP2 Handling Trailer null pointer exception @taoyuanyuan  Fix bug where HTTP request headers are not standardized by default @nejisama Fix panic exceptions caused by disconnected connections during HTTP request processing @wangfakang Fix read/write lock copy issue with dubbo registry @champly  ","excerpt":"We are happy to announce the release of MOSN v0.14.0. Congratulations to Changyu Yao (@trainyao) for …","ref":"https://mosn.io/en/blog/releases/v0.14.0/","title":"Announcing MOSN v0.14.0"},{"body":"We are happy to announce the release of MOSN v0.13.0.\nNew Features  Support Strict DNS Cluster @dengqian Stream Filter @wangfakang that supports GZip processing Dubbo service registry complete Beta version @cch123 Stream Filter @NeGnail that supports standalone fault isolation Integrated Sentinel flow limiting capability @ansiz  Optimization  Optimize implementation of EDF LB and re-implement WRR LB using EDF @CodingSinger Configure to get ADMIN API optimizations, add features and environment variable related ADMIN API @nejisama Update that triggers a health check when updating Host changed from asynchronous mode to synchronous mode @nejisama Updated the Dubbo library to optimize the performance of Dubbo Decode @zonghaishang Optimize Metrics output in Prometheus, using regularity to filter out illegal Key @nejisama Optimize MOSN\u0026rsquo;s return status code @wangfakang  Bug fix  Fix concurrent conflict issues with health check registration callback functions @nejisama Fix the error where the configuration persistence function did not handle the null configuration correctly @nejisama Fix the problem that DUMP as a file fails when ClusterName/RouterName is too long @nejisama Fix the problem of not getting the XProtocol protocol correctly when getting it @wangfakang Fix the problem with fetching the wrong context when creating StreamFilter @wangfakang  ","excerpt":"We are happy to announce the release of MOSN v0.13.0.\nNew Features  Support Strict DNS Cluster …","ref":"https://mosn.io/en/blog/releases/v0.13.0/","title":"Announcing MOSN v0.13.0"},{"body":"We are happy to announce the release of MOSN v0.12.0. Thanks to Sun Fuze (@peacocktrain) for his great contribution to this release, certified as commiter🎉 by MOSN Community Leaders.\nYou can see the changelog below.\nNew Features  Support Skywalking @arugal Stream Filter adds a new phase of Receive Filter execution, which allows you to execute Receive Filter @wangfakang again after MOSN has finished routing Host HTTP2 supports streaming @peacocktrain @taoyuanyuan FeatureGate adds interface KnownFeatures to output current FeatureGate status @nejisama Provide a protocol-transparent way to obtain requested resources (PATH, URI, ARG), with the definition of resources defined by each protocol itself @wangfakang New load balancing algorithm  Support for ActiveRequest LB @CodingSinger Support WRR LB @nejisama    Optimize  XProtocol protocol engine optimization @neverhook  Modifies the XProtocol heartbeat response interface to support the protocol\u0026rsquo;s heartbeat response to return more information Optimize connpool for heartbeat triggering, only heartbeats will be triggered if the protocol for heartbeats is implemented   Dubbo library dependency version updated from v1.5.0-rc1 to v1.5.0 @cch123 API Adjustments, HostInfo added health check related interface @wangfakang Optimize circuit breaking function @wangfakang Responsible for balanced selection logic simplification, Hosts of the same address multiplex the same health check mark @nejisama @cch123 Optimize HTTP building logic and improve HTTP building performance @wangfakang Log rotation logic triggered from writing logs, adjusted to timed trigger @nejisama Typo fixes @xujianhai666 @candyleer  Bug Fix  Fix the xDS parsing fault injection configuration error @champly Fix the request hold issue caused by the MOSN HTTP HEAD method @wangfakang Fix a problem with missing StatusCode mappings in the XProtocol engine @neverhook Fix the bug for DirectReponse triggering retries @taoyuanyuan  ","excerpt":"We are happy to announce the release of MOSN v0.12.0. Thanks to Sun Fuze (@peacocktrain) for his …","ref":"https://mosn.io/en/blog/releases/v0.12.0/","title":"Announcing MOSN v0.12.0"},{"body":"We are happy to announce the release of MOSN v0.11.0. You can see the changelog below.\nNew features  Support the extension of Listener Filter, the transparent hijacking capability is implemented based on Listener Filter @wangfakang New Set method for variable mechanism @neverhook Added automatic retry and exception handling when SDS Client fails @pxzero Improve TraceLog and support injecting context @taoyuanyuan Added FeatureGate auto_config, when the feature is enabled, the dynamically updated configuration will be saved to the startup configuration @nejisama  Refactoring  Refactored XProtocol Engine and reimplemented SOFARPC protocol @neverhook  Removed SOFARPC Healthcheck filter and changed to xprotocol\u0026rsquo;s built-in heartbeat implementation Removed the original protocol conversion (protocol conv) support of the SOFARPC protocol, and added a new protocol conversion extension implementation capability based on stream filter xprotocol adds idle free and keepalive Protocol analysis and optimization   Modify the Encode method parameters of HTTP2 protocol @taoyuanyuan Streamlined LDS interface parameters @nejisama Modified the routing configuration model, abandoned connection_manager @nejisama  Optimization  Optimize Upstream dynamic domain name resolution mechanism @wangfakang Optimized TLS encapsulation, added error log, and modified timeout period in compatibility mode @nejisama Optimize timeout setting, use variable mechanism to set timeout @neverhook Dubbo parsing library dependency upgraded to 1.5.0 @cch123 Reference path migration script adds OS adaptation @taomaree  Bug fix  Fix the problem of losing query string during HTTP2 protocol forwarding @champly  ","excerpt":"We are happy to announce the release of MOSN v0.11.0. You can see the changelog below.\nNew features …","ref":"https://mosn.io/en/blog/releases/v0.11.0/","title":"Announcing MOSN v0.11.0"},{"body":"Why use MOSN instead of Istio\u0026rsquo;s default data plane? Before the Service Mesh transformation, we have expected that as the next generation of Ant Group\u0026rsquo;s infrastructure, Meshization will inevitably bring revolutionary changes and evolution costs. We have a very ambitious blueprint: ready to integrate the original network and middleware various capabilities have been re-precipitated and polished to create a low-level platform for the next-generation architecture of the future, which will carry the responsibility of various service communications.\nThis is a long-term planning project that takes many years to build and meets the needs of the next five or even ten years, and cooperates to build a team that spans business, SRE, middleware, and infrastructure departments. We must have a network proxy forwarding plane with flexible expansion, high performance, and long-term evolution. Nginx and Envoy have a very long-term capacity accumulation and active community in the field of network agents. We have also borrowed from other excellent open source network agents such as Nginx and Envoy. At the same time, we have enhanced research and development efficiency and flexible expansion. Mesh transformation involves a large number of departments and R \u0026amp; D personnel. We must consider the landing cost of cross-team cooperation. Therefore, we have developed a new network proxy MOSN based on Go in the cloud-native scenario. For Go\u0026rsquo;s performance, we also did a full investigation and test in the early stage to meet the performance requirements of Ant Group\u0026rsquo;s services.\nAt the same time, we received a lot of feedback and needs from the end user community. Everyone has the same needs and thoughts. So we combined the actual situation of the community and ourselves to conduct the research and development of MOSN from the perspective of satisfying the community and users. We believe that the open source competition is mainly competition between standards and specifications. We need to make the most suitable implementation choice based on open source standards.\nWhat is the difference between MOSN and Envoy? What are the advantages of MOSN? Differences in language stacks\nMOSN is written in Go. Go has strong guarantees in terms of production efficiency and memory security. At the same time, Go has an extensive library ecosystem in the cloud-native era. The performance is acceptable and usable in the Service Mesh scenario. Therefore, MOSN has a lower intellectual cost for companies and individuals using languages such as Go and Java.\nDifferentiation of core competence\n MOSN supports a multi-protocol framework, and users can easily access private protocols with a unified routing framework; Multi-process plug-in mechanism, which can easily extend the plug-ins of independent MOSN processes through the plug-in framework, and do some other management, bypass and other functional module extensions; Transport layer national secret algorithm support with Chinese encryption compliance;  Is the open source MOSN the same version as the MOSN used internally by Ant Group? First of all, there is no so-called independent MOSN version inside Ant Group. Ant Group has many modules developed based on MOSN, and the internal modules rely on the open source version of MOSN. The research and development of business-independent MOSN core capabilities are carried out directly on the open source version.\nWhat is the difference between the open source and commercial versions of MOSN? Ant Group has commercial Mesh products. Commercial products mainly provide a complete solution from development to delivery runtime. At the same time, in order to meet the business needs of enterprise users, MOSN will be extended, so the so-called MOSN commercial version It mainly carries the version of the business user\u0026rsquo;s own business module.\nWhat is MOSN\u0026rsquo;s open source plan? The release cycle of MOSN open source is one month. We are about to announce Roadmap for 2020, and we look forward to co-building with more enterprises.\nWhat version of Istio does MOSN support? When will it be available in Istio? MOSN currently runs the bookinfo example based on Istio 1.5.2. In September 2020, Istio is expected to fully support the capabilities of Istio and become an integral part of Istio Sidecar deployment options available. Please join the MOSN community to learn about working with Istio.\nWhat service registration and discovery mechanisms does MOSN support? MOSN mainly supports two service registration and discovery mechanisms: one is to directly adapt to Istio, and the other is to integrate the SDK and use it with different registration centers and configuration centers.\nHow to participate in the MOSN open source community? Join the MOSN slack worksapce https://mosnproxy.slack.com to participate in the open source community. You can also visit the Community repository to learn about the organizational structure of the MOSN open source community and to obtain community materials.\n","excerpt":"Why use MOSN instead of Istio\u0026rsquo;s default data plane? Before the Service Mesh transformation, we …","ref":"https://mosn.io/en/docs/faq/","title":"FAQ"},{"body":"We are happy to announce the release of MOSN v0.10.0. You can see the changelog below.\nNew features  Support multi-process plugin mode (#979, @taoyuanyuan) Startup parameters support service-meta parameters (#952, @trainyao) Supports abstract UDS mode to mount SDS socket  Refactoring  Separate some MOSN base library code into mosn.io/pkg package Separate MOSN interface definition to mosn.io/api package  Optimization  The log basic module is separated into mosn.io/pkg, and the log of MOSN is optimized Optimize FeatureGate (#927, @nejisama) Added processing when failed to get SDS configuration When CDS deletes a cluster dynamically, it will stop the health check corresponding to the cluster The callback function when SDS triggers certificate update adds certificate configuration as a parameter  Bug fixes  Fixed a memory leak issue when SOFARPC Oneway request failed Fixed the issue of 502 error when receiving non-standard HTTP response Fixed possible conflicts during DUMP configuration Fixed the error of Request and Response Size of TraceLog statistics Fixed write timeout failure due to concurrent write connections Fixed serialize bug Fixed the problem that the memory reuse buffer is too large when the connection is read, causing the memory consumption to be too high Optimize Dubbo related implementation in XProtocol  ","excerpt":"We are happy to announce the release of MOSN v0.10.0. You can see the changelog below.\nNew features …","ref":"https://mosn.io/en/blog/releases/v0.10.0/","title":"Announcing MOSN v0.10.0"},{"body":"","excerpt":"","ref":"https://mosn.io/en/index.json","title":""},{"body":"We are happy to announce the release of MOSN v1.4.0.\nv1.4.0 New Features  Support record HTTP health check log (#2096) @dengqian Add least_connection load balancer (#2184) @dengqian Add API to force reconnect and send ADS request (#2183) @dengqian Support pprof debug server endpoint configure (#2202) @dengqian Integrate with mosn.io/envoy-go-extension, consult document (#2200) @antJack (#2222) @3062 Add API to support override registration (mosn/pkg#72) @antJack Add a field in variables to record mosn processing time (#2235) @z2z23n0 Support setting cluster idle_timeout to zero to indicate never timeout (#2197) @antJack  Refactoring  Move pprof import to pkg/mosn (#2216) @3062  Optimization  Reduce logging for proxywasm benchmarks (#2189) @Crypt Keeper  Bug fixes  Enlarge UDP DNS resolve buffer (#2201) @dengqian Fix the debug server not inherited during smooth upgrade (#2204) @dengqian Fix where new mosn would delete reconfig.sock when smooth upgrade failed (#2205) @dengqian Fix HTTP health check URL with query string will be unescaped (#2207) @dengqian Fix lb ReqRoundRobin fails to choose host when index exceeds hosts length (#2209) @dengqian Fix the problem that after RDS creates a route, the established connection cannot find the route (#2199) @dengqian (#2210) @3062 Fix old cache values are read after the execution of Variable.Set (mosn/pkg#73) @antJack Fix panic caused by DefaultRoller not setting time (mosn/pkg#74) @dengqian Advance the timing of metrics initialization to make it work for static config (#2221) @dengqian Fix a concurrency problem caused by multiple health checkers sharing rander (#2228) @dengqian Set HTTP/1.1 as the HTTP protocol to be sent upstream (#2225) @dengqian Completing the missing statistics (#2215) @3062  ","excerpt":"We are happy to announce the release of MOSN v1.4.0.\nv1.4.0 New Features  Support record HTTP health …","ref":"https://mosn.io/en/blog/releases/v1.4.0/","title":"Announcing MOSN v1.4.0"},{"body":"We are happy to announce the release of MOSN v1.5.0.\nv1.5.0 New Features  EdfLoadBalancer supports slow start mode (#2178) @jizhuozhi Support cluster exclusive connectionPool (#2281) @yejialiango LeastActiveRequest and LeastActiveConnection load balancers support setting active_request_bias (#2286) @jizhuozhi Support configuration of metric sampler (#2261) @jizhuozhi Add PeakEWMA load balancer (#2253) @jizhuozhi  Changes  README update partners \u0026amp; users (#2245) @doujiang24 Update dependencies (#2242) (#2248) (#2249) @dependabot Upgrade the floor Go version supported by MOSN to 1.18 (#2288) @muyuan0  Optimization  Use logical clock to make edf scheduler more stable (#2229) @jizhuozhi Change log level on missing proxy_on_delete from ERROR to WARN in proxywasm (#2246) @codefromthecrypt Receiver names are different for connection object (#2262) @diannaowa Disable over strict linters in workflow (#2259) @jizhuozhi Disable workflow when PR in draft mode (#2269) @diannaowa Use pointer to avoid overhead of duffcopy and duffzero (#2272) @jizhuozhi Remove unnecessary imports (#2292) @spacewander CI add goimports check (#2297) @spacewander  Bug fixes  Fix panic caused by different hosts using the same rander during health check (#2240) @dengqian Fix connpool binding conn id (#2263) @antJack Fix saved client stream protocol information to DownStreamProtocol in the context (#2270) @nejisama Fix not using the correct Go version for testing (#2288) @muyuan0 Fix incorrectly assume the variable not found if the real value is \u0026lsquo;-\u0026rsquo; (#2174) @3062 Fix nil interface panic caused by cluster certificate configuration error (#2291) @3062 Fix parsing error caused by using interface type in the leastActiveRequestLoadBalancer configuration (#2284) @jizhuozhi Fix configuration lbConfig not effective (#2299) @3062 Fix activeRequestBias missing default value and some naming case error (#2298) @jizhuozhi  ","excerpt":"We are happy to announce the release of MOSN v1.5.0.\nv1.5.0 New Features  EdfLoadBalancer supports …","ref":"https://mosn.io/en/blog/releases/v1.5.0/","title":"Announcing MOSN v1.5.0"},{"body":"We are happy to announce the release of MOSN v1.6.0.\nv1.6.0 New Features  PeakEWMA supports configuring activeRequestBias (#2301) @jizhuozhi gRPC filter supports UDS (#2309) @wenxuwan Support init inherit old mosn config function (#2241) @dengqian Allow custom proxy defaultRouteHandlerName (#2308) @fibbery  Changes  Example http-sample README adding configuration file link (#2226) @mimani68 Update wazero to 1.2.1 (#2254) @codefromthecrypt Update dependencies (#2230) (#2233) (#2247) (#2302) (#2326) (#2332) (#2333) @dependabot  Refactoring  Refactor debug log content, move data into tracef (#2316) @antJack  Optimization  Optimize the default EWMA of newly added hosts (#2301) @jizhuozhi PeakEwma LB no longer counts error responses (#2323) @jizhuozhi  Bug fixes  Fix edfScheduler incorrectly fixing weight to 1 in dynamic load algorithm (#2306) @jizhuozhi Fix unstable LB behavior caused by changing the order of cluster hosts (#2258) @dengqian Fix panic caused by missing EWMA() method in NilMetrics (#2310) @antJack (#2312) @jizhuozhi Fix panic caused by empty cluster hosts when xDS is updated (#2314) @dengqian Fix reboot failure due to undeleted UDS socket file when MOSN exits abnormally (#2318) @wenxuwan Fix xDS status code not converted error. Fix unhandled istio inbound IPv6 address error (#2144) @kkrrsq Fix new connection error when Listener does not close directly during graceful exit of non-hot upgrade (#2234) @hui-cha Fix goimports lint error (#2313) @spacewander  ","excerpt":"We are happy to announce the release of MOSN v1.6.0.\nv1.6.0 New Features  PeakEWMA supports …","ref":"https://mosn.io/en/blog/releases/v1.6.0/","title":"Announcing MOSN v1.6.0"},{"body":"This is the blog section. It has two categories: News and Releases.\nFiles in these directories will be listed in reverse chronological order.\n","excerpt":"This is the blog section. It has two categories: News and Releases.\nFiles in these directories will …","ref":"https://mosn.io/en/blog/","title":"Blog"},{"body":"MOSN is an open source project that anyone in the community can use, improve, and enjoy. It was open-sourced by Ant Group on July, 2018. We\u0026rsquo;d love you to join us! Here\u0026rsquo;s a few ways to find out what\u0026rsquo;s happening and get involved.\nCommunity materials For more materials about MOSN community, please go to the community repo.\nWorking groups MOSN including the following working groups now.\n Istio Working Group Dubbo Working Group  Choose to join a working group that interests you and start your MOSN journey!\nCommunity meeting MOSN community holds regular meetings.\n  Wednesday 8:00 PM CST(Beijing) every other week\n  Meeting notes\n  Partners Partners participate in MOSN co-development to make MOSN better.\n               End Users The MOSN users.\n                                                  Please leave a comment here to tell us your scenario to make MOSN better!\nEcosystem The MOSN community actively embraces the open source ecosystem and has established good relationships with the following open source communities.\n                        Committers The MOSN Community Certified Committer is as follows.\n   Name GitHub 公司     Yang Tian taoyuanyuan Ant Group   Fakang Wang wangfakang Ant Group   Peng Bai nejisama Ant Group   Chunhui Cao cch123 Ant Group   Fuze Sun peacocktrain zhipin.com   Peng Chen champly dmall.com   Changyu Yao trainyao youmi.net   Qian Deng dengqian Alibaba Cloud   Runhao Huang glyasai goodrain   Zechao Zheng CodingSinger ByteDance   Jianhao Fu AlphaBaby JD.com   Zhuozhi Ji jizhuozhi JDL    Committer is an individual with MOSN repository write access to the following criteria.\n Individuals who can make sustained contributions to issues, PR over time. Participate in the maintenance of issue lists and discussion of important features. Active participation in code reviews and community meetings.  Meetup https://github.com/mosn/meetup\nTutorials See MOSN tutorials.\nCommunication Communicate with MOSN developers on DingTalk, scan the the QR code below ","excerpt":"MOSN is an open source project that anyone in the community can use, improve, and enjoy. It was …","ref":"https://mosn.io/en/docs/community/","title":"Community"},{"body":"  #td-cover-block-0 { background-image: url(/en/featured-background_hu82ae0439b5aa134274e6954a2aec5274_285821_960x540_fill_q75_catmullrom_top.jpg); } @media only screen and (min-width: 1200px) { #td-cover-block-0 { background-image: url(/en/featured-background_hu82ae0439b5aa134274e6954a2aec5274_285821_1920x1080_fill_q75_catmullrom_top.jpg); } }  Modular Open Smart Network Learn More   Download   The Cloud-Native Network Proxy Platform\n\n        What is MOSN?  MOSN (Modular Open Smart Network) is a cloud-native network proxy written in Go language. It is open sourced by Ant Group and verified by hundreds of thousands of production containers in 11.11 global shopping festival. MOSN provides the capabilities of multiple protocol, modularity, intelligent and security. It integrates a large number of cloud-native components, and also integrates a Envoy network library, which is high-performance and easy to expand. MOSN and Istio can be integrated to build Service Mesh, and can also be used as independent L4/L7 load balancers, API gateways, cloud native Ingress, and etc.   MOSN enriches the CNCF Cloud Native Landscape.      Any questions? Features request, ask questions or report bugs? Feel free to file a issue.\n   Contributions welcome! We do a Pull Request contributions workflow on GitHub. New users are always welcome!\n   Follow us on Twitter! For announcement of latest features etc on @MosnProxy.\n     This is the second Section     -- ","excerpt":"#td-cover-block-0 { background-image: …","ref":"https://mosn.io/en/","title":"MOSN"},{"body":"","excerpt":"","ref":"https://mosn.io/en/search/","title":"Search Results"},{"body":"MOSN tutorials use Killercoda as an online environment to provide interactive learning without having to deploy your own environment. To experience it, visit MOSN Tutorials on Killercoda.\nCourses list Here are the courses we have supported in the list.\n MOSN with Istio Istio with MOSN adapt dubbo MOSN with SkyWalking  Contributing The MOSN tutorial source code is located at [mosn/mosn-tutorial](https:// github.com/mosn/mosn-tutorial) repository. To contribute, read the [Contribution Guide](https://github.com/mosn/mosn-tutorial /blob/master/contributing.md).\n","excerpt":"MOSN tutorials use Killercoda as an online environment to provide interactive learning without …","ref":"https://mosn.io/en/docs/tutorial/","title":"Tutorial"}]