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

 这个系列是微服务高并发设计,所以我们先从最外层的接入层入手,看都有什么样的策略保证高并发。接入层的架构如下图所示: 接下来我们依次解析各个部分以及可以做的优化。 一、数据中心之外:DNS,HttpDNS,GSLB当我们要访问一个网站的服务的时候,首先访问的肯定是一个域名,然后由DNS,将域名解析为IP地址。我们首先先通过DNS访问数据中心中的对象存储上的静态资源为例子,看一看整个过程。我们建议将例如文件,图片,视频,音频等静态资源放在对象存储中,直接通过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.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和springcloud,服务的注册中心可以是zookeeper, consul, etcd, eureka等。我们以consul为例子,既然服务之间的调用已经注册到consul上,则nginx自然也可以通过consul来获取后端服务的状态,实现动态的负载均衡。nginx可以集成consul-template,可监听consul的事件, 当已注册service列表或key/value 发生变化时, consul-template会修改配置文件同时可执行一段shell, 如 nginx reload
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。
upstream test {
       server 127.0.0.1:11111;
       # 所有的后端服务列表会从consul拉取, 并删除上面的占位server
       upsync 127.0.0.1:8500/v1/catelog/service/test upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=off;
       # 备份的地址, 保证nginx不强依赖consul
       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测试,同时上线两套系统,通过切入部分流量的方式,测试新上系统的稳定性或者是否更受欢迎。

相关内容推荐