第二章：核心概念与术语

好，咱们正式开始聊干货。这一章我会把几个最核心的概念掰开揉碎讲清楚。你可能会觉得这些词都听过——事件驱动、微服务、消息队列、状态机、编排与协同。但说实话，我在项目里见过太多人用错它们。

为什么会这样？因为光知道定义没用，你得知道它们在实际的 Genesys 系统里到底扮演什么角色。来，我一个一个说。

2.1 事件驱动架构

事件驱动架构，说白了就是「发生了什么事，然后怎么办」。传统的请求-响应模式就像你打电话问客服，得等着。事件驱动就像发微信——你发完消息该干嘛干嘛，对方看到了自然会回。

在 Genesys 系统里，事件无处不在：客户来电了、座席空闲了、路由决策完成了、报表数据更新了……这些都是事件。我习惯把事件分成三类：

• 业务事件：客户进线、挂断、满意度评价
• 系统事件：服务启动、连接断开、资源不足
• 状态事件：座席签入/签出、通话状态变更

我在项目中遇到过一件事：某客户把 Genesys 的事件流直接连到业务系统，结果业务系统扛不住每秒几千个事件的冲击。嗯，这里要注意——事件驱动架构必须有背压机制和流量控制，否则就是灾难。

2.2 微服务

微服务不是什么新鲜词了。但在 Genesys 场景下，它有特殊含义。Genesys 本身就是一个微服务集群——路由服务、统计服务、录音服务、报表服务……每个都是独立的微服务。

我个人习惯把微服务拆分的粒度定义为「一个服务只做一件事，并且做好」。比如：

• 路由服务只管「把客户分配给谁」
• IVR 服务只管「客户按键后跳转到哪里」
• 录音服务只管「把通话录下来存好」

你想想看，如果把这些都揉到一个服务里，改个路由逻辑还得担心会不会影响录音——这不就回到单体架构的老路上了吗？

2.3 消息队列

消息队列是事件驱动架构的「血管」。没有它，事件就流不动。在 Genesys 里，消息队列承担着三大职责：

1. 解耦：生产者不用管消费者是谁，只管往队列里丢消息
2. 缓冲：流量高峰时，消息先排队，消费者慢慢处理
3. 可靠：消息持久化，服务挂了重启还能继续消费

我曾经踩过一个坑：用 Redis 的 List 当消息队列用。结果消息一多，Redis 内存爆了，丢了一堆事件。后来老老实实换成了 Kafka。记住——专业的事交给专业的工具。

在 Genesys 里，我常用的消息队列方案有：

场景	推荐方案	原因
高吞吐事件流	Kafka	分区机制、持久化、重放能力
任务分发	RabbitMQ	灵活的路由、确认机制
轻量级通知	Redis Pub/Sub	简单、低延迟

2.4 状态机

状态机这东西，听起来高大上，其实就是一个「当前状态 + 事件 = 下一个状态」的规则表。在 Genesys 里，座席的状态机是最典型的例子：

• 空闲 → 来电 → 忙碌
• 忙碌 → 挂断 → 后处理
• 后处理 → 完成 → 空闲

我建议你在设计状态机时，一定要画出完整的状态转换图。别漏掉边界情况——比如座席在忙碌时突然断网了，状态应该怎么变？

状态机的实现方式有很多：可以用 Spring State Machine，也可以用简单的枚举 + Map。我个人偏好用轻量级的实现，因为 Genesys 的状态变化非常频繁，太重了反而影响性能。

2.5 编排与协同

这两个词经常被混用，但区别很大。我简单说：

• 编排（Orchestration）：有一个中心控制器，告诉每个服务「你该做什么」。就像乐队指挥。
• 协同（Choreography）：没有中心控制器，每个服务根据事件自己决定做什么。就像即兴爵士乐。

在 Genesys 里，我两种都用。比如：

• 客户进线后的 IVR 流程，用编排——因为流程是固定的，需要中心控制
• 座席状态变更后的通知链，用协同——因为多个服务需要各自响应，没必要统一调度

你想想看，如果所有事情都用编排，那编排服务本身就成了单点故障。如果所有事情都用协同，出了问题很难排查。所以我的原则是：有明确流程的用编排，有松散耦合的用协同。

知识体系图

下面这张图展示了本章核心概念之间的关系。我习惯用这种图来跟团队对齐思路——一看就明白。

好了，这一章的核心概念就这些。记住，概念是死的，但用法是活的。下一章我们会把这些概念串起来，看看它们在实际项目中怎么配合。

---

公众号:蓝海资料掘金营，微信deep3321