背景

首先，使用者資料會經過 kafka 佇列傳遞到我們的業務層。我們希望使用者能夠通過一個通用層接入我們的kafka服務，但是有的使用者希望能夠直接連到我們的 kafka 上面，這就需要我們的 kafka 對外暴露broke服務以便被接入。那麼如何保證使用者資料接入的可靠性和安全性，就成為了這篇文章的主要內容。

目標

我們希望其他公司資料接入的方式儘量鬆耦合，儘量不依賴內部架構，而對於一些使用者要直接接入 kafka 的要求也可以支援。同時，還要保證資料在傳遞過程中的安全性，防止惡意的連線攻擊等。具體如下幾點：
1. 接入方式儘量鬆耦合；
2. 連線的可靠性，即只有特定的使用者或IP 可以建立連線；
3. 資料的安全性，傳遞過程中的資料是經過加密的；
4. 支援使用者直連 kafka 的broke，但客戶端的所有行為都是被許可的。

方案設計

首先，我們希望使用者的接入方式是簡單的、通用的、安全的，是不影響內部業務邏輯的。其次，對於那些指定要直連 kafka 的接入方式，也應該是支援的。那麼下面就有了兩種情況：普通接入方式和 kafka 接入方式。

普通接入方式

近年來，當提到業務對接或者資料傳遞的時候，大家首先想到的就是“調介面”，那麼這個“介面”其實也就是HTTP 介面，大家普遍認為是最普通的、也是最簡單的一種資料傳遞方式，那麼，既然普通簡單，那就是我們所需要的。
所以，接入流程應該是這樣的：接入方先呼叫我們的HTTP 介面，然後我們在web服務中把資料傳遞到kafka中，然後再到我們的業務層。如圖：

這樣，就達到了我們的目標1，即，連線的鬆耦合。這樣，那麼我們就可以隨意改變kafka的部署方式或者內部連線方式，隨意增刪broke，而不用去擔心會影響使用者的使用，就像加入了一個介面卡一樣。當然，此時，broke之間是以內網地址進行互連的，甚至我們可以直接使用現有的kafka叢集而不需要對其做任何改動。
但是另一方面，我們還要保證連線的可靠和資料的安全，上面的方式顯然是不能夠達到的，因為誰都可以接入且資料也是明文的。那就需要繼續在這個設計基礎上進行改進，對HTTP協議的安全升級策略也很常見，只需將HTTP換成HTTPS即可。但，常見的HTTPS只能保證對其一方的認證和資料的加密，就像我們上百度網站一樣，百度是不會對我們每個人進行認證識別的，因為百度不在意我們是誰。可是，我們在意到底是誰接入了我們的服務，所以，這裡應該是雙向認證。
下面來談談HTTPS的好處。首先，比較常見，就是加入了SSL/TLS的HTTP；其次，可以保證資料在傳遞過程中的安全性，因為資料在傳輸過程中是密文的形式，就算是被劫取也沒關係；再者，我們可以對客戶端可以進行身份互相認證識別，只要我們彼此的私鑰和CA證書不被洩露，那麼連線雙方的身份就是確定的。
同時，為了進一步加強連線的可靠性，我們還可以讓特定的IP接入，即使用IP白名單策略保證連線的可靠性。
改進之後的資料流向圖：

這種方式我也稱之為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

這樣，其實就能很好的達到我們的要求：進行細粒度的許可權控制。
所以，這種情況下，接入的資料流程圖應該是這樣的：

那麼現在問題又來了，當我們的內網需要使用這群kafka的時候，也需要進行配置tls雙向認證嗎？顯然是不需要的，一來太麻煩，二來沒必要，因為不會有不信任的連線，也不會洩露資料，三的話就是使用tls雙向認證會大幅度影響效率，延長建立連線的時間。
這樣的話，就應該採用混合式的連線方式比較好，若干broke提供對外網的連線，若干broke提供對內網的連線，而所有的broke之間採用文字的方式傳輸資料。改進後的設計圖如下：

方案定論
綜合以上兩種接入方式，我們既要支援HTTP接入，又要支援kafka接入方式，那麼最後的部署方式應該是這樣的：