Shulou(Shulou.com)06/02 Report--

The purpose of this article is to share with you what are the three synchronization strategies for configuring cache in Soul high availability gateways. The editor thinks it is very practical, so I hope you can learn something after reading this article. Let's take a look at it with the editor.

Preface

Gateway is the entrance of traffic request and plays a very important role in micro-service architecture. The importance of high availability of gateway is self-evident. In the process of using the gateway, in order to meet the business demands, it is often necessary to change the configuration, such as flow control rules, routing rules and so on. Therefore, the dynamic configuration of the gateway is an important factor to ensure the high availability of the gateway. So how does the Soul gateway support dynamic configuration?

Students who have used Soul know that the plug-ins of Soul are all hot-swappable, and the selectors and rules of all plug-ins are dynamically configured and take effect immediately, and there is no need to restart the service. However, in the process of using the Soul gateway, users also gave us a lot of feedback.

Rely on zookeeper, which bothers users who use etcd, consul, and nacos registries

Relying on redis and influxdb, I haven't used current-limiting plug-ins and monitoring plug-ins, so why do I need these?

So, we partially refactored Soul, and after a two-month iteration, we released version 2.0.

Data synchronization removes the strong dependence on zookeeper, adding http long polling and websocket

Current-limiting plug-ins and monitoring plug-ins achieve real dynamic configuration, from the previous yml configuration to admin background user dynamic configuration

1. Someone may ask me, why not use configuration Center for configuration synchronization?

A: first of all, the introduction of configuration center will add a lot of additional costs, whether it is operation and maintenance, and will make Soul very heavy; in addition, with configuration center, the data format is not controllable, which is not convenient for soul-admin configuration management.

two。 Maybe someone else will ask? Dynamic configuration updates? Every time I check the database, or redis, isn't that all right? What you get is the latest, where are so many things?

A: soul is used as a gateway. In order to provide higher response speed, all configurations are cached in the Hashmap of JVM, and each request is cached locally, which is very fast. Therefore, this paper can also be understood as three ways of memory synchronization in a distributed environment.

Principle analysis

Let's start with a high-definition uncoded image. The following figure shows the process of Soul data synchronization. When starting, the Soul gateway synchronizes the configuration data from the slave configuration service, and supports push-pull mode to obtain configuration change information and update the local cache. The administrator in the management background, changes users, rules, plug-ins, traffic configuration, through the push-pull mode to synchronize the change information to the Soul gateway, specifically, push mode or pull mode depends on the configuration. About the configuration synchronization module, it is actually a simplified version of the configuration center.

In version 1.x, the configuration service relies on the zookeeper implementation, and the management background push the change information to the gateway. Version 2.x supports webosocket, http and zookeeper. The corresponding synchronization policy is specified through soul.sync.strategy. By default, http long polling synchronization policy is used to achieve data synchronization in seconds. However, it is important to note that soul-web and soul-admin must use the same synchronization mechanism.

As shown in the following figure, after a configuration change occurs, soul-admin sends out a configuration change notification through EventPublisher, which is processed by EventDispatcher, and then sends the configuration to the corresponding event handler according to the configured synchronization policy (http, weboscket, zookeeper).

If it is a websocket synchronization policy, the changed data will be actively pushed to the soul-web, and at the gateway layer, the corresponding WebsocketCacheHandler processor will process the admin data push.

If it is a zookeeper synchronization policy, the change data is updated to zookeeper, and the ZookeeperSyncCache supervisor hears the data change from zookeeper and handles it.

If it is a http synchronization policy, soul-web initiates a long polling request with a default timeout of 90s. If there is no data change in soul-admin, it will block the http request. If there is a data change, it will respond to the changed data information. If there is still no data change in more than 60s, it will respond to empty data. After receiving the response, the gateway layer will continue to issue http requests and repeat the same request.

Zookeeper synchronization

The synchronization principle based on zookeeper is very simple, mainly relying on the watch mechanism of zookeeper. Soul-web will monitor the configured node. When soul-admin starts, it will write all the data to zookeeper, and when the subsequent data changes, it will incrementally update the node of zookeeper. At the same time, soul-web will listen on the node of configuration information and update the local cache when any information changes.

Soul writes configuration information to the zookeeper node through fine design.

Websocket synchronization

The mechanism of websocket is similar to that of zookeeper. When a websocket connection is established between the gateway and admin, admin will push all the data once. If the configuration data is changed later, the incremental data will be actively pushed to soul-web through websocket.

When using websocket synchronization, pay special attention to disconnecting and reconnecting, also known as maintaining a heartbeat. Soul uses java-websocket, a third-party library, for websocket connections.

Public class WebsocketSyncCache extends WebsocketCacheHandler {/ * * The Client. * / private WebSocketClient client; public WebsocketSyncCache (final SoulConfig.WebsocketConfig websocketConfig) {ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor (1, SoulThreadFactory.create ("websocket-connect", true)); client = new WebSocketClient (new URI (websocketConfig.getUrl () {@ Override public void onOpen (final ServerHandshake serverHandshake) {/ /.... } @ Override public void onMessage (final String result) {/ /.... }}; / / connect client.connectBlocking (); / / disconnect and reconnect using the scheduled thread pool, executor.scheduleAtFixedRate (()-> {if (client! = null & & client.isClosed ()) {client.reconnectBlocking ();}}, 10,30, TimeUnit.SECONDS) } http long polling

The mechanism of zookeeper and websocket data synchronization is relatively simple, while http synchronization is relatively complex. Soul draws lessons from the design ideas of Apollo and Nacos, depends on the essence, and realizes the data synchronization function of http long polling. Note that this is not the traditional ajax long polling!

The http long polling mechanism is shown above. The soul-web gateway requests the configuration service of admin, and the read timeout is 90s, which means that the gateway layer request configuration service will wait up to 90s, which facilitates the admin configuration service to respond to change data in a timely manner, thus realizing quasi-real-time push.

After the http request arrives at the sou-admin, it does not respond to the data immediately, but uses the asynchronous mechanism of Servlet3.0 to respond to the data asynchronously. First of all, the long polling request task LongPollingClient is thrown into the BlocingQueue, and the scheduling task is enabled and executed after 60s. The purpose of this is to remove the long polling request from the queue after 60s, even if the configuration data has not changed during this period. Because even if there is no configuration change, you have to let the gateway know that it cannot be left to wait, and there is a 90s timeout when the gateway requests configuration services.

Public void doLongPolling (final HttpServletRequest request, final HttpServletResponse response) {/ / because soul-web may not be notified of a configuration change, so MD5 values may be inconsistent, then immediately respond List changedGroup = compareMD5 (request); String clientIp = getRemoteIp (request); if (CollectionUtils.isNotEmpty (changedGroup)) {this.generateResponse (response, changedGroup); return } / / Servlet3.0 asynchronously responds to http requests final AsyncContext asyncContext = request.startAsync (); asyncContext.setTimeout (0L); scheduler.execute (new LongPollingClient (asyncContext, clientIp, 60));} class LongPollingClient implements Runnable {LongPollingClient (final AsyncContext ac, final String ip, final long timeoutTime) {/ / omitted. } @ Override public void run () {/ / join the scheduled task. If there is no configuration change within 60 seconds, it will be executed 60 seconds later. In response to the http request this.asyncTimeoutFuture = scheduler.schedule (()-> {/ / clients is a blocking queue), the request information clients.remove (LongPollingClient.this) of the soul-web from the source is saved. List changedGroups = HttpLongPollingDataChangedListener.compareMD5 ((HttpServletRequest) asyncContext.getRequest ()); sendResponse (changedGroups);}, timeoutTime, TimeUnit.MILLISECONDS); / / clients.add (this);}}

If the administrator changes the configuration data during this period, the long polling request in the queue will be removed one by one and respond to the data, telling which Group's data has changed (we divide the plug-in, rules, traffic configuration, and user configuration data into different groups). After receiving the response message, the gateway only knows which Group has changed its configuration, and needs to request the configuration data of that Group again. Some people may ask, why not write out the changed data directly? We also discussed this issue in depth during development, because the http long polling mechanism can only guarantee real time. If it is not processed in time at the gateway layer, or if the administrator updates the configuration frequently, it is very likely that the push of a configuration change will be missed. For security reasons, we only inform that a certain Group information has changed.

/ / soul-admin changes the configuration, remove the requests from the queue one by one, and respond to class DataChangeTask implements Runnable {DataChangeTask (final ConfigGroupEnum groupKey) {this.groupKey = groupKey;} @ Override public void run () {try {for (Iterator iter = clients.iterator (); iter.hasNext ();) {LongPollingClient client = iter.next () Iter.remove (); client.sendResponse (Collections.singletonList (groupKey));}} catch (Throwable e) {LOGGER.error ("data change error.", e);}

When the soul-web gateway layer receives the http response information, it pulls the change information (if there is any change), and then requests the configuration service of soul-admin again, and so on.

Quick use

Get soul-admin.jar

Wget https://yu199195.github.io/jar/soul-admin.jar

Start soul-admin.jar

Java-jar soul-admin.jar-Dspring.datasource.url= "your mysql url"-Dspring.datasource.username='you username'-Dspring.datasource.password='you password'

Visit: http://localhost:8887/index.html username:admin password: 123456

Get soul-bootstrap.jar

Wget https://yu199195.github.io/jar/soul-bootstrap.jar

Start soul-bootstrap.jar

Java-jar soul-bootstrap.jar

This article introduces soul as a highly available micro-service gateway, in order to optimize the response speed, in the configuration rule selector data local cache three ways, learned this article, I believe you have a certain understanding of the more popular configuration center, look at their code may become easy, I believe you can also write a distributed configuration center. Version 3.0 is already planned and will certainly bring you a surprise.

These are the three major synchronization strategies for configuring cache in Soul high availability gateways. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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