未来已来，只是不均衡地分布在当下

大家好，我是菜农，欢迎来到我的频道。

(资料图片仅供参考)

近年来 Web 3 的概念在程序员的小圈子也几乎是人尽皆知了。功能再强，噱头再足，但是如果访问速度没有跟上，一起都是浮云。哪怕拿现在已经成熟的 Web 2.0来说，内容也相当丰富，动态网页、个性化内容、电子交易数据等。但是内容逐渐丰富，人们的访问速度却逐渐变慢，使用体验也会随之下降。因此对于动态内容的加速也尤为重要，而这篇，我们将了解有几种加速方式可以实际改善我们使用体验。

经典的 MVC 架构分为了三层，分别是：

表现层是 Web 系统与外部系统的交互界面，这层负责接收用户端的 HTTP 内容访问请求，从文件系统中读取静态文件提供给用户，需要时向中间的应用逻辑层发起请求。

业务逻辑层是 Web 系统的核心层，负责处理所有业务逻辑和动态内容的生成。内容的动态生成通常涉及个性化内容处理、数据处理等工作，因此需要与前端的表现层、后端的数据访问层通信。

数据访问层位于系统的后端，负责管理Web系统的主要信息和数据存储，通常由数据库服务器和存储设备组成。

那么在我们已有认知的加速处理方案中，位当其先的要数 CDN 处理了。

对于CDN 这个名词，大家大可以望文生义：Content Distribute Network，也就是 内容分发网络。CDN 的工作很纯粹：将内容从源站传递到用户端。

说到 CDN 的认知，我们就需要先认知什么是 互联网，互联网这个词对于程序员乃至大部分用户来说已经是印着脑子里的东西了。但是我们常说的互联网，是指广义上的互联网，，由两层组成：一层是以 TCP/IP 为代表的网络层（四层协议）；另一层是以万维网 WWW 为代表的应用层（七层协议）。目前普遍存在的一个认识误区也就是家好难过个互联网和万维网混为一谈。

可理解为 狭义的互联网。实际上是广义互联网的下层，是网络的基础，这一层的主要作用是通过计算机之间的互联，将各种信息的数据报文以极低的成本进行传输，俗称 管道。

互联网的设计理念是：网络是中立和无控制的，任何人都没有决定权；网络是与应用无关的，它的任务就是如何更好地将数据包进行端到端的传输。

可理解为 广义的互联网。这一层包括很多种类型的流量和应用，所有SP（Service Provider 服务提供商）提供的都是这些用户看得见、摸得着的应用。

两者的区别：以铁路为例子的话，*互联网是铁路轨道和信号系统，万维网则是在铁路上运行的列车之一。

有了CDN之后会极大地简化网站的系统维护工作量，网站维护人员只需将网站内容注入CDN的系统，通过CDN部署在各个物理位置的服务器进行全网分发，就可以实现跨运营商、跨地域的用户覆盖。由于CDN将内容推送到网络边缘，大量的用户访问被分散到网络边缘，就不再对网站出口、互联互通点的资源挤占，也不再需要跨越长距离IP路由了。

DNS 服务器根据用户 IP 地址，将域名解析成相应节点的缓存服务器 IP 地址，实现用户就近访问。使用 CDN 服务的网站，只需将其域名解析权交给 CDN 的 GSLB 设备，将需要分发的内容注入 CDN，就可以实现内容加速了。

说到这里文章当然不可能就高一段落了，否则也太水了，我们近而深究下为什么 CDN 可以实现加速？究其原因还是逃脱不了 缓存定理 。

Web 网站借助 CDN 技术能够获得更好的扩展性和高性能，关于这一优点已经是无可争议的事实了。那么其核心就在于 CDN 采用的缓存（Caching）和复制（Replication）机制。其中缓存是将最近经常被访问的原服务器拥有的内容复制到边缘服务器上，可被视为具有特定策略的复制。

CDN 的复制机制是指将源 Web 系统逻辑架构的各个层次的相应部分复制到边缘服务器上，以实现缓解源系统的处理压力 ，主要表现在 Web 传统的三层模型中：

上面说到了 CDN 的复制机制能够有效提升动态内容的访问速度。

边缘计算用于将应用程序、数据和计算能力（服务）从网络中的少量集中点推送到网络的逻辑边缘位置。边缘计算复制并分发在多个分布式网络中的Web服务器中保存的信息片段。这一层复制能力直接将业务处理逻辑和数据层的访问能力也复制到了各个边缘节点上，进而利用边缘计算平台提供分发服务的同时减少从企业读取数据的次数和读取数据的大小，降低系统的响应延迟。

在边缘计算能力分布后，源站提供的数据存储仍然还是单一一个，因此边缘服务器上的应用逻辑只能共享集中化的系统数据库。在这种情况下，对于那些瓶颈在后端数据访问层而不是业务逻辑层的 Web 应用，还是难以解决系统的扩展性和性能问题。因此就需要考虑用 CDN 对应用数据进行复制和管理，利用边缘服务器代替源站 Web 系统的后台数据访问层中的数据库系统。

我们通常的处理方式是将业务逻辑层处理过/查询过的数据进行边缘服务器的复制，这种查询结果的缓存技术影响效能的关键在于缓存的命中率。为了使得应用逻辑查询的结果能够高频率地被后续查询请求所命中，我们就需要提高以及优化查询匹配引擎。

在数据缓存层面最常面临的问题也是 缓存一致性 的问题，不过目前存在多种算法以解决分布式缓存的问题，这里就不再进行赘述。

我们在软件层面利用 CDN 以及复制计算能力为加速做出了不小的努力。但有一点不容忽视，那就是网络。

应用加速网络（Application Delivery Networking，ADN），利用网络优化和加速设备，确保客户业务应用能够快速、安全、可靠地交付给用户。应用加速网络实际上是传统的网络负载均衡的升级和扩展，综合使用了负载平衡、TCP 优化管理、链接管理、SSL VPN、压缩优化、智能网络地址转换、高级路由、智能端口镜像等各种技术。

如何能够让广域网像局域网一样工作

我们都知道广域网的传输范围大于局域网，而城域网又大于广域网。当然我们这里不做过多的扩展延伸，我们只讨论广域网的问题。

衡量广域网传输性能和质量的主要指标是带宽和时延。跟局域网相比，广域网的带宽更低，时延更大，而这也是很多小伙伴家里宽带测试的常见误区，带宽大不一定网速就快，时延是个很重要的影响因素。

传输时延是由多方面的原因造成的：

那么要进行广域网加速，就需要从以上几个问题入手：

网络带宽不足问题

这里主要涉及的技术就是数据压缩和缓存技术。其次，针对广域网时延问题，目前最常用的办法是在广域网的两端成对部署设备，通过对TCP协议进行优化，实现整个传输过程的优化。最后，应用协议也存在低效的问题，一般是从应用层优化本身来做，即针对应用协议进行传输的改进，比如采用通过预测客户行为做一些数据包的提前发送等技术，同时缓存的应用也是一个手段。

TCP协议优化

好了，以上便是本篇的所有内容，如果觉得对你有帮助的小伙伴不妨点个关注做个伴，便是对小菜最大的支持。不要空谈，不要贪懒，和小菜一起做个吹着牛X做架构的程序猿吧~ 咱们下文再见！

今天的你多努力一点，明天的你就能少说一句求人的话！

我是小菜，一个和你一起变强的男人。

微信公众号已开启，菜农曰，没关注的同学们记得关注哦！

标签： 负载均衡 数据访问 服务器上