[rocketmq-site] branch new-official-website updated: Remove a user case and update the mse image (#517)

[ji...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

jinrongtong pushed a commit to branch new-official-website
in repository https://gitbox.apache.org/repos/asf/rocketmq-site.git


The following commit(s) were added to refs/heads/new-official-website by this push:
     new 36817796e Remove a user case and update the mse image (#517)
36817796e is described below

commit 36817796ea223df9a983ea1fdd8e365b85b2cd8c
Author: Jack Tsai <ts...@outlook.com>
AuthorDate: Mon Feb 27 10:07:07 2023 +0800

    Remove a user case and update the mse image (#517)
    
    Co-authored-by: tsaitsung-han.tht <ts...@alibaba-inc.com>
---
 blog/01xiaohongshu.md | 96 ---------------------------------------------------
 docusaurus.config.js  |  1 -
 2 files changed, 97 deletions(-)

diff --git a/blog/01xiaohongshu.md b/blog/01xiaohongshu.md
deleted file mode 100644
index 69125391e..000000000
--- a/blog/01xiaohongshu.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: 小红书消息中间件的运维实践与治理之路
-description: 小红书消息中间件的运维实践与治理之路
-hide_table_of_contents: false
----
-
-
-<!--truncate-->
-
-## 1. 消息队列业务场景与挑战
-
-### 1.1 整体规模
-
-下图展示了 RocketMQ 和 Kafka 的总体规模。其中峰值  TPS 的 8000w/s 一般出现在晚上下班以后的时间段，写入量达到50GB/s，每天新增2-3PB数据，节点数1200+个。
-
-<img src="https://tva1.sinaimg.cn/large/e6c9d24egy1h3gaz0px0oj21c40bumyo.jpg
-" alt="Example banner" />;
-
-### 1.2 业务架构
-
-虽然 RocketMQ 和 Kafka 的性能相似，但在使用场景上还是有所区别的。RocketMQ 丰富的业务特性更适用于在线业务场景，而 Kafka 的高吞吐性使其更偏向离线、近线业务。当然，在实际应用中也会有交叉使用的现象，有时在线业务也会使用 Kafka 解耦，有的流处理数据也会使用 RocketMQ 存储。
-
-业务总体架构如下图所示，业务日志和APP用户行为打点类的内容会发给 Kafka，数据库增量日志、在线业务、线上数据交换等会发给 RocketMQ。Kafka 和 RocketMQ 中的数据会有一部分流入 flink 中构建实时数仓、离线数仓以及一些数据产品（如报表、监控，等），RocketMQ 中另一部分数据会用于在线业务APP异步解耦。
-
-
-
-<img src="https://tva1.sinaimg.cn/large/e6c9d24egy1h3gb1can0cj21c60no40y.jpg
-" alt="Example banner" />;
-
-### 1.3 稳定性挑战
-a.   背景：
-小红书整体收敛消息组件较晚，公司技术架构最大的目标是提升系统稳定性；
-
-b.   挑战：
-现存消息组件使用量极大，但没有稳定性保障；同时面临人手紧缺、时间紧，对MQ原理了解不深入的困境；
-
-c.   策略：
-先做监控，增强集群的可观测能力是了解其健康状况的最高效手段。
-
-### 1.4 稳定性治理
-
-除了监控告警，我们在稳定性治理方面还做了以下改造工作：
-1. 引擎：资源隔离，新增监控打点等；
-2. 平台：工单审核，权限管控，业务追溯；
-3. 治理：针对集群可视化能力和集群可运维能力的建设；
-
-
-<img src="https://tva1.sinaimg.cn/large/e6c9d24egy1h3gb3mslkpj21680scabg.jpg
-" alt="Example banner" />;
-
-## 2. 消息队列治理实践
-
-### 2.1、集群可视化：监控metrics
-
-下图是基于 Prometheus Grafana 构建的消息中间件体系架构。
-
-
-<img src="https://tva1.sinaimg.cn/large/e6c9d24ely1h56gvs5vfij20st0gwac3.jpg
-" alt="Example banner" />;
-
-图中包含三个监控维度：硬件维度、服务维度和业务维度，累计收集监控指标150+项。
-
-那么如何定义这三个维度的监控指标呢？
-
-1. 硬件维度：主要包括网络带宽、CPU使用率、磁盘容量/IO、TCP丢包/延迟等资源指标；
-
-2. 服务维度：主要指运行状况的指标，如：宕机监控、JVM指标、读写时延、请求队列等；
-
-3. 业务维度：即面向用户的指标，这是客户比较关心的指标，如：消费延迟/积压、QPS、Topic吞吐量、Offset等；
-
-
-
-由于公司内部规定一个节点只能使用一个端口给Prometheus，而各项监控指标大多是分开收集，于是设计了指标聚合服务 MAS 将所有指标汇集在一起，同时又增加了一些元信息帮助进一步排查问题。这里 MAS 相当于metric 的一个代理层，可以根据业务的实际情况来添加。
-
-### 2.2 告警处理
-下图列举了一些发生在监控体系刚建立时候的告警信息，当时每天的告警信息约有600-700条之多，告警的问题也是各式各样，根本无法处理，造成监控系统形同虚设。
-
-
-
-<img src="https://tva1.sinaimg.cn/large/e6c9d24ely1h56gx5m8poj20bv0h9t9b.jpg" alt="Example banner"/>;
-
-鉴于以上情况，我们提出监控的核心原则要宁缺毋滥，不要淹没在告警海中，告警太多和没有告警没什么区别。根据这一原则制定了一系列应对策略：
-
-初期：关闭低优告警，以确保每一条高优告警能得到及时发现和处理；
-
-中期：随着高优告警的减少，逐步打开之前屏蔽的告警，进一步处理，实现告警数量逐步减少；
-
-后期：打开全部告警，确保日常告警每一条都能及时发现和处理。
-
-
-
-根据我们的经验，到后期基本不会有“服务不可用”这类的告警，大部分告警属于预警，如果预警能及时介入处理，就可以确保在问题进一步扩大之前解决。
-
-
-
-
diff --git a/docusaurus.config.js b/docusaurus.config.js
index ca4a0a619..c9e4e015c 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -31,7 +31,6 @@ const darkCodeTheme = require("prism-react-renderer/themes/dracula");
     scripts: [
       {
         src: '//g.alicdn.com/mamba/assets/0.0.10/mse-arc-ui.min.js',
-        async: true
       },
     ],
     stylesheets: [