云服务的抽象路由模型

云服务路由的诉求

在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，负责接收用户请求并转发到系统内。L1是纯粹的LB能力，通常是4层转发。典型的实现方式是等价路由＋LVS＋Nginx集群。

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。

本文链接：http://www.yunweipai.com/22856.html