雲服務路由的訴求

在PaaS或SaaS領域內，雲服務是PaaS與SaaS中第二個S（Service）的實現者，一個看似簡單的雲服務，其實現上通常是很複雜的，且並不是獨立的。

典型的如亞馬遜的S3服務，S3本身是一個跨地域對全球提供服務的服務，S3服務內部之間需要互相通訊交換資料與指令，同時S3又依賴AWS內的其他基礎服務（IAM、CloudWatch等）。

這些眾多的資料與訊息交換，需要有一個穩定、快速的路由匯流排，路由匯流排好比高速公路，高速公路修好了，汽車（訊息或資料）才能暢通無阻。

本文定義了路由匯流排的DNA，抽象出了雲服務的典型路由匯流排模型，分析了模型中各個部件的屬性，對通用的雲服務具備普適性，可參考。

路由匯流排的DNA

訪問點

路由匯流排中各個訪問點是關鍵，外部或內部與雲服務互動，都是從訪問點進入，在雲服務路由匯流排設計時候，需要明確有多少個訪問點，每個訪問點的用途、協議。

介面認證方式

介面暴露到訪問點上，需要明確介面的認證方式，使用者通過什麼憑證訪問介面。

介面註冊方式

雲服務的介面通過什麼方式註冊到路由總線上，如何將不同的介面註冊到不同的訪問點，並設定認證模式。

路由抽象模型：5 Layers，6 Endpoints

5 Layers

路由匯流排抽象模型分為5層，每一層有明確的職責。

L1: APIGWLB/UILB

使用者訪問雲服務API或介面頂層Load Balancer，負責接收使用者請求並轉發到系統內。

L2: APIGW

雲服務暴露對外介面的API閘道器，APIGW掛接在L1的LB之下，負責處理外部API請求。APIGW通常具備API編排與治理（流控，認證）等能力，註冊到APIGW上的API需要指定認證方式，典型的AWS的API認證方式為AK/SK。

部分APIGW還具備認證憑證轉換的能力，典型的如將AK/SK轉換為內部的Token，對內部系統遮蔽外部的認證憑證差異。

為什麼會有認證憑證差異？因為不同場景下需要不同的認證憑證。典型的UI API的認證憑證是Session（通過使用者密碼登入後換得的），APIGW還可以將Session也換成內部的Token。

L3: ServiceLB

由於APIGW通常不帶LB能力，因此釋出到APIGW上的API訪問點必須是LB的訪問點，所以需要一個ServiceLB。Service LB掛接在L2的APIGW之下，負責接收APIGW轉發過來的請求。

ServiceLB還有一個用途是雲服務內部服務之間通訊使用。

L4: Internal Router

Internal Router 用於服務內微服務之間通訊使用，它的存在是為了方便管理API。服務內部的API不對其他服務開放，因此變更時候好管控。

L5: TenantLB

Tenant LB用於場景比較特殊，在同時提供IaaS服務的雲服務場景下使用，如果IaaS也是同一個供應商提供的，那麼使用者可以使用TenantLB這個通道訪問雲服務API，TenantLB這個通道是內部通道，在虛擬機器沒有連線到Internet的情況下，也可以訪問到雲服務。由於是內部通道，因此對於有在客戶虛擬機器上部署的Agent的雲服務，Agent也走此通道。

6 Endpoints

E1: Tenant North API

使用者通過Internet訪問雲服務API的通道，認證方式可以多樣。

E2: UI API

使用者通過Internet訪問雲服務UI的通道，通常使用使用者密碼認證。

E3: Service API

雲服務內部服務之間互相訪問通道。

E4: Micro Service API

雲服務內部微服務之間互相訪問通道。

E5: Tenant Agent API

雲服務部署在使用者通過IaaS分配的虛擬機器上的Agent訪問雲服務的通道，內部通道，不需要通過Internet。

E6: Tenant South API

IaaS分配的虛擬機器上訪問雲服務通道，內部通道，不需要通過Internet。