最近做了一個分佈式數據推送項目，第一版是用普通 http 輪詢，第二版是 grpc 的 stream 長連接，第三版是用 etcd 的 watch 功能進行監聽。其中跨機房的數據備份是用官方提供的 make-mirror，於是乎如何在公網上安全保密的傳輸就格外重要了。
make-mirror
- 首先，make-mirror 這個官方工具有個巨大的缺點，就是假如兩個 etcd 集羣都設了賬號密碼，只有在源 etcd 集羣可以配置賬號密碼，並沒有配置目標 etcd 集羣的入口。
- 所以只能使用 TLS Common Name 去做安全保密的傳輸。
生成證書
- 因爲項目是用 Java 寫的，同時需要使用 v3 的 client，所以選擇 jetcd 。由於 jetcd 的本質是 grpc，所以一開始我以爲生成證書是和 grpc-java 裏的方式一樣。但這是錯誤的姿勢！！但這是錯誤的姿勢！！但這是錯誤的姿勢！！
- 正確的姿勢是使用 cfssl ，詳見官方文檔，同時官方還有一個非常好的 demo。親測可以搭一個 etcd 集羣起來。然後你可以使用 etcdctl ，再加上證書進行訪問。
- 使用 jetcd 的話，還需要對證書進行轉換，然後使用轉換過的證書。
openssl pkcs8 -topk8 -nocrypt -in cert/etcd1-key.pem -out cert/etcd1.key
jetcd 配合證書進行訪問
- 生成了證書只是成功了一半。之後還需要用 jetcd 使用證書訪問 etcd，首先說一下 jetcd-core 和 jetcd-all 的差別，當你的項目有 netty 和 grpc 全套相關依賴時，使用 jetcd-all，這樣可以避免版本不一致導致的包衝突。如果沒有，請使用 jetcd-core。jetcd-all 是對一些常用包名做了替換。
- 使用了 jetcd-core，仍然會有
java.lang.IllegalStateException: Could not find TLS ALPN provider; no working netty-tcnative, Conscrypt, or Jetty NPN/ALPN availabler之類的報錯。主要是因爲 jetcd 使用的是 grpc-netty，而我們之前用 grpc-netty-shaded。下面是官方原話：
Users of grpc-netty-shaded will automatically use netty-tcnative with BoringSSL.
grpc-netty users will need to add the appropriate netty-tcnative-boringssl-static artifact to the application’s classpath. Artifacts are available for 64 bit Windows, OS X, and 64 bit Linux.
- 所以需要使用
netty-tcnative-boringssl-static
<dependencies>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-tcnative-boringssl-static</artifactId>
<version>2.0.20.Final</version> <!-- See table for correct version -->
<scope>runtime</scope>
</dependency>
</dependencies>
- 注意，要使用正確的版本號！！要使用正確的版本號！！要使用正確的版本號！！
結束語
- 路漫漫其修遠兮，好記性不如爛鍵盤。加油加油！堅持月更！