链接
- 第 1 部分：简介和架构 <--本文
- 第 2 部分：设置 Kubernetes 和 Kafka
- 第 3 部分：设置保险柜
- 第 4 部分：构建微服务
- 第 5 部分：部署和测试
介绍
微服务是一种设计模式，其中大型单体应用程序被分离成更小、更易于管理的组件。这些组件可以协同工作来解决特定的业务问题。
为此，组件需要相互通信。组件之间的通信可以通过多种方式实现：RESTful Web 服务、SOAP Web 服务、RPC、消息传递等。消息传递（发布/订阅）的一种流行实现是 Kafka。
与大多数消息传递系统相比，Kafka 具有更好的吞吐量、内置的分区、复制和容错能力，这使其成为大规模消息处理应用程序的良好解决方案。
发布订阅
Kafka 遵循发布订阅模式。这种模式就像一个公告板。例如，如果爱丽丝在公告板上发布公告。鲍勃和查尔斯都能读懂它们。他们可以同时阅读，也可以一个接一个地阅读。 Bob 今天可以阅读黑板，Charles 可以在明天阅读。爱丽丝的公告将保留在公告板上，直到它的到期日期过去为止。
在消息传递系统中，我们会有发布者（Alice）和订阅者（Bob 和 Charles）。公告板称为主题，公告称为事件或消息。
如您所见，主题需要在规定的时间段内保留数据。因此，需要保护主题中的数据。不幸的是，Kafka（在撰写本文时）不处理端到端的数据加密。
这就是 Vault 的用武之地。
保险库
Vault 为我们提供加密服务。这使我们能够为我们的消息拥有和端到端的加密方案。
但为什么是保险柜？我们真的需要它吗？现在，当然，我们需要加密从发布者到订阅者的消息是私钥/公钥基础设施。创建这些密钥并将它们嵌入到发布者和订阅者服务中非常容易，如下所示：
问题是当我们有多个订阅者时，每个订阅者都有自己的一组私钥/公钥。当我们需要管理密钥的生命周期时，问题就会出现。例如，在到期时，两个密钥都需要更换。如果密钥是嵌入的，则可能需要重新部署。
另一个问题是何时需要临时撤销和替换密钥。使用嵌入式键没有简单的方法来做到这一点。
在不同服务具有不同密钥集的微服务环境中，这个问题变得更加夸张——例如下面的服务网格：
试图在仅有 4 个服务网格中管理或撤销密钥几乎是不可能的。
Vault 允许我们集中管理所有这些密钥：
此外，Vault 允许我们动态分配哪个服务可以访问哪个密钥。如果某项服务遭到破坏，一旦系统再次受到保护，密钥就很容易被撤销和恢复。
架构
我们的应用程序的架构如下所示。它支持使用 Vault 和 Kafka 的安全端到端通信（消息传递）：
申请流程：
- 交易服务将启动从一个存款账户到另一个存款账户的资金转移。
- Transaction Message 由 Transaction 微服务创建并由 Vault 加密。
- 将加密的交易消息传递给请求主题
- 订阅者将消费消息并执行交易——将资金从一个账户转移到另一个账户。
- 然后，订阅者将通过响应主题将结果余额回复给事务服务
