应用架构的演变——理解虚拟化环境

Application Evolution

Posted by Zeusro on October 29, 2020

kube-killer 的中文文档里面,我简单介绍了应用架构的演变过程。

今天,我决定从更高层面,分多个维度描述应用架构的演变过程。

业务维度

一只大黄鸭

image

docker 没有发布之前,其实容器技术就已经在探索了很多年了。实际上,Java 这门语言就是一种容器化的技术。Java 这门蹩脚的语言之所以大放异彩,是因为他通过虚拟机的方式,无视了各个操作系统以及硬件方面的差异。而对标 Java 的 C# 则是强绑定平台的,因为微软想推销自己的 windows server

那么,既然有一个免费的 Linux 系统,为什么还要 windows server 系统呢? 所以 Java 相当于降维打击了 C# 。

语言是实现业务价值的一种工具。在上古时期,应用的架构更加偏向于单体应用。在这个单体应用里面,包含了整个web程序所需要包含的所有逻辑。

企业的发展在于业务,业务的发展是一个外向圆。所以很多网站发展到最后其实变成了一个巨大的航空母舰。

黄鸭漏气了

image

随着业务的膨胀,对应的源代码也相应膨胀。签入迁出的次数越来越频繁,每次代码合并都是一个噩梦。所以到这一步,单体应用的弊端开始显现。不管是开发,部署都成为了一个巨大的工程难题。

所以到了这个时候,小黄鸭就漏气了。

漏气之后那该怎么办呢?结论是分拆。

变成小小鸭

image

分拆在业务维度叫做服务治理。其实远在10年前就有这种思路。当时叫做SOA。微软的那套体系叫做 WCF ,当时偶尔会有人在网上问 JAVA 程序怎么访问 WCF 服务。其实那个就是服务治理的雏形。

在我看来,近几年吹的微服务不过是新瓶装旧酒。本质的思路并没有发生根本性改变。不过话说回来,分拆业务的效果是显著的,各个模块的人只需要关注自身的业务即可。

运维维度

而从运维维度,应用部署的模型就稍显不同。

百家争鸣时代

在这个时代,各种语言你方唱罢我登场。而作为运维,总是需要自行掌握 Windows ServerCentosUbuntu 之间各个平台的差异。更苦逼的在于,语言本身也在不停地发展中,有时会出现多个版本的语言打架的情况。

image

除了软件层面,硬件层面也是一个问题。各个硬件厂商都想搞垄断,于是弄了一个自己才有的东西,然后申请专利,美其名曰“技术创新”,然后兜售给客户。但站在运维角度,这种差异性是很折磨人的。

而且硬件跟软件之间需要一个接入层,这个接入层叫做驱动。而有些硬件厂商懒得在特定操作系统上做驱动,于是英伟达就收获了 Linus 大佬那名扬天下的中指。

Java 容器时代

image

Java 之所以这么流行,是因为他在操作系统之上又做了一层抽象,他通过这一层抽象抹除了平台的差异性。所以我一直强调, Java 本质是一种容器技术,而不是一种语言。

那么问题又来了, 如果一台服务器上面要运行多个 Java 程序的话,怎么办呢?

docker 容器时代

这就是 docker 容器更绝的地方,他对“系统”都做了一层抽象。在这一层面上,你可以允许任意的程序,而且对机器上面的其他程序没有一点影响。

“系统”在 docker 镜像的语境里面只是一堆只读的文件,而程序是顶端可读写的一层“文件”。docker的横空出现,让单一机器上运行多版本的 Java 程序成为了可能,并且他设计的精妙之处在于各个容器之间的环境是“隔离的”(实际上服务器资源无法隔离),他的隔离是指,你在你的虚拟环境里面随便怎么装软件,都不会影响到其他容器。

到这一步,运维只需要跟开发说:“你给我个镜像吧。无论你给我什么玩意,我只需要 docker run 就可以运行。”

Serviceless 时代

我之前在《广州地铁》这篇文章说过:

当前的 web 只是 Serverless 的一种特例(存活期很长的 Serverless )

连续是不连续的特殊态,大部分人没能认识到这一点。

而在 Serviceless 时代,容器其实是一种朝生夕死的易失架构。这对 DevOps工程师其实提出了新的要求,要设计好监控和日志系统,以适应这一套全新的架构。

公有云维度

如果站在公有云角度,就会看到另外一幅有趣的光景。

黑网吧时代

在黑网吧时代,公有云通过 Xen or KVM 虚拟方式切分了实际的物理机,加上计费规则之后再卖给用户。

公有云其实一直有一个“超售”的机制。他卖给你2核4G。实际上是通过切分一个虚拟的环境给你租用,物理机的实际配置是96核196G,但是实际上卖出去的“服务器”配置总和可能是200核400G。

超售是合理的,因为我们观测到大部分的服务器负载是有规律的,不可能24小时满负荷运载。那么,这里面的水分,就是超售机制成立的第一性条件。

计算存储分离时代

我们知道,家用PC的硬盘和CPU都是放在同一块主板上的。但是这对于公有云来说,就有点费劲。如果用户要一台2核4G的机器,但是硬盘要4T,而整台64核128G的物理机只有4T硬盘咋办?

所以计算与存储是大势所趋。因为只有架构更加灵活,才能更加适应用户多元化的选择。

集约化管理时代

Kubernetes 是容器的调度系统,它从微观到宏观,对应用,服务器,网络等组件都做了一层抽象,这一套庞大的操作系统,其实相当于再建了一套公有云的操作系统。

对于研发而言,其实我只需要设定我的期望值就行了,剩下的交给 DevOps工程师;

对于 DevOps工程师而言,则是建立一个顺畅的构建管道,实现代码到镜像的构建,再完成从镜像到工作负载的事情。最后解决下工作负载的问题;

而对于公有云而言,根据 Kubernetes 提供的消息,我们再对应排错即可。公有云卖的不是服务器,而是算力资源池。

Serviceless 无服务器时代

ingress –> service –> deployment 已经打通了应用到web前端的交付,那对于公有云来说,是不是可以更简单利索一点。不卖服务器给用户了,只要用户给我交付一个容器,那么我就能完成一整个应用的发版?

这就是 Serviceless 无服务器时代的牛逼之处。哥卖的不是服务器,也不是服务,而是一个应用发版平台。公有云变成了一个 Cloud Native Application Store

而且对于公有云, Serviceless 时代有一个更大的好处:取消了虚拟化的开销。对于公有云来说,只要做好监控、资源限制、进程隔离、计费管理,他可以直接在一个超强物理机上运行你的程序。虚拟化是有开销的,如果这部分开销都可以省略,那么对于整体的公有云运作效率而言,其实是相当巨大的提升。

不过,这其实是一种理想化的架构。要实现这个目标,首先得完成对于容器的计算与存储分离。

例行吐槽

image

参考链接

[1] 容器技术之发展简史 https://mp.weixin.qq.com/s/RZj26jdw-a_7QErPxOpyrg

[2] SOA架构设计经验分享—架构、职责、数据一致性 https://www.cnblogs.com/wangiqngpei557/p/4486177.html

[3] Xen V.S. KVM终于画上了一个完美的句号 https://zhuanlan.zhihu.com/p/33324585

[4] 计算应该与存储分离吗? https://cloud.tencent.com/developer/article/1619383