架構-微服務：微服務架構技術棧

本文轉載自查看原文 2019-10-31 15:47 1621 架構

ylbtech-架構-微服務：微服務架構技術棧

1.返回頂部

1、

微服務架構技術棧

2019-07-09 • 347 瀏覽 • 7 評論

微服務

一、微服務基礎架構關鍵點

主要由下面七個模塊組成：

微服務技術體系，粉紅色標注的模塊是和微服務關系最密切的模塊：

二、服務框架選型

1.基於 Spring 的框架本質上可以認為是一種 RESTFul 框架，序列化協議主要采用基於文本的 JSON，通訊協議一般基於 HTTP,RESTful 框架天然支持跨語言，任何語言只要有 HTTP 客戶端都可以接入調用，但是客戶端一般需要自己解析 payload。Swagger 自動生成 API 文檔
feign

2.服務間調用 RPC 框架

dubbo 本質上是一套基於 Java 的 RPC 框架，協議 thrift/dubbo
dobbox，是當當擴展了 dubbo,支持了 RESTFul 接口暴露能力
thrift, 基於 thrift 協議跨語言 RPC 框架
TChannel,基於 thrift 協議跨語言 RPC 框架，對比 thrift，實現了調用鏈追蹤，集群監控
Finagle
Hassian

三、運行時支撐服務選型

運行時支撐服務主要包括服務注冊中心，服務路由網關和集中式配置中心三個產品。

1.服務注冊中心

如果采用 Spring Cloud 體系，選擇 Eureka 是最佳搭配，Eureka 在 Netflix 經過大規模生產驗證，支持跨數據中心，客戶端配合 Ribbon 可以實現靈活的客戶端軟負載，但 Eureka2.0 已閉源，使用時，需考慮版本問題
Consul，基礎架構中的一款服務發現和配置的工具
- 服務發現：Consul client 可以提供服務，例如 API 或 MySQL，也可以使用 Consul client 來發現指定服務的提供者。使用 DNS 或 HTTP，應用程序可以輕松找到他們所依賴的服務。
- 健康檢查：Consul client 可以提供任何數量的健康檢查，或者與給定的服務（“Web 服務器是否返回 200 OK”），或與本地節點（“內存利用率是否低於 90％”）相關聯。可以使用此信息來監控集群運行狀況，服務發現組件使用此信息將流量從有問題的主機中移除出去。
- KV Store：應用程序可以使用 Consul 的分層鍵/值存儲，包括動態配置，功能標記，協調，leader 選舉等等。簡單的 HTTP API 使其易於使用。
- 多數據中心：Consul 支持多個數據中心。這意味着 Consul 的用戶不必擔心構建額外的抽象層以擴展到多個區域。

2.服務網關

zuul,Spring Cloud 體系，1.X
Kong,基於 Nginx/OpenResty，采用 nginx 內核，異步性能較強
Spring-Cloud-Gateway,性能比 zuul 好，完美兼容 Spring cloud 體系

3.配置中心

Spring-Cloud-Config，配合 Git 使用，需要 spring-cloud-bus 可實現配置事時生效
disconf，螞蟻金服技術專家發起，但與 Spring boot 和 Spring cloud 相關性弱
apollo，攜程開發，配置實時生效，攜程經過生產級驗證，且完美支持 Spring cloud

四、服務監控選型

主要包括日志監控，調用鏈監控，Metrics 監控，健康檢查和告警通知等產品。

ELK 目前可以認為是日志監控的標配，功能完善開箱即用。Elastalert 是 Yelp 開源的針對 ELK 的告警通知模塊。

調用鏈監控目前社區主流是點評 CAT，Twitter 之前開源現在由 OpenZipkin 社區維護的 Zipkin 和 Naver 開源的 Pinpoint。個人比較推薦點評開源的 CAT，在點評和國內多家互聯網公司有落地案例，生產級特性和治理能力較完善，另外 CAT 自帶告警模塊。

Metrics 監控主要依賴於時間序列數據庫 (TSDB)，目前較成熟的產品是 StumbleUpon 公司開源的基於 HBase 的 OpenTSDB（基於 Cassandra 的 KariosDB 也是一個選擇，它基本上是 OpenTSDB 針對 Cassandra 的一個改造版），OpenTSDB 具有分布式能力可以橫向擴展，但是相對較重，適用於中大規模企業。

OpenTSDB 本身不提供告警模塊，Argus 是 Salesforce 開源的基於 OpenTSDB 的統一監控告警平台，支持豐富的告警函數和靈活的告警配置，可以作為 OpenTSDB 的告警補充。近年也出現一些輕量級的 TSDB，如 InfluxDB 和 Prometheus，這些產品函數報表能力豐富，自帶告警模塊，但是分布式能力不足，適用於中小規模企業。Grafana 是 Metrics 報表展示的社區標配。

五、服務容錯選型

針對 Java 技術棧，Netflix 的 Hystrix 把熔斷、隔離、限流和降級等能力封裝成組件，任何依賴調用（數據庫，服務，緩存）都可以封裝在 Hystrix Command 之內，封裝后自動具備容錯能力。Hystrix 起源於 Netflix 的彈性工程項目，經過 Netflix 大規模生產驗證，目前是容錯組件的社區標准。其它語言棧也有類似 Hystrix 的簡化版本組件。

Hystrix 一般需要在應用端或者框架內埋點，有一定的使用門檻。對於采用集中式反向代理（邊界和內部）做服務路由的公司，則可以集中在反向代理上做熔斷限流，例如采用 Nginx 或者 Kong 這類反向代理，它們都插件支持靈活的限流容錯配置。Zuul 網關也可以集成 Hystrix 實現網關層集中式限流容錯。集中式反向代理需要有一定的研發和運維能力，但是可以對限流容錯進行集中治理，可以簡化客戶端。
Spring-Cloud-Gateway 內部已經集成 hystrix

六、后台服務選型

后台服務主要包括消息系統，分布式緩存，分布式數據訪問層和任務調度系統。后台服務是一個相對比較成熟的領域，很多開源產品基本可以開箱即用。

1.消息系統

kafka 分布式架構
RocketMQ 分布式架構
RabbitMQ 主從架構
ActiveMQ 主從架構

2.分布式緩存

Redis，有搜狐開源的 cachecloud，統一管理
Memcached

3.分布式數據訪問層

sharding-jdbc,當當開源，分庫分表邏輯做在客戶端 JDBC driver 中，客戶端直連數據庫比較簡單輕量
MyCAT，mycat 是從阿里 Cobar 演化出來的社區開源分庫分表中間件

4.任務調度系統

xxl-job，許雪里開源，部署簡單輕量
elastic-job，當當開源

七、服務安全選型

對於微服務安全認證授權機制一塊，目前業界雖然有 OAuth 和 OpenID connect 等標准協議，但是各家具體實現的做法都不太一樣，企業一般有很多特殊的定制需求，整個社區還沒有形成通用生產級開箱即用的產品。
大部分公司的做法都是基於 OAuth 和 OpenID connect 標准，在參考一些開源產品的基礎上（例如 Mitre 開源的 OpenID-Connect-Java-Spring-Server），定制自研輕量級授權服務器。
Wso2 提出了一種微服務安全的參考方案，建議參考，該方案的關鍵步驟如下：

使用支持 OAuth 2.0 和 OpenID Connect 標准協議的授權服務器（個人建議定制自研）；
使用 API 網關作為單一訪問入口，統一實現安全治理；
客戶在訪問微服務之前，先通過授權服務器登錄獲取 access token，然后將 access token 和請求一起發送到網關；
網關獲取 access token，通過授權服務器校驗 token，同時做 token 轉換獲取 JWT token。
網關將 JWT Token 和請求一起轉發到后台微服務；
JWT 中可以存儲用戶會話信息，該信息可以傳遞給后台的微服務，也可以在微服務之間傳遞，用作認證授權等用途；
每個微服務包含 JWT 客戶端，能夠解密 JWT 並獲取其中的用戶會話信息。
整個方案中，access token 是一種 by reference token，不包含用戶信息可以直接暴露在公網上；JWT token 是一種 by value token，可以包含用戶信息但不暴露在公網上。

八、服務部署平台選型

容器已經被社區接受為交付微服務的一種理想手段，可以實現不可變（immutable）發布模式。一個輕量級的基於容器的服務部署平台主要包括容器資源調度，發布系統，鏡像治理，資源治理和 IAM 等模塊。

集群資源調度系統：屏蔽容器細節，將整個集群抽象成容器資源池，支持按需申請和釋放容器資源，物理機發生故障時能夠實現自動故障遷移 (fail over)。目前 Google 開源的 Kubernetes，在 Google 背書和社區的強力推動下，基本已經形成市場領導者地位，社區的活躍度已經遠遠超過了 mesos 和 swarm 等競爭產品，所以容器資源調度建議首選 K8s。當然如果你的團隊有足夠定制自研能力，想深度把控底層調度算法，也可以基於 Mesos 做定制自研。

鏡像治理：基於 Docker Registry，封裝一些輕量級的治理功能。VMware 開源的 harbor 是目前社區比較成熟的企業級產品，在 Docker Registry 基礎上擴展了權限控制，審計，鏡像同步，管理界面等治理能力，可以考慮采用。

資源治理：類似於 CMDB 思路，在容器雲環境中，企業仍然需要對應用 app，組織 org，容器配額和數量等相關信息進行輕量級的治理。目前這塊還沒有生產級的開源產品，一般企業需要根據自己的場景定制自研。

發布平台：面向用戶的發布管理控制台，支持發布流程編排。它和其它子系統對接交互，實現基本的應用發布能力，也實現如藍綠，金絲雀和灰度等高級發布機制。目前這塊生產級的開源產品很少，Netflix 開源的 spinnaker 是一個，但是這個產品比較復雜重量（因為它既要支持適配對接各種 CI 系統，同時還要適配對接各種公有雲和容器雲，使得整個系統異常復雜），一般企業建議根據自己的場景定制自研輕量級的解決方案。

IAM：是 identity & access management 的簡稱，對發布平台各個組件進行身份認證和安全訪問控制。社區有不少開源的 IAM 產品，比較知名的有 Apereo CAS，JBoss 開源的 keycloak 等。但是這些產品一般都比較復雜重量，很多企業考慮到內部各種系統靈活對接的需求，都會考慮定制自研輕量級的解決方案。

考慮到服務部署平台目前還沒有端到端生產級解決方案，企業一般需要定制集成，下面給出一個可以參考的具備輕量級治理能力的發布體系：

簡化發布流程如下：

應用通過 CI 集成后生成鏡像，用戶將鏡像推到鏡像治理中心；
用戶在資產治理中心申請發布，填報應用，發布和配額相關信息，然后等待審批通過；
發布審批通過，開發人員通過發布控制台發布應用；
發布系統通過查詢資產治理中心獲取發布規格信息；
發布系統向容器雲發出啟動容器實例指令；
容器雲從鏡像治理中心拉取鏡像並啟動容器；
容器內服務啟動后自注冊到服務注冊中心，並保持定期心跳；
用戶通過發布系統調用服務注冊中心調撥流量，實現藍綠，金絲雀或灰度發布等機制；
網關和內部微服務客戶端定期同步服務注冊中心上的服務路由表，將流量按負載均衡策略分發到新的服務實例上。

另外，持續交付流水線（CD Pipeline）也是微服務發布重要環節，這塊主要和研發流程相關，一般需要企業定制，下面是一個可供參考的流水線模型，在鏡像治理中心上封裝一些輕量級的治理流程，例如只有通過測試環境測試的鏡像才能升級發布到 UAT 環境，只有通過 UAT 環境測試的鏡像才能升級發布到生產環境，通過在流水線上設置一些質量門，保障應用高質量交付到生產。