只有程序员才能读懂的西游记(上)

一、我佛造经传极乐

只有IT人才能读懂的西游记(上)

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

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

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

只有IT人才能读懂的西游记(上)

在每个区域Region,为保证真经永固,设置多个藏经楼,称为可用区(Available Zone)。

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

只有IT人才能读懂的西游记(上)

只有IT人才能读懂的西游记(上)

只有IT人才能读懂的西游记(上)

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

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

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

只有IT人才能读懂的西游记(上)

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

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

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

只有IT人才能读懂的西游记(上)

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

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

只有IT人才能读懂的西游记(上)

只有IT人才能读懂的西游记(上)

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

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

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

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

只有IT人才能读懂的西游记(上)

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

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

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

二、观音奉旨上长安

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

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

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

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

只有IT人才能读懂的西游记(上)

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

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

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

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

三、玄奘秉诚建大会

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

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

只有IT人才能读懂的西游记(上)

只有IT人才能读懂的西游记(上)

只有IT人才能读懂的西游记(上)

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

这种模式,称为CDN。

只有IT人才能读懂的西游记(上)

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

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

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

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

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

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

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

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

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

四、观音显像化金蝉

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

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

只有IT人才能读懂的西游记(上)

只有IT人才能读懂的西游记(上)

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

这个过程称为DNS解析。

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

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

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

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

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

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

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

只有IT人才能读懂的西游记(上)

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

只有IT人才能读懂的西游记(上)

只有IT人才能读懂的西游记(上)

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

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

只有IT人才能读懂的西游记(上)

只有IT人才能读懂的西游记(上)

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

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

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

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

只有IT人才能读懂的西游记(上)

只有IT人才能读懂的西游记(上)

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

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

只有IT人才能读懂的西游记(上)

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,就可以了。

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

只有IT人才能读懂的西游记(上)

只有IT人才能读懂的西游记(上)

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

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

只有IT人才能读懂的西游记(上)

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

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

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

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

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

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

欢迎工作一到五年的Java工程师朋友们加入Java高并发: 957734884,群内提供免费的Java架构学习资料(里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码,MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料)合理利用自己每一分每一秒的时间来学习提升自己,不要再用"没有时间“来掩饰自己思想上的懒惰!趁年轻,使劲拼,给未来的自己一个交代! 

想要领取图片上的资料,加群:957734884,即可免费领取

猜你喜欢

转载自blog.csdn.net/kukelook/article/details/89360105