架构：接入层架构演变

  随着互联网行业的发展，服务端的架构也在不断随着行业的发展主键的完善，本文将介绍接入层架构的演变过程，以及各个过程遇到的核心问题。对接入层有一个整体的认知。

单机架构

  有一天，你突然有一个比较好的想法，想实现你创业的梦想，于是你快速开发完的代码，并申请了域名 www.dream.com ，购买了一台云服务器，项目也很快上线。项目一经上线，获得了用户的一致好评，用户量快速增长，单台服务也很快到达瓶颈，每到高峰期，你的网站都会宕机。于是你在思考如何解决当前的问题?

问题：单机瓶颈导致整个服务很快到达瓶颈。

第一次演变：DNS负载均衡

  既然单机存在瓶颈，那就可以引入多台服务器，并且各个服务器上部署相同的代码，来共同分担线上的流量。为了达到这个目标最简单的方式就是配置多个域名的A记录。因为DNS解析时会轮训配置的A记录，以此来达到负载均衡的目的。

  通过向云提供商购买了3个外网IP和3台服务器，暂时缓解了高峰期的宕机问题。但是没过多久这3个服务器也到达了瓶颈。而且偶尔单机的故障也没有太好的解决办法，因为DNS的配置修改存在比较长的延迟。与此同时每次扩容都需要购买外网IP。作为一个初创团队，这也是一比开销。

问题：通过DNS做负载均衡存在成本高，延迟高的问题

第二次演变：7层负载均衡

  于是，你开始了第二次架构演变，目前需要解决的问题是：如何能够快速的扩缩容？如何能够快速下线一台指定的服务器来解决单机问题？
  通过调研你发现，nginx这个组件可以解决你的问题。通过nginx来承接外网流量，内网流量调度交由nginx来完成，在nginx这一层，可以灵活的解决上面提的问题。同时只需要用一个外网IP即可，节省了这部分的花销。

  通过上面的调整，你可以快速对服务进行扩容，服务器的容量永远都不再是瓶颈了，你乐滋滋的看着自己的天才构想。但是好景不长，单台nginx成了瓶颈，nginx的宕机导致所有流量没有办法转发到服务器，整个项目出现了比较长的故障。

问题：Nginx虽然解决了后端实例的水平扩容问题，但是Nginx的单机问题成为整个服务的瓶颈。

第三次演变：4层负载均衡

  既然1台Nginx存在瓶颈，也可以参考之前的思路，使用多台Nginx实例，如果引入多台Nginx，那么就需要考虑如果对Nginx上层的流量进行分流。幸运的是我们已经有了现成的方案LVS，LVS是一个四层负载均衡器，引入LVS后的接入层架构：

  引入四层负载均衡器之后，我们方便的对7层负载均衡进行横向扩容。当LVS工作在DR模式时，只做请求转发，性能很高。在4层负载均衡之前再使用DNS轮训的方式，可以大大增加接入层的能力。但是又有问题了，LVS成了流量的入口，他的可用性直接觉得了整个架构的稳定性，虽然吞吐提高了，但是稳定性成了不确定的点。

问题：LVS解决了7层负载均衡的水平扩容问题，但是单点LVS导致架构稳定性问题。

第四次演变：LVS+keepalived

  一台LVS存在单点问题，那么可以使用两台LVS实例，并且通过keepalived的方式将两台LVS做双机热备，当主机挂了，会通过keepalived自动选择备机继续提供服务，提高服务的容错性。

  至此，我们的服务架构已经初见规模，并且可以承担比较大的流量，服务的稳定性也有很大的提升。本以为可以稍作喘息，但新的挑战又来了。我们的产品中有大量的用户图片，而我们的用户来自全国各地， 而我们的服务器只部署在特定的几个地方。导致用户的体检不一致，远离服务器的位置用户体检就会稍差一些。除此之外，过多的图片请求也带来了带宽的损耗。

第五次演变：就近访问

  图片和视频是一种相对特殊的资源，一旦创建，除了删除是不会被修改的，所以就很方便做缓存。为了对于这些静态资源加速，我们可以进行特殊处理，把这些静态资源分发到全国各地，请求时根据用户请求的IP
地址来选择合适的数据存储位置。以此来提供更流畅的体验，这种技术我们称为内容分发网络CDN，现在我们的整个接入层架构如下：

  对于静态资源，我们选择特定的域名，然后通过域名的CNAME记录指向我们的CDN加速域名，最后再通过智能DNS根据用户请求的IP地址，选择合适的 CDN节点，并实现了就近访问，与此同时，这些静态资源的请求也不会直接访问到我们的计算资源。节省了比较多的网络带宽。

总结

  通过这几次的演变，我们搭建除了一个具有灵活伸缩性，高可用的接入层系统架构，但是这一些还远远没有结束，我们还是有很多的挑战需要面对。例如如何解决多运营商间的高速跨运营商访问？DNS域名解析出现问题如何容灾？剩下的部分先留个坑，后面再做分析。