Spring Cloud - 技術棧

整理自楊波老師的總結

註冊中心

• Eureka
• Consul支持 KV 模型存儲和靈活健康檢查能力。

服務網關

• Spring Cloud選擇 Zuul 是最佳搭配，但異步性能不足（基於 Netty 的異步 Zuul 未推出正式版）。
• 基於 Nginx/OpenResty 的 API 網關 Kong 在 github 上比較火。由於採用 Nginx 內核，Kong 的異步性能較強，基於 lua 的插件比較豐富，從安全到限流熔斷都有，還有很多開源的管理界面，可以集中管理 Kong 集羣。

服務容錯

• Hystrix 在應用端或者框架內埋點，有必定侵入性。

集中式限流容錯，對於 Nginx或者 Kong，能夠集中在反向代理上作熔斷限流，其插件支持靈活的限流容錯配置。Zuul 也能夠集成 Hystrix 實現網關層集中式限流容錯。

配置中心

• Spring Cloud Config 缺失治理能力。
• [推薦]攜程的 Apollo 配置中心，具有高可用，配置實時生效（推拉結合），配置審計和版本化，多環境多集羣支持等生產級特性。https://github.com/ctripcorp/...

調用鏈監控

• 點評的 CAT ？仍是 incubator-skywalking ？
• zipkin 報表少，依賴分析過於簡陋，不支持Metric。
• Pinpoint 比zipkin好一點，經過字節碼作埋點，但不支持Metric。

日誌監控

• ElasticSearch + kibana + Logstash + Filebeat + Elastalert。不說了。

Metrics 監控

存儲依賴於時間序列數據庫 (TSDB)。

• OpenTSDB 分佈式能力強，可是相對較重。
• prometheus 輕量級，自帶告警模塊，可是分佈式能力不足。

Metrics報表展現用 Grafana，不說了。

隊列

• 對於日誌等可靠性要求不高的場景，用Kafka。對 Kafka 的監控和治理能夠結合 hermes。
• RocketMQ 高性能，分佈式能力強。
• RabbitMQ 性能和分佈式能力稍弱，中小規模場景可選。

緩存

客戶端jedis或redisson，redisson有中文文檔 連接描述

• [推薦] 客戶端直連模式（簡單輕量），用 cachecloud 緩存治理平臺。
• 中間層 Proxy 模式，則用 Twitter 的 twemproxy 或 CodisLab 的 codis。

數據訪問層

• sharding-jdbc，分庫分表邏輯作在客戶端 jdbc driver 中，客戶端直連數據庫簡單輕量，建議中小規模場景。
• MyCAT 數據庫訪問中間層 proxy 模式，但運維成本較高，建議中大規模場景。

任務調度

• [推薦] xxl-job 簡單輕量，大部分場景夠用。
• elastic-job 功能強大但複雜。

服務安全

開源的很雜亂，沒有現成的，只能自研。