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