这个系列是微服务高并发设计，所以我们先从最外层的接入层入手，看都有什么样的策略保证高并发。
接入层的架构如下图所示：
接下来我们依次解析各个部分以及可以做的优化。
一、数据中心之外：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测试，同时上线两套系统，通过切入部分流量的方式，测试新上系统的稳定性或者是否更受欢迎。
转至https://www.cnblogs.com/163yun/p/8867408.html