Spring Cloud Wii是一個用來 快速整合 Spring Cloud 與
異構微服務 的框架，靈感來自 Spring Cloud Netflix Sidecar[1] 。目前支持的服務發現組件：•Nacos
•Consul
術語
異構微服務
非Spring Cloud應用，統稱異構微服務。比如你的遺留項目，或者非JVM應用。
“完美整合”的三層含義
•享受服務發現的優勢
•有負載均衡
•有斷路器
為什麼要造這個輪子？
原因有兩點：
•Spring Cloud子項目 Spring Cloud Netflix Sidecar 是可以快速整合異構微服務的。然而，Sidecar只支持使用Eureka作為服務發現，如果使用其他服務發現組件就抓瞎了。
•Sidecar是基於Zuul 1.x的，Spring Cloud官方明確聲明，未來將會逐步淘汰Zuul。今年早些時候，我有給Spring Cloud官方提出需求，希望官方實現一個基於Spring Cloud Gateway的新一代Sidecar，然而官方表示並沒有該計劃。詳見：https://github.com/spring-cloud/spring-cloud-gateway/issues/735[2]
既然沒有，索性自己寫了。
原理
•Wii根據配置的異構微服務的IP、端口等信息，將異構微服務的IP/端口註冊到服務發現組件上 。
•Wii實現了 健康檢查 ，Wii會定時檢測異構微服務是否健康。如果發現異構微服務不健康，Wii會自動將代表異構微服務的Wii實例下線；如果異構微服務恢復正常，則會自動上線。最長延遲是30秒，詳見 WiiChecker#check 。
要求
•【必須】你的異構微服務需使用HTTP通信。這一點嚴格來說不算要求，因為Spring Cloud本身就是基於HTTP的；
•【可選】如果微服務配置了 wii.health-check-url ，則表示開啟了Wii的健康檢查，此時，你的異構微服務需實現健康檢查（可以是空實現，只要暴露一個端點，返回類似 {"status": "UP"} 的字符串即可）。
使用示例
•如使用Nacos作為服務發現組件，詳見 examples/spring-cloud-wii-example-nacos
•如使用Consul作為服務發現組件，詳見 examples/spring-cloud-wii-example-consul
示例代碼（以Nacos服務發現為例）
1 依賴管理：Spring Cloud Alibaba版本必須是2.1.x+，否則會報錯。這主要是因為Spring Cloud Alibaba修改了包名命名…不同版本的類名包結構不同，而Wii使用了Nacos的類，所以版本必須保持一致。
<dependencymanagement>
<dependencies>
<dependency>
<groupid>org.springframework.cloud/<groupid>
<artifactid>spring-cloud-dependencies/<artifactid>
<version>${spring-cloud.version}/<version>
<type>pom/<type>
<scope>import/<scope>
/<dependency>
<dependency>
<groupid>com.alibaba.cloud/<groupid>
<artifactid>spring-cloud-alibaba-dependencies/<artifactid>
<version>2.1.0.RELEASE/<version>
<type>pom/<type>
<scope>import/<scope>
/<dependency>
/<dependencies>
/<dependencymanagement>
2 加依賴：
<dependency>
<groupid>com.itmuch/<groupid>
<artifactid>spring-cloud-wii/<artifactid>
<version>0.0.1-SNAPSHOT/<version>
/<dependency>
3 寫配置：
server:
port: 8070
spring:
cloud:
nacos:
discovery:
server-addr: localhost:8848
gateway:
discovery:
locator:
enabled: true
application:
name: wii-node-service
wii:
# 異構微服務的IP
ip: 127.0.0.1
# 異構微服務的端口
port: 8060
# 異構微服務的健康檢查URL
health-check-url: http://localhost:8060/health.json
配置比較簡單，就是把Wii註冊到Nacos上，然後添加了幾行wii的配置。
異構微服務
我這裡準備了一個NodeJS編寫的簡單微服務。
var http = require('http');
var url = require("url");
var path = require('path');
// 創建server
var server = http.createServer(function(req, res) {
// 獲得請求的路徑
var pathname = url.parse(req.url).pathname;
res.writeHead(200, { 'Content-Type' : 'application/json; charset=utf-8' });
// 訪問http://localhost:8060/，將會返回{"index":"歡迎來到首頁"}
if (pathname === '/') {
res.end(JSON.stringify({ "index" : "歡迎來到首頁" }));
}
// 訪問http://localhost:8060/health，將會返回{"status":"UP"}
else if (pathname === '/health.json') {
res.end(JSON.stringify({ "status" : "UP" }));
}
// 其他情況返回404
else {
res.end("404");
}
});
// 創建監聽，並打印日誌
server.listen(8060, function() {
console.log('listening on localhost:8060');
});
測試
測試1：Spring Cloud微服務完美調用異構微服務
你的Spring Cloud項目整合Ribbon，只需構建 http://wii-node-service 就可以請求到異構微服務了。
示例：
Ribbon請求 http://wii-node-service/ 會請求到 http://localhost:8060/ 以此類推。
至於斷路器，正常為你的Spring Cloud微服務整合Sentinel或者Hystirx、Resilience4J即可 。
測試2：異構微服務完美調用Spring Cloud微服務
由於Wii基於Spring Cloud Gateway，而網關自帶轉發能力啊。
示例：
如果你有一個Spring Cloud微服務叫做 spring-cloud-microservice ，那麼NodeJS應用只需構建 http://localhost:8070/spring-cloud-microservice/** ，Wii就會把請求轉發到 spring-cloud-microservice 的 /** 。
而Spring Cloud Gateway是整合了Ribbon的，所以實現了負載均衡；Spring Cloud Gateway還可以整合Sentinel或者Hystirx、Resilience4J，所以也帶有了斷路器。
Wii優缺點分析
Wii的設計和Sidecar基本一致，優缺點和Sidecar的優缺點也是一樣的。
優點：
•接入簡單，幾行代碼就可以將異構微服務整合到Spring Cloud生態
•不侵入原代碼
缺點：
•每接入一個異構微服務實例，都需要額外部署一個Wii實例，增加了部署成本（雖然這個成本在Kubernetes環境中幾乎可以忽略不計（只需將Wii實例和異構微服務作為一個Pod部署即可））；
•異構微服務調用Spring Cloud微服務時，本質是把Wii當網關在使用，經過了一層轉發，性能有一定下降。不過一般認為這個性能損耗是可以接受的。和快速接入帶來的好處相比，這點性能損耗算啥。
GitHub地址
https://github.com/eacdy/spring-cloud-wii 歡迎Star、follow。
乾貨分享
最近將個人學習筆記整理成冊，使用PDF分享。關注我，回覆如下代碼，即可獲得百度盤地址，無套路領取！
•001：《Java併發與高併發解決方案》學習筆記；
•002：《深入JVM內核——原理、診斷與優化》學習筆記；
•003：《Java面試寶典》
•004：《Docker開源書》
•005：《Kubernetes開源書》
•006：《DDD速成（領域驅動設計速成）》
•007：全部
•008：加技術討論群
閱讀更多 IT牧場 的文章
