Home | 简体中文 | 繁体中文 | 杂文 | 知乎专栏 | Github | OSChina 博客 | 云社区 | 云栖社区 | Facebook | Linkedin | 视频教程 | 打赏(Donations) | About
知乎专栏多维度架构 微信号 netkiller-ebook | QQ群:128659835 请注明“读者”

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

3.2.1. 硬件造成的网络损耗

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

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

最理想情况是服务器托管在电信机房,服务器网卡直接设置公网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秒的延迟。

3.2.2. 云平台造成的网络损耗

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

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

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

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

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

3.2.3. 容器中造成的网络损耗

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

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

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

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

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

3.2.4. 微服务造成的网络损耗

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

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

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

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