西游记视角解读“计算机网络协议”！我他喵直接好家伙

作者：死性Oo不改2502917357 | 来源：互联网 | 2023-07-01 20:02

前言这是一个有关计算机网络协议的故事。一家之言，不必当真。一、我佛造经传极乐话说我佛如来为度化天下苍生，有三藏真经，可劝人为善。

前言

这是一个有关计算机网络协议的故事。一家之言&＃xff0c;不必当真。

一、我佛造经传极乐

话说我佛如来为度化天下苍生&＃xff0c;有三藏真经&＃xff0c;可劝人为善。

就如图中所示&＃xff0c;真经所藏之处&＃xff0c;在于云端。佛祖所管辖之下&＃xff0c;有四个区域Region&＃xff0c;称为四大部洲&＃xff0c; 一是东胜神洲&＃xff0c;二是南赡部洲&＃xff0c;三是西牛贺洲&＃xff0c;四是北俱卢洲。

我佛所在西牛贺洲&＃xff0c;是主站点。

在每个区域Region&＃xff0c;为保证真经永固&＃xff0c;设置多个藏经楼&＃xff0c;称为可用区&＃xff08;Available Zone&＃xff09;。

每个藏经楼里面是一排一排的柜子&＃xff0c;称为机柜&＃xff0c;里面有一排一排的格子&＃xff0c;称为服务器&＃xff0c;经文就摆放在格子中。

在藏经楼中&＃xff0c;柜子根据经文分门别类的组织起来&＃xff0c;由不同的神仙进行管理&＃xff0c;管理一个柜子的经文的神仙&＃xff0c;访问这里面经文的钥匙就在他手里&＃xff0c;称为接入层神仙&＃xff08;接入层交换机&＃xff09;。

多个接入层神仙被一组汇聚层神仙&＃xff08;汇聚层交换机&＃xff09;管着&＃xff0c;多个汇聚层的神仙被一组核心层神仙&＃xff08;核心交换机&＃xff09;管着。

神仙体系组织严格&＃xff0c;层次分明&＃xff0c;不同的接入层神仙交换经文&＃xff0c;要通过汇聚层神仙同意&＃xff0c;不同的汇聚层神仙交换经文&＃xff0c;需要核心层神仙同意。

经文的看守要万无一失&＃xff0c;因而每一层都是分组看护&＃xff0c;互相监督&＃xff0c;互相备份&＃xff0c;称为堆叠。

虽说每个柜子里面放满了经文&＃xff0c;为了防止经文被偷听偷看&＃xff0c;经文的内容是被仙术封装在一个虚拟的私密空间里面&＃xff0c;虽然有人可能会偷到物质的经文&＃xff0c;但是没有仙术打开这个私密空间&＃xff0c;看到的经文如同空白的一样。这个虚拟的私密空间称为VPC。

要解读经文&＃xff0c;需要使用每一格中一个不起眼的法宝&＃xff0c;就是称为Openvswitch的虚拟交换机&＃xff0c;顾名思义就是起到经文在虚拟私密空间和物理空间之间的转换作用。

Openvswitch如何转换呢&＃xff1f;使用的是一种称为VXLAN的封装技术&＃xff0c;但是必须要事先知道芝麻开门的ID&＃xff0c;也即VXLAN ID&＃xff0c;才能看到经文的真正内容。

在虚拟的空间中&＃xff0c;放着真正可以解读的真经。

真经有法一藏&＃xff0c;谈天&＃xff1b;论一藏&＃xff0c;说地&＃xff1b;经一藏&＃xff0c;度鬼&＃xff1b;三藏共计三十五部&＃xff0c;该一万五千一百四十四卷&＃xff0c;乃是修真之径&＃xff0c;正善之门。

看来已经前中后台分离&＃xff0c;分为基础服务层&＃xff0c;组合服务层&＃xff0c;Controller层&＃xff0c;共三十五个模块&＃xff0c;一万五千多个服务&＃xff0c;真是微服务架构啊。

如何能够不要迷失在这个一万五千卷经文中&＃xff0c;也是很有挑战的事情&＃xff0c;需要一个索引和指南&＃xff0c;这就是常说的RPC框架和服务注册与发现中心。

为了方便诸多僧侣前来取经&＃xff0c;灵山脚下会有一个统一的入口地址&＃xff0c;这里有一个神仙&＃xff0c;称为金顶大仙&＃xff0c;专门来接应取经人的。

由于前来取经的人很多&＃xff0c;同时经文也很多&＃xff0c;所以金顶大仙多起到负载均衡的作用&＃xff0c;将不同的取经人引领到不同的藏经楼&＃xff0c;访问不同的经文。

金顶大仙所在的灵山脚下&＃xff0c;是一个世界知名的地址&＃xff0c;称为外网IP地址&＃xff0c;这个地址是全球可定位的&＃xff0c;所有的取经人都先到这个地方&＃xff0c;金顶大仙通过NAT规则&＃xff0c;将外网IP地址&＃xff0c;变成藏经楼的私有IP地址&＃xff0c;例如2号藏经楼三楼&＃xff0c;4号藏经楼五楼等。在灵山藏经楼里面&＃xff0c;是通过私有IP地址定位的。

真经已经准备好&＃xff0c;就差东土取经人了。

二、观音奉旨上长安

可是佛祖愁啊&＃xff0c;是这样说的&＃xff1a;我待要送上东土&＃xff0c;叵耐那方众生愚蠢&＃xff0c;毁谤真言&＃xff0c;不识我法门之要旨&＃xff0c;怠慢了瑜迦之正宗。怎么得一个有法力的&＃xff0c;去东土寻一个善信&＃xff0e;教他苦历千山&＃xff0c;远经万水&＃xff0c;到我处求取真经&＃xff0c;永传东土&＃xff0c;劝他众生&＃xff0c;却乃是个山大的福缘&＃xff0c;海深的善庆、谁肯去走一遭来&＃xff1f;

真经就在灵山&＃xff0c;可以东土之人愚钝&＃xff0c;不知道灵山咋办呢&＃xff1f;要一个法力无边的人告诉他们呀。而且最好能够告诉全世界&＃xff0c;灵山这里有真经。

好在有观音菩萨&＃xff0c;道&＃xff1a;“弟子不才&＃xff0c;愿上东土寻一个取经人来也。”&＃xff0c;观音菩萨有什么法力呢&＃xff1f;当然是BGP协议了。

刚才那张图画的是一个可用区的情况&＃xff0c;对于多个可用区的情况&＃xff0c;我们可以隐去计算节点的情况&＃xff0c;将外网访问区域放大。

外网IP是放在虚拟网关的外网网口上的&＃xff0c;这个IP如何让全世界知道呢&＃xff1f;在核心交换外面是安全设备&＃xff0c;然后就是边界路由器。边界路由器会和多个运营商连接&＃xff0c;从而每个运营商都能够访问到这个网站。边界路由器可以通过BGP协议&＃xff0c;将自己数据中心里面的外网IP向外广播&＃xff0c;也就是告诉全世界&＃xff0c;如果要访问这些外网IP&＃xff0c;都来我这里。

每个运营商也有很多的路由器、很多的点&＃xff0c;于是就可以将如何到达这些IP地址的路由信息&＃xff0c;广播到全国乃至全世界。

厉害吧&＃xff0c;这是我佛如来告诉观音菩萨的&＃xff1a;“这一去。要踏看路道&＃xff0c;不许在霄汉中行&＃xff0c;须是要半云半雾&＃xff1b;目过山水&＃xff0c;谨记程途远近之数&＃xff0c;叮咛那取经人。“

就是说你去东土的路上&＃xff0c;经过了哪些道路&＃xff0c;要记住路径&＃xff0c;要记住远近&＃xff0c;才能告诉取经人这一路应该怎么走。

三、玄奘秉诚建大会

当观音菩萨来到东土大唐&＃xff0c;正看到玄奘法师正坐在高台上&＃xff0c;带领众人诵经&＃xff0c;念一会《受生度亡经》&＃xff0c;谈一会《安邦天宝篆》&＃xff0c;又宣一会《劝修功卷》。

菩萨近前来&＃xff0c;叫道&＃xff1a;“那和尚&＃xff0c;你只会谈小乘教法&＃xff0c;可会谈大乘么&＃xff1f;”玄奘闻言&＃xff0c;心中大喜&＃xff0c;翻身跳下台来&＃xff0c;对菩萨起手道&＃xff1a;“老师父&＃xff0c;弟子失瞻&＃xff0c;多罪。见前的盖众僧人&＃xff0c;都讲的是小乘教法&＃xff0c;却不知大乘教法如何。”菩萨道&＃xff1a;“你这小乘教法&＃xff0c;度不得亡者超升&＃xff0c;只可浑俗和光而已。我有大乘佛法三藏&＃xff0c;能超亡者升天&＃xff0c;能度难人脱苦&＃xff0c;能修无量寿身&＃xff0c;能作无来无去。”

你看&＃xff0c;在西方极乐净土&＃xff0c;我佛已经有了更牛的佛经&＃xff0c;遥远的东方&＃xff0c;还在读本土的僧人早期从西方传过来的经。

这种模式&＃xff0c;称为CDN。

我们部署应用的时候&＃xff0c;一般会把静态资源保存在两个地方&＃xff0c;一个是nginx后面的varnish缓存里面&＃xff0c;一般是静态页面&＃xff1b;对于比较大的、不经常更新的静态图片&＃xff0c;会保存在对象存储里面。这两个地方的静态资源都会配置CDN&＃xff0c;将资源下发到边缘节点。

最初佛祖传经&＃xff0c;都是口口相传&＃xff0c;经文都会记在高僧大德的心里&＃xff0c;随着高僧云游天下&＃xff0c;随着庙宇遍布天下&＃xff0c;佛经从而遍布天下。这就相当于将佛经缓存在边缘节点。

配置了CDN之后&＃xff0c;权威DNS服务器上&＃xff0c;会为静态资源设置一个CNAME别名&＃xff0c;指向另外一个域名cdn.com&＃xff0c;返回给本地DNS服务器。

当本地DNS服务器拿到这个新的域名时&＃xff0c;需要继续解析这个新的域名。这个时候&＃xff0c;再访问的时候就不是原来的权威DNS服务器了&＃xff0c;而是 cdn.com 的权威DNS服务器。这是CDN自己的权威DNS服务器。

在这个服务器上&＃xff0c;还是会设置一个CNAME&＃xff0c;指向另外一个域名&＃xff0c;也即CDN网络的全局负载均衡器。

本地DNS服务器去请求CDN的全局负载均衡器解析域名&＃xff0c;全局负载均衡器会为用户选择一台合适的缓存服务器提供服务&＃xff0c;将IP返回给客户端&＃xff0c;客户端去访问这个边缘节点&＃xff0c;下载资源。缓存服务器响应用户请求&＃xff0c;将用户所需内容传送到用户终端。

如果这台缓存服务器上并没有用户想要的内容&＃xff0c;那么这台服务器就要向它的上一级缓存服务器请求内容&＃xff0c;直至追溯到网站的源服务器&＃xff0c;将内容拉到本地。

CDN的全局负载均衡策略&＃xff0c;就相当于当僧人们想读佛经的时候&＃xff0c;不必要都去西天&＃xff0c;而是可以就近去问&＃xff0c;周围有没有庙宇&＃xff0c;然后向庙宇的师傅去请教佛经。

然而缓存的佛经当然是比不上西天取到的经文更新&＃xff0c;所以东土由于离西天较远&＃xff0c;缓存的还是小乘佛教&＃xff0c;要读大乘佛教&＃xff0c;就要去西天取经&＃xff0c;称为回源。

四、观音显像化金蝉

观音菩萨打算度化玄奘法师&＃xff0c;回源去西天取经。

可是怎么去呢&＃xff0c;地址在哪里呢&＃xff1f;玄奘法师只听说西天&＃xff0c;不知道具体的地址&＃xff0c;这就要问观音菩萨了。

这个时候&＃xff0c;大家才知道&＃xff0c;西天在灵山大雷音寺&＃xff0c;距此十万八千里。

这个过程称为DNS解析。

当在手机上面打开一个App的时候&＃xff0c;首先要做的事情就是解析这个网站的域名。

在手机运营商所在的互联网区域里&＃xff0c;有一个本地的DNS&＃xff0c;手机会向这个DNS请求解析DNS。当这个DNS本地有缓存&＃xff0c;则直接返回&＃xff1b;如果没有缓存&＃xff0c;本地DNS才需要递归地从根DNS服务器&＃xff0c;查到.com的顶级域名服务器&＃xff0c;最终查到权威DNS服务器。

如果你使用云平台的时候&＃xff0c;配置了智能DNS和全局负载均衡&＃xff0c;在权威DNS服务中&＃xff0c;一般是通过配置CNAME的方式&＃xff0c;我们可以起一个别名&＃xff0c;例如 vip.yourcomany.com &＃xff0c;然后告诉本地DNS服务器&＃xff0c;让它请求GSLB解析这个域名&＃xff0c;GSLB就可以在解析这个域名的过程中&＃xff0c;通过自己的策略实现负载均衡。

GSLB通过查看请求它的本地DNS服务器所在的运营商和地址&＃xff0c;就知道用户所在的运营商和地址&＃xff0c;然后将距离用户位置比较近的Region里面&＃xff0c;将三个本地负载均衡的公网IP地址&＃xff0c;返回给本地DNS服务器。本地DNS解析器将结果缓存后&＃xff0c;返回给客户端。

对于手机APP来说&＃xff0c;可以绕过刚才的传统DNS解析机制&＃xff0c;直接只要HTTPDNS服务&＃xff0c;通过直接调用HTTPDNS服务器&＃xff0c;得到这三个本地负载均衡的公网IP地址。

这个公网IP地址&＃xff0c;就是金顶大仙所在的位置。其实这个时候&＃xff0c;金顶大仙已经在等待了。

这个时候&＃xff0c;李世民突然开始说话了&＃xff0c;曰&＃xff1a;“谁肯领朕旨意&＃xff0c;上西天拜佛求经&＃xff1f;“ 并愿意买下观音手中的两件宝物&＃xff0c;“锦澜袈裟”一领&＃xff0c;“九环锡杖”一根&＃xff0c;佛祖说过&＃xff1a;”若有取经人坚心来此&＃xff0c;穿我的袈裟&＃xff0c;免堕轮回&＃xff1b;持我的锡枚&＃xff0c;不遭毒害。“

玄奘法师回答&＃xff1a;“贫僧不才&＃xff0c;愿效犬马之劳&＃xff0c;与陛下求取真经&＃xff0c;祈保我王江山永固。”

这个时候&＃xff0c;菩萨说了&＃xff1a;“西天路远&＃xff0c;更多虎豹妖魔。只怕有去无回&＃xff0c;难保身命。”

玄奘道&＃xff1a;“我已发了弘誓大愿&＃xff0c;不取真经&＃xff0c;永堕沉沦地狱。“

其实这里的对话是很有意思的&＃xff0c;玄奘法师回复李世民的和回复观音菩萨的不同。

这个时候&＃xff0c;李世民作为世俗的君王&＃xff0c;已经想求取真经了&＃xff0c;也就是东土大唐作为客户端&＃xff0c;要发起对于服务端的请求了。但是玄奘法师知道&＃xff0c;唐王李世民去取经&＃xff0c;求的是江山永固。所以李世民的请求是应用层的&＃xff0c;发起的是HTTP的协议&＃xff0c;在HTTP的请求正文中&＃xff0c;怕是写的“江山永固”四个字。

而玄奘法师回复观音菩萨的时候&＃xff0c;说的就不同了&＃xff0c;是一种对于真经和佛法本身的坚持。所以玄奘法师是TCP层的&＃xff0c;TCP是面向连接的&＃xff0c;TCP 是靠谱的协议&＃xff0c;但是这不能说明它面临的网络环境好。从 IP 层面来讲&＃xff0c;如果网络状况的确那么差&＃xff0c;是没有任何可靠性保证的&＃xff0c;而作为 IP 的上一层 TCP 也无能为力&＃xff0c;唯一能做的就是更加努力&＃xff0c;不断重传&＃xff0c;通过各种算法保证。也就是说&＃xff0c;对于 TCP 来讲&＃xff0c;IP 层你丢不丢包&＃xff0c;我管不着&＃xff0c;但是我在我的层面上&＃xff0c;会努力保证可靠性。

这一点在流沙河有了验证。观音菩萨度化沙悟净的时候&＃xff0c;沙悟净说&＃xff1a;“菩萨&＃xff0c;我在此间吃人无数&＃xff0c;向来有几次取经人来&＃xff0c;都被我吃了。凡吃的人头&＃xff0c;抛落流沙&＃xff0c;竟沉水底(这个水&＃xff0c;鹅毛也不能浮)&＃xff0c;惟有九个取经人的骷髅&＃xff0c;浮在水面&＃xff0c;再不能沉。我以为异物&＃xff0c;将索儿穿在一处&＃xff0c;闲时拿来顽耍&＃xff0c;这去&＃xff0c;但恐取经人不得到此&＃xff0c;却不是反误了我的前程也&＃xff1f;”菩萨日&＃xff1a;“岂有不到之理&＃xff1f;你可将骷髅地挂在头顶下&＃xff0c;等候取经入&＃xff0c;自有用处。”

所以沙悟净脖子上这九个骷髅&＃xff0c;是唐三藏的前九辈子&＃xff0c;一旦吃了&＃xff0c;就不断的重试。

为了能够实现重试&＃xff0c;实现TCP的可靠性&＃xff0c;客户端和服务器需要建立连接。

HTTPS协议是基于TCP协议的&＃xff0c;因而要先建立TCP的连接。在这个例子中&＃xff0c;TCP的连接是从手机上的App和负载均衡器SLB之间的。也就是唐僧和金顶大仙之间&＃xff0c;到了金顶大仙&＃xff0c;就不怕了&＃xff0c;会指引到佛祖那里的。

尽管中间要经过很多的路由器和交换机&＃xff0c;但是TCP的连接是端到端的。TCP这一层和更上层的HTTPS无法看到中间的包的过程。尽管建立连接的时候&＃xff0c;所有的包都逃不过在这些路由器和交换机之间的转发&＃xff0c;转发的细节我们放到那个下单请求的发送过程中详细解读&＃xff0c;这里只看端到端的行为。

对于TCP连接来讲&＃xff0c;需要通过三次握手建立连接&＃xff0c;为了维护这个连接&＃xff0c;双方都需要在TCP层维护一个连接的状态机。

一开始&＃xff0c;客户端和服务端都处于CLOSED状态。服务端先是主动监听某个端口&＃xff0c;处于LISTEN状态。然后客户端主动发起连接SYN&＃xff0c;之后处于SYN-SENT状态。服务端收到发起的连接&＃xff0c;返回SYN&＃xff0c;并且ACK客户端的SYN&＃xff0c;之后处于SYN-RCVD状态。

客户端收到服务端发送的SYN和ACK之后&＃xff0c;发送ACK的ACK&＃xff0c;之后处于ESTABLISHED状态。这是因为&＃xff0c;它一发一收成功了。服务端收到ACK的ACK之后&＃xff0c;处于ESTABLISHED状态&＃xff0c;因为它的一发一收也成功了。

当TCP层的连接建立完毕之后&＃xff0c;接下来轮到HTTPS层建立连接了&＃xff0c;在HTTPS的交换过程中&＃xff0c;TCP层始终处于ESTABLISHED。

对于HTTPS&＃xff0c;客户端会发送Client Hello消息到服务器&＃xff0c;用明文传输TLS版本信息、加密套件候选列表、压缩算法候选列表等信息。另外&＃xff0c;还会有一个随机数&＃xff0c;在协商对称密钥的时候使用。

然后&＃xff0c;服务器会返回Server Hello消息&＃xff0c;告诉客户端&＃xff0c;服务器选择使用的协议版本、加密套件、压缩算法等。这也有一个随机数&＃xff0c;用于后续的密钥协商。

然后&＃xff0c;服务器会给你一个服务器端的证书&＃xff0c;然后说&＃xff1a;“Server Hello Done&＃xff0c;我这里就这些信息了。”

客户端当然不相信这个证书&＃xff0c;于是你从自己信任的CA仓库中&＃xff0c;拿CA的证书里面的公钥去解密电商网站的证书。如果能够成功&＃xff0c;则说明电商网站是可信的。这个过程中&＃xff0c;你可能会不断往上追溯CA、CA的CA、CA的CA的CA&＃xff0c;反正直到一个授信的CA&＃xff0c;就可以了。

其实观音菩萨手里的锡杖和袈裟&＃xff0c;就相当于佛祖办法的证书&＃xff0c;保证西行路上的安全&＃xff0c;玄奘法师这个网络包别被别人吃了&＃xff0c;或者篡改。

就像误入小雷音一集中&＃xff0c;白眉老佛想吃了唐僧肉&＃xff0c;自己披上袈裟&＃xff0c;西天取经&＃xff0c;求得正果。

当然&＃xff0c;一开始观音菩萨拿出锡杖和袈这个证书的时候&＃xff0c;大家也不相信&＃xff0c;所以需要观音菩萨现出真身&＃xff0c;作为CA&＃xff0c;证明给客户端&＃xff0c;唐王李世民和玄奘法师才下拜。

证书验证完毕之后&＃xff0c;觉得这个服务端是可信的&＃xff0c;于是客户端计算产生随机数字Pre-master&＃xff0c;发送Client Key Exchange&＃xff0c;用证书中的公钥加密&＃xff0c;再发送给服务器&＃xff0c;服务器可以通过私钥解密出来。

接下来&＃xff0c;无论是客户端还是服务器&＃xff0c;都有了三个随机数&＃xff0c;分别是&＃xff1a;自己的、对端的&＃xff0c;以及刚生成的Pre-Master随机数。通过这三个随机数&＃xff0c;可以在客户端和服务器产生相同的对称密钥。

有了对称密钥&＃xff0c;客户端就可以说&＃xff1a;“Change Cipher Spec&＃xff0c;咱们以后都采用协商的通信密钥和加密算法进行加密通信了。”

然后客户端发送一个Encrypted Handshake Message&＃xff0c;将已经商定好的参数等&＃xff0c;采用协商密钥进行加密&＃xff0c;发送给服务器用于数据与握手验证。

同样&＃xff0c;服务器也可以发送Change Cipher Spec&＃xff0c;说&＃xff1a;“没问题&＃xff0c;咱们以后都采用协商的通信密钥和加密算法进行加密通信了”&＃xff0c;并且也发送Encrypted Handshake Message的消息试试。

当双方握手结束之后&＃xff0c;就可以通过对称密钥进行加密传输了。

五、唐王素酒送三藏

玄奘这个网络包要发出了。

太宗设朝&＃xff0c;聚集文武&＃xff0c;要去送行。李世民送给玄奘三个东西。

上一节说了太宗是应用层&＃xff0c;关注保大唐江山永固&＃xff0c;玄奘是TCP层&＃xff0c;要通过坚定的意志到达西天。

李世民给的第一个东西是通关文牒&＃xff0c;这个是IP层的&＃xff0c;将来要通过这个文牒通过一个个城关。

第二个东西是紫金钵盂&＃xff0c;这个用于玄奘法师到了某个城市里面化斋&＃xff0c;同时打听路的时候使用&＃xff0c;这个是一个MAC层的。

第三个东西是白马一匹&＃xff0c;作为远程脚力&＃xff0c;这个是物理层的。

最后&＃xff0c;太宗敬了玄奘一杯素酒&＃xff0c;言道&＃xff1a;宁恋本乡一捻土&＃xff0c;莫爱他乡万两金。三藏方悟捻土之意&＃xff0c;复谢恩饮尽&＃xff0c;辞谢出关而去。

当客户端和服务端之间建立了连接后&＃xff0c;接下来就要发送下单请求的网络包了。

在用户层发送的是HTTP的网络包&＃xff0c;因为服务端提供的是RESTful API&＃xff0c;因而HTTP层发送的就是一个请求。

POST /purchaseOrder HTTP/1.1 Host: www.geektime.com Content-Type: application/json; charset&＃61;utf-8 Content-Length: nnn { "order": { "date": "2018-07-01", "className": "趣谈网络协议", "Author": "刘超", "price": "68" } }

HTTP的报文大概分为三大部分。第一部分是请求行&＃xff0c;第二部分是请求的首部&＃xff0c;第三部分才是请求的正文实体。

在请求行中&＃xff0c;URL就是 www.geektime.com/purchaseOrder &＃xff0c;版本为HTTP 1.1。

请求的类型叫作POST&＃xff0c;它需要主动告诉服务端一些信息&＃xff0c;而非获取。需要告诉服务端什么呢&＃xff1f;一般会放在正文里面。正文可以有各种各样的格式&＃xff0c;常见的格式是JSON。

请求行下面就是我们的首部字段。首部是key value&＃xff0c;通过冒号分隔。

Content-Type是指正文的格式。例如&＃xff0c;我们进行POST的请求&＃xff0c;如果正文是JSON&＃xff0c;那么我们就应该将这个值设置为JSON。

接下来是正文&＃xff0c;这里是一个JSON字符串&＃xff0c;里面通过文本的形式描述了&＃xff0c;要买一个课程&＃xff0c;作者是谁&＃xff0c;多少钱。

这样&＃xff0c;HTTP请求的报文格式就拼凑好了。接下来浏览器或者移动App会把它交给下一层传输层。

怎么交给传输层呢&＃xff1f;也是用Socket进行程序设计。如果用的是浏览器&＃xff0c;这些程序不需要你自己写&＃xff0c;有人已经帮你写好了&＃xff1b;如果在移动APP里面&＃xff0c;一般会用一个HTTP的客户端工具来发送&＃xff0c;并且帮你封装好。

HTTP协议是基于TCP协议的&＃xff0c;所以它使用面向连接的方式发送请求&＃xff0c;通过Stream二进制流的方式传给对方。当然&＃xff0c;到了TCP层&＃xff0c;它会把二进制流变成一个的报文段发送给服务器。

在TCP头里面&＃xff0c;会有源端口号和目标端口号&＃xff0c;目标端口号一般是服务端监听的端口号&＃xff0c;源端口号在手机端&＃xff0c;往往是随机分配一个端口号。这个端口号在客户端和服务端用于区分请求和返回&＃xff0c;发给那个应用。

在IP头里面&＃xff0c;都需要加上自己的地址&＃xff08;即源地址&＃xff09;和它想要去的地方&＃xff08;即目标地址&＃xff09;。当一个手机上线的时候&＃xff0c;PGW会给这个手机分配一个IP地址&＃xff0c;这就是源地址&＃xff0c;而目标地址则是云平台的负载均衡器的外网IP地址。

在IP层&＃xff0c;客户端需要查看目标地址和自己是否是在同一个局域网&＃xff0c;计算是否是同一个网段&＃xff0c;往往需要通过CIDR子网掩码来计算。

对于这个下单场景&＃xff0c;目标IP和源IP不会在同一个网段&＃xff0c;因而需要发送到默认的网关。一般通过DHCP分配IP地址的时候&＃xff0c;也会同时配置默认网关的IP地址。

但是客户端不会直接使用默认网关的IP地址&＃xff0c;而是发送ARP协议&＃xff0c;来获取网关的MAC地址&＃xff0c;然后将网关MAC作为目标MAC&＃xff0c;自己的MAC作为源MAC&＃xff0c;放入MAC头&＃xff0c;发送出去。

一个完整的网络包的格式是这样的。

接下来&＃xff0c;网络包就正式发出了。

如果你是用手机打开APP&＃xff0c;下单购物发送网络包&＃xff0c;一般通过手机运营商的网络。

客户的手机开机以后&＃xff0c;在附近寻找基站eNodeB&＃xff0c;发送请求&＃xff0c;申请上网。基站将请求发给MME&＃xff0c;MME对手机进行认证和鉴权&＃xff0c;还会请求HSS看有没有钱&＃xff0c;看看是在哪里上网。

当MME通过了手机的认证之后&＃xff0c;开始建立隧道&＃xff0c;建设的数据通路分两段路&＃xff0c;其实是两个隧道。一段是从eNodeB到SGW&＃xff0c;第二段是从SGW到PGW&＃xff0c;在PGW之外&＃xff0c;就是互联网。

PGW会为手机分配一个IP地址&＃xff0c;手机上网都是带着这个IP地址的。

对于手机来讲&＃xff0c;默认的网关在PGW上。在移动网络里面&＃xff0c;从手机到SGW&＃xff0c;到PGW是有一条隧道的。在这条隧道里面&＃xff0c;会将上面的这个包作为隧道的乘客协议放在里面&＃xff0c;外面SGW和PGW在核心网机房的IP地址。网络包直到PGW&＃xff08;PGW是隧道的另一端&＃xff09;才将里面的包解出来&＃xff0c;转发到外部网络。

所以&＃xff0c;从手机发送出来的时候&＃xff0c;网络包的结构为&＃xff1a;

源MAC&＃xff1a;手机也即UE的MAC&＃xff1b;

目标MAC&＃xff1a;网关PGW上面的隧道端点的MAC&＃xff1b;

源IP&＃xff1a;UE的IP地址&＃xff1b;

目标IP&＃xff1a;SLB的公网IP地址。

进入隧道之后&＃xff0c;要封装外层的网络地址&＃xff0c;因而网络包的格式为&＃xff1a;

外层源MAC&＃xff1a;E-NodeB的MAC&＃xff1b;

外层目标MAC&＃xff1a;SGW的MAC&＃xff1b;

外层源IP&＃xff1a;E-NodeB的IP&＃xff1b;

外层目标IP&＃xff1a;SGW的IP&＃xff1b;

内层源MAC&＃xff1a;手机也即UE的MAC&＃xff1b;

内层目标MAC&＃xff1a;网关PGW上面的隧道端点的MAC&＃xff1b;

内层源IP&＃xff1a;UE的IP地址&＃xff1b;

内层目标IP&＃xff1a;SLB的公网IP地址。

当隧道在SGW的时候&＃xff0c;切换了一个隧道&＃xff0c;为从SGW到PGW的隧道&＃xff0c;因而网络包的格式为&＃xff1a;

外层源MAC&＃xff1a;SGW的MAC&＃xff1b;

外层目标MAC&＃xff1a;PGW的MAC&＃xff1b;

外层源IP&＃xff1a;SGW的IP&＃xff1b;

外层目标IP&＃xff1a;PGW的IP&＃xff1b;

内层源MAC&＃xff1a;手机也即UE的MAC&＃xff1b;

内层目标MAC&＃xff1a;网关PGW上面的隧道端点的MAC&＃xff1b;

内层源IP&＃xff1a;UE的IP地址&＃xff1b;

内层目标IP&＃xff1a;SLB的公网IP地址。

在PGW的隧道端点将包解出来&＃xff0c;转发出去的时候&＃xff0c;一般在PGW出外部网络的路由器上&＃xff0c;会部署NAT服务&＃xff0c;将手机的IP地址转换为公网IP地址&＃xff0c;当请求返回的时候&＃xff0c;再NAT回来。

因而在PGW之后&＃xff0c;相当于做了一次欧洲十国游型的转发&＃xff0c;网络包的格式为&＃xff1a;

源MAC&＃xff1a;PGW出口的MAC&＃xff1b;

目标MAC&＃xff1a;NAT网关的MAC&＃xff1b;

源IP&＃xff1a;UE的IP地址&＃xff1b;

目标IP&＃xff1a;SLB的公网IP地址。

在NAT网关&＃xff0c;相当于做了一次玄奘西游型的转发&＃xff0c;网络包的格式变成&＃xff1a;

源MAC&＃xff1a;NAT网关的MAC&＃xff1b;

目标MAC&＃xff1a;A2路由器的MAC&＃xff1b;

源IP&＃xff1a;UE的公网IP地址&＃xff1b;

目标IP&＃xff1a;SLB的公网IP地址。

在手机运营商的网络里面&＃xff0c;网络状况是比较好的。

对于玄奘法师&＃xff0c;在大唐国境之内&＃xff0c;还是比较平安的。原文说&＃xff1a;们行了数日&＃xff0c;到了巩州城。早有巩州合属官吏人等&＃xff0c;迎接入城中。安歇一夜&＃xff0c;次早出城前去。一路饥餐渴饮&＃xff0c;夜住晓行&＃xff0c;两三日&＃xff0c;又至河州卫。早有镇边的总兵与本处僧道&＃xff0c;闻得是钦差御弟法师上西方见佛&＃xff0c;无不恭敬&＃xff0c;接至里面供给了&＃xff0c;着僧纲请往福原寺安歇。本寺僧人&＃xff0c;一一参见&＃xff0c;安排晚斋。斋毕&＃xff0c;吩咐二从者饱喂马匹&＃xff0c;天不明就行。

真的是有接有送。

行经半日&＃xff0c;只见对面处&＃xff0c;有一座大山&＃xff0c;真个是高接青霄&＃xff0c;崔巍险峻。此山唤做两界山&＃xff0c;东半边属我大唐所管&＃xff0c;西半边乃是鞑靼的地界。过了这座山&＃xff0c;就不是大唐的土地了。

六、历经千山与万险

离开大唐的国土&＃xff0c;接下来的路应该怎么走呢&＃xff1f;

好在此去西天&＃xff0c;要经过一个个国家&＃xff0c;每个国家有一个个城关&＃xff0c;玄奘法师只要到处问路&＃xff0c;只要这些城关的守门人知道大概路怎么走&＃xff0c;就能一个个国家的走下去&＃xff0c;如果遇到国家&＃xff0c;还有通关文牒&＃xff0c;还能保护玄奘法师在国内的安全。

这里有两个问题要解决&＃xff0c;第一个是每个城关的守门人和每个国家&＃xff0c;是怎么知道去西天怎么走的。第二个问题是玄奘如何问路&＃xff0c;如何走。

我们先第一个问题&＃xff0c;这个观音菩萨从西天来东土的时候&＃xff0c;已经通过一种法术告诉这些国家和城关了。

菩萨的法术主要分两种情况&＃xff0c;一种情况是在一个国家内部如何走&＃xff0c;另一种情况在国家之间&＃xff0c;在野外如何走的问题。

在一个国家内部&＃xff0c;菩萨主要遵循最短路径原则&＃xff0c;就是走得路越少越好&＃xff0c;道路越短越好。

但是国家之间&＃xff0c;菩萨不但要考虑远近的问题&＃xff0c;还要考虑政策的问题。例如有的国家路近&＃xff0c;但是路过的国家看不惯僧人&＃xff0c;见了僧人就抓。例如灭法国&＃xff0c;连光头都要抓。这样的情况即便路近&＃xff0c;也最好绕远点走。

菩萨的法术是什么呢&＃xff1f;咱们在大学里面学习计算机网络与数据结构的时候&＃xff0c;知道求最短路径常用的有两种方法&＃xff0c;一种是 Bellman-Ford 算法&＃xff0c;一种是 Dijkstra 算法。在计算机网络中基本也是用这两种方法计算的。

距离矢量路由&＃xff08;distance vector routing&＃xff09;&＃xff0c;它是基于 Bellman-Ford 算法的。

链路状态路由&＃xff08;link state routing&＃xff09;&＃xff0c;基于 Dijkstra 算法。

最常用的两种路由协议&＃xff1a;

OSPF&＃xff08;Open Shortest Path First&＃xff0c;开放式最短路径优先&＃xff09;就是这样一个基于链路状态路由协议&＃xff0c;广泛应用在数据中心中的协议&＃xff0c;称为内部网关协议&＃xff08;Interior Gateway Protocol&＃xff0c;简称IGP&＃xff09;

BGP 协议使用的算法是路径矢量路由协议&＃xff08;path-vector protocol&＃xff09;。它是距离矢量路由协议的升级版&＃xff0c;称为外网路由协议&＃xff08;Border Gateway Protocol&＃xff0c;简称BGP&＃xff09;

路由协议是城关之间相互沟通到哪里应该怎么走的协议。

第二个问题&＃xff0c;也就是玄奘如何问路&＃xff0c;如何走。这就是IP协议。

这就要靠通关文牒了&＃xff0c;里面写着贫僧来自东土大唐&＃xff08;就是源IP地址&＃xff09;&＃xff0c;欲往西天拜佛求经&＃xff08;指的是目标IP地址&＃xff09;。路过宝地&＃xff0c;借宿一晚&＃xff0c;明日启行&＃xff0c;请问接下来该怎么走啊&＃xff1f;

在解决第一个问题的时候&＃xff0c;每个城关已经通过菩萨的法术&＃xff0c;和邻近的城关进行沟通&＃xff0c;知道了下面的信息。

这个叫路由表&＃xff0c;根据这个表格&＃xff0c;可以告诉唐僧怎么走。

接下来我们看完整故事。

出了NAT网关&＃xff0c;就从核心网到达了互联网。在网络世界&＃xff0c;每一个运营商的网络成为自治系统AS。每个自治系统都有边界路由器&＃xff0c;通过它和外面的世界建立联系。

对于云平台来讲&＃xff0c;它可以被称为Multihomed AS&＃xff0c;有多个连接连到其他的AS&＃xff0c;但是大多拒绝帮其他的AS传输包。例如一些大公司的网络。对于运营商来说&＃xff0c;它可以被称为Transit AS&＃xff0c;有多个连接连到其他的AS&＃xff0c;并且可以帮助其他的AS传输包&＃xff0c;比如主干网。

如何从出口的运营商到达云平台的边界路由器&＃xff1f;在路由器之间需要通过BGP协议实现&＃xff0c;BGP又分为两类&＃xff0c;eBGP和iBGP。自治系统间&＃xff0c;边界路由器之间使用eBGP广播路由。内部网络也需要访问其他的自治系统。

边界路由器如何将BGP学习到的路由导入到内部网络呢&＃xff1f;通过运行iBGP&＃xff0c;使内部的路由器能够找到到达外网目的地最好的边界路由器。

网站的SLB的公网IP地址早已经通过云平台的边界路由器&＃xff0c;让全网都知道了。于是这个下单的网络包选择了下一跳是A2&＃xff0c;也即将A2的MAC地址放在目标MAC地址中。

到达A2之后&＃xff0c;从路由表中找到下一跳是路由器C1&＃xff0c;于是将目标MAC换成C1的MAC地址。到达C1之后&＃xff0c;找到下一跳是C2&＃xff0c;将目标MAC地址设置为C2的MAC。到达C2后&＃xff0c;找到下一跳是云平台的边界路由器&＃xff0c;于是将目标MAC设置为边界路由器的MAC地址。

你会发现&＃xff0c;这一路&＃xff0c;都是只换MAC&＃xff0c;不换目标IP地址。这就是所谓下一跳的概念。

在云平台的边界路由器&＃xff0c;会将下单的包转发进来&＃xff0c;经过核心交换&＃xff0c;汇聚交换&＃xff0c;到达外网网关节点上的SLB的公网IP地址。

我们可以看到&＃xff0c;手机到SLB的公网IP&＃xff0c;是一个端到端的连接&＃xff0c;连接的过程发送了很多包。所有这些包&＃xff0c;无论是TCP三次握手&＃xff0c;还是HTTPS的密钥交换&＃xff0c;都是要走如此复杂的过程到达SLB的&＃xff0c;当然每个包走的路径不一定一致。

当网络包走在这个复杂的道路上&＃xff0c;很可能一不小心就丢了&＃xff0c;怎么办&＃xff1f;这就需要借助TCP的机制重新发送。

既然TCP要对包进行重传&＃xff0c;就需要维护一个Sequence Number&＃xff0c;看哪些包到了&＃xff0c;哪些没到&＃xff0c;哪些需要重传&＃xff0c;传输的速度应该控制到多少&＃xff0c;这就是TCP的滑动窗口协议。

整个TCP的发送&＃xff0c;一开始会协商一个Sequence Number&＃xff0c;从这个Sequence Number开始&＃xff0c;每个包都有编号。滑动窗口将接收方的网络包分成四个部分&＃xff1a;

已经接收&＃xff0c;已经ACK&＃xff0c;已经交给应用层的包&＃xff1b;

已经接收&＃xff0c;已经ACK&＃xff0c;未发送给应用层&＃xff1b;

已经接收&＃xff0c;尚未发送ACK&＃xff1b;

未接收&＃xff0c;尚有空闲的缓存区域。

对于TCP层来讲&＃xff0c;每一个包都有ACK。ACK需要从SLB回复到手机端&＃xff0c;将上面的那个过程反向来一遍&＃xff0c;当然路径不一定一致&＃xff0c;可见ACK也不是那么轻松的事情。

如果发送方超过一定的时间没有收到ACK&＃xff0c;就会重新发送。只有TCP层ACK过的包&＃xff0c;才会发给应用层&＃xff0c;并且只会发送一份&＃xff0c;对于下单的场景&＃xff0c;应用层是HTTP层。

你可能会问了&＃xff0c;TCP老是重复发送&＃xff0c;会不会导致一个单下了两遍&＃xff1f;是否要求服务端实现幂&＃xff1f;从TCP的机制来看&＃xff0c;是不会的。只有收不到ACK的包才会重复发&＃xff0c;发到接收端&＃xff0c;在窗口里面只保存一份&＃xff0c;所以在同一个TCP连接中&＃xff0c;不用担心重传导致二次下单。

但是TCP连接会因为某种原因断了&＃xff0c;例如手机信号不好&＃xff0c;这个时候手机把所有的动作重新做一遍&＃xff0c;建立一个新的TCP连接&＃xff0c;在HTTP层调用两次RESTful API。这个时候可能会导致两遍下单的情况&＃xff0c;因而RESTful API需要实现幂等。

当ACK过的包发给应用层之后&＃xff0c;TCP层的缓存就空了出来&＃xff0c;这会导致上面图中的大三角&＃xff0c;也即接收方能够容纳的总缓存&＃xff0c;整体顺时针滑动。小的三角形&＃xff0c;也即接收方告知发送方的窗口总大小&＃xff0c;也即还没有完全确认收到的缓存大小&＃xff0c;如果把这些填满了&＃xff0c;就不能再发了&＃xff0c;因为没确认收到&＃xff0c;所以一个都不能扔。

七、功成行满见真如

唐僧经历九九八十一难&＃xff0c;终于到达了西天。发现金顶大仙已经在等他们了。

网络包从手机端经历千难万险&＃xff0c;终于到了SLB的公网IP所在的公网网口。由于匹配上了MAC地址和IP地址&＃xff0c;因而将网络包收了进来。

到了西天&＃xff0c;唐僧度过最后一条河凌云仙渡的时候&＃xff0c;发现滚浪飞流&＃xff0c;约有八九里宽阔&＃xff0c;四无人迹。好不容易盼来一条船&＃xff0c;还没有底。原来驾船的是接引佛祖&＃xff0c;玄奘法师的肉体随着河水飘走&＃xff0c;从而脱胎换骨&＃xff0c;成就金身。

在虚拟网关节点的外网网口上&＃xff0c;会有一个NAT规则&＃xff0c;将公网IP地址转换为VPC里面的私网IP地址&＃xff0c;这个私网IP地址就是SLB的HAProxy所在的虚拟机的私网IP地址。

从而网络包也脱胎换骨&＃xff0c;实现公网IP到私有网络IP的转换。

当然为了承载比较大的吞吐量&＃xff0c;虚拟网关节点会有多个&＃xff0c;物理网络会将流量分发到不同的虚拟网关节点。同样HAProxy也会是一个大的集群&＃xff0c;虚拟网关会选择某个负载均衡节点&＃xff0c;将某个请求分发给它&＃xff0c;负载均衡之后是Controller层&＃xff0c;也是部署在虚拟机里面的。

当网络包里面的目标IP变成私有IP地址地址之后&＃xff0c;虚拟路由会查找路由规则&＃xff0c;将网络包从下方的私网网口发出来。这个时候包的格式为&＃xff1a;

源MAC&＃xff1a;网关MAC&＃xff1b;

目标MAC&＃xff1a;HAProxy虚拟机的MAC&＃xff1b;

源IP&＃xff1a;UE的公网IP&＃xff1b;

目标IP&＃xff1a;HAProxy虚拟机的私网IP。

在第一部分&＃xff0c;我们说佛经是存放在一个虚拟空间里面的&＃xff0c;要打开这个虚拟空间&＃xff0c;解读经文&＃xff0c;需要一个芝麻开门的ID。接引佛祖会给玄奘法师一个ID。

在虚拟路由节点上&＃xff0c;也会有OVS&＃xff0c;将网络包封装在VXLAN隧道里面&＃xff0c;VXLAN ID就是给你的租户创建VPC的时候分配的。VXLAN ID就是VPC虚拟空间的ID&＃xff0c;OVS就是那个能够封装和解开私密空间的法宝。

包的格式为&＃xff1a;

外层源MAC&＃xff1a;网关物理机MAC&＃xff1b;

外层目标MAC&＃xff1a;物理机A的MAC&＃xff1b;

外层源IP&＃xff1a;网关物理机IP&＃xff1b;

外层目标IP&＃xff1a;物理机A的IP&＃xff1b;

内层源MAC&＃xff1a;网关MAC&＃xff1b;

内层目标MAC&＃xff1a;HAProxy虚拟机的MAC&＃xff1b;

内层源IP&＃xff1a;UE的公网IP&＃xff1b;

内层目标IP&＃xff1a;HAProxy虚拟机的私网IP。

在物理机A上&＃xff0c;OVS会将包从VXLAN隧道里面解出来&＃xff0c;发给HAProxy所在的虚拟机。HAProxy所在的虚拟机发现MAC地址匹配&＃xff0c;目标IP地址匹配&＃xff0c;就根据TCP端口&＃xff0c;将包发给HAProxy进程&＃xff0c;因为HAProxy是在监听这个TCP端口的。因而HAProxy就是这个TCP连接的服务端&＃xff0c;客户端是手机。对于TCP的连接状态&＃xff0c;滑动窗口等&＃xff0c;都是在HAProxy上维护的。

在这里HAProxy是一个四层负载均衡&＃xff0c;也即他只解析到TCP层&＃xff0c;里面的HTTP协议他不关心&＃xff0c;就将请求转发给后端的多个Controller层的一个。

HAProxy发出去的网络包就认为HAProxy是客户端了&＃xff0c;看不到手机端了。网络包格式如下&＃xff1a;

源MAC&＃xff1a;HAProxy所在虚拟机的MAC&＃xff1b;

目标MAC&＃xff1a;Controller层所在虚拟机的MAC&＃xff1b;

源IP&＃xff1a;HAProxy所在虚拟机的私网IP&＃xff1b;

目标IP&＃xff1a;Controller层所在虚拟机的私网IP。

当然这个包发出去之后&＃xff0c;还是会被物理机上的OVS放入VXLAN隧道里面&＃xff0c;网络包格式为&＃xff1a;

外层源MAC&＃xff1a;物理机A的MAC&＃xff1b;

外层目标MAC&＃xff1a;物理机B的MAC&＃xff1b;

外层源IP&＃xff1a;物理机A的IP&＃xff1b;

外层目标IP&＃xff1a;物理机B的IP&＃xff1b;

内层源MAC&＃xff1a;HAProxy所在虚拟机的MAC&＃xff1b;

内层目标MAC&＃xff1a;Controller层所在虚拟机的MAC&＃xff1b;

内层源IP&＃xff1a;HAProxy所在虚拟机的私网IP&＃xff1b;

内层目标IP&＃xff1a;Controller层所在虚拟机的私网IP。

在物理机B上&＃xff0c;OVS会将包从VXLAN隧道里面解出来&＃xff0c;发给Controller层所在的虚拟机。Controller层所在的虚拟机发现MAC地址匹配&＃xff0c;目标IP地址匹配&＃xff0c;就根据TCP端口&＃xff0c;将包发给Controller层的进程&＃xff0c;因为他是在监听这个TCP端口的。

在HAProxy和Controller层之间&＃xff0c;维护一个TCP的连接。

Controller层收到包之后&＃xff0c;他是关心HTTP里面是什么的&＃xff0c;于是解开HTTP的包&＃xff0c;发现是一个POST请求&＃xff0c;内容是下单购买一个课程。

八、取得真经成金身

玄奘法师终于到达西天大雷音寺&＃xff0c;见到了我佛如来。

佛祖愿意传经给玄奘&＃xff0c;于是让玄奘去藏经楼取经文&＃xff0c;谁知道西天也有西天的规矩&＃xff0c;如果不懂这里的规矩&＃xff0c;就很难和管理经文的人沟通&＃xff0c;取不到真经。

同理&＃xff0c;在电商服务里面&＃xff0c;往往在组合服务层会有一个专门管理下单的服务&＃xff0c;Controller层虽然对外暴露的是标准的RESTful协议&＃xff0c;但是对内会通过RPC协议调用这个组合服务层。如果不懂这个协议&＃xff0c;就没法通信。

假设我们使用的是Dubbo&＃xff0c;则Controller层需要读取注册中心&＃xff0c;将下单服务的进程列表拿出来&＃xff0c;选出一个来调用。

Dubbo中默认的RPC协议是Hessian2。Hessian2将下单的远程调用序列化为二进制进行传输。

Netty是一个非阻塞的基于事件的网络传输框架。Controller层和下单服务之间&＃xff0c;使用了Netty的网络传输框架。有了Netty&＃xff0c;就不用自己编写复杂的异步Socket程序了。Netty使用的方式&＃xff0c;就是咱们讲Socket编程的时候&＃xff0c;一个项目组支撑多个项目&＃xff08;IO多路复用&＃xff0c;从派人盯着到有事通知&＃xff09;这种方式。

Netty还是工作在Socket这一层的&＃xff0c;发送的网络包还是基于TCP的。在TCP的下层&＃xff0c;还是需要封装上IP头和MAC头。如果跨物理机通信&＃xff0c;还是需要封装的外层的VXLAN隧道里面。当然底层的这些封装&＃xff0c;Netty都不感知&＃xff0c;它只要做好它的异步通信即可。

在Netty的服务端&＃xff0c;也即下单服务中&＃xff0c;收到请求后&＃xff0c;先用Hessian2的格式进行解压缩。然后将请求分发到线程中进行处理&＃xff0c;在线程中&＃xff0c;会调用下单的业务逻辑。

玄奘师徒好在后来碰到了懂得内情的注册中心——弥勒佛&＃xff0c;从而会到灵山&＃xff0c;还是按照人家的规矩办了&＃xff0c;才将无字经文&＃xff0c;换成有字经文。

下单的业务逻辑比较复杂&＃xff0c;往往要调用基础服务层里面的库存服务、优惠券服务等&＃xff0c;将多个服务调用完毕&＃xff0c;才算下单成功。下单服务调用库存服务和优惠券服务&＃xff0c;也是通过Dubbo的框架&＃xff0c;通过注册中心拿到库存服务和优惠券服务的列表&＃xff0c;然后选一个调用。

调用的时候&＃xff0c;统一使用Hessian2进行序列化&＃xff0c;使用Netty进行传输&＃xff0c;底层如果跨物理机&＃xff0c;仍然需要通过VXLAN的封装和解封装。

咱们以库存为例子的时候&＃xff0c;讲述过幂等的接口实现的问题。因为如果扣减库存&＃xff0c;仅仅是谁调用谁减一。这样存在的问题是&＃xff0c;如果扣减库存因为一次调用失败&＃xff0c;而多次调用&＃xff0c;这里指的不是TCP多次重试&＃xff0c;而是应用层调用的多次重试&＃xff0c;就会存在库存扣减多次的情况。

这里常用的方法是&＃xff0c;使用乐观锁&＃xff08;Compare and Set&＃xff0c;简称CAS&＃xff09;。CAS要考虑三个方面&＃xff0c;当前的库存数、预期原来的库存数和版本&＃xff0c;以及新的库存数。在操作之前&＃xff0c;查询出原来的库存数和版本&＃xff0c;真正扣减库存的时候&＃xff0c;判断如果当前库存的值与预期原值和版本相匹配&＃xff0c;则将库存值更新为新值&＃xff0c;否则不做任何操作。

这是一种基于状态而非基于动作的设计&＃xff0c;符合REST的架构设计原则。这样的设计有利于高并发场景。当多个线程尝试使用CAS同时更新同一个变量时&＃xff0c;只有其中一个线程能更新变量的值&＃xff0c;而其它线程都失败&＃xff0c;失败的线程并不会被挂起&＃xff0c;而是被告知这次竞争中失败&＃xff0c;并可以再次尝试。

最终&＃xff0c;当下单更新到分布式数据库中之后&＃xff0c;整个下单过程才算真正告一段落。