You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@dubbo.apache.org by GitBox <gi...@apache.org> on 2018/07/27 07:47:38 UTC
[GitHub] ralf0131 closed pull request #61: Update blog post about using
Dubbo with Sentinel
ralf0131 closed pull request #61: Update blog post about using Dubbo with Sentinel
URL: https://github.com/apache/incubator-dubbo-website/pull/61
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/blog/en-us/sentinel-introduction-for-dubbo.md b/blog/en-us/sentinel-introduction-for-dubbo.md
new file mode 100644
index 0000000..de91f8d
--- /dev/null
+++ b/blog/en-us/sentinel-introduction-for-dubbo.md
@@ -0,0 +1,104 @@
+# Sentinel: The flow sentinel of Dubbo services
+
+In large clusters there may be thousands of Dubbo service instances in production, with continuous traffic coming in. However, in distributed systems, some services may be unavailable due to various of failure such as traffic surge, high system load, and network latency. If no control actions are performed, this may cause cascading failure, affecting the availability of the service. So we need a powerful library - Sentinel, which can guarantee the stability of the service, to protect the Dubbo service.
+
+## Introduction to Sentinel
+
+[Sentinel](https://github.com/alibaba/Sentinel) is a powerful library opensourced by Alibaba Middleware Team. Sentinel takes "**flow**" as the breakthrough point, and covers multiple fields including flow control, concurrency, circuit breaking and load protection to protect service stability.
+
+There are mainly three features in Sentinel:
+
+- **Flow Control**: Sentinel can control the traffic flow of resource calls based on different runtime metrics (such as QPS, number of threads, system load, etc.), for different invocation paths, and adjust random traffic to appropriate shapes (e.g. uniform speed).
+- **Circuit Breaking**: When a resource in the invocation chain is unstable (average RT increase or exception ratio increase), Sentinel will fast-fail the call request for this resource to avoid affecting other resources, causing cascade failure.
+- **System Load Protection**: Sentinel can be used to protect your server in case the system load goes too high. It helps you to achieve a good balance between system load and incoming requests.
+
+The commonly used circuit breaker/isolation library in production is [Netflix Hystrix](https://github.com/Netflix/Hystrix). Hystrix focuses on the concept of isolation, which isolates dependencies (that is resource in Sentinel) through thread pools or semaphores. The benefit of Hystrix thread pool isolation is that the isolation is thorough, but the downside is that you have to create a lot of thread pools, pre-divide dependencies, and allocate thread pools to each dependency. Sentinel provides another idea for resource isolation: it is controlled by **the number of concurrent threads**. In this way, developer does not need to specify the size of the thread pool in advance, and there is less loss of thread context switching. When the resource is in an unstable state, the response time becomes longer and the number of threads gradually increases. When the number of threads of a resource is raised to a threshold, traffic flow limit is triggered until the stacked thread completes the task and then continues to accept the requests.
+
+Hystrix uses Circuit Breaker Pattern to automatically fast-fail the service when exception ratio exceeds the threshold. Sentinel's circuit breaking feature is more versatile, which supports two metrics: average response time and failure ratio. Sentinel also provides various invocation chain path and flow control effects support, as well as the ability to adjust the traffic in real time according to the system load to protect the system. At the same time, Sentinel also provides a real-time monitoring API and dashboard, which allows developers to quickly understand the current state of the system and understand the stability of the service. The scenarios are more abundant.
+
+## Best Practice for using Dubbo with Sentinel
+
+[Sentinel Dubbo Adapter](https://github.com/dubbo/dubbo-sentinel-support) provides service consumer filter and provider filter for Dubbo services. We can add the following dependency in `pom.xml` (if you are using Maven):
+
+```xml
+<dependency>
+ <groupId>com.alibaba.csp</groupId>
+ <artifactId>sentinel-dubbo-adapter</artifactId>
+ <version>x.y.z</version>
+</dependency>
+```
+
+The two filters are enabled by default. Once you add the dependency, the Dubbo services and methods will become protected resources in Sentinel, which can leverage Sentinel's flow control and guard ability when rules are configured. If you don't want to enable the filter, you can manually disable it. For example:
+
+```java
+@Bean
+public ConsumerConfig consumerConfig() {
+ ConsumerConfig consumerConfig = new ConsumerConfig();
+ consumerConfig.setFilter("-sentinel.dubbo.consumer.filter");
+ return consumerConfig;
+}
+```
+
+We've provided sereval demos, you can check here: [sentinel-demo-dubbo](https://github.com/alibaba/Sentinel/tree/master/sentinel-demo/sentinel-demo-dubbo)。
+
+### Service Provider
+
+Dubbo service providers provide services for outside world and handle requests from consumers. To protect the service provider from suffering the proliferation of traffic flow, you can set flow rules in **QPS mode** to the service provider. Thus, when the number of requests per second exceeds the threshold, new requests are automatically rejected.
+
+The flow control for Dubbo services has two granularities: service interface and service method.
+
+- Service interface：resourceName format is `interfaceName`，e.g. `com.alibaba.csp.sentinel.demo.dubbo.FooService`
+- Service method：resourceName format is `interfaceName:methodSignature`，e.g. `com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String)`
+
+For the detail of flow rule configuration and flow control, please refer to [Flow Control | Sentinel](https://github.com/alibaba/Sentinel/wiki/Flow-Control).
+
+Let's take a look at the effect of the QPS flow control. Assume that we have a service interface `com.alibaba.csp.sentinel.demo.dubbo.FooService`, which contains a method `sayHello(java.lang.String)`. We set flow rule for service provider (QPS count = 10). Then we do RPC 15 times at service consumer continuously in 1s. We can see the blocked metrics in the log. The log of blocked calls is located in `~/logs/csp/sentinel-block.log`：
+
+```
+2018-07-24 17:13:43|1|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String),FlowException,default,|5,0
+```
+
+Log messages will also appear in provider's metric log：
+
+```
+1532423623000|2018-07-24 17:13:43|com.alibaba.csp.sentinel.demo.dubbo.FooService|15|0|15|0|3
+1532423623000|2018-07-24 17:13:43|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String)|10|5|10|0|0
+```
+
+In many circumstances, it's also significant to control traffic flow based on the **caller**. For example, assuming that there are two services A and B, both of them initiate remote call requests to the service provider. If we want to limit the calls from service B only, we can set the `limitApp` of flow rule as the identifier of service B (e.g. service name). The Sentinel Dubbo Adapter will automatically resolve the Dubbo consumer's *application name* as the caller's name (`origin`), and will bring the caller's name when doing resource protection. If `limitApp` of flow rules is not configured (`default`), flow control will take effects on all callers. If `limitApp` of a flow rule is configured with a caller, then the corresponding flow rule will only take effect on the specific caller.
+
+> Note: Dubbo consumer does not provide its Dubbo application name when doing RPC, so developers should manually put the application name into *attachment* at consumer side, then extract it at provider side. Sentinel Dubbo Adapter has implemented a filter where consumer can carry application name information to provider automatically. If the counsmer does not use Sentinel Dubbo Adapter but requires flow control based on caller, developers can manually put the application name into attachment with the key `dubboApplication`.
+
+The `sentinel-block.log` will also record caller name. For example:
+
+```
+2018-07-25 16:26:48|1|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String),FlowException,default,demo-consumer|5,0
+```
+
+The `demo-consumer` in the log is the caller name (origin).
+
+### Service Consumer
+
+Dubbo service consumers act as a client to invoke the remote service. Each service may depend on several downstream services. If a service A depends on the downstream service B, and service B is unstable (i.e. the response time becomes longer), the number of threads where service A invokes service B will accumulate, thus may eventually run out of service A's thread pool. We use the thread count to control access to downstream service B. This can ensure service itself not affected by others when downstream services are not stable and reliable. Based on this scenario, it is recommended to set flow rules with **thread count mode** to consumers so that it's not affected by unstable services.
+
+The thread-count-based flow control mode does not require us to explicitly perform thread pool isolation. Sentinel will control the number of threads of the resource, and the excess requests will be rejected directly until the stacked tasks are completed.
+
+### Sentinel Dashboard
+
+For ease of use, Sentinel provides a Dashboard for configuring rules, viewing monitoring metrics, machine discovery, and more. We only need to start the dashborad according to the [Sentinel dashboard documentation](https://github.com/alibaba/Sentinel/wiki/Dashboard), then add the appropriate parameters to the corresponding application and launch it. For example, the startup parameters of the service provider demo in this article is:
+
+```bash
+-Djava.net.preferIPv4Stack=true -Dcsp.sentinel.api.port=8720 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=dubbo-provider-demo
+```
+
+After launching the service provider demo, we can find our application in the Sentinel dashboard. It's convenient to configure the rules in the dashboard：
+
+
+
+Or view real-time metrics：
+
+
+
+## Summary
+
+This blog post only introduces the simplest scenario in Sentinel - Traffic Flow Control. Sentinel can handle more complex scenarios like circuit breaking, cold starting and uniform traffic flow. For more scenarios, you can dig into [Sentinel Wiki](https://github.com/alibaba/Sentinel/wiki).
diff --git a/blog/zh-cn/sentinel-introduction-for-dubbo.md b/blog/zh-cn/sentinel-introduction-for-dubbo.md
index 280f95a..bd96178 100644
--- a/blog/zh-cn/sentinel-introduction-for-dubbo.md
+++ b/blog/zh-cn/sentinel-introduction-for-dubbo.md
@@ -1,4 +1,4 @@
-# Sentinel: Dubbo 服务的流量哨兵
+# Sentinel 为 Dubbo 服务保驾护航
在复杂的生产环境下可能部署着成千上万的 Dubbo 服务实例，流量持续不断地进入，服务之间进行相互调用。但是分布式系统中可能会因流量激增、系统负载过高、网络延迟等一系列问题，导致某些服务不可用，如果不进行相应的控制可能导致级联故障，影响服务的可用性，因此我们需要一个能够保障服务稳定性的利器 —— Sentinel，来为 Dubbo 服务保驾护航。
@@ -18,7 +18,7 @@ Hystrix 熔断降级功能采用熔断器模式，在某个服务失败比率高
## Sentinel 与 Dubbo 整合的最佳实践
-Sentinel 提供了与 Dubbo 整合的模块 - [Sentinel Dubbo Adapter](https://github.com/sczyh30/alibaba-sentinel-dubbo-adapter)，主要包括针对 Service Provider 和 Service Consumer 实现的 Filter。使用时用户只需引入以下模块（以 Maven 为例）：
+Sentinel 提供了与 Dubbo 整合的模块 - [Sentinel Dubbo Adapter](https://github.com/dubbo/dubbo-sentinel-support)，主要包括针对 Service Provider 和 Service Consumer 实现的 Filter。使用时用户只需引入以下模块（以 Maven 为例）：
```xml
<dependency>
@@ -58,6 +58,18 @@ Service Provider 用于向外界提供服务，处理各个消费者的调用请
1532423623000|2018-07-24 17:13:43|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String)|10|5|10|0|0
```
+很多场景下，根据**调用方**来限流也是非常重要的。比如有两个服务 A 和 B 都向 Service Provider 发起调用请求，我们希望只对来自服务 B 的请求进行限流，则可以设置限流规则的 `limitApp` 为服务 B 的名称。Sentinel Dubbo Adapter 会自动解析 Dubbo 消费者（调用方）的 application name 作为调用方名称（`origin`），在进行资源保护的时候都会带上调用方名称。若限流规则未配置调用方（`default`），则该限流规则对所有调用方生效。若限流规则配置了调用方则限流规则将仅对指定调用方生效。
+
+> 注：Dubbo 默认通信不携带对端 application name 信息，因此需要开发者在调用端手动将 application name 置入 attachment 中，provider 端进行相应的解析。Sentinel Dubbo Adapter 实现了一个 Filter 用于自动从 consumer 端向 provider 端透传 application name。若调用端未引入 Sentinel Dubbo Adapter，又希望根据调用端限流，可以在调用端手动将 application name 置入 attachment 中，key 为 `dubboApplication`。
+
+在限流日志中会也会记录调用方的名称，如：
+
+```
+2018-07-25 16:26:48|1|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String),FlowException,default,demo-consumer|5,0
+```
+
+其中日志中的 `demo-consumer` 即为调用方名称。
+
## Service Consumer
Service Consumer 作为客户端去调用远程服务。每一个服务都可能会依赖几个下游服务，若某个服务 A 依赖的下游服务 B 出现了不稳定的情况，服务 A 请求 服务 B 的响应时间变长，从而服务 A 调用服务 B 的线程就会产生堆积，最终可能耗尽服务 A 的线程数。我们通过用并发线程数来控制对下游服务 B 的访问，来保证下游服务不可靠的时候，不会拖垮服务自身。基于这种场景，推荐给 Consumer 配置**线程数模式**的限流，来保证自身不被不稳定服务所影响。限流粒度同样可以是服务接口和服务方法两种粒度。
diff --git a/md_json/blog.json b/md_json/blog.json
index 8bd12f8..c6b021b 100644
--- a/md_json/blog.json
+++ b/md_json/blog.json
@@ -38,7 +38,7 @@
},
{
"filename": "sentinel-introduction-for-dubbo.md",
- "__html": "<h1>Sentinel: Dubbo 服务的流量哨兵</h1>\n<p>在复杂的生产环境下可能部署着成千上万的 Dubbo 服务实例，流量持续不断地进入，服务之间进行相互调用。但是分布式系统中可能会因流量激增、系统负载过高、网络延迟等一系列问题，导致某些服务不可用，如果不进行相应的控制可能导致级联故障，影响服务的可用性，因此我们需要一个能够保障服务稳定性的利器 —— Sentinel，来为 Dubbo 服务保驾护航。</p>\n<h2>Sentinel 介绍</h2>\n<p><a href=\"https://github.com/alibaba/Sentinel\">Sentinel</a> 是阿里中间件团队开源的，面向分布式服务架构的轻量级流量控制产品，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。</p>\n<p>Sentinel 主要功能有三部分：</p>\n<ul>\n<li>流量控制：Sentinel 可以针对不同的调用关系，以不同的运行指标（如 QPS、线程数、系统负载等）为基准，对资源调用进行流量控制，将随机的请求调整成合适的形状。</li>\n<li>熔断降级：当调用链路中某个资源出现不稳定的情况，如平均 RT 增高、异常比例升高的时候，Sentinel 会使对此资源的调用请求快速失败，避免影响其它的资源，导致级联失败。</li>\n<li>系统负载保护：Sentinel 对系统的维度提供保护。当系统负载较高的时候，如果仍持续让请求进入，可能会导致系统崩溃，无法响应。在集群环境下，网络负载均衡会把本应这台机器承载的流量转发到其它的机器上去。如果这个时候其它的机器也处在一个边缘状态的时候，这个增加的流量就会导致这台机器也崩溃，最后导致整个集群不可用。针对这个情况，Sentinel 提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。</li>\n</ul>\n<p>目前业界常用的熔断降级/隔离的库是 Netflix 的 <a href=\"https://github.com/Netflix/Hystrix\">Hystrix</a>。Hystrix 注重隔离的概念，通过线程池或信号量的方式来对依赖（即 Sentinel 中对应的资源）进行隔离。Hystrix 线程池隔离的好处是比较彻底，但是不足之处在于要开很多线程池，还要预先去划分依赖，并给每个依赖分配线程池。Sentinel 为资源隔离提供了另一种思路：通过并发线程数进行控制。这样用户就不需要预先指定线程池的大小，而且没有线程切换的损耗。当资源处于不稳定状态时，响应时间变长，线程数逐步增加。当某个资源的线程数飙高到设定的阈值时，会触发对此资源请求的限流，直到堆积的线程完成任务后再继续接收请求。</p>\n<p>Hystrix 熔断降级功能采用熔断器模式，在某个服务失败比率高时自动进行熔断。Sentinel 的熔断降级功能更为通用，支持平均响应时间与失败比率两个指标。Sentinel 还提供各种调用链路关系和流量控制效果支持，同时还可以根据系统负载去实时地调整流量来保护系统，应用场景更为丰富。同时，Sentinel 还提供了实时的监控 API 和控制台，可以方便用户快速了解目前系统的状态，对服务的稳定性了如指掌。</p>\n<h2>Sentinel 与 Dubbo 整合的最佳实践</h2>\n<p>Sentinel 提供了与 Dubbo 整合的模块 - <a href=\"https://github.com/sczyh30/alibaba-sentinel-dubbo-adapter\">Sentinel Dubbo Adapter</a>，主要包括针对 Service Provider 和 Service Consumer 实现的 Filter。使用时用户只需引入以下模块（以 Maven 为例）：</p>\n<pre><code class=\"language-xml\"><span class=\"hljs-tag\"><<span class=\"hljs-name\">dependency</span>></span>\n <span class=\"hljs-tag\"><<span class=\"hljs-name\">groupId</span>></span>com.alibaba.csp<span class=\"hljs-tag\"></<span class=\"hljs-name\">groupId</span>></span>\n <span class=\"hljs-tag\"><<span class=\"hljs-name\">artifactId</span>></span>sentinel-dubbo-adapter<span class=\"hljs-tag\"></<span class=\"hljs-name\">artifactId</span>></span>\n <span class=\"hljs-tag\"><<span class=\"hljs-name\">version</span>></span>x.y.z<span class=\"hljs-tag\"></<span class=\"hljs-name\">version</span>></span>\n<span class=\"hljs-tag\"></<span class=\"hljs-name\">dependency</span>></span>\n</code></pre>\n<p>引入此依赖后，Dubbo 的服务接口和方法（包括调用端和服务端）就会成为 Sentinel 中的资源，在配置了规则后就可以自动享受到 Sentinel 的防护能力。若不希望开启 Sentinel Dubbo Adapter 中的某个 Filter，可以手动关闭对应的 Filter，比如：</p>\n<pre><code class=\"language-java\"><span class=\"hljs-meta\">@Bean</span>\n<span class=\"hljs-function\"><span class=\"hljs-keyword\">public</span> ConsumerConfig <span class=\"hljs-title\">consumerConfig</span><span class=\"hljs-params\">()</span> </span>{\n ConsumerConfig consumerConfig = <span class=\"hljs-keyword\">new</span> ConsumerConfig();\n consumerConfig.setFilter(<span class=\"hljs-string\">\"-sentinel.dubbo.consumer.filter\"</span>);\n <span class=\"hljs-keyword\">return</span> consumerConfig;\n}\n</code></pre>\n<p>我们还提供了几个具体的 Demo，具体代码请见 <a href=\"https://github.com/alibaba/Sentinel/tree/master/sentinel-demo/sentinel-demo-dubbo\">sentinel-demo-dubbo</a>。</p>\n<h2>Service Provider</h2>\n<p>Service Provider 用于向外界提供服务，处理各个消费者的调用请求。为了保护 Provider 不被激增的流量拖垮影响稳定性，可以给 Provider 配置 <strong>QPS 模式</strong>的限流，这样当每秒的请求量超过设定的阈值时会自动拒绝多的请求。限流粒度可以是服务接口和服务方法两种粒度。若希望整个服务接口的 QPS 不超过一定数值，则可以为对应服务接口资源（resourceName 为<strong>接口全限定名</strong>）配置 QPS 阈值；若希望服务的某个方法的 QPS 不超过一定数值，则可以为对应服务方法资源（resourceName 为<strong>接口全限定名:方法签名</strong>）配置 QPS 阈值。有关配置详情请参考 <a href=\"https://github.com/alibaba/Sentinel/wiki/%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6\">流量控制 | Sentinel</a>。</p>\n<p>我们看一下这种模式的限流产生的效果。假设我们已经定义了某个服务接口 <code>com.alibaba.csp.sentinel.demo.dubbo.FooService</code>，其中有一个方法 <code>sayHello(java.lang.String)</code>，Provider 端该方法设定 QPS 阈值为 10。在 Consumer 端在 1s 之内连续发起 15 次调用，可以通过日志文件看到 Provider 端被限流。拦截日志统一记录在 <code>~/logs/csp/sentinel-block.log</code> 中：</p>\n<pre><code>2018-07-24 17:13:43|1|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String),FlowException,default,|5,0\n</code></pre>\n<p>在 Provider 对应的 metrics 日志中也有记录：</p>\n<pre><code>1532423623000|2018-07-24 17:13:43|com.alibaba.csp.sentinel.demo.dubbo.FooService|15|0|15|0|3\n1532423623000|2018-07-24 17:13:43|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String)|10|5|10|0|0\n</code></pre>\n<h2>Service Consumer</h2>\n<p>Service Consumer 作为客户端去调用远程服务。每一个服务都可能会依赖几个下游服务，若某个服务 A 依赖的下游服务 B 出现了不稳定的情况，服务 A 请求 服务 B 的响应时间变长，从而服务 A 调用服务 B 的线程就会产生堆积，最终可能耗尽服务 A 的线程数。我们通过用并发线程数来控制对下游服务 B 的访问，来保证下游服务不可靠的时候，不会拖垮服务自身。基于这种场景，推荐给 Consumer 配置<strong>线程数模式</strong>的限流，来保证自身不被不稳定服务所影响。限流粒度同样可以是服务接口和服务方法两种粒度。</p>\n<p>采用基于线程数的限流模式后，我们不需要再显式地去进行线程池隔离，Sentinel 会控制资源的线程数，超出的请求直接拒绝，直到堆积的线程处理完成。</p>\n<p>我们看一下这种模式的效果。假设当前服务 A 依赖两个远程服务方法 <code>sayHello(java.lang.String)</code> 和 <code>doAnother()</code>。前者远程调用的响应时间 为 1s-1.5s之间，后者 RT 非常小（30 ms 左右）。服务 A 端设两个远程方法 thread count 为 5。然后每隔 50 ms 左右向线程池投入两个任务，作为消费者分别远程调用对应方法，持续 10 次。可以看到 <code>sayHello</code> 方法被限流 5 次，因为后面调用的时候前面的远程调用还未返回（RT 高）；而 <code>doAnother()</code> 调用则不受影响。线程数目超出时快速失败能够有效地防止自己被慢调用所影响。</p>\n<h2>Sentinel Dashboard</h2>\n<p>Sentinel 还提供 API 用于获取实时的监控信息，对应文档见<a href=\"https://github.com/alibaba/Sentinel/wiki/%E5%AE%9E%E6%97%B6%E7%9B%91%E6%8E%A7\">此处</a>。为了便于使用，Sentinel 还提供了一个控制台（Dashboard）用于配置规则、查看监控、机器发现等功能。我们只需要按照 <a href=\"https://github.com/alibaba/Sentinel/wiki/%E6%8E%A7%E5%88%B6%E5%8F%B0\">Sentinel 控制台文档</a> 启动控制台，然后给对应的应用程序添加相应参数并启动即可。比如本文中 Service Provider 示例的启动参数：</p>\n<pre><code class=\"language-bash\">-Djava.net.preferIPv4Stack=<span class=\"hljs-literal\">true</span> -Dcsp.sentinel.api.port=8720 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=dubbo-provider-demo\n</code></pre>\n<p>这样在启动 Service Provider 示例以后，就可以在 Sentinel 控制台中找到我们的应用了。可以很方便地在控制台中配置限流规则：</p>\n<p><img src=\"../../img/blog/sentinel-dashboard-view-rules.png\" alt=\"规则配置\"></p>\n<p>或者查看实时监控数据：</p>\n<p><img src=\"../../img/blog/sentinel-dashboard-metrics.png\" alt=\"秒级实时监控\"></p>\n<h2>总结</h2>\n<p>以上介绍的只是 Sentinel 的一个最简单的场景 —— 限流。Sentinel 还可以处理更复杂的各种情况，比如超时熔断、冷启动、请求匀速等。可以参考 <a href=\"https://github.com/alibaba/Sentinel/wiki/%E4%B8%BB%E9%A1%B5\">Sentinel 文档</a>，更多的场景等待你去挖掘！</p>\n"
+ "__html": "<h1>Sentinel 为 Dubbo 服务保驾护航</h1>\n<p>在复杂的生产环境下可能部署着成千上万的 Dubbo 服务实例，流量持续不断地进入，服务之间进行相互调用。但是分布式系统中可能会因流量激增、系统负载过高、网络延迟等一系列问题，导致某些服务不可用，如果不进行相应的控制可能导致级联故障，影响服务的可用性，因此我们需要一个能够保障服务稳定性的利器 —— Sentinel，来为 Dubbo 服务保驾护航。</p>\n<h2>Sentinel 介绍</h2>\n<p><a href=\"https://github.com/alibaba/Sentinel\">Sentinel</a> 是阿里中间件团队开源的，面向分布式服务架构的轻量级流量控制产品，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。</p>\n<p>Sentinel 主要功能有三部分：</p>\n<ul>\n<li>流量控制：Sentinel 可以针对不同的调用关系，以不同的运行指标（如 QPS、线程数、系统负载等）为基准，对资源调用进行流量控制，将随机的请求调整成合适的形状。</li>\n<li>熔断降级：当调用链路中某个资源出现不稳定的情况，如平均 RT 增高、异常比例升高的时候，Sentinel 会使对此资源的调用请求快速失败，避免影响其它的资源，导致级联失败。</li>\n<li>系统负载保护：Sentinel 对系统的维度提供保护。当系统负载较高的时候，如果仍持续让请求进入，可能会导致系统崩溃，无法响应。在集群环境下，网络负载均衡会把本应这台机器承载的流量转发到其它的机器上去。如果这个时候其它的机器也处在一个边缘状态的时候，这个增加的流量就会导致这台机器也崩溃，最后导致整个集群不可用。针对这个情况，Sentinel 提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。</li>\n</ul>\n<p>目前业界常用的熔断降级/隔离的库是 Netflix 的 <a href=\"https://github.com/Netflix/Hystrix\">Hystrix</a>。Hystrix 注重隔离的概念，通过线程池或信号量的方式来对依赖（即 Sentinel 中对应的资源）进行隔离。Hystrix 线程池隔离的好处是比较彻底，但是不足之处在于要开很多线程池，还要预先去划分依赖，并给每个依赖分配线程池。Sentinel 为资源隔离提供了另一种思路：通过并发线程数进行控制。这样用户就不需要预先指定线程池的大小，而且没有线程切换的损耗。当资源处于不稳定状态时，响应时间变长，线程数逐步增加。当某个资源的线程数飙高到设定的阈值时，会触发对此资源请求的限流，直到堆积的线程完成任务后再继续接收请求。</p>\n<p>Hystrix 熔断降级功能采用熔断器模式，在某个服务失败比率高时自动进行熔断。Sentinel 的熔断降级功能更为通用，支持平均响应时间与失败比率两个指标。Sentinel 还提供各种调用链路关系和流量控制效果支持，同时还可以根据系统负载去实时地调整流量来保护系统，应用场景更为丰富。同时，Sentinel 还提供了实时的监控 API 和控制台，可以方便用户快速了解目前系统的状态，对服务的稳定性了如指掌。</p>\n<h2>Sentinel 与 Dubbo 整合的最佳实践</h2>\n<p>Sentinel 提供了与 Dubbo 整合的模块 - <a href=\"https://github.com/dubbo/dubbo-sentinel-support\">Sentinel Dubbo Adapter</a>，主要包括针对 Service Provider 和 Service Consumer 实现的 Filter。使用时用户只需引入以下模块（以 Maven 为例）：</p>\n<pre><code class=\"language-xml\"><span class=\"hljs-tag\"><<span class=\"hljs-name\">dependency</span>></span>\n <span class=\"hljs-tag\"><<span class=\"hljs-name\">groupId</span>></span>com.alibaba.csp<span class=\"hljs-tag\"></<span class=\"hljs-name\">groupId</span>></span>\n <span class=\"hljs-tag\"><<span class=\"hljs-name\">artifactId</span>></span>sentinel-dubbo-adapter<span class=\"hljs-tag\"></<span class=\"hljs-name\">artifactId</span>></span>\n <span class=\"hljs-tag\"><<span class=\"hljs-name\">version</span>></span>x.y.z<span class=\"hljs-tag\"></<span class=\"hljs-name\">version</span>></span>\n<span class=\"hljs-tag\"></<span class=\"hljs-name\">dependency</span>></span>\n</code></pre>\n<p>引入此依赖后，Dubbo 的服务接口和方法（包括调用端和服务端）就会成为 Sentinel 中的资源，在配置了规则后就可以自动享受到 Sentinel 的防护能力。若不希望开启 Sentinel Dubbo Adapter 中的某个 Filter，可以手动关闭对应的 Filter，比如：</p>\n<pre><code class=\"language-java\"><span class=\"hljs-meta\">@Bean</span>\n<span class=\"hljs-function\"><span class=\"hljs-keyword\">public</span> ConsumerConfig <span class=\"hljs-title\">consumerConfig</span><span class=\"hljs-params\">()</span> </span>{\n ConsumerConfig consumerConfig = <span class=\"hljs-keyword\">new</span> ConsumerConfig();\n consumerConfig.setFilter(<span class=\"hljs-string\">\"-sentinel.dubbo.consumer.filter\"</span>);\n <span class=\"hljs-keyword\">return</span> consumerConfig;\n}\n</code></pre>\n<p>我们还提供了几个具体的 Demo，具体代码请见 <a href=\"https://github.com/alibaba/Sentinel/tree/master/sentinel-demo/sentinel-demo-dubbo\">sentinel-demo-dubbo</a>。</p>\n<h2>Service Provider</h2>\n<p>Service Provider 用于向外界提供服务，处理各个消费者的调用请求。为了保护 Provider 不被激增的流量拖垮影响稳定性，可以给 Provider 配置 <strong>QPS 模式</strong>的限流，这样当每秒的请求量超过设定的阈值时会自动拒绝多的请求。限流粒度可以是服务接口和服务方法两种粒度。若希望整个服务接口的 QPS 不超过一定数值，则可以为对应服务接口资源（resourceName 为<strong>接口全限定名</strong>）配置 QPS 阈值；若希望服务的某个方法的 QPS 不超过一定数值，则可以为对应服务方法资源（resourceName 为<strong>接口全限定名:方法签名</strong>）配置 QPS 阈值。有关配置详情请参考 <a href=\"https://github.com/alibaba/Sentinel/wiki/%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6\">流量控制 | Sentinel</a>。</p>\n<p>我们看一下这种模式的限流产生的效果。假设我们已经定义了某个服务接口 <code>com.alibaba.csp.sentinel.demo.dubbo.FooService</code>，其中有一个方法 <code>sayHello(java.lang.String)</code>，Provider 端该方法设定 QPS 阈值为 10。在 Consumer 端在 1s 之内连续发起 15 次调用，可以通过日志文件看到 Provider 端被限流。拦截日志统一记录在 <code>~/logs/csp/sentinel-block.log</code> 中：</p>\n<pre><code>2018-07-24 17:13:43|1|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String),FlowException,default,|5,0\n</code></pre>\n<p>在 Provider 对应的 metrics 日志中也有记录：</p>\n<pre><code>1532423623000|2018-07-24 17:13:43|com.alibaba.csp.sentinel.demo.dubbo.FooService|15|0|15|0|3\n1532423623000|2018-07-24 17:13:43|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String)|10|5|10|0|0\n</code></pre>\n<p>很多场景下，根据<strong>调用方</strong>来限流也是非常重要的。比如有两个服务 A 和 B 都向 Service Provider 发起调用请求，我们希望只对来自服务 B 的请求进行限流，则可以设置限流规则的 <code>limitApp</code> 为服务 B 的名称。Sentinel Dubbo Adapter 会自动解析 Dubbo 消费者（调用方）的 application name 作为调用方名称（<code>origin</code>），在进行资源保护的时候都会带上调用方名称。若限流规则未配置调用方（<code>default</code>），则该限流规则对所有调用方生效。若限流规则配置了调用方则限流规则将仅对指定调用方生效。</p>\n<blockquote>\n<p>注：Dubbo 默认通信不携带对端 application name 信息，因此需要开发者在调用端手动将 application name 置入 attachment 中，provider 端进行相应的解析。Sentinel Dubbo Adapter 实现了一个 Filter 用于自动从 consumer 端向 provider 端透传 application name。若调用端未引入 Sentinel Dubbo Adapter，又希望根据调用端限流，可以在调用端手动将 application name 置入 attachment 中，key 为 <code>dubboApplication</code>。</p>\n</blockquote>\n<p>在限流日志中会也会记录调用方的名称，如：</p>\n<pre><code>2018-07-25 16:26:48|1|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String),FlowException,default,demo-consumer|5,0\n</code></pre>\n<p>其中日志中的 <code>demo-consumer</code> 即为调用方名称。</p>\n<h2>Service Consumer</h2>\n<p>Service Consumer 作为客户端去调用远程服务。每一个服务都可能会依赖几个下游服务，若某个服务 A 依赖的下游服务 B 出现了不稳定的情况，服务 A 请求 服务 B 的响应时间变长，从而服务 A 调用服务 B 的线程就会产生堆积，最终可能耗尽服务 A 的线程数。我们通过用并发线程数来控制对下游服务 B 的访问，来保证下游服务不可靠的时候，不会拖垮服务自身。基于这种场景，推荐给 Consumer 配置<strong>线程数模式</strong>的限流，来保证自身不被不稳定服务所影响。限流粒度同样可以是服务接口和服务方法两种粒度。</p>\n<p>采用基于线程数的限流模式后，我们不需要再显式地去进行线程池隔离，Sentinel 会控制资源的线程数，超出的请求直接拒绝，直到堆积的线程处理完成。</p>\n<p>我们看一下这种模式的效果。假设当前服务 A 依赖两个远程服务方法 <code>sayHello(java.lang.String)</code> 和 <code>doAnother()</code>。前者远程调用的响应时间 为 1s-1.5s之间，后者 RT 非常小（30 ms 左右）。服务 A 端设两个远程方法 thread count 为 5。然后每隔 50 ms 左右向线程池投入两个任务，作为消费者分别远程调用对应方法，持续 10 次。可以看到 <code>sayHello</code> 方法被限流 5 次，因为后面调用的时候前面的远程调用还未返回（RT 高）；而 <code>doAnother()</code> 调用则不受影响。线程数目超出时快速失败能够有效地防止自己被慢调用所影响。</p>\n<h2>Sentinel Dashboard</h2>\n<p>Sentinel 还提供 API 用于获取实时的监控信息，对应文档见<a href=\"https://github.com/alibaba/Sentinel/wiki/%E5%AE%9E%E6%97%B6%E7%9B%91%E6%8E%A7\">此处</a>。为了便于使用，Sentinel 还提供了一个控制台（Dashboard）用于配置规则、查看监控、机器发现等功能。我们只需要按照 <a href=\"https://github.com/alibaba/Sentinel/wiki/%E6%8E%A7%E5%88%B6%E5%8F%B0\">Sentinel 控制台文档</a> 启动控制台，然后给对应的应用程序添加相应参数并启动即可。比如本文中 Service Provider 示例的启动参数：</p>\n<pre><code class=\"language-bash\">-Djava.net.preferIPv4Stack=<span class=\"hljs-literal\">true</span> -Dcsp.sentinel.api.port=8720 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=dubbo-provider-demo\n</code></pre>\n<p>这样在启动 Service Provider 示例以后，就可以在 Sentinel 控制台中找到我们的应用了。可以很方便地在控制台中配置限流规则：</p>\n<p><img src=\"../../img/blog/sentinel-dashboard-view-rules.png\" alt=\"规则配置\"></p>\n<p>或者查看实时监控数据：</p>\n<p><img src=\"../../img/blog/sentinel-dashboard-metrics.png\" alt=\"秒级实时监控\"></p>\n<h2>总结</h2>\n<p>以上介绍的只是 Sentinel 的一个最简单的场景 —— 限流。Sentinel 还可以处理更复杂的各种情况，比如超时熔断、冷启动、请求匀速等。可以参考 <a href=\"https://github.com/alibaba/Sentinel/wiki/%E4%B8%BB%E9%A1%B5\">Sentinel 文档</a>，更多的场景等待你去挖掘！</p>\n"
},
{
"filename": "spring-boot-dubbo-start-stop-analysis.md",
@@ -69,6 +69,10 @@
{
"filename": "qcon-beijing-2018.md",
"__html": "<h2>Dubbo roadmap is announced in QCon Beijing 2018</h2>\n<p>Ian Luo has delivered a great talk at QCon Beijing 2018, where the roadmap of Dubbo has also be announced. Please enjoy the <a href=\"https://github.com/dubbo/awesome-dubbo/raw/master/slides/qcon2018/dubbo-present-and-future.pdf\">slides</a>!</p>\n"
+ },
+ {
+ "filename": "sentinel-introduction-for-dubbo.md",
+ "__html": "<h1>Sentinel: The flow sentinel of Dubbo services</h1>\n<p>In large clusters there may be thousands of Dubbo service instances in production, with continuous traffic coming in. However, in distributed systems, some services may be unavailable due to various of failure such as traffic surge, high system load, and network latency. If no control actions are performed, this may cause cascading failure, affecting the availability of the service. So we need a powerful library - Sentinel, which can guarantee the stability of the service, to protect the Dubbo service.</p>\n<h2>Introduction to Sentinel</h2>\n<p><a href=\"https://github.com/alibaba/Sentinel\">Sentinel</a> is a powerful library opensourced by Alibaba Middleware Team. Sentinel takes "<strong>flow</strong>" as the breakthrough point, and covers multiple fields including flow control, concurrency, circuit breaking and load protection to protect service stability.</p>\n<p>There are mainly three features in Sentinel:</p>\n<ul>\n<li><strong>Flow Control</strong>: Sentinel can control the traffic flow of resource calls based on different runtime metrics (such as QPS, number of threads, system load, etc.), for different invocation paths, and adjust random traffic to appropriate shapes (e.g. uniform speed).</li>\n<li><strong>Circuit Breaking</strong>: When a resource in the invocation chain is unstable (average RT increase or exception ratio increase), Sentinel will fast-fail the call request for this resource to avoid affecting other resources, causing cascade failure.</li>\n<li><strong>System Load Protection</strong>: Sentinel can be used to protect your server in case the system load goes too high. It helps you to achieve a good balance between system load and incoming requests.</li>\n</ul>\n<p>The commonly used circuit breaker/isolation library in production is <a href=\"https://github.com/Netflix/Hystrix\">Netflix Hystrix</a>. Hystrix focuses on the concept of isolation, which isolates dependencies (that is resource in Sentinel) through thread pools or semaphores. The benefit of Hystrix thread pool isolation is that the isolation is thorough, but the downside is that you have to create a lot of thread pools, pre-divide dependencies, and allocate thread pools to each dependency. Sentinel provides another idea for resource isolation: it is controlled by <strong>the number of concurrent threads</strong>. In this way, developer does not need to specify the size of the thread pool in advance, and there is less loss of thread context switching. When the resource is in an unstable state, the response time becomes longer and the number of threads gradually increases. When the number of threads of a resource is raised to a threshold, traffic flow limit is triggered until the stacked thread completes the task and then continues to accept the requests.</p>\n<p>Hystrix uses Circuit Breaker Pattern to automatically fast-fail the service when exception ratio exceeds the threshold. Sentinel's circuit breaking feature is more versatile, which supports two metrics: average response time and failure ratio. Sentinel also provides various invocation chain path and flow control effects support, as well as the ability to adjust the traffic in real time according to the system load to protect the system. At the same time, Sentinel also provides a real-time monitoring API and dashboard, which allows developers to quickly understand the current state of the system and understand the stability of the service. The scenarios are more abundant.</p>\n<h2>Best Practice for using Dubbo with Sentinel</h2>\n<p><a href=\"https://github.com/dubbo/dubbo-sentinel-support\">Sentinel Dubbo Adapter</a> provides service consumer filter and provider filter for Dubbo services. We can add the following dependency in <code>pom.xml</code> (if you are using Maven):</p>\n<pre><code class=\"language-xml\"><span class=\"hljs-tag\"><<span class=\"hljs-name\">dependency</span>></span>\n <span class=\"hljs-tag\"><<span class=\"hljs-name\">groupId</span>></span>com.alibaba.csp<span class=\"hljs-tag\"></<span class=\"hljs-name\">groupId</span>></span>\n <span class=\"hljs-tag\"><<span class=\"hljs-name\">artifactId</span>></span>sentinel-dubbo-adapter<span class=\"hljs-tag\"></<span class=\"hljs-name\">artifactId</span>></span>\n <span class=\"hljs-tag\"><<span class=\"hljs-name\">version</span>></span>x.y.z<span class=\"hljs-tag\"></<span class=\"hljs-name\">version</span>></span>\n<span class=\"hljs-tag\"></<span class=\"hljs-name\">dependency</span>></span>\n</code></pre>\n<p>The two filters are enabled by default. Once you add the dependency, the Dubbo services and methods will become protected resources in Sentinel, which can leverage Sentinel's flow control and guard ability when rules are configured. If you don't want to enable the filter, you can manually disable it. For example:</p>\n<pre><code class=\"language-java\"><span class=\"hljs-meta\">@Bean</span>\n<span class=\"hljs-function\"><span class=\"hljs-keyword\">public</span> ConsumerConfig <span class=\"hljs-title\">consumerConfig</span><span class=\"hljs-params\">()</span> </span>{\n ConsumerConfig consumerConfig = <span class=\"hljs-keyword\">new</span> ConsumerConfig();\n consumerConfig.setFilter(<span class=\"hljs-string\">\"-sentinel.dubbo.consumer.filter\"</span>);\n <span class=\"hljs-keyword\">return</span> consumerConfig;\n}\n</code></pre>\n<p>We've provided sereval demos, you can check here: <a href=\"https://github.com/alibaba/Sentinel/tree/master/sentinel-demo/sentinel-demo-dubbo\">sentinel-demo-dubbo</a>。</p>\n<h3>Service Provider</h3>\n<p>Dubbo service providers provide services for outside world and handle requests from consumers. To protect the service provider from suffering the proliferation of traffic flow, you can set flow rules in <strong>QPS mode</strong> to the service provider. Thus, when the number of requests per second exceeds the threshold, new requests are automatically rejected.</p>\n<p>The flow control for Dubbo services has two granularities: service interface and service method.</p>\n<ul>\n<li>Service interface：resourceName format is <code>interfaceName</code>，e.g. <code>com.alibaba.csp.sentinel.demo.dubbo.FooService</code></li>\n<li>Service method：resourceName format is <code>interfaceName:methodSignature</code>，e.g. <code>com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String)</code></li>\n</ul>\n<p>For the detail of flow rule configuration and flow control, please refer to <a href=\"https://github.com/alibaba/Sentinel/wiki/Flow-Control\">Flow Control | Sentinel</a>.</p>\n<p>Let's take a look at the effect of the QPS flow control. Assume that we have a service interface <code>com.alibaba.csp.sentinel.demo.dubbo.FooService</code>, which contains a method <code>sayHello(java.lang.String)</code>. We set flow rule for service provider (QPS count = 10). Then we do RPC 15 times at service consumer continuously in 1s. We can see the blocked metrics in the log. The log of blocked calls is located in <code>~/logs/csp/sentinel-block.log</code>：</p>\n<pre><code>2018-07-24 17:13:43|1|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String),FlowException,default,|5,0\n</code></pre>\n<p>Log messages will also appear in provider's metric log：</p>\n<pre><code>1532423623000|2018-07-24 17:13:43|com.alibaba.csp.sentinel.demo.dubbo.FooService|15|0|15|0|3\n1532423623000|2018-07-24 17:13:43|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String)|10|5|10|0|0\n</code></pre>\n<p>In many circumstances, it's also significant to control traffic flow based on the <strong>caller</strong>. For example, assuming that there are two services A and B, both of them initiate remote call requests to the service provider. If we want to limit the calls from service B only, we can set the <code>limitApp</code> of flow rule as the identifier of service B (e.g. service name). The Sentinel Dubbo Adapter will automatically resolve the Dubbo consumer's <em>application name</em> as the caller's name (<code>origin</code>), and will bring the caller's name when doing resource protection. If <code>limitApp</code> of flow rules is not configured (<code>default</code>), flow control will take effects on all callers. If <code>limitApp</code> of a flow rule is configured with a caller, then the corresponding flow rule will only take effect on the specific caller.</p>\n<blockquote>\n<p>Note: Dubbo consumer does not provide its Dubbo application name when doing RPC, so developers should manually put the application name into <em>attachment</em> at consumer side, then extract it at provider side. Sentinel Dubbo Adapter has implemented a filter where consumer can carry application name information to provider automatically. If the counsmer does not use Sentinel Dubbo Adapter but requires flow control based on caller, developers can manually put the application name into attachment with the key <code>dubboApplication</code>.</p>\n</blockquote>\n<p>The <code>sentinel-block.log</code> will also record caller name. For example:</p>\n<pre><code>2018-07-25 16:26:48|1|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String),FlowException,default,demo-consumer|5,0\n</code></pre>\n<p>The <code>demo-consumer</code> in the log is the caller name (origin).</p>\n<h3>Service Consumer</h3>\n<p>Dubbo service consumers act as a client to invoke the remote service. Each service may depend on several downstream services. If a service A depends on the downstream service B, and service B is unstable (i.e. the response time becomes longer), the number of threads where service A invokes service B will accumulate, thus may eventually run out of service A's thread pool. We use the thread count to control access to downstream service B. This can ensure service itself not affected by others when downstream services are not stable and reliable. Based on this scenario, it is recommended to set flow rules with <strong>thread count mode</strong> to consumers so that it's not affected by unstable services.</p>\n<p>The thread-count-based flow control mode does not require us to explicitly perform thread pool isolation. Sentinel will control the number of threads of the resource, and the excess requests will be rejected directly until the stacked tasks are completed.</p>\n<h3>Sentinel Dashboard</h3>\n<p>For ease of use, Sentinel provides a Dashboard for configuring rules, viewing monitoring metrics, machine discovery, and more. We only need to start the dashborad according to the <a href=\"https://github.com/alibaba/Sentinel/wiki/Dashboard\">Sentinel dashboard documentation</a>, then add the appropriate parameters to the corresponding application and launch it. For example, the startup parameters of the service provider demo in this article is:</p>\n<pre><code class=\"language-bash\">-Djava.net.preferIPv4Stack=<span class=\"hljs-literal\">true</span> -Dcsp.sentinel.api.port=8720 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=dubbo-provider-demo\n</code></pre>\n<p>After launching the service provider demo, we can find our application in the Sentinel dashboard. It's convenient to configure the rules in the dashboard：</p>\n<p><img src=\"../../img/blog/sentinel-dashboard-view-rules.png\" alt=\"Rule List\"></p>\n<p>Or view real-time metrics：</p>\n<p><img src=\"../../img/blog/sentinel-dashboard-metrics.png\" alt=\"Real-time metrics monitoring\"></p>\n<h2>Summary</h2>\n<p>This blog post only introduces the simplest scenario in Sentinel - Traffic Flow Control. Sentinel can handle more complex scenarios like circuit breaking, cold starting and uniform traffic flow. For more scenarios, you can dig into <a href=\"https://github.com/alibaba/Sentinel/wiki\">Sentinel Wiki</a>.</p>\n"
}
]
}
\ No newline at end of file
diff --git a/site_config/blog.js b/site_config/blog.js
index 2b0225e..dcf1bf4 100644
--- a/site_config/blog.js
+++ b/site_config/blog.js
@@ -3,6 +3,13 @@ export default {
barText: 'Blog',
postsTitle: 'All posts',
list: [
+ {
+ title: 'Sentinel: The flow sentinel of Dubbo services',
+ author: 'Eric Zhao',
+ dateStr: 'July 27th, 2018',
+ desc: 'This blog introduces to the Sentinel and its best practice with Dubbo services. Sentinel is a powerful library that takes "flow" as the breakthrough point, and covers multiple fields including flow control, circuit breaking and load protection to guarantee service stability.',
+ link: '/blog/sentinel-introduction-for-dubbo.md',
+ },
{
title: 'Tracking with Pinpoint',
author: '@majinkai',
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org