如何快速全面掌握Kafka？5000字吐血整理

Posted 2022-01-27 大数据技术架构

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了如何快速全面掌握Kafka？5000字吐血整理相关的知识，希望对你有一定的参考价值。

Kafka 是目前主流的分布式消息引擎及流处理平台，经常用做企业的消息总线、实时数据管道，本文挑选了 Kafka 的几个核心话题，帮助大家快速掌握 Kafka，包括：

Kafka 体系架构
Kafka 消息发送机制
Kafka 副本机制
Kafka 控制器
Kafka Rebalance 机制

因为涉及内容较多，本文尽量做到深入浅出，全面的介绍 Kafka 原理及核心组件，不怕你不懂 Kafka。

1. Kafka 快速入门

Kafka 是一个分布式消息引擎与流处理平台，经常用做企业的消息总线、实时数据管道，有的还把它当做存储系统来使用。早期 Kafka 的定位是一个高吞吐的分布式消息系统，目前则演变成了一个成熟的分布式消息引擎，以及流处理平台。

1.1 Kafka 体系架构

Kafka 的设计遵循生产者消费者模式，生产者发送消息到 broker 中某一个 topic 的具体分区里，消费者从一个或多个分区中拉取数据进行消费。拓扑图如下：

目前，Kafka 依靠 Zookeeper 做分布式协调服务，负责存储和管理 Kafka 集群中的元数据信息，包括集群中的 broker 信息、topic 信息、topic 的分区与副本信息等。

1.2 Kafka 术语

这里整理了 Kafka 的一些关键术语：

Producer：生产者，消息产生和发送端。

Broker：Kafka 实例，多个 broker 组成一个 Kafka 集群，通常一台机器部署一个 Kafka 实例，一个实例挂了不影响其他实例。

Consumer：消费者，拉取消息进行消费。一个 topic 可以让若干个消费者进行消费，若干个消费者组成一个 Consumer Group 即消费组，一条消息只能被消费组中一个 Consumer 消费。

Topic：主题，服务端消息的逻辑存储单元。一个 topic 通常包含若干个 Partition 分区。

Partition：topic 的分区，分布式存储在各个 broker 中，实现发布与订阅的负载均衡。若干个分区可以被若干个 Consumer 同时消费，达到消费者高吞吐量。一个分区拥有多个副本（Replica），这是Kafka在可靠性和可用性方面的设计，后面会重点介绍。

message：消息，或称日志消息，是 Kafka 服务端实际存储的数据，每一条消息都由一个 key、一个 value 以及消息时间戳 timestamp 组成。

offset：偏移量，分区中的消息位置，由 Kafka 自身维护，Consumer 消费时也要保存一份 offset 以维护消费过的消息位置。

1.3 Kafka 作用与特点

Kafka 主要起到削峰填谷（缓冲）、系统解构以及冗余的作用，主要特点有：

高吞吐、低延时：这是 Kafka 显著的特点，Kafka 能够达到百万级的消息吞吐量，延迟可达毫秒级；

持久化存储：Kafka 的消息最终持久化保存在磁盘之上，提供了顺序读写以保证性能，并且通过 Kafka 的副本机制提高了数据可靠性。

分布式可扩展：Kafka 的数据是分布式存储在不同 broker 节点的，以 topic 组织数据并且按 partition 进行分布式存储，整体的扩展性都非常好。

高容错性：集群中任意一个 broker 节点宕机，Kafka 仍能对外提供服务。

2. Kafka 消息发送机制

Kafka 生产端发送消息的机制非常重要，这也是 Kafka 高吞吐的基础，生产端的基本流程如下图所示：

主要有以下方面的设计：

2.1 异步发送

Kafka 自从 0.8.2 版本就引入了新版本 Producer API，新版 Producer 完全是采用异步方式发送消息。生产端构建的 ProducerRecord 先是经过 keySerializer、valueSerializer 序列化后，再是经过 Partition 分区器处理，决定消息落到 topic 具体某个分区中，最后把消息发送到客户端的消息缓冲池 accumulator 中，交由一个叫作 Sender 的线程发送到 broker 端。

这里缓冲池 accumulator 的最大大小由参数 buffer.memory 控制，默认是 32M，当生产消息的速度过快导致 buffer 满了的时候，将阻塞 max.block.ms 时间，超时抛异常，所以 buffer 的大小可以根据实际的业务情况进行适当调整。

2.2 批量发送

发送到缓冲 buffer 中消息将会被分为一个一个的 batch，分批次的发送到 broker 端，批次大小由参数 batch.size 控制，默认16KB。这就意味着正常情况下消息会攒够 16KB 时才会批量发送到 broker 端，所以一般减小 batch 大小有利于降低消息延时，增加 batch 大小有利于提升吞吐量。

那么生成端消息是不是必须要达到一个 batch 大小时，才会批量发送到服务端呢？答案是否定的，Kafka 生产端提供了另一个重要参数 linger.ms，该参数控制了 batch 最大的空闲时间，超过该时间的 batch 也会被发送到 broker 端。

2.3 消息重试

此外，Kafka 生产端支持重试机制，对于某些原因导致消息发送失败的，比如网络抖动，开启重试后 Producer 会尝试再次发送消息。该功能由参数 retries 控制，参数含义代表重试次数，默认值为 0 表示不重试，建议设置大于 0 比如 3。

3. Kafka 副本机制

前面提及了 Kafka 分区副本（Replica）的概念，副本机制也称 Replication 机制是 Kafka 实现高可靠、高可用的基础。Kafka 中有 leader 和 follower 两类副本。

3.1 Kafka 副本作用

Kafka 默认只会给分区设置一个副本，由 broker 端参数 default.replication.factor 控制，默认值为 1，通常我们会修改该默认值，或者命令行创建 topic 时指定 replication-factor 参数，生产建议设置 3 副本。副本作用主要有两方面：

消息冗余存储，提高 Kafka 数据的可靠性；

提高 Kafka 服务的可用性，follower 副本能够在 leader 副本挂掉或者 broker 宕机的时候参与 leader 选举，继续对外提供读写服务。

3.2 关于读写分离

这里要说明的是 Kafka 并不支持读写分区，生产消费端所有的读写请求都是由 leader 副本处理的，follower 副本的主要工作就是从 leader 副本处异步拉取消息，进行消息数据的同步，并不对外提供读写服务。

Kafka 之所以这样设计，主要是为了保证读写一致性，因为副本同步是一个异步的过程，如果当 follower 副本还没完全和 leader 同步时，从 follower 副本读取数据可能会读不到最新的消息。

3.3 ISR 副本集合

Kafka 为了维护分区副本的同步，引入 ISR（In-Sync Replicas）副本集合的概念，ISR 是分区中正在与 leader 副本进行同步的 replica 列表，且必定包含 leader 副本。

ISR 列表是持久化在 Zookeeper 中的，任何在 ISR 列表中的副本都有资格参与 leader 选举。

ISR 列表是动态变化的，并不是所有的分区副本都在 ISR 列表中，哪些副本会被包含在 ISR 列表中呢？副本被包含在 ISR 列表中的条件是由参数 replica.lag.time.max.ms 控制的，参数含义是副本同步落后于 leader 的最大时间间隔，默认10s，意思就是说如果某一 follower 副本中的消息比 leader 延时超过10s，就会被从 ISR 中排除。Kafka 之所以这样设计，主要是为了减少消息丢失，只有与 leader 副本进行实时同步的 follower 副本才有资格参与 leader 选举，这里指相对实时。

3.4 Unclean leader 选举

既然 ISR 是动态变化的，所以 ISR 列表就有为空的时候，ISR 为空说明 leader 副本也“挂掉”了，此时 Kafka 就要重新选举出新的 leader。但 ISR 为空，怎么进行 leader 选举呢？

Kafka 把不在 ISR 列表中的存活副本称为“非同步副本”，这些副本中的消息远远落后于 leader，如果选举这种副本作为 leader 的话就可能造成数据丢失。Kafka broker 端提供了一个参数 unclean.leader.election.enable，用于控制是否允许非同步副本参与 leader 选举；如果开启，则当 ISR 为空时就会从这些副本中选举新的 leader，这个过程称为 Unclean leader 选举。

前面也提及了，如果开启 Unclean leader 选举，可能会造成数据丢失，但保证了始终有一个 leader 副本对外提供服务；如果禁用 Unclean leader 选举，就会避免数据丢失，但这时分区就会不可用。这就是典型的 CAP 理论，即一个系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）中的两个。所以在这个问题上，Kafka 赋予了我们选择 C 或 A 的权利。

我们可以根据实际的业务场景选择是否开启 Unclean leader选举，这里建议关闭 Unclean leader 选举，因为通常数据的一致性要比可用性重要的多。

4. Kafka 控制器

控制器（Controller）是 Kafka 的核心组件，它的主要作用是在 Zookeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一个 broker 都能充当控制器的角色，但在运行过程中，只能有一个 broker 成为控制器。

这里先介绍下 Zookeeper，因为控制器的产生依赖于 Zookeeper 的 ZNode 模型和 Watcher 机制。Zookeeper 的数据模型是类似 Unix 操作系统的 ZNode Tree 即 ZNode 树，ZNode 是 Zookeeper 中的数据节点，是 Zookeeper 存储数据的最小单元，每个 ZNode 可以保存数据，也可以挂载子节点，根节点是 /。基本的拓扑图如下：

Zookeeper 有两类 ZNode 节点，分别是持久性节点和临时节点。持久性节点是指客户端与 Zookeeper 断开会话后，该节点依旧存在，直到执行删除操作才会清除节点。临时节点的生命周期是和客户端的会话绑定在一起，客户端与 Zookeeper 断开会话后，临时节点就会被自动删除。

Watcher 机制是 Zookeeper 非常重要的特性，它可以在 ZNode 节点上绑定监听事件，比如可以监听节点数据变更、节点删除、子节点状态变更等事件，通过这个事件机制，可以基于 ZooKeeper 实现分布式锁、集群管理等功能。

4.1 控制器选举

当集群中的任意 broker 启动时，都会尝试去 Zookeeper 中创建 /controller 节点，第一个成功创建 /controller 节点的 broker 则会被指定为控制器，其他 broker 则会监听该节点的变化。当运行中的控制器突然宕机或意外终止时，其他 broker 能够快速地感知到，然后再次尝试创建 /controller 节点，创建成功的 broker 会成为新的控制器。

4.2 控制器功能

前面我们也说了，控制器主要作用是管理和协调 Kafka 集群，那么 Kafka 控制器都做了哪些事情呢，具体如下：

主题管理：创建、删除 topic，以及增加 topic 分区等操作都是由控制器执行。

分区重分配：执行 Kafka 的 reassign 脚本对 topic 分区重分配的操作，也是由控制器实现。

Preferred leader 选举：这里有一个概念叫 Preferred replica 即优先副本，表示的是分配副本中的第一个副本。Preferred leader 选举就是指 Kafka 在某些情况下出现 leader 负载不均衡时，会选择 preferred 副本作为新 leader 的一种方案。这也是控制器的职责范围。

集群成员管理：控制器能够监控新 broker 的增加，broker 的主动关闭与被动宕机，进而做其他工作。这里也是利用前面所说的 Zookeeper 的 ZNode 模型和 Watcher 机制，控制器会监听 Zookeeper 中 /brokers/ids 下临时节点的变化。

数据服务：控制器上保存了最全的集群元数据信息，其他所有 broker 会定期接收控制器发来的元数据更新请求，从而更新其内存中的缓存数据。

从上面内容我们大概知道，控制器可以说是 Kafka 的心脏，管理和协调着整个 Kafka 集群，因此控制器自身的性能和稳定性就变得至关重要。

社区在这方面做了大量工作，特别是在 0.11 版本中对控制器进行了重构，其中最大的改进把控制器内部多线程的设计改成了单线程加事件队列的方案，消除了多线程的资源消耗和线程安全问题，另外一个改进是把之前同步操作 Zookeeper 改为了异步操作，消除了 Zookeeper 端的性能瓶颈，大大提升了控制器的稳定性。

5. Kafka 消费端 Rebalance 机制

前面介绍消费者术语时，提到了消费组的概念，一个 topic 可以让若干个消费者进行消费，若干个消费者组成一个 Consumer Group 即消费组，一条消息只能被消费组中的一个消费者进行消费。我们用下图表示Kafka的消费模型。

5.1 Rebalance 概念

就 Kafka 消费端而言，有一个难以避免的问题就是消费者的重平衡即 Rebalance。Rebalance 是让一个消费组的所有消费者就如何消费订阅 topic 的所有分区达成共识的过程，在 Rebalance 过程中，所有 Consumer 实例都会停止消费，等待 Rebalance 的完成。因为要停止消费等待重平衡完成，因此 Rebalance 会严重影响消费端的 TPS，是应当尽量避免的。

5.2 Rebalance 发生条件

关于何时会发生 Rebalance，总结起来有三种情况：

消费组的消费者成员数量发生变化

消费主题的数量发生变化

消费主题的分区数量发生变化

其中后两种情况一般是计划内的，比如为了提高消息吞吐量增加 topic 分区数，这些情况一般是不可避免的，后面我们会重点讨论如何避免因为组内消费者成员数发生变化导致的 Rebalance。

5.3 Kafka 协调器

在介绍如何避免 Rebalance 问题之前，先来认识下 Kafka 的协调器 Coordinator，和之前 Kafka 控制器类似，Coordinator 也是 Kafka 的核心组件。

主要有两类 Kafka 协调器：

组协调器（Group Coordinator）

消费者协调器（Consumer Coordinator）

Kafka 为了更好的实现消费组成员管理、位移管理，以及 Rebalance 等，broker 服务端引入了组协调器（Group Coordinator），消费端引入了消费者协调器（Consumer Coordinator）。每个 broker 启动的时候，都会创建一个 GroupCoordinator 实例，负责消费组注册、消费者成员记录、offset 等元数据操作，这里也可以看出每个 broker 都有自己的 Coordinator 组件。另外，每个 Consumer 实例化时，同时会创建一个 ConsumerCoordinator 实例，负责消费组下各个消费者和服务端组协调器之前的通信。可以用下图表示协调器原理：

客户端的消费者协调器 Consumer Coordinator 和服务端的组协调器 Group Coordinator 会通过心跳不断保持通信。

5.4 如何避免消费组 Rebalance

接下来我们讨论下如何避免组内消费者成员发生变化导致的 Rebalance。组内成员发生变化无非就两种情况，一种是有新的消费者加入，通常是我们为了提高消费速度增加了消费者数量，比如增加了消费线程或者多部署了一份消费程序，这种情况可以认为是正常的；另一种是有消费者退出，这种情况多是和我们消费端代码有关，是我们要重点避免的。

正常情况下，每个消费者都会定期向组协调器 Group Coordinator 发送心跳，表明自己还在存活，如果消费者不能及时的发送心跳，组协调器会认为该消费者已经“死”了，就会导致消费者离组引发 Rebalance 问题。这里涉及两个消费端参数：session.timeout.ms 和 heartbeat.interval.ms，含义分别是组协调器认为消费组存活的期限，和消费者发送心跳的时间间隔，其中 heartbeat.interval.ms 默认值是3s，session.timeout.ms 在 0.10.1 版本之前默认 30s，之后默认 10s。另外，0.10.1 版本还有两个值得注意的地方：

从该版本开始，Kafka 维护了单独的心跳线程，之前版本中 Kafka 是使用业务主线程发送的心跳。

增加了一个重要的参数 max.poll.interval.ms，表示 Consumer 两次调用 poll 方法拉取数据的最大时间间隔，默认值 5min，对于那些忙于业务逻辑处理导致超过 max.poll.interval.ms 时间的消费者将会离开消费组，此时将发生一次 Rebalance。

此外，如果 Consumer 端频繁 FullGC 也可能会导致消费端长时间停顿，从而引发 Rebalance。因此，我们总结如何避免消费组 Rebalance 问题，主要从以下几方面入手：

合理配置 session.timeout.ms 和 heartbeat.interval.ms，建议 0.10.1 之前适当调大 session 超时时间尽量规避 Rebalance。

根据实际业务调整 max.poll.interval.ms，通常建议调大避免 Rebalance，但注意 0.10.1 版本之前没有该参数。

监控消费端的 GC 情况，避免由于频繁 FullGC 导致线程长时间停顿引发 Rebalance。

合理调整以上参数，可以减少生产环境中 Rebalance 发生的几率，提升 Consumer 端的 TPS 和稳定性。

6. 总结

本文总结了 Kafka 体系架构、Kafka 消息发送机制、副本机制，Kafka 控制器、消费端 Rebalance 机制等各方面核心原理，通过本文的介绍，相信你已经对 Kafka 的内核知识有了一定的掌握，更多的 Kafka 原理实践后面有时间再介绍。

往期文章精选：

1、干货 | Elasticsearch 内核解析之写入流程

2、Apache Kafka 版本演进及特性介绍

3、京东JDHBase异地多活实践

4、美团点评基于 Flink 的实时数仓平台实践

如果您喜欢这篇文章，点【在看】与转发都是一种鼓励，期待得到您的认可 ❥(^_-)

清华大佬吐血整理5000字真言 | 快速学习大厂们的软件案例经验！

这篇文章主要向大家介绍吐血整理 | 快速学习大厂们的软件案例经验,主要内容包括基础应用、实用技巧、原理机制等方面，希望对大家有所帮助。

如有任何问题或建议，欢迎及时交流和碰撞。测试交流群：175317069

前几天，去了趟北京，参加了为期三天的全球软件案例研究峰会（TOP 100）。前端

同时记了一些笔记，整理后分享出来，但愿对你们有所帮助，拓展眼界很是重要。mysql

内容比较多（已经精简过），你们能够挑本身感兴趣的学习，建议三连。git

一级目录以下：github

百度内部业务 ServieMesh 实践。
云原生开发平台在腾讯游戏运营中的实践。
快狗打车可持续交付实践。
网易数帆从微服务框架到服务网格架构平滑演进及最佳实践。
不破不立：企业级研发效能提高的创新实践。
自如云原生落地最佳实践。
研发效能度量的误区、体系化实践和效能提高案例。
京东 BDP 的全域监控、管控平台搭建实践。
构建发布效率从10分钟到秒级的提高 - 云原生下编程方式的探索和实践。
全面监控体系建设及智能监控的探索实践。
低代码技术在贝壳的实践。

百度内部业务 ServieMesh 实践

本场演讲内容主要为微服务到服务网格的过程。其中涉及百度在异构场景下的一系列演进和适配操做。web

同时也能得知百度也是本身作了个 bmesh，自此归纳几乎全一线互联网大厂，均为自研（或结合）ServieMesh。redis

总体演进

1.0 时代

第一代微服务架构（1.0时代），主体是基于 SDK/开发框架的微服务治理体系。算法

主要存在如下问题：sql

开发成本高：异构语言的问题，每一个语言都要从新开发。
升级成本高：框架上线以来业务。
管理成本高：服务拓扑和治理没有统一管理（须要治理）。

2.0时代

第二代微服务架构（2.0时代），主体是基于微服务框架到服务网格，也就是把服务治理能力抽取出来，做为一个进程（sidecar），与业务逻辑解耦。shell

从概念上来说，主要分为如下两类：数据库

数据平面
- 与业务无关。
- 与语言无关。
- 独立的升级（直接升级 sidecar 的进程），可以解耦。
控制平面
- 可以统一的管控。

百度现状

各语言在内部势均力敌，没有谁强谁弱。各自都有框架，且有可能有多个框架，可自行脑补一下在公司内部一种语言有 N 种框架，且多种协议（含私有协议）的状况

存在如下问题：

多个语言开发。
多个框架改造。
多个通信协议。

简单来说就是 “异构系统”，传统的微服务框架没法知足了，成本很是高，甚至不可行。只能经过服务网关的方式来实现微服务治理。

上服务网格的困难

改形成本：
- 各类内部框架的支持。
- 各类通信协议的支持。
性能问题：
- 通信延迟，有些敏感业务没法接受，例如：搜索。
- 资源开源，数十万机器，每一个服务都加边车，成本极大。
规模问题：
- 随着接入的节点越多，规模越大，控制平面下发配置的速度越慢，甚至没法工做。

百度的解决方案（总体架构）

在开源的技术栈上进行了本身的拓展，用的是 istio+envoy。

而且在 istio 之上作了一层抽象，实现了 Mesh 的管理界面。

另外实际上在调参时，是须要不少实际经验的，例如：超时的值到底怎么配，所以又基于此在平台上提供了智能调参系统。

与目前所知的一线互联网大厂改造比较相似，区别在于还作了不少自有平台。

遇到的问题（大规模落地三步走）

解决接入问题

流量劫持方案：
- 社区自有的方案没法修改服务治理的参数（例如：致使原有的超时重试变成了对边车重试）。
- iptables 存在性能问题。
- 没法在 mesh 和非 mesh 下切换：不能彻底信任，挂掉后怎么处理，流量怎么切。解决方案是劫持服务发现的过程（边车劫持的是的服务地址），就可以解决流量劫持的自由问题。
自有协议代理：有二十多种协议，解决方案是抽了一层公共 Proxy，实现 codec 就能够了。但也无法解决所有问题，由于 Mesh 对协议有要求，例如加字段。但有的老协议是无法扩展的。最后解决方案是作协议转换，业务代码就不须要修改了。
多框架支持：网格对框架有基本要求（治理行为可拓展，透传 Trace 信息），但有的老框架无法支持。经过探针逻辑修改框架行为（探针感知逻辑，修改框架行为）。

解决性能问题

网络性能优化：
- envoy 的最大问题是性能不怎么好，拓展性是第一，性能是他的第二位。
- envoy 的多线程的竞争是很是厉害的。最后是采起 envoy+brpc 的融合方案（难度很大，组件替换，逐步替换）解决，总体延迟和 CPU 使用率明显低于原生版本。作了开关，能在原生和融合后版本切换。
网络控制面优化：
- istio 原生的配置是全量下发的，很是不科学。
- 改造为经过获取关系按需下发。服务发现改成由控制面下发到数据面。简单来说就是原生 istio 控制面在大规模下有不少问题，为此改了不少逻辑。
网络性能优化：
- istio 原生为 both side 模式，要转换 2 次，损耗 2 次网络开销，2次性能开源，内部认为不可接受。改成 client side 的模式（架构上的折中，有的业务很敏感，不推荐为主流方式）。

享受网格的红利

流量可操控：
- 全部的流量都在本身的手中，能够去作不少事情。例如作不少动态的事情，全局流控，根据延迟分配请求到不一样的下游等，带来的新的问题就是太多配置，太吃经验，所以作了哥全局智能调参。
- 结合高级治理，配合自愈和剔除，可用性的修复时间大大的提升，提升了可用性。
服务可观测：
- 结合框架透传 Trace 信息，Sidecar 负责上报监控，便可造成追踪。
自动止损
- 结合监控平台采集实例、集群信息，发现异常，上报给控制平面。而后就能够屏蔽掉某个实例、集群。实现自动止损。
异常注入
- 混沌平台负责配置、评估，服务网格负责实施异常注入。
容量管理
- 传统须要作压测，对整个系统进行很长时间的压测（想压到极限，要构造大量的数据和流量），很是麻烦。
- 经过服务网格能够在局部构造出极限的压力。

落地状况

百度目前正在逐渐落地，已接入实例数万。经过高级的服务治理（须要自实现）带来了很大的收益。

但须要注意，若是只是单纯接入服务网格，并不能带来上述所说的收益。他的收益更多的是面向后续的一些高级治理等高级场景。

总结

服务网格不是微服务治理的银弹：
- 彻底无侵入支持全部空间和治理策略的 Mesh 方案是不存在的。
- 大规模落地必定会涉及已有治理的兼容升级和改造。
服务网格确实实现了业务逻辑和服务治理架构的解耦。
服务网格的开始是最难的，落地服务网格会很是困难和艰辛。

QA

第一个：
- 新产品能够上服务网格，但要有一个现成成熟的服务网格，自研工做量是很是之大的。
第二个：
- 和开源社区结合的问题，会不按期更新 envoy，istio 的版本。
- 服务网格不能只看节省的成本，若是只是说框架的治理，那是很是小的，最大的收益是把全部的流量都汇总到一块儿后收益很是大。网格一开始会很是痛苦，须要把流量真正的拦截上去。
- 边车的定位是服务于服务之间的通信代理，与业务逻辑比较紧耦合是不适合放进去的。
- 推广的目标不是全站覆盖，核心链路上到就能够，由于有的应用对这类没什么诉求。
第三个：
- 是否 SSL 看企业场景。
第四个：
- bmesh 能够从全局角度监控，现有的监控模式可能你会是本身有问题。

云原生开发平台在腾讯游戏运营中的实践

平台的指望：提升研发效能，业务落地成长。
业务背景：营销活动，上线活动不少是不报备的，所以伸缩性要求高，日活很容易上千万。活动多（天天新增 50 个以上），数量量幅度大，服务质量要求高。
实际成效：这么大的规模，如今只须要 3 个专职运维，晚上 6 点就下班了。

本质需求

频繁发布：版本发布更新。
动态伸缩：数据量大。
持续高可用：常常变动。

运维的任务

以往都是开发提交给运维的，问题是有极多个开发对接有限的运维。面临的问题：

面临的环境，部署的东西，都是否是固定的。
开发须要转移知识给运维。
实际常常会出现意外状况。
对部署的风险：运维本能排斥变化。

呈现的结果是运维忙于救火，开发提个需求，就只能排队，线上总不稳定。

解决办法

持续交付：
- 控制产品发布节奏，需求尽快上线，不积压。
打造部署安全网：
- 微服务、并行部署，完善的监控。
实现可重复性：
- 控制环境和部署的构建，自动化，保证输入输出的同样的。
变化是必然的：
- 以故障是常态去设计。

碎片的解决方案

要解决上述所提到的问题，基本目前在业界都有基本的解决方案，但其都是 “碎片化” 的，以下：

“碎片化” 指的是不一样的组件都分别是解决特定的问题。这就致使了下述问题：

各方面的学习成本高。
系统自动化程度低。
有经验开发人员有限：
- 人员招聘成本高，限制发展规模。
无生命周期：
- 总体的上线到下线没有管理。

云原生开发平台的设计

真正的完整解决方案就是作一个 “云原生开发平台”，提供一整套的服务来支持软件的开发和运维，实现各类云原生软件的诉求。

从设计角度上来说：

运维不暴露太多的基础建设，只是开放角度去作。开发人员只须要关注应用程序，不须要关注底层的基础设施。

不须要让业务关注你用的是 k8s、envoy、gitlab 什么基础设施，不用去学习一些特定的知识体系。

资源评估中心化的运维

开发须要申请资源，运维须要评估，分配，再审核执行。最快是小时级，是平台的瓶颈。

解决方案是把资源分片，实现团队自治，开发就可能承担了部分运维以往的工做。

此时又会带来因为运维部分工做转移到开发后的成本问题，这部分就须要由平台来解决，提供下述全流程：

智能的容量评估
自动化提单/审批
自动下线（经过日志、性能、调用来识别）
自治并释放资源。

最终的成效是目前全部的审批都是业务团队本身去作，运维只负责供应资源。

微服务下的依赖问题

思考：服务 A 流量上涨，依赖的服务如何扩容？

利用 istio 作全链路分析，实现全自动化，精准识别出入流量，计算差别部分，就能知道改变的服务链路和所需放大的倍数。

实现可重复性

应用跑不起来，确定是有东西改变了：

环境控制：镜像。
构件控制：全自动化流水线，例如：代码版本、编译命令等。
运行时配置：提供配置管理，实现版本控制。

控制可运行时容器，就能够作一系列工做。系统提供默认安全，应用也就安全。

变化是必然的

面向故障设计：

多可用区可用（异地多活？）.
主机故障自愈/剔除能力。
实例守护剔除能力。
配置恢复能力。

开发阶段如何提高效率

作了个服务市场，业务应用。沉淀利用现有的能力。

总结

基础设施，团队自治，统一且自动化的交付。开发运维一体化，转移到开发的成本，要用平台来解决。

QA

第一个：
- 故障定位，看基础设施，如果软件业务逻辑，软件业务逻辑是经过平台来提供工具来支持业务排查，帮助定位，大部分仍是靠业务团队作的，如果基础设施基本都是大面积的。
第二个
- 版本一致性，必然存在，发布有前后顺序，能够走蓝绿，业务逻辑也要作一些兼容处理。
第三个
- 去抖动下发的策略，会持续监听 IP 并收集，配置下发有最小的间隔，例如十秒间隔的统一下发（存在必定延迟）。又或是到了必定数量级也会下发。不会来一发触发一条。
第四个
- 开发要对利用率关注，压测，让平台上可以自动化去帮他实现，帮助他认识，自动生成出建议的数量和规模。同时服务的流量是分高峰，平峰的，平台要有提供自动扩缩容的机制（例如：也能够作定时策略）。支持自定义指标的扩缩容，要有一个超卖的策略。
第五个
- 研发和运维的分界线，版本上线的告警目前都是由业务本身作的，代码是业务本身写的，暗含的逻辑运维必然不知道。开发要作全生命周期的跟踪。
- 统一网关不包含业务逻辑，更多的是支持公有云私有云，私有协议，一些登录。业务网关更多的是跟业务相关的。
第六个
- 长链接如何作无损发布，超过 30s 后 ipvs 感知不到链接断开，流量仍是会分过来。存在局限性，要感知协议类型（内部作了针对性的自动化断定），判断流量是否结束，若结束则转发到新的。四层仍是须要业务本身实现的。

网易数帆从微服务框架到服务网格架构平滑演进及最佳实践

介绍微服务相关的理念和服务网格的演进，前半部分很是高关注率，听众大量拍照。

后半部分主要是网易轻舟的产品和技术介绍，主要是偏向 Java 方向，所以主要是在思想上进行参考，有必定的价值意义。

从 2017 年开始进行 ServieMesh 的研究，不断进行打磨，直到 2020 年正式释出网易轻舟这一个技术产品。

为何要从微服务框架演进至服务网关

在 2012 年正式提出微服务，介绍了微服务的发展史：

1.0时代：2011-2017，以框架为表明的微服务框架。
2.0时代：2017-至今，以服务网关为表明，业务与治理解耦。

微服务框架存在的问题

适用范围。
升级成本。
侵入性。
治理能力有限。
框架负担。
架构演进与云原生相冲突（注册中心部分）。

服务网格的定义和优点

服务网格定义为服务间通信的基础设施层，经过轻量的网络代理进行拦截和处理。堪称异构语言的救星。

服务网格的技术升级改形成本

思考：我真的须要服务网格吗？

业务诉求是否只能用服务网格解决？
业务现状是否知足网格接入条件？
业务团队是否可以驾驭得了服务网格？
是否有开发配套的基础设施？

演进的成本问题

ROI 策略，作成本分析。

接入诉求

要关注业务指望收益是什么？

微服务框架和服务网格共存

微服务框架：面向应用内的服务治理。
服务网格：面向服务间的服务治理。

微服务框架和服务网格二者存在重合的区域，但又没法彻底替代：

网易轻舟的平滑演进主要是针对 Java 系，对此 JavaAgent 作了一些调整（以下业务迁移），以此来实现平滑演进。

业务迁移

微服务框架 =》融合（过分）期：存在流量管理的能力冲突 =》服务网格

逐步分离，缓慢实现技术升级。方案分为：

经过 JavaAgent 迁移。
经过网关作灰度流量迁移。

服务网格与真实的使用场景差别

设计上比较理想化，很难直接拿来给业务直接用，业务真正使用都要作定制化改造：

为了解决这些问题，网易轻舟作了如下加强：

通信协议加强支持（例如：Dubbo、Thrift）。
sidecar 的管理问题：每次的升级问题，社区方案每次都要重启 pod。网易轻舟是实现了热升级。
多场景的限流方案：社区方案的性能常被人吐槽，而且场景支持不充足。
基于服务网格的能力拓展：例如：监控。

提供微服务框架和服务网格的一体化的控制台，简单来说就是经过平台将用户的业务改形成本和学习成本和运维成本大幅度下降了。

所以平台化是解决服务网格 “成本” 的一个出路。

将来

中间件 Mesh
排障体系建设
故障演练体系

总结

认为落地过程必定是曲折的，服务网格将来必定会是光明的。

细节会是魔鬼。

QA

第一个：
- 微服务框架到服务网格的最大难点：解决服务发现的过分问题，如何把注册中心打通。
第二个：
- 2017 年开始关注投入，不断打磨，到 2020 年才出现网易轻舟。由于官方也不断在演进，他们也在不断演进。
第三个：
- 中间件 Mesh，性能影响？目前主要仍是偏向监测，访问成功，错误率，流量，使用的，偏向监控方面的设计。
第四个：
- 如今遇到的业务诉求是否必定要用服务网格去解决？以及内部是否定同服务网格？

不破不立：企业级研发效能提高的创新实践

会场全场站满，讲师颇有趣，经历丰厚，是研发效能的出品人。其介绍了许多研发效能和度量相关的知识和理念。

同时驳斥了如今业界不少的一些基本的理念，让人深思。

为何研发效能火了

为何之前研发效能都无法塞满一个会场，为何如今出现如此盛况？总的来说是时代变了，商业逻辑变了，你们对研发效能有了更大的理解：

靠信息不对称，对称后如何在研发这一侧如何快速的交付，同时要高质量，既要又要。

研发效能的五大 “灵魂拷问”

归纳研发领域的现象，以下图：

拉车的人（代指：老板）没空看轮子，不知道轮子是否是方的，而推轮子的人是咱们工程师。你知道不知道轮子是什么形状？

第一问：研发团队的忙碌可以表明高效率吗？

例如：凌晨半夜三点修 BUG 的人必定是最好的吗？BUG 颇有多是他埋的，他不修谁修？

建议方向：

架构的长期规划。
中台的持续沉淀。

第二问：敏捷是研发效能提高的银弹吗？

敏捷指的是能更快速的尝试，有问题的话立刻调头。敏捷是要作小船。

第三问：自动化测试真的提高软件质量了吗？

若是卡死自动化测试的覆盖率没意义，最后会变成覆盖率很高，走的很慢，由于让覆盖率变高有很是多种方法。

而卡死自动化测试，就会致使没有精力去作探索性测试，更多的测试。需求变了，自动化测试又变了，又要花时间继续作新的自动化测试。。

自动化测试只是个手段，不是目标。新功能不该该作自动化，功能自己趋向稳定了，才应该去作自动化测试，成本才低，成就感才高。

第四问：没有度量就没有改进，这是真的吗？

研发效能很难在真正意义上度量，软件研发是创造性的劳动，不一样的人来作是不同的，硬要作，就会变成你度量什么，工程师就作什么。

你度量钉子，那你获得的就是钉子。你度量什么，就必定会获得什么。

不要用来考量 KPI，不然千行就会变成万行，要慎重。

第五问：研发效能的提高必定是由技术驱动的吗？

不要陷入局部思惟，真正的问题不是单点的问题。

例如：看医生，真正挂号多久，但你真正花时间的是排队，看完医生1分钟，又开单验血，又等。所以等待时间是最大的。

在软件领域中，也是在等待时常上花的时间最久的。是部门墙，信息不对称致使的问题。

研发效能究竟是什么？

先有的现象，再有的结果，定义。

研发效能提高的案例

前端代码的自动化生成。
- 工程师在白板上画 UI，自动识别并生成出代码和界面（利用了 AI 的相关技术）。
临界参数下的 API 测试
- 自动的测试数据生成。
微服务架构下的环境困局。
- 公共基础环境的问题，高效的方法是作公共基础环境，也就是如今的云端环境。天天和生产环境同步。

研发效能的第一性原理

顺畅，高质量地持续交付有效价值的闭环。

作有价值的东西，作用户须要的，不要作用户不要的。
凡事作的事情能让这五个 “持续” 提升，就算研发效能。
全部的过程改进要用数听说话，但不要用来考核。

“研发效能” 的点点滴滴

研发效能的点点滴滴，作这些都能提升，针对性举例：

例如：云 IDE，很是方便。
例如：（举例 sonar）sonar 的机制为时已晚，没什么意义。能够在本地就去跑 linter，走得快质量还高。
例如：代码复杂度，最终呈现的就是软件和架构的腐化。研发工程师就开始复制粘贴改，最后没几年就废了。
例如：代码递交规范，你会把需求id带进去吗？不带的话，后面全部的度量都无法作，追踪都无法作，拿不到需求 id 都没作。
例如：分布式编译，各个模块分散到分布式去编译，从十分钟变 10 秒。

研发效能提高的一些经验和实践

推荐看书，用 MVP 思想作，和作通用工具彻底不同。

研发效能要先发现钉子，再去找锤子。和作通用工具不一样，工具是拿锤子找钉子。

研发效能通常采用逐渐扎小孔，一层层作的模式。每次给的功能点足够小，但每一次给的都有价值。

作 MVP 不是横切一刀，是包含各方面的斜切

这部份内容太太太多了，讲师也没有讲完。下方为根据讲了的部分整理：

从痛点入手：
- 测试数据的搭建统一到测试数据中台去作。
- 如研发度量的数据获取是最重要得，例如由工具自动触发状态的改变，而不须要研发工程师去调整，且得到的数据是真实有效的。
从全局切入：
- 例如：一个 BUG，真正修复的时间是多少？
用户获益：
- 让用户获益，是研发效能的核心
- 不要你觉得业务团队要，业务团队关心的是温饱问题。例如：你就看看业务团队本身有没有在搞，他们有在搞，这就说明是真的需求。
- 结构很重要，若是设计的体制要每一个人都大公无私是必然失败。每一个人越自私越自利越能成功。举了和尚分粥的例子。
- 谁接入了多少不是最重要的，是业务获得了什么。
- 服务意识，早期保姆式服务，沉淀后，就是共赢，
持续改进
- 例如：GitHook 直接调 JIRA API 不是最好的方案，没有版本管理，规模大了绝对不是好方法。
- 应该走消息队列，揭藕。平台化。
全局优化
- 下层提出，上层承认。
杜绝掩耳盗铃
- 虚荣性指标 vs 可执行指标
- 例如 sonar 接了多少个项目，就是虚荣性指标。应该考察可执行指标，例如严重 BUG 存在了多久。
吃本身的狗粮：
- 本身的产品你都不用，别人更不可能。

研发效能的将来

表达核心观点：“敏态” 和 “稳态” 必定是齐头并进的。

快狗打车可持续交付实践

主要面向测试环境治理的演讲，Devops 不是单纯的技术问题，总体来看 Devops 是一个复杂的混合问题。

理想与现实

快狗打车前期是存在固定的多套测试环境，测试环境相互影响。测试同窗 A 用完环境，次日给了测试同窗 B，B 同窗发现有问题，又找回 A。A 同窗又认为不是本身的问题：

测试环境V1

早期测试环境的具体表现，主体为稳定环境全量部署，下分四套环境，根据需求部署：

早期几十个集群还没什么问题，等到规模变大后几千个集群后问题就会很严重。同时测试人人都有管理权限，第二套变动后，会同步到稳定环境，那么其余几套环境的同步由谁负责（他们早期是手动维护）。

另外并行需求多了就会发现固定的测试环境不够用。呈现的结果是投入产出比差别过大，各配置互相影响，稳定性不好，最终形成的测试结果也不稳定。

理想的测试环境是怎么样的？

即点即用
- 任什么时候间均可以部署，并不须要排队。
自动隔离
- 任何环境都是相互隔离的。
依赖关系
- 系统自动解析，根据配置自动部署依赖上下游，使用者无需关注。
缩放自如。
- 资源池管理，资源弹性伸缩。
独立闭环
- 独立部署，无需跨部门沟通（不用找运维要资源）。

第一轮的优化实践

核心要点：规范、格式、自动。

针对各服务作依赖关系的自动解析。细则以下：

制定了配置文件的格式规范，用于扫描上下游依赖，层层扫描，最终得出总体的依赖图。
规范要符合公司现状，绝大部分都能适配，只有让小部分的人要改。
服务按照类型优先级部署，这里结合了应用信息（上层应用服务，底层应用、数据库、Redis 等）。

测试环境 V2

只有一套稳定环境，剩余的均可以按照需求来拉环境。但存在服务直连的状况，致使出现流量拦截和调动有问题。

属于企业内部自身的债务问题了，不展开赘述。

测试环境 V3

结合基础架构组，最后实现按需部署，谁开发谁部署，不改动不部署。

属于企业内部自身的历史债务问题了，不展开赘述。

总结

在治理优化实践上一共作了以下：

测试环境的服务按需部署。
依赖环境的自动解析。
部署资源池管理：评估部署所需资源，再经过资源管理平台，统一资源的调度。
自动流转与执行：Nginx（vhost、location）、域名（独立域名、泛解析）、MQ、堡垒机等的自动申请、审核。
资源自动回收：需求完成上线后，需求所关联的都自动释放，又或是回收到资源池。

总体上来说，技术不是难点，最难的是人与人的沟通，例如：跨部门的沟通，最重要的是方向、坚持、执行力。

QA

第一个：
- 测试环境数据库也没有采用按需，由于测试环境数据库不是主要痛点（矛盾点），主要权衡的是投入产出比，由于并非建起数据库就能解决的，还要造数据，各类成本很高，结合权衡没往这个方向作。
第二个：
- 资源低于 60%，则针对于已经完成上线的机器，并非资源池内的。
第三个：
- 部署的互相依赖和网状结构，经过打标签的方式，若已经部署了则不会再部署了。
第四个：
- 资源平台优化策略，目前正在转向 K8S 这类云平台，后续再也不自行关注。
第五个：
- 公共组件是否也是从新部署，目前 redis 是从新部的，主要是针对 mysql、redis。kafka 这类是没有独立部署的。
第六个：
- 最大的困难是什么，是 “人”，人的认知，达成全员的共识，为何作这件事情，讲清楚，比作什么更重要。

自如云原生落地最佳实践

主要演讲内容是自如的云原生演进之路，以下：

当时存在大量的问题，进行了调研。结果提示低 NPS（-44%），也就是 100 个里有 52 我的对 CI/CD 系统不满意。

具体的痛点：

运维人肉运维。
生产、测试环境不同。
分支合并漏发代码、漏发配置。
上线发布一台台点。
kvm CPU 使用率低。

进过调研和选型，发现开源的均有缺点，最终选择自研一站式研发平台。主体功能结构：

上层的平台服务：面向开发同窗。
下层的 K8S 等：面向 Ops 同窗。

平台在总体的设计边界和原则上以下：

边界：只作无状态应用的容器化。
原则：能放到平台的操做坚定不用人。

容器化后遇到的问题

容器化后一堆新的知识 pod、ingress、service，网络模式也变了，开发同窗都不懂，产生了大量的成本（学习、运维等）。

所以就决定了作应用平台，也就上面提到的平台服务。流程图以下：

CI/CD

定规范，统一环境。
定分支，统一分支模型。
- 在各个 feature 分支上进行开发。
- release 分支环境用于集成和发布。
Dcoker/Deployment 零配置
- 根据建立应用所填写的信息自动配置，研发不须要关心。
工具-跳板机
- 在平台上作跳板机，不须要关心 IP，也不用登录。

总结

云原平生台化，运维 0 参与。公司标准化（环境、分支等）。
不要闭门造车，统一思想，走 MVP（步子不要迈的太大）、持续运营、持续关注 NPS。

QA

第一个
- 流量染色，是为了动态的的调控服务调用。
第二个
- 数据库污染，利用帐户体系来作。同时注意 mq 这类须要隔离。
第三个
- webshell 建立 bash 不要太多，超过 32 个会有问题。产生僵尸进程。
第四个
- 微服务到云原生的成本，学习成本必然，把 dev 和 ops 放到一块儿。
第五个
- 目前自如是让业务在平台上配一个专门的探活接口，再去探活。
第六个
- 最大的阻力，就是人，CTO 把基础架构把运维放到了一块儿，造成了互补。组织结构要先调整。

研发效能度量的误区、体系化实践和效能提高案例

Devops 专题的出品人，会场火爆，所有站满。开局表示如今已经再也不是讨论要不要 Devops，而是讨论怎么去作。

讲的很好，会场人员承认度高。

研发效能的状况

你的研发效率在业界属于什么水平？与竞争对手差距？
敏捷转 Devops 的转型有没有效果？是否能够量化评估吗？

软件交付效能的度量指标

部署频率。
变动前置时间。
服务恢复时间。
变动失败率。

研发效能评估（愿景）

阿里（211）

需求 2 周内交付。
变动 1 小时内完成发布。
需求 1 周内开发完毕。

腾讯

项目团队规模扩张控制在 20 人如下
迭代周期在 1 周内

研发效能度量的原则

结果指标 > 过程指标。
全局指标 > 局部指标。
定量指标 > 定性指标。
团队指标 > 我的指标。
指导性，可牵引行动。
全面性，可互相制约。
动态性，按阶段调整。

工具链网络

Devops 工具链网络：强调 “网络”，工具与工具的关联，代码与需求，代码与合并，与编译，各类信息能不能追溯到下面全部的环节（把工具串联集成起来）。而不是单单管理某一个领域。
- 项目协做域。
- 开发域。
- 测试域。
价值流的交付模型：要从用户、客户的视角去看，从端到端的角度去看，而不是开发、测试的角度。要从完整的一个用户需求提上来每一步的具体步骤。
- 工做流。
- 生命周期。
- 流动效率（不是资源的占用率）。
效能度量分析模型：软件研发效果，最终思考的是组织效能、业务结构。
- 交付效率：需求前置时间、产研交付周期、需求吞吐量。
- 交付质量：变动成功率、线上缺陷密度、故障恢复速度。
- 交付能力：变动前置时间、部署频率。

给出了分析模型里的大量的度量考察指标，并表示企业内部有更多，几百个。但要注意度量指标不在于多，在于精。不一样阶段也不同，要有北极星指标。

你作的实践不必定表明有用，但要不断地思考和实践并改善。例如单元覆盖率，有个公司永远在 80%+，后面发现是对 KPI 战法，甚至单元测试里没有断言（多个讲师提到）。

不只要关注创造价值的工做，还要关注保护价值的工做：

业务需求。
产品需求。
研发需求。

企业内部实践

展现了京东内部的研发度量系统，看上去很是完善，能够进行多层次的下钻（事业部 -> 项目组 -> 研发人员）：

总结和避坑

成本问题：看板里的数据，如何让度量更准，那就是标准，那就须要大量培训。让需求和代码有关联，自动触发变动状态。自动化。
避免平均值陷阱：相似长尾问题，尽可能用分位数。
度量不是为了控制，而是指导改进：若是是 KPI，你度量什么就会获得什么，只是否是以你所但愿的方式获得的（古德哈特法则）。

总结：那些不懂数字的人是糟糕的，而那些只看数字的人是最最糟糕的。应该走下去看具体是什么达成的，走到工做现场，看看是否真的有改进。

京东 BDP 的全域监控、管控平台搭建实践

基本介绍

基于 Prometheus 生态进行了大量的改造：

采集端改造：PushGateway 会推数据到 Kafka，再另外消费。
模块拆解，做为不一样的角色，读写分离，便于扩展。
- 数据采集。
- 预计算。
- 数据分析。
- 监控告警，
多级缓存：监控数据的数据是短期内不会变的，会进行缓存（不一样业务可配不一样）。
kongming 服务：基于不一样的 promql 决定执行什么策略，例如：实时做业、离线任务、集群调度等。至关因而一个拓展了，高级监控治理了。

监控实践

单点监控：常见面板，
组监控：业务提供黄金指标，自动生成对应的组监控，能够作到千人前面。
关系链监控：父级节点和大表盘。

平台实践

平台提供让业务选择，业务不须要关注底层的表达式：

在更具体的实践上：

告警通知：支持父子节点的通知。
告警通知：支持告警人的动态通知，支持业务在上报指标时指定的。
高级治理：利用所拓展的 kongming 模块，作了许多基于历史数据和现状的干预，例如：实时做业干预、智能调度（削峰、自愈等）。也就是至关于 “人工智能” 的那一块相关内容了。

整体来说，作自动化也会是相似的思路，要拓展出一个模块。这样子你作什么均可以，只要基于 Prometheus 的一些表达式和数据源就能够了。

总结

监控系统不只要能发现，还要哪能解决问题，监只是手段，控才是目标。

解决各类人力问题。

淘宝系 - 云原生下编程方式的探索和实践

淘宝现状

中心化：微服务化。
去中心化：FatSDK，以 SDK 的方式提供能力。可以保障稳定性和性能。淘系绝大部分都是采起的第二种模式。出问题的话，就只有你本身的服务有问题，不会影响其余依赖方。

在 SDK 上他们只提供 Java，其余你本身想办法，常见的能够作个代理。

通用能力下沉

把原有 SDK 的能力剥离到独立的进程，而不是像本来那样沉淀在应用中：

利用云原生的容器，提供运维能力容器，业务能力容器，解决中心化的问题。在此书实际上是参照了 ServiceMesh 的方式，走 Sidecar 就行了。

解决多语言问题

加多一层，提供 GRPC API 来进行对接。对于业务来说只须要面对标准化的 API 就能够了：

业务不会直接对外对接暴露，全部东西都是经过对外/对内的中间层来进行衔接：

开发市场

作了一个应用市场，业务开发能够提供组件能力上去，避免重复造轮子：

全面监控体系建设及智能监控的探索实践

PPT 内容比较抽象，简单来说：AIOps = 大数据+算法+运维场景。

经过各项能力，建设了对于历史数据的分析，作了各类分析和告警合并等场景。每一个模块都大体讲了，但均没有深刻讲，只能大概听个响，与原有所知的监控思路基本一致。

智能运维业界目前没有开源方案，都是一线大厂分享的经验。放一张 PPT 图：

按分层自下往上看，基本是基于数据进行智能化的预示来达到效果。

低代码技术在贝壳的实践

更具体的演示效果可看平台方发的视频（指望/现状）。

提效

能覆盖到的场景基本把前端功效给去掉了，但同时后端的工做量会加大。

现状

河图1.0：已开源。定制化需求，一开始想让客户本身开发插件化，效果不行。最终决定走向智能化。
河图2.0：智能化。
- 指望：自动识别设计稿，国外有，支持多端。
- 目前：
  - 贝壳如今支持的是上传 sketch 设计稿，支持不一样的 iOS，安卓，Flutter 以及本身的小程序。
  - 支持后台管理增删改查，小程序，中后台等。
- 将来：
  - 后期会引入智能化，将会持续开源。