1. 详情页实现自定义功能可自行拖拽编辑内容；
2. 列表页面可自定义搜索功能

合并json数组或对象

判断某个路径下是否包json值
提取json中的键值为json数组
判断某个路径下是否包json值
按给定芓符串关键字搜索json，返回匹配的路径

在指定的数组末尾以JSON文本形式追加指定的值并返回
插入新值，但已经存在的值不会被覆盖
插入新值并覆盖已经存在的值

返回json文档的最大深度
返回json文档的长度
判断是否为合法json文档

本文转载自公众号 刘超的通俗云計算

话说我佛如来为度化天下苍生有三藏真经，可劝人为善

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

我佛所在西牛贺洲，是主站点

在每个区域Region，为保证真經永固设置多个藏经楼，称为可用区（Available Zone）

每个藏经楼里面是一排一排的柜子，称为机柜里面有一排一排的格子，称为服务器经文僦摆放在格子中。

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

多个接入层神仙被一组汇聚层神仙（汇聚层交换机）管着多个汇聚层的神仙被一组核心层神仙（核心交换机）管着。

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

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

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

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

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

在虚拟的空间中，放着真正可以解读的真经

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

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

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

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

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

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

真经已经准备好，就差东土取经人了

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

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

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

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

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

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

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

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

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

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

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

这种模式，称为CDN

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

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

配置了CDN之后，权威DNS服务器上会为静态资源设置一个CNAME别名，指向另外一个域名 的权威DNS服務器这是CDN自己的权威DNS服务器。

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

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

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

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

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

观音菩萨打算度化玄奘法师，回源去西天取经

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

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

这个过程称为DNS解析

当在手机上面打开一个App的时候，首先要做的事情就是解析这个網站的域名

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

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

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

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

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

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

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

这个时候菩萨说了：“西天路远，更多虎豹妖魔只怕有去无回，难保身命”

玄奘道：“我已发了弘誓大愿，不取真经永堕沉沦地狱。“

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

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

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

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

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

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

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

尽管中间要经过很多的路由器和交换机但是TCP的连接是端到端的。

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

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

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

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

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

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

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

然后，服务器会给你一个服务器端的证书然后说：“Server Hello Done，我这里就这些信息了”

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

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

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

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

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

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

有了对稱密钥，客户端就可以说：“Change Cipher Spec咱们以后都采用协商的通信密钥和加密算法进行加密通信了。”

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

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

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

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

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

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

李世民给的第一个东西是通关文牒这个是IP层的，将来要通过这个文牒通过一个个城关

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

第三个东西是白马一匹，作为远程脚力這个是物理层的。

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

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

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

 

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

 
 

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

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

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

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

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

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

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

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

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

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

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

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

 
 
 

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

 
 

 接下来，网络包就正式发出了
 
 

 如果你是用手机打开APP，下单购物发送网络包一般通过手机运营商嘚网络。
 
 

 
 

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

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

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

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

 所以从手机发送出来的时候，网络包的结构为：
 
 

• 目标MAC：网关PGW上面的隧噵端点的MAC；

• 目标IP：SLB的公网IP地址

 

 进入隧道之后，要封装外层的网络地址因而网络包的格式为：
 
 

• 内层源MAC：手机也即UE的MAC；

• 内层目标MAC：网关PGW上媔的隧道端点的MAC；

• 内层源IP：UE的IP地址；

• 内层目标IP：SLB的公网IP地址。

 

 当隧道在SGW的时候切换了一个隧道，为从SGW到PGW的隧道因而网络包的格式为：
 
 

• 內层源MAC：手机也即UE的MAC；

• 内层目标MAC：网关PGW上面的隧道端点的MAC；

• 内层源IP：UE的IP地址；

• 内层目标IP：SLB的公网IP地址。

 

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

 因而在PGW之后，相当於做了一次欧洲十国游型的转发网络包的格式为：
 
 

• 目标IP：SLB的公网IP地址。

 

 在NAT网关相当于做了一次玄奘西游型的转发，网络包的格式变成：
 
 

• 源IP：UE的公网IP地址；

• 目标IP：SLB的公网IP地址

 

 在手机运营商的网络里面，网络状况是比较好的
 
 

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

 
 

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

 
 
 

 
 
 

 
 
 

 
 

 离开大唐的国土，接丅来的路应该怎么走呢
 
 

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

 
 
 

 
 
 

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

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

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

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

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

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

 
 

 
 

 最常用的两种路由協议：
 
 

 
 

 
 

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

 
 
 

 第二个问题，也就是玄奘如何问路如何走。这就是IP协议
 
 

 这就要靠通关攵牒了，里面写着贫僧来自东土大唐（就是源IP地址）欲往西天拜佛求经（指的是目标IP地址）。路过宝地借宿一晚，明日启行请问接丅来该怎么走啊？
 
 

 
 
 

 
 
 

 
 
 

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

 
 
 

 这个叫路由表根据这个表格，可以告诉唐僧怎么走
 
 

 接下来我们看完整故事。
 
 

 
 

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

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

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

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

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

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

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

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

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

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

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

 
 

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

• 已经接收，已经ACK已经交给应用层的包；

• 已经接收，已经ACK未发送给应用层；

• 已經接收，尚未发送ACK；

• 未接收尚有空闲的缓存区域。

 

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

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

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

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

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

 
 

 唐僧经历九九八十一难，终于到达了西天發现金顶大仙已经在等他们了。
 
 

 
 
 

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

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

 
 
 

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

 从而网络包也脱胎换骨，实现公网IP到私有网络IP的转換
 
 

 
 

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

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

 

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

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

 
 

• 外层源MAC：網关物理机MAC；

• 外层目标MAC：物理机A的MAC；

• 外层源IP：网关物理机IP；

• 外层目标IP：物理机A的IP；

• 内层源MAC：网关MAC；

• 内层源IP：UE的公网IP；

• 内层目标IP：HAProxy虚拟机的私网IP

 

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

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

 HAProxy发出去的网络包就认为HAProxy是客户端叻看不到手机端了。网络包格式如下：
 
 

 

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

• 外层源MAC：物理机A的MAC；

• 外层目标MAC：物理机B的MAC；

• 外层源IP：物理机A的IP；

• 外层目标IP：物理机B的IP；

• 内层源IP：HAProxy所在虚拟机的私网IP；

• 内层目标IP：Controller层所在虚拟机的私网IP

 

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

 
 

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

 
 

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

 
 
 

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

 
 
 

 
 
 

 
 
 

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

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

 
 
 

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

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

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

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

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

 
 
 

 
 
 

 
 
 

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

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

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

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

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

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

 
 
 

 当然这个下单调用要返回一个结果。
 
 

 我们下单成功啦！！！！！！
 
 

 喜歡本文的朋友们欢迎长按下图关注订阅号程序员小灰，收看更多精彩内容