架构设计中的网络损耗

架构设计中的网络损耗

中国的大网络环境

你出过国吗？或旅游，或出差，或长期工作。你没发现在外国上网跟国内上网的体验完全不同吗？

给你几分钟，你现在回忆一下，在外国上网有什么不同？

你是否发现在外国上网，在浏览器地址栏输入域名，敲下回车键的那一刻，网站立即展现出来？而在中国你的浏览器总是卡那么一下，转一圈（约0.2~1秒的时间）才出来。

这是为什么？

这是因为我们从自己的电脑到达服务器并返回数据经过的路径太长，节点太多造成了。

中国的网络环境是相当复杂：

南北互通问题

带宽容量的问题

层层NAT转发问题

架构设计不合理的问题

GFW过滤的问题

等等

访问过程中每经过一个节点都会造成一定延迟，当我们在浏览器中输入域名，中国DNS解析压力绝对比外国的服务器压力大，这是人口数量决定的。接着由于中国IP资源有限，我们需要层层NAT转发，然后还要被GFW拆包解包判断你的方案是否合规合法，最终到达我们的服务器，现在的云环境，微服务架构等等，大量应用七层负载均衡和代理。

最终使我们无法体验到真正的互联网速度。

架构设计需要考虑网络损耗

硬件造成的网络损耗

网上有大量的架构设计文章，但几乎没有人探讨过，架构设计中的网络损耗问题。

现在的架构设计很多是相互借鉴，堆技术，架构师也多是技术控。不能从产品和用户体验角度思考。

最理想情况是服务器托管在电信机房，服务器网卡直接设置公网IP地址，网关直接指向电信的核心路由器，通过操作系统携带的防火墙控制访问策略。这是我们2005年之前的做法，那时还没有实力购买硬件防火墙。也正是因为这样使用部署过，对比后面架构才意识到我们是不是走偏了。

2005-2010 年我们开始使用 Cisco ASA 系列防火墙，机房分配的IP地址全部绑定在防火墙上，防火墙分为 Inside 和 Outside 两个策略，然后通过ACL将公网IP地址指向到局域网中的服务器上。使用硬件防火墙的确提高了运维效率，同时也提高了安全性。例如 xxx.xxx.xxx.xxx:80 => 172.16.0.10 将某公网IP的80端口指向局域网中的WEB服务器。

与之前相比，之前是从机房核心交换机上直接拉网线插到每台服务上，所有服务器网关指向机房出口路由器。服务器在机房的交换机上交换，出口走机房核心路由器，压力被转嫁。单台服务器故障，不影响整体。

现在的情况，机房一条网线拉过来，插到防火墙，我们的防火墙承担了所有服务器的流量和会话数。如果防火墙挂掉，全玩完，还好思科的设备没有掉过链子。

回到损耗话题，每次进入机房维护服务器，都会看看其他机柜，发现放多公司更多是使用路由器接入，不用防火墙。防火墙放在路由器后面给部分服务器做安全防护。

路由器与防火墙是有差异的。路由器侧重路由，携带了完善的路由协议，而防火墙侧重转发，只有RIP，其他路由协议被阉割（只有RIP，没有OSPF，IS-IS，BGP等等）

我们测试过物理服务器直接设置公网IP的延迟是比经过防火墙要低的，经过路由器的延迟可以忽略不计。

到了2010之后，云计算兴起，少量服务器不再托管，直接购买云服务。所以几乎没有人在托管一两台服务器，服务器网卡直接设置公网IP的做法了。此时的云服务器简称VPS，使用 Xen，OpenVZ 等技术实现，KVM还在孕育中。Xen,OpenVZ 等等都是半虚拟化，也不太成熟，当时体验VPS的整体印象，卡顿，卡顿，还是卡顿。所以我们还是以托管服务器为主。

F5，Array，A10…… 慢慢都用到了项目当中。还有开源的LVS, haproxy, nginx 用的一个爽，用的一个High。我心里清楚，从用户到服务器，中间每经过一个节点，都会造成网络延迟，但是这些技术能不用吗？不能！所以我视而不见。

我发现每经过一个网络设备可能会造成0.2-0.5秒的延迟。

云平台造成的网络损耗

在云平台中，大平台接入层使用的是万兆旗舰网络设备，价格在百万到千万之间。那些小的云平台不太可能使用这种网络设备。

进入云平台后，云平台的网络是SDN（软件定义网络），通过操作系统中的虚拟网络设备，例如网桥，实现平台的网络管理。SDN 能整合所有服务器的网络，有点类似交换机中的生成树VLAN 技术，随意在一组服务器上划分私有网络，映射公网IP地址和端口转发。

配置过linux 系统的小伙伴很容易理解，就是sysctl + iptables +tc 等等工具实现的。

所以云平台的损耗是非常高的，大家在一个共用的SDN下。

很多架构中，无法避免使用 haproxy, nginx 等等再做一层转发。

容器中造成的网络损耗

最近几年容器技术很火，云平台和容器都降低了运维难度和对运维人员的技术能力要求。

容器的网络也是虚拟网络设备技术，大量使用iptables 做IP映射和端口转发。

Kubernetes 中Ingress 是 nginx 实现，使用Istio 实现 sidecar 模式，可谓疯狂，为每个 pod 都做一个 proxy。

这么做有错吗？Google 当然没错，他们会使用旗舰机的网络设备和服务器。

你的公司 40GB的光纤交换机可能都用不起。

微服务造成的网络损耗

现在不懂微服务，都不好意思说自己是架构师。

我以 Spring Cloud 为例，用户经过前文所说的那些网络设备，最终达到微服务网关，这个网关实质上就7层负载均衡，然后转发到 Openfeign 服务，Openfeng 到注册中心获取服务节点，服务节点去配置中心获取配置，完成业务逻辑运算，返回结果给 Openfeign，最后由经网关，再经过一堆网络设备，展现结果给用户。

不知道我说没说明白，我说明白了，你听没听明白。对比上文服务器直接绑定公网IP的做法，你又想到了什么？

微服务的拆分和治理，又引出了一个问题「分布式任务」后面会谈到这个问题。

总结

除了网络延迟损耗，每增加一个节点就会多一个故障节点，如果超时时间设置不合理，就会出现雪崩效应。导致这个链路节点后面所有服务瘫痪。

我曾经写过一篇文章叫《警惕IT黑洞》有兴趣可以看看，在网上可以搜索到，现在我认为应该警惕架构黑洞。

下一讲就讲讲架构设计中的超时时间。