微服务的接入层设计与动静资源隔离

服务器 服务器产品
假设全国有多个数据中心,托管在多个运营商,每个数据中心三个可用区Available Zone,对象存储通过跨可用区部署,实现高可用性,在每个数据中心中,都至少部署两个内部负载均衡器,内部负载均衡器后面对接多个对象存储的前置服务proxy-server。

零题记

这个系列是微服务高并发设计,所以我们先从最外层的接入层入手,看都有什么样的策略保证高并发。

接入层的架构画一个简图来讲包括下面的部分。

接下来我们依次解析各个部分以及可以做的优化。

一、数据中心之外:DNS、HttpDNS、GSLB

当我们要访问一个网站的服务的时候,首先访问的肯定是一个域名,然后由DNS,将域名解析为IP地址。

我们首先先通过DNS访问数据中心中的对象存储上的静态资源为例子,看一看整个过程。

[[229196]]

我们建议将例如文件、图片、视频、音频等静态资源放在对象存储中,直接通过CDN下发,而非放在服务器上,和动态资源绑定在一起。

假设全国有多个数据中心,托管在多个运营商,每个数据中心三个可用区Available Zone,对象存储通过跨可用区部署,实现高可用性,在每个数据中心中,都至少部署两个内部负载均衡器,内部负载均衡器后面对接多个对象存储的前置服务proxy-server。

1、当一个客户端要访问object.yourcompany.com的时候,需要将域名转换为IP地址进行访问,所以他要请求本地的resolver帮忙。

2、本地的resolver看本地的缓存是否有这个记录呢?如果有则直接使用。

3、如果本地无缓存,则需要请求本地的Name Server。

4、本地的Name Server一般部署在客户的数据中心或者客户所在的运营商的网络中,本地Name Server看本地是否有缓存,如果有则返回。

5、如果本地没有,本地Name Server需要从Root Name Server开始查起,Root Name Server会将.com Name Server的地址返回给本地Name Server。

6、本地的Name Server接着访问.com的Name Server,他会将你们公司的yourcompany.com的Name Server给本地Name Server。

7、本地的Name Server接着访问yourcompany.com的Name Server,按说这一步就应该返回真实要访问的IP地址。

对于不需要做全局负载均衡的简单应用来讲,yourcompany.com的Name Server可以直接将object.yourcompany.com这个域名解析为一个或者多个IP地址,然后客户端可以通过多个IP地址,进行简单的轮询,实现简单的负载均衡即可。

但是对于复杂的应用,尤其是跨地域跨运营商的大型应用,则需要更加复杂的全局负载均衡机制,因而需要专门的设备或者服务器来做这件事情,这就是GSLB,全局负载均衡器。

从yourcompany.com的Name Server中,一般是通过配置CNAME的方式,给object.yourcompany.com起一个别名,例如object.vip.yourcomany.com,然后告诉本地Name Server,让他去请求GSLB去解析这个域名,则GSLB就可以在解析这个域名的过程中,通过自己的策略实现负载均衡。

图中画了两层的GSLB,是因为分运营商和分地域,我们希望将属于不同运营商的客户,访问相同运营商机房中的资源,这样不用跨运营商访问,有利于提高吞吐量,减少时延。

8、***层GSLB通过查看请求他的本地Name Server所在的运营商,就知道了用户所在的运营商,假设是移动,然后通过CNAME的方式,通过另一个别名object.yd.yourcompany.com,告诉本地Name Server去请求第二层的GSLB。

9、第二层的GSLB通过查看请求他的本地Name Server所在的地址,就知道了用户所在的地理位置,然后将距离用户位置比较近的Region的里面的内部负载均衡SLB的地址共六个返回给本地Name Server。

10、本地Name Server将结果返回给resolver。

11、resolver将结果缓存后,返回给客户端。

12、客户端开始访问属于相同运营商的距离较近的Region1中的对象存储,当然客户端得到了六个IP地址,他可以通过负载均衡的方式,随机或者轮询选择一个可用区进行访问,对象存储一般会有三份备份,从而可以实现对存储读写的负载均衡。

从上面的过程可以看出,基于DNS域名的GSLB实现全局的负载均衡,可是现在跨运营商和跨地域的流量调度,但是由于不同运营商的DNS缓存策略不同,会造成GSLB的工作实效。

有的用户的DNS会将域名解析的请求转发给其他的运营商的DNS进行解析,导致到GSLB的时候,错误的判断了用户所在的运营商。

有的运营商的DNS出口会做NAT,导致GSLB判断错误用户所在的运营商。

所以不同于传统的DNS,有另一种机制称为httpDNS,可以在用户的手机App里面嵌入SDK,通过http的方式访问一个httpDNS服务器,由于手机App可以精确的获得自己的IP地址,可以将IP地址传给httpDNS服务器,httpDNS服务器完全由应用的服务商提供,可以实现完全自主的全网流量调度。

二、数据中心之外:CDN

对于静态资源来讲,其实在真实的访问机房内的对象存储之前,在最最接近用户的地方,可以先通过CDN进行缓存,这也是高并发应用的一个总体的思路,能接近客户,尽量接近客户。

CDN厂商的覆盖范围往往更广,在每个运营商,每个地区都有自己的POP点,所以总有更加靠近用户的相同运营商和相近地点的CDN节点就近获取静态数据,避免了跨运营商和跨地域的访问。

在使用了CDN之后,用户访问资源的时候,和上面的过程类似,但是不同的是,DNS解析的时候,会将域名的解析权交给CDN厂商的DNS服务器,而CDN厂商的DNS服务器可以通过CDN厂商的GSLB,找到最最接近客户的POP点,将数据返回给用户。

当CDN中没有找到缓存数据的时候,则需要到真正的服务器中去拿,这个称为回源,仅仅非常少数的流量需要回源,大大减少了服务器的压力。

三、数据中心边界与核心:边界路由、核心交换、等价路由

如果真的需要回源,或者访问的压根就不是静态资源,而是动态资源,则需要进入数据中心了。

刚才***节中说到,最终GSLB返回了6个IP地址,都是内部负载均衡SLB的IP地址,说明这6个IP地址都是公网可以访问的,那么公网如何知道这些IP地址的呢?

这就要看机房的结构了。

一个机房一般会有边界路由器、核心交换机,每个AZ有汇聚交换机,6个SLB是在AZ里面的,所以他们的IP地址是通过iBGP协议告知边界路由器的。

当用户从六个IP里面选择了一个IP地址进行访问的时候,可以通过公网上面的路由,找到机房的边界路由器,边界路由器知道当时这个路由是从哪个AZ里面给他的,于是就通过核心交换一层,将请求转发给某一个AZ,这个AZ的汇聚交换机会将请求转发给这个SLB。

如果一个AZ出现了问题,是否可以让对某个公网IP的访问给另一个AZ呢?当然是可以的,在核心路由和核心交换之间,可以做ECMP等价路由。当然也可以在边界路由上将外部地址NAT称为内部的一个VIP地址,通过等价路由实现跨AZ的流量分担。

四、数据中心可用区中:负载均衡SLB、LVS、HAProxy

进入一个可用区AZ之后,首先到达的是负载均衡SLB,可以购买商用的SLB,也可以自己搭建,例如通过LVS实现基本的负载均衡功能。

LVS的性能比较好,很多工作通过内核模块ipvs完成。

LVS可使用keepalived实现双机热备,也可以通过OSPF使用等价路由的方式,在多个LVS之间进行流量分担,往往作为统一的负载均衡入口,承载大的流量。

有时候需要更加复杂的4层和7层负载均衡,则会在LVS后面加上HAProxy集群,也即将LVS导入的流量,分发到一大批HAProxy上,这些HAProxy可以根据不同的应用或者租户进行隔离,每个租户独享单独的HAProxy,但是所有的租户共享LVS集群。

如果有云环境,则HAProxy可以部署在虚拟机里面,可以根据流量的情况和租户的请求进行动态的创建和删除。

五、数据中心可用区中:接入层Nginx、接入层缓存

在负载均衡之后,是接入网关,或者API网关,往往需要实现很多灵活的转发策略,这里会选择使用Nginx+Lua或者OpenResty做这一层。

由于Nginx本身也有负载均衡机制,有的时候会将HAProxy这一层和Nginx这一层合并,LVS后面直接跟Nginx集群。

接入层作用一:API的聚合

使用微服务之后,后端的服务会拆分的非常的细,因而前端应用如果要获取整个页面的显示,往往需要从多个服务获取数据,将数据做一定的聚合后,方能够显示出来。

如果是网页其实还好,如果你用Chrome的debug模式下,打开一个复杂的电商主页的时候,你会发现这个页面同时会发出很多的http的请求,最终聚合称为一个页面。

如果是APP的话,其实也没有问题,但是会有大量的工作要在客户端做,这样会非常的耗电,用户体验非常不好,因而***有一个地方可以将请求聚合,这就是API网关的职责之一。这样对于前端APP来讲,后端接是似乎是一个统一的入口,则后端的服务的拆分和聚合,灰度发布,缓存策略等全部被屏蔽了。

接入层作用二:服务发现与动态负载均衡

既然统一的入口变为了接入层,则接入层就有责任自动的发现后端拆分、聚合、扩容、缩容的服务集群,当后端服务有所变化的时候,能够实现健康检查和动态的负载均衡。

对于微服务来讲,服务之间也是需要做服务发现的,常见的框架是Dubbo和Spring Cloud,服务的注册中心可以是ZooKeeper、Consul、etcd、Eureka等。

我们以Consul为例子,既然服务之间的调用已经注册到Consul上,则Nginx自然也可以通过Consul来获取后端服务的状态,实现动态的负载均衡。

Nginx可以集成consul-template,可监听Consul的事件, 当已注册service列表或key/value 发生变化时, consul-template会修改配置文件同时可执行一段shell,如nginx reload。

  1. consul-template \    -template "/tmp/nginx.hcl:/var/nginx/nginx.conf:service nginx reload" \ 

consul-template模式配置相对复杂,需要reload nginx。

另一种集成Consul的方式是nginx-upsync-module,可以同步Consul的服务列表或key/value存储,需要重新编译nginx,不需要reload nginx。

  1. upstream test { 
  2.         server 127.0.0.1:11111; 
  3.         # 所有的后端服务列表会从consul拉取, 并删除上面的占位server 
  4.         upsync 127.0.0.1:8500/v1/catelog/service/test upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=off
  5.         # 备份的地址, 保证nginx不强依赖consul 
  6.         upsync_dump_path /usr/local/nginx/conf/servers/servers_test.conf; 

还有一种方式是OpenResty+Lua,相对nginx-upsync-module, 可以加入更多自己的逻辑,init_*_by_lua阶段通过http api获取服务列表载入Nginx内存,并设置timer轮训更新列表,balancer_by_lua阶段读取内存的列表, 设置后端服务器。

Lua实现同样可以不reload nginx,相比nginx-upsync-module来说更加可扩展。

接入层作用三:动静资源隔离、静态页面缓存、页面静态化

为什么静态资源需要隔离呢,静态资源往往变化较少,但是却往往比较大,如果每次都加载,则影响性能,浪费带宽。其实静态资源可以预加载,并且可以进行缓存,甚至可以推送到CDN。

所以应该在接入层Nginx中配置动态资源和静态资源的分离,将静态资源的url导入到Nginx的本地缓存或者单独的缓存层如Varnish或者Squid,将动态的资源访问后端的应用或者动态资源的缓存。

在Nginx中,可以通过配置expires、cache-control、if-modified-since来控制浏览器端的缓存控制。使得浏览器端在一段时间内,对于静态资源,不会重复请求服务端。这一层称为浏览器端的缓存。

当有的请求的确到达了接入层Nginx的时候,也不用总是去应用层获取页面,可以在接入层Nginx先拦截一部分热点的请求。在这里可以有两层缓存。一是Nginx本身的缓存proxy_cache,二是缓存层的Varnish或者Squid。

在使用接入层缓存的时候,需要注意的是缓存key的选择,不应该包含于用户相关的信息,如用户名、地理信息、cookie、deviceid等,这样相当于每个用户单独的一份缓存,使得缓存的***率比较低。

在分离了静态和动态资源之后,就存在组合的问题,可以通过Ajax访问动态资源,在浏览器端进行组合,也可以在接入层进行组合。

如果在接入层聚合,或者Varnish进行聚合,则可以让接入层缓存定时轮询后端的应用,当有数据修改的时候,进行动态页面静态化,这样用户访问的数据到接入层就会被拦截,缺点是更新的速度有些慢,对于大促场景下的并发访问高的页面,可以进行如此的处理。

接入层作用四:动态资源缓存

在动静分离之后,静态页面可以很好的缓存,而动态的数据还是会向后端请求,而动态页面静态化延时相对比较高,而且页面数目多的时候,静态化的工作量也比较大,因而在接入层还可以通过Redis或者Memcached,对动态资源进行缓存。

接入层作用五:资源隔离

接入层的Nginx集群不是一个,而是不同的请求可以有独立的Nginx集群。

例如抢券或者秒杀系统,会成为热点中的热点,因而应该有独立的Nginx集群。

接入层作用六:统一鉴权、认证、过滤

API Gateway的另一个作用是统一的认证和鉴权。

一种是基于session的,当客户端输入用户名密码之后,API Gateway会向后端服务提交认证和鉴权,成功后生成session,session统一放在Redis里面,则接下来的访问全部都带着session进行。

另一种方式是通过统一的认证鉴权中心,分配token的方式进行。

这是一个三角形的结构,当API Gateway接收到登陆请求的时候,去认证中心请求认证和授权,如果成功则返回token,token是一个加密过的字符串,里面包含很多的认证信息,接下来的访问中,API Gateway可以验证这个token是否有效来认证,而真正的服务可以根据token来鉴权。

接入层作用七:限流

在大促过程中,常常会遇到真实的流量远远大于系统测试下来的可承载流量,如果这些流量都进来,则整个系统一定垮掉,***谁也别玩。所以长做的方式是限流。

限流是从上到下贯穿整个应用的,当然接入层作为最外面的屏障,需要做好整个系统的限流。

对于Nginx来讲,限流有多种方式,可以进行连接数限制limit_conn,可以进行访问频率限制limit_req,可以启用过载保护sysgurad模块。

对请求的目标URL进行限流(例如:某个URL每分钟只允许调用多少次)。

对客户端的访问IP进行限流(例如:某个IP每分钟只允许请求多少次)。

对于被限流的用户,可以进行相对友好的返回,不同的页面的策略可以不同。

对于首页和活动页,是读取比较多的,可以返回缓存中的老的页面,或者APP定时刷新。

对于加入购物车、下单、支付等写入请求被限流的,可以返回等待页面,或者返回一个圈圈转啊转,如果过了一段时间还转不出来,就可以返回挤爆了。

对于支付结果返回,如果被限流,需要马上返回错误页面。

接入层作用八:灰度发布与AB测试

在接入层,由于可以配置访问路由,以及访问权重,可以实现灰度发布,或者AB测试,同时上线两套系统,通过切入部分流量的方式,测试新上系统的稳定性或者是否更受欢迎。

作者:刘超,毕业于上海交通大学,15年云计算领域研发及架构经验,先后在EMC,CCTV证券资讯频道,HP,华为,网易从事云计算和大数据架构工作。在工作中积累了大量运营商系统,互联网金融系统,电商系统等容器化和微服务化经验。

责任编辑:武晓燕 来源: 架构师小秘圈
相关推荐

2018-03-12 09:05:48

高并发微服务架构

2018-12-06 14:56:46

微服务隔离熔断

2021-08-09 11:35:40

设计实践应用

2023-08-27 16:13:50

架构微服务器

2011-05-17 14:44:08

云计算云计算平台数据中心

2023-11-24 07:16:10

DDD微服务

2021-10-18 06:54:45

应用服务器微服务

2022-04-25 10:44:08

微服务架构设计

2022-08-14 07:04:44

微服务架构设计模式

2017-02-21 13:16:49

微服务RPC技术

2022-08-08 13:55:47

通信设计模式微服务

2019-10-21 16:54:48

数据库设计SQL

2022-08-07 22:11:25

微服务架构

2017-07-04 17:35:46

微服务架构Spring Clou

2021-09-07 08:23:45

GitOpsCICD

2021-02-10 08:24:47

微服务CICD

2020-04-02 10:37:55

微服务架构数据

2023-10-11 11:37:36

微服务架构

2022-04-23 16:58:24

微服务微服务架构

2017-09-13 13:42:09

微服务缓存架构
点赞
收藏

51CTO技术栈公众号