云服务路由的诉求
在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
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/tech/pnotes/53284.html