kafka 对外提供服务方案简述

╰+攻爆jí腚メ 2022-01-06 10:39 169阅读 0赞

## 背景 ##

首先，用户数据会经过 kafka 队列传递到我们的业务层。我们希望用户能够通过一个通用层接入我们的kafka服务，但是有的用户希望能够直接连到我们的 kafka 上面，这就需要我们的 kafka 对外暴露broke服务以便被接入。那么如何保证用户数据接入的可靠性和安全性，就成为了这篇文章的主要内容。

## 目标 ##

我们希望其他公司数据接入的方式尽量松耦合，尽量不依赖内部架构，而对于一些用户要直接接入 kafka 的要求也可以支持。同时，还要保证数据在传递过程中的安全性，防止恶意的连接攻击等。具体如下几点：   
1. 接入方式尽量松耦合；   
2. 连接的可靠性，即只有特定的用户或IP 可以建立连接；   
3. 数据的安全性，传递过程中的数据是经过加密的；   
4. 支持用户直连 kafka 的broke，但客户端的所有行为都是被许可的。

## 方案设计 ##

首先，我们希望用户的接入方式是简单的、通用的、安全的，是不影响内部业务逻辑的。其次，对于那些指定要直连 kafka 的接入方式，也应该是支持的。那么下面就有了两种情况：普通接入方式和 kafka 接入方式。

## 普通接入方式 ##

近年来，当提到业务对接或者数据传递的时候，大家首先想到的就是“调接口”，那么这个“接口”其实也就是HTTP 接口，大家普遍认为是最普通的、也是最简单的一种数据传递方式，那么，既然普通简单，那就是我们所需要的。   
所以，接入流程应该是这样的：接入方先调用我们的HTTP 接口，然后我们在web服务中把数据传递到kafka中，然后再到我们的业务层。如图：

![SouthEast][]  
   
这样，就达到了我们的目标1，即，连接的松耦合。这样，那么我们就可以随意改变kafka的部署方式或者内部连接方式，随意增删broke，而不用去担心会影响用户的使用，就像加入了一个适配器一样。当然，此时，broke之间是以内网地址进行互连的，甚至我们可以直接使用现有的kafka集群而不需要对其做任何改动。   
但是另一方面，我们还要保证连接的可靠和数据的安全，上面的方式显然是不能够达到的，因为谁都可以接入且数据也是明文的。那就需要继续在这个设计基础上进行改进，对HTTP协议的安全升级策略也很常见，只需将HTTP换成HTTPS即可。但，常见的HTTPS只能保证对其一方的认证和数据的加密，就像我们上百度网站一样，百度是不会对我们每个人进行认证识别的，因为百度不在意我们是谁。可是，我们在意到底是谁接入了我们的服务，所以，这里应该是双向认证。   
下面来谈谈HTTPS的好处。首先，比较常见，就是加入了SSL/TLS的HTTP；其次，可以保证数据在传递过程中的安全性，因为数据在传输过程中是密文的形式，就算是被劫取也没关系；再者，我们可以对客户端可以进行身份互相认证识别，只要我们彼此的私钥和CA证书不被泄露，那么连接双方的身份就是确定的。   
同时，为了进一步加强连接的可靠性，我们还可以让特定的IP接入，即使用IP白名单策略保证连接的可靠性。   
改进之后的数据流向图：

![SouthEast 1][]  
   
这种方式我也称之为HTTP接入方式，当一个用户需要使用我们的 IOT，那么接入的方式就应该优先使用这种方式。

## KAFKA 接入方式 ##

所谓的kafka 接入，就是指用户使用kafka的客户端程序直连broke服务群的方式。这种接入方式就需要暴露broke来提供用户连接，需要给出连接broke的IP和端口。   
为了实现我们的既定目标，也需要把client和broke之间加入类似SSL的安全层协议，幸好，kafka对client支持tls和sasl两种认证方式，在这之间，我选择tls双向认证。

What is SASL?
    
    SASL是一个依赖于其他协议的框架，本质上是一个间接层，允许在现有的应用程序协议中插入可插入的身份验证系统和数据安全性(e.g LDAP, SMTP, Subversion, …)。
    它是否以及如何提供安全的身份验证和数据加密，很大程度上取决于该框架内使用的底层机制。如果使用SASL中，可以选择使用GSSAPI、Kerberos、NTLM等。

如上个接入方式所说，tls双向认证协议保证了双方的可靠性，同时也能保证数据的安全性。在这种情况下，我们能够保证连接到我们kafka的客户端都是我们允许的，只是并不能约束客户端的行为，比如说，客户端可以随意读取所有的topic数据，这显然是不能允许的。   
还好，kafka支持使用ACL权限控制机制。kafka附带一个可插拔的认证，并使用zookeeper来存储所有的acl。kafka的acl在一般格式定义”Principal P is \[Allowed/Denied\] Operation O From Host H On Resource R”，意思就是说可以使某个资源针对特定IP特定用户进行特定的操作。   
例子：假设你要添加一个acl “以允许198.51.100.0和198.51.100.1，Principal为User:Bob和User:Alice对主题是Test-Topic有Read和Write的执行权限” 。可通过以下命令实现：

bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:Bob --allow-principal User:Alice --allow-host 198.51.100.0 --allow-host 198.51.100.1 --operation Read --operation Write --topic Test-topic

这样，其实就能很好的达到我们的要求：进行细粒度的权限控制。   
所以，这种情况下，接入的数据流程图应该是这样的：

![SouthEast 2][]  
   
那么现在问题又来了，当我们的内网需要使用这群kafka的时候，也需要进行配置tls双向认证吗？显然是不需要的，一来太麻烦，二来没必要，因为不会有不信任的连接，也不会泄露数据，三的话就是使用tls双向认证会大幅度影响效率，延长建立连接的时间。   
这样的话，就应该采用混合式的连接方式比较好，若干broke提供对外网的连接，若干broke提供对内网的连接，而所有的broke之间采用文本的方式传输数据。改进后的设计图如下：

![SouthEast 3][]  
   
方案定论   
综合以上两种接入方式，我们既要支持HTTP接入，又要支持kafka接入方式，那么最后的部署方式应该是这样的：

![SouthEast 4][]

原文：https://blog.csdn.net/hohoo1990/article/details/79128329   
版权声明：本文为博主原创文章，转载请附上博文链接！

[SouthEast]: /images/20211227/a12e52e595834efbb9ecb61fef5a5a7b.png
[SouthEast 1]: /images/20211227/be3548ebcb7645f1b4f24845837e16c9.png
[SouthEast 2]: /images/20211227/58a58e8367df4a07a3acc43dcd8ad706.png
[SouthEast 3]: /images/20211227/e57358f956ef46498675265040b290db.png
[SouthEast 4]: /images/20211227/9a9f51469013418c8dc0fb9ddff0f1e6.png