云服务的抽象路由模型

社区广播:运维派(Yunweipai.com)是国内最早成立的IT运维社区,欢迎大家投稿,让运维人不再孤寂的成长!

云服务路由的诉求

在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。

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

暂无评论

Copyright © 2012-2017 YUNWEIPAI.COM - 运维派 - 粤ICP备14090526号-3
扫二维码
扫二维码
返回顶部