BankNext 微服务：案例研究

作者 |MicroStone
来源 | 今日头条

本文是“BankNext”的案例研究：它包括数字化转型、客户入职流程以及事件驱动和隐藏地雷。

业务目标

“ BankNext ”正处于雄心勃勃的数字化转型阶段，并希望使其客户入职流程无缝衔接。经过详细的功能流程分析，BankNext 实现了一个编排架构，可以在各种微服务之间进行协作。

业务流程

1. 启动：潜在客户在 BankNext 上启动加入流程
2. 预检查：BankNext 首先调用筛选 MSvc和重复数据删除 Msvc来研究潜在客户并确保该实体不存在于系统中
3. 处理(预检查通过后)：CustomerMgt Msvc创建客户实体，AccountMgt Msvc为该客户创建 Account 实体。
4. 合规性：在初始阶段监控 Msvc以检查可疑活动并推荐 Msvc以根据客户偏好提供客户满意度。

构建反馈

BankNext 对这种架构非常满意，原因如下：

1. Entity Orchestrator Msvc 为系统提供了在多个微服务之间进行协作的能力。
2. 协调器能够对调用进行排序和同步。
3. 编排器根据来自被调用微服务的响应/异常响应地调整操作。
4. 协调器巧妙地使用可完成的未来从异步并行调用中受益，只要调用不相互依赖。

构建负面反馈

BankNext 很快意识到：我们有一个问题：

1. 调用和整理来自多个微服务的响应时出现不希望的延迟 。
2. 假设每个 Msvc 需要 300ms，那么所有 7 个所需的总时间至少为 1 秒(即 300ms * 7)。
3. 这种等待使潜在客户不高兴。
4. 任何新 Msvc 的引入都会迫使 Orchestrator 显式编写该调用调用，这会导致不希望的紧密耦合。

回到规划

经过深入分析，工程和业务团队共同确定延迟的根本原因是运行时间最长的服务。

商业评论

业务审查得出结论，筛选和重复数据删除预检查是强制性的。一旦通过，用户就可以清楚地获得一个帐户，因此可以发送确认信息。监控和推荐是辅助服务，不应耽误用户确认。

技术挑战

为了实现这一业务愿景，系统设计必须演变为打破流程，以便在预检查后立即发送用户确认。其余的过程，即客户创建和帐户创建、监控和推荐应该异步发生。这将极大地提升用户体验。

技术实施

1. 工程团队立即意识到事件驱动的编排将是解决这一挑战的正确方法。
2. 成功预检查后，EntityMgt Msvc*将此新实体 txn 发布到 Kafka “ *new_entity_initiated_topic ”。
3. EntityMgt Msvc 将初始确认信息发送回用户。
4. CustomerMgt Msvc订阅 Kafka “new_entity_initiated_topic” 并使用此事件。
5. CustomerMgt Msvc 在系统中创建客户并将此事件发布到 Kafka “ new_customer_created_topic ”。
6. AccountMgt Msvc 订阅 Kafka “ new_customer_created_topic ”并使用此事件。
7. AccountMgt Msvc 在系统中为该客户创建帐户并将此事件发布到 Kafka “ new_account_created_topic ”
8. 新实体在系统中成功创建。
9. 支持服务，即监控 Msvc 和推荐 Msvc 订阅 Kafka “ new_account_created_topic ”。

10.由于此过程是异步的，因此还需要一个新的 Notification Msvc 将帐户详细信息通知给客户。

11.这个 Notification Msvc 可以通过简单的订阅 Kafka “ new_account_created_topic ”快速连接到这个新架构中。

新架构的优点

1. 对客户的响应能力显着提高。
2. 消除紧密耦合，因为不再需要显式服务调用。系统只需要知道要发布或订阅的主题。
3. 通过订阅正确的主题，可以快速整合新服务，从而获得巨大的未来灵活性。

新的建筑负面因素：隐藏的地雷

1. 随着灵活性的提高，这种架构带来了更高的系统复杂性。
2. 通过引入健壮的消息传递组件，主要的基础架构增强以启用事件驱动的处理。
3. 可观察性、系统调试和跟踪能力需要显着提高，以排除故障场景。
4. 状态管理、重试和系统范围的回滚机制增加了复杂性。
5. 系统原子性需要详细的 SAGA 实现

摘要：架构、TechStack 和基本原理