许多云服务厂商都有事件中心/事件总线之类的产品，例如阿里云的事件总线、Azure的事件中心，Shopee的数据事件中心等产品，分别了解下各家的事件中心类产品设计理念和使用场景，看看能借鉴哪些思路。

阿里云-事件总线

文档地址：https://help.aliyun.com/document_detail/163239.html

据官方文档简介，阿里云的事件总线以标准化的CloudEvents 1.0规范在这些应用之间路由事件，用来帮助构建松耦合、分布式的事件驱动架构。其涉及以下几个概念：

• 事件：状态变化的数据记录。
• 事件源：事件的来源，负责生产事件。
• 事件目标：事件的处理终端，负责消费事件。
• 事件总线：事件的接收者，负责存储事件。
• 事件规则：用于监控特定类型的事件。当发生匹配事件时，事件会被路由到与事件规则关联的事件目标。

特点：阿里云的事件总线这个产品主打事件路由功能，例如应用发布事件，可以通过配置路由规则实现某个步骤成功或失败（事件发生）后钉钉、邮件通知或webhook、发MQ进行后处理等（事件目标）。审计功能不强，提供了按id和按时间检索的功能。

Azure-事件中心

文档地址：https://docs.microsoft.com/zh-cn/azure/event-hubs/

Azure的事件中心和Kafka很像，甚至Api都是兼容的，可以认为是解耦的、PaaS平台版的Kafka。对比一下消息队列和事件中心的使用差异，不难看出消息队列是要求Consumer接入的，订阅的消息/事件的消费逻辑是在分布在各个服务的消费者里面实现；而事件中心则更灵活一些，将事件生成者与事件使用者分离开来。

关键组件：

• 事件生成者：向事件中心发送数据的所有实体。 事件发布者可以使用 HTTPS、AMQP 1.0 或 Apache Kafka（1.0 和更高版本）发布事件。
• 分区：每个使用者只读取消息流的特定子集或分区。
• 使用者组：整个事件中心的视图（状态、位置或偏移量）。 通过使用者组来使用应用程序时，每个应用程序都有事件流的单独视图。 使用者根据自身的步调和情况独立读取流。
• 吞吐量单位：预先购买的容量单位，控制事件中心的吞吐量容量。
• 事件接收者：从事件中心读取事件数据的所有实体。 所有事件中心使用者通过 AMQP 1.0 会话进行连接。 事件中心服务在事件变得可用时通过会话来提供事件。 所有 Kafka 使用者都通过 Kafka 协议 1.0 及更高版本进行连接。

特点：基于Kafka，兼容Kafka Producer Api，已经接入MQ的系统再接入事件中心会比较方便。完全的PaaS平台和服务解耦，支持实时捕获、处理数据。对比阿里云的事件总线，更偏向于数据流式处理、收集。

腾讯云-事件中心

文档地址：https://cloud.tencent.com/document/product/248/14361

腾讯云的事件中心是云监控产品里的一个功能，从结构图上来看和上面那些产品类似，都是有生产、消费的概念。但是腾讯云的事件中心仅限于云监控产品的一些事件，可复用性不高。

Shopee-数据事件中心

Shopee的这个事件中心主要用于数据同步，DEC (Data Event Center) 是 Shopee 的数据库事件订阅和任务执行平台，负责监听 MySQL 数据库数据变更事件，并根据用户配置对数据事件进行处理，执行数据同步、缓存同步、事件回调等不同类型的任务。

从系统架构图可以看出，其核心部分也是由Kafka完成的，生产者是MySQL，消费者是其他各个需要同步的数据源。大体设计思路和上面的事件中心类似，但是仅仅针对数据同步功能有所应用

总结

调研了上面几款事件中心类的产品，发现其大体结构和MQ还是比较像的，甚至完全兼容MQ的Api。但是其扩展能力更好，消费终端更多样化，同时PaaS的模式也一定程度上避免了业务方接入复杂的问题。事件中心的功能还是阿里云抽象的比较好，主要通过不同的规则来进行一个路由的操作。但是阿里云的审计/数据处理功能不强。基于对上面这些产品的调研，感觉我们的事件中心可以从通过规则的事件路由和审计这两方面去考虑如何设计，同时根据Azure的事件中心和Kafka的区别联系考虑与我们现有MQ、MSG等服务的关系，以及消费终端的需求收集和设计。

git rebase：对一个分支执行变基操作。常用场景：commit压缩和并行分支合并

使用 rebase 压缩 commit

在日常开发过程中，经常无法保证commit的原子性，产生了多条相同功能点或含义的commit，这种情况下在进行code review时就会带来很多麻烦，且后续如果要回滚到某个时间点也会产生困扰，影响开发效率和部署的健壮性。此时可以使用git rebase命令来对多条连续的commit进行压缩操作，保证push到远程分支上的代码保持条理性和清晰性。

以一次实际开发过程为例，使用git rebase -i HEAD~5命令对最近5条commit做修改，注意这里列出的commit时间顺序和git log列出的时间顺序是相反的（git log是最上面最新，rebase是最下面最新）：

- 阅读剩余部分 -

SkyWalking 作为一套 OpenTracing 标准的实现，其存储的数据结构也遵循 OpenTracing 的规范。

关于 OpenTracing 的语义标准，SkyWalking 的作者吴晟贡献了一篇翻译文献：OpenTracing官方标准-中文版，目前包含两个部分：

1. specification.md, OpenTracing 标准正本
2. semantic_conventions.md, 该文档描述，在常见场景下，Span进行tag、log操作时，key的使用习惯。

OpenTracing 标准提供了最基础的 APM 记录内容的语义，具体存储的数据结构下面以 SkyWalking 在ES 中的存储为例分析。

- 阅读剩余部分 -

1. 选择 Repo

nameserver: rocketmqinc/rocketmq-namesrv

broker: rocketmqinc/rocketmq-broker

查找过程中发现 rocketmqinc 官方还有一个单独的 rocketmq 仓库，但是已经很久没更新了，所以选择比较新的

2. 目录挂载映射

默认 rocketmq 日志和存储放在 home 目录，用户是 root，配置如下：

namesrv:

broker:

这里一开始犯了个错误，把自定义的 broker.conf 所在 conf 目录映射到了 rocketmq 的 workspace 里，造成 conf 目录被替换，而我的配置文件只有一个 broker.conf，造成缺少其他配置文件无法启动 broker 的问题。

3. 配置 broker

本机的 conf 目录下建立自定义的 broker.conf 配置：

brokerClusterName = DefaultCluster
brokerName = broker-syf
brokerId = 0
deleteWhen = 04
fileReservedTime = 48
brokerRole = ASYNC_MASTER
flushDiskType = ASYNC_FLUSH
brokerIP1=10.208.203.69

这里需要注意的是 brokerIP，需要指定为你的内/外网 ip。比如我连接的网络本机内网 ip 是 10.208.203.69，后面才可以用 localhost 访问，否则默认的 172.x.x.x 是容器内网 ip，离开容器在外面是访问不到的。

同时在 docker-compose.yml 文件中手动指定我们刚刚创建的 broker.conf，根据映射关系在容器中的路径是 /root/conf/broker.conf，启动命令配置如下：

sh mqbroker -n namesrv:9876 -c /root/conf/broker.conf

完整的 docker-compose.yml 文件如下：

- 阅读剩余部分 -

首先生成一个 height*weight*3 的全零 numpy 矩阵，dtype 为 uint8。

将其 RGB 中的绿色（G）通道设置为 255（纯绿色）。

然后使用 Pillow 将其保存到本地图片，最后调用 ffmpeg 命令生成对应视频。

ffmpeg 命令行参数：

ffmpeg -framerate 24 -loop 1 -i .\cache.png -pix_fmt yuv420p -t 39.540 -vcodec libx264 green_1080p24.mp4 -y

完整代码：

- 阅读剩余部分 -