【摘要】 本文介紹了基於開源自建和適配雲廠商開發框架兩種構建多雲架構的思路，以及這些思路的優缺點。

微服務生態

微服務生態本質上是一種微服務架構模式的實現，包括微服務開發SDK，以及微服務基礎設施。

目前比較成熟的 JAVA 微服務生態包括 servicecomb（華為）, spring-cloud (Pivotal), dubbo（阿里）, tsf（騰訊）等。gRPC、Thrift 等也用於內部服務之間的通訊，但是微服務基礎設施比較欠缺。

核心的微服務基礎設施包括：註冊中心、配置中心、應用閘道器。此外，分散式事物管理、計劃任務、呼叫鏈跟蹤系統等也是微服務基礎設施的組成部分。完整的微服務基礎實施還包括開發使能工具，包括介面管理工具、灰度釋出管理、程式碼生成等，這部分主要由雲廠商提供，比較少開源方案。

微服務生態的核心是 SDK，而 SDK 的核心是 RPC 框架，這個是不同微服務生態的本質區別。在基礎設施方面，不同的微服務生態是可以相互選擇的，比如 spring-cloud 生態可以採用 spring-cloud-huawei 接入servicecomb 提供的註冊中心 servicecomb-service-center、配置中心 servicecomb-kie，也可以通過 spring-cloud-alibaba 接入阿里的配置中心；servicecomb 也可以通過引入擴充套件，使用其他的配置中心。一些基礎的開發元件，比如 spring、spring boot，這些微服務開發 SDK 都支援整合。

對微服務生態進行比較是一個很難的課題。下面的表格僅對一些核心功能進行比較。使能工具、核心基礎設施、可選基礎設施等方面，不同的微服務生態是可以相互使用的，這裡的比較只針對該生態原生提供的來說，並不代表某個微服務生態缺少這塊功能，該生態的開發者用不了這方面的能力。對於開源生態應該採用一個大生態的眼光來看待，每個生態的設計者也會盡可能融入其他生態，繼承和複用其他生態的能力。但是在商業選型上，需要考慮技術支援等因素。

對微服務生態的比較的另外一個視角就是如何構建微服務應用架構。 一般的微服務應用架構會包括應用閘道器、業務微服務和靜態頁面。靜態頁面的部署相對比較靈活，可以放到應用閘道器內部，也可以放到應用閘道器，還可以放到應用閘道器外面。其中放到閘道器裡面的方式最靈活，比如可以通過配置閘道器的負載均衡策略，將請求轉發到使用者最近的region，也可以對部分靜態頁面進行訪問控制。

增加應用閘道器可以增強應用系統的彈性，能夠支撐系統的持續演進（參考分析文章），同時可以結合網路基礎設施，更好的實現應用系統的能力開放。比如如果接入層使用 API Gateway 掛載，可以很好的實現內部系統的能力開放和計費；使用LVS接入，只可以提高轉發效能，比較適合訪問量大的應用，接入閘道器邏輯少，應用閘道器可以彈性擴容；使用DNS則對於網站很有用，遮蔽使用者訪問的地址差異，並且可以使用DNS將請求轉發到不同區域的應用閘道器。

Servicecomb, spring-cloud 都能夠很好的支援這種架構，而 dubbo 對這種架構支援的不是很好，很多 dubbo 開發者都是通過在業務服務之外增加一個接入層，使用 spring-cloud 的應用閘道器來搭建這個應用架構。

多雲微服務架構的兩種方案

採用開源微服務框架

很多業務系統的構建，都是從選擇一個開源方案開始。 一般會首先選擇一個微服務開發 SDK， 然後選擇其他的微服務基礎設施。 對於自主研發的情況，微服務基礎設施也會選擇開源方案。 比如選擇 ServiceComb 微服務開發 SDK 的場景，可以通過在不同的雲上部署開源服務，來實現一套系統，多個雲上執行。 雲廠商如果存在微服務基礎設施的商業版本， 可以在雲上購買使用， 使用雲產商提供的基礎設施服務，通常可以降低自己運維的成本，並能夠得到更好的效能優化和可靠性支援。

另外一個開源解決方案是部分整合雲產商提供的元件，儘可能多的使用雲產商的基礎設施。 比如選擇 Spring Cloud 微服務解決方案， 可以使用 spring-cloud-huawei, spring-cloud-alibaba 等雲產商提供的擴充套件，使用雲上的基礎設施。

下面對開源解決方案的評估點做一個總結：

1. 只需要維護一套程式碼和熟悉一個開發框架，多雲執行。不同雲的執行體驗存在差異，可以部分使用雲廠商的中介軟體。 如果其他雲沒有對應的中介軟體，需要自行安裝和維護中介軟體。

2. 微服務框架選型之前，需要考慮“基礎設施”是否也開源。比如微服務基礎設施最重要的中介軟體“配置中心”、“註冊中心”和“應用閘道器”。開源可獲得性是一套程式碼，多雲執行的前提。

適配多供應商開發框架

每個雲產商都存在一個主打的微服務開發框架， 使用主打微服務開發框架能夠最好使用雲產商提供的微服務基礎設施。 為了在不同的雲上， 獲得最佳的微服務管理能力，需要儘可能使用對應雲的主打框架。 但是維護多套程式碼是困難的。 適配多供應商的開發框架， 需要對核心業務做好分離，避免重複開發，然後將適配層做薄，只實現簡單適配，降低開發難度。 大部分 JAVA 微服務開發框架都支援 Spring， 因此可以採用下面的設計模式，實現一套核心程式碼，編譯成多個雲產商開發框架的可執行程式的多雲版本。

上圖是一個微服務的內部結構，一個微服務可能包含如下幾個目錄：

* application-core

* application-runtime-servicecomb

* application-runtime-hsf

下面對適配多供應商開發框架方案的評估點做一個總結：

1. 需要做好業務抽象，並熟悉多個開源微服務開發框架，相對於開源自建方案維護成本高。

2. 不需要考慮自行安裝和維護基礎中介軟體的問題，雲廠商自己的微服務框架，一般針對這個框架提供了各種中介軟體支援，使用和接入開發成本低。

3. 這種方案是優秀程式碼架構設計。在開源方案中，也建議做好核心業務邏輯分離和介面抽象，每個方案適配不同雲廠商非微服務基礎設施（比如資料庫、物件儲存、EI等功能）也都是需要的。

點選關注，第一時間瞭解華為雲新鮮技