To experience the growth of an open source project from the user’s perspective is the original intention of our “Developer Talk” column, which provides developers with more three-dimensional project information when selecting open source projects. Jason Joo, @Committer (Beijing), Sentinel Committer. This post is part 6 of “Developer Speak.”

1ST: An In-depth Analysis of the Transaction Coordinator for Open source Distributed Transaction Scheme Seata

2nd: High Availability Design for RocketMQ Message Sending

3ST: My Take on Message Queue Kafka and RocketMQ

4th: “How to Get involved in Defining an IDE plug-in”

5th: “NacOS-based Gateway Grayscale Routing and Service Weight Grayscale”

Integrated Sentinel prelife

Flow control in a distributed system is a more basic needs, the need to load in the system, service quality, traffic security screening, safety risk control, and according to the needs of the business, dynamically adjust or artificial temporary intervention, especially in the period of some events, in order to achieve the effect of fast control and recovery services.

Flow control devices are generally mounted on traffic gateways and logic within services.

Traffic gateway is common in Nginx proxy layer, through extension plug-ins, Lua scripts for IP/Path/Query and other forms of flow control. In the business, most semaphores, thread pools, timeouts or other logic are carried out locally or in the framework layer to achieve flow control. The former is mainly reflected in the operability of operation and maintenance and does not invade the business line, while the latter is more targeted but needs to be deployed when there is invasion or modification, which is controllable for the business team.

The two types of flow control tend to be fragmented (controlled by different teams in an unshared space) and often have incongruous indicators.

In order to solve this problem, we began to summarize the existing requirements, investigate related systems, and prepare a set of flow control implementation that can be both business oriented and operation oriented, application level isolation and meet the requirements of basic rule types. The expectation is to implement a more powerful flow control module on the Nginx side using LuaJIT.

During the investigation, Sentinel 0.1/0.2 was released at the same time. It supports servlet integration (URL flow limiting) with Dashboard, basic real-time status viewing, real-time modification of distribution rules, global load and single point fuse, and flow control based on QPS, semaphores and other forms. Except for zero intrusion, it basically meets our requirements, so we plan to try the scheme landing based on Sentinel.

Integrating Sentinel practices

Our basic needs are as follows:

  • Flow control based on URL
  • Dynamically change rules based on Dashboards
  • The business side targets SpringMVC/SpringBoot
  • Support for asynchronous servlets (presented later)
  • Sentinel-transport listening port customizable (involving firewall configuration, multiple services on the same node)

Integration adaptation Based on the functions and adaptation modes provided by Sentinel, basic configurations and modifications are required.

Integration mode Most of the traffic entry part of existing projects is based on SpringMVC, and a small part is SpringBoot project. From the perspective of operation and maintenance deployment, there are common operation mode (JVM/Tomcat) and container mode at present.

  • Normal running: Try to avoid modifying JVM startup parameters, which are defined in a central configuration center or properties file.
  • Containerized: Parameters are mostly defined by the ENV environment variable.

Therefore, we encapsulated Sentinel initialization according to actual requirements, provided XML initialization based on SpringMVC and annotation initialization based on SpringBoot, for example:

    @InitDefaults(

          projectName = "demo",

          sentinelPort = 19000,

          sentinelGroup = "test"

     )
Copy the code


Integrated block diagram



The integration points

  • Automatically determine whether Sentinel dependencies are introduced
  • Automatic configuration
  • Using ZooKeeper as the rules storage hub (reusing existing infrastructure)
  • The node supports read and write of rules
  • Integrate Sentinel-transport-netty-HTTP to support Dashboard
  • Rules are indirectly written to Zookeeper and distributed to all nodes using Dashboard’s ability to operate on a single node through the API

Sentinel-web-servlet is mainly used. With this solution, there is no need to do any secondary development of Dashboard, which can be upgraded with less intrusion to business

Expectations for Sentinel

  • Simplify flow control integration and landing in different scenarios
  • More simple and non-strict cluster traffic limiting, introducing high availability
  • Dashboard
  • Realization of Dubbo/ZooKeeper/Spring/Servlet related standard out-of-the-box

The author:

Jason Joo, Sentinel Committer, @Youlewu (Beijing), [email protected], has more than 10 years of technical practice in hardware and software systems. Java/C/Golang, data middleware/distributed system design/container scheduling familiar with TCP/IP protocol stack and optimization (* NIX), Linux kernel secondary development.


Author of this article: Middleware brother

The original link

This article is the original content of the cloud habitat community, shall not be reproduced without permission.