背景

Serverless 应用引擎 SAE 事件中心主要面向早期的 SAE 控制台只有针对于应用维度的事件，这个事件是 K8s 原生的事件，其实绝大多数的用户并不会关心，同时也可能看不懂。而事件中心，是希望能够成为一个更高维度入口，可以总览全局的事件（着重于异常事件），并且配置相关的通知与告警。

建设事件中心和监控最大的区别在于：

事件中心的核心意义在于通过显示、通知来将 SAE 上的应用与用户更紧密的连接起来。

事件中心整体能力大图如下：

SAE Web 上线后对于用户的事件需求更加的敏感，因为 Web 支持百毫秒弹性，所以对于事件的实时性和可靠性的要求更高，对于用户的通知和告警消息感知也更重要，针对这些需求 SAE 针对 Web 进行开发了事件中心让用户可以更好的感知异常事件。

整体架构

事件中心

技术挑战技术选型

基于 SAE 微服务事件架构实现

最终方案： 事件模型采用 SAE 微服务事件中心架构实现写入，但是 Web 的事件不直接写入事件而是通过一层数据清洗后写入事件库避免信息爆炸。

数据爆炸资源数据架构现状

微服务 K8s 资源架构

微服务 K8s 资源架构基于 K8s 基础之上建设的，所以对于 workload 和 pod 当资源异常状态的时候会重试非重建，所以 workload 的 key 和 pod 的 key 是唯一的，这时是不会造成事件信息的数据爆炸的，所以最终通过组件将原始事件信息写入到日志库中最终通过事件中心进行消费。

Web 极速系统资源架构

Web 是自主研发的一套极速系统可以实现百毫秒弹性实例的资源系统，可以通过流量控制弹性，闲置时进行缩容。

版本切流： 微服务 K8s 架构是根据 workload 进行部署发布，Web 是基于版本流量进行发布。

数据爆炸风险： 基于上述内容 Web 架构的实例会动态的扩容和缩容，失败的时候不断的重建实例造成 ID 会重建，包括版本失败的信息也和实例扩缩容有关系，所以资源的事件数据量要远远大于微服务 K8s 架构的事件数据。

解决方案

数据爆炸解决方案：通过分布式缓存进行数据聚合，根据时间阈值后进行事件生成，其实类似一种数据队列的模式。

数据爆炸最初用的缓存方案，但是没有采用分布式锁，所以出现了事件中心管控多任务实例造成了同一个事件写入重复多份的问题，下面有问题和优化方案。

Full Gc

问题：因为基于微服务事件中心架构的模型是 java，最初是一次性获取缓存中所有的事件记录写到一个 Java 的 HashMap 中，而这一个 hashmap 有几百兆，如果在事件生成时比较慢会有多个线程都进行拉取就会造成上一个对象没回收下一个线程又获取了一个新的对象，这样就很容易 full gc 了，问题的监控图如下：

优化：

优化内容：

未来和展望

因为面向资源的原始事件相对于 SAE 的用户来讲太难理解了，所以事件中心的出现是更简单的帮助用户进行诊断和定位问题并且第一时间进行通知更加及时的定位问题根据事件，目前很多用户基于 SAE 的事件中心发现问题并诊断自闭环，比如南瓜电影、迅捷联动等用户。

事件中心不仅仅提供白屏化和可订阅通知能力，还可以和用户的运维系统进行定制化集成起来，如：南瓜电影将事件中心集成到了运维平台。

未来计划在事件中心上丰富更多的诊断和智能运维事件结合 AI 场景进行分析和定位让用户可以精确锁定问题和快速处理，实现真正一键定位和简单运维。