在 kube-killer 的中文文档里面，我简单介绍了应用架构的演变过程。
今天，我决定从更高层面，分多个维度描述应用架构的演变过程。
业务维度
一只大黄鸭
在 docker 没有发布之前，其实容器技术就已经在探索了很多年了。实际上，Java 这门语言就是一种容器化的技术。Java 这门蹩脚的语言之所以大放异彩，是因为他通过虚拟机的方式，无视了各个操作系统以及硬件方面的差异。而对标 Java 的 C# 则是强绑定平台的，因为微软想推销自己的 windows server 。
那么，既然有一个免费的 Linux 系统，为什么还要 windows server 系统呢？ 所以 Java 相当于降维打击了 C# 。
语言是实现业务价值的一种工具。在上古时期，应用的架构更加偏向于单体应用。在这个单体应用里面，包含了整个web程序所需要包含的所有逻辑。
企业的发展在于业务，业务的发展是一个外向圆。所以很多网站发展到最后其实变成了一个巨大的航空母舰。
黄鸭漏气了
随着业务的膨胀，对应的源代码也相应膨胀。签入迁出的次数越来越频繁，每次代码合并都是一个噩梦。所以到这一步，单体应用的弊端开始显现。不管是开发，部署都成为了一个巨大的工程难题。
所以到了这个时候，小黄鸭就漏气了。
漏气之后那该怎么办呢？结论是分拆。
变成小小鸭
分拆在业务维度叫做服务治理。其实远在10年前就有这种思路。当时叫做SOA。微软的那套体系叫做 WCF ，当时偶尔会有人在网上问 JAVA 程序怎么访问 WCF 服务。其实那个就是服务治理的雏形。
在我看来,近几年吹的微服务不过是新瓶装旧酒。本质的思路并没有发生根本性改变。不过话说回来，分拆业务的效果是显著的，各个模块的人只需要关注自身的业务即可。
运维维度
而从运维维度，应用部署的模型就稍显不同。
百家争鸣时代
在这个时代，各种语言你方唱罢我登场。而作为运维，总是需要自行掌握 Windows Server ，Centos ， Ubuntu 之间各个平台的差异。更苦逼的在于，语言本身也在不停地发展中，有时会出现多个版本的语言打架的情况。
除了软件层面，硬件层面也是一个问题。各个硬件厂商都想搞垄断，于是弄了一个自己才有的东西，然后申请专利，美其名曰“技术创新”，然后兜售给客户。但站在运维角度，这种差异性是很折磨人的。
而且硬件跟软件之间需要一个接入层，这个接入层叫做驱动。而有些硬件厂商懒得在特定操作系统上做驱动，于是英伟达就收获了 Linus 大佬那名扬天下的中指。
Java 容器时代
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 时代有一个更大的好处：取消了虚拟化的开销。对于公有云来说，只要做好监控、资源限制、进程隔离、计费管理，他可以直接在一个超强物理机上运行你的程序。虚拟化是有开销的，如果这部分开销都可以省略，那么对于整体的公有云运作效率而言，其实是相当巨大的提升。
不过，这其实是一种理想化的架构。要实现这个目标，首先得完成对于容器的计算与存储分离。
例行吐槽
参考链接
[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
In the Chinese documentation of kube-killer, I briefly introduced the evolution process of application architecture.
Today, I’ve decided to describe the evolution process of application architecture from a higher level, across multiple dimensions.
Business Dimension
A Big Yellow Duck
Before docker was released, container technology had actually been explored for many years. In fact, Java as a language is a containerization technology. The reason this awkward language shined so brightly is that it ignored differences between operating systems and hardware through virtualization. C#, which competes with Java, is strongly platform-bound because Microsoft wanted to promote its own windows server.
So, since there’s a free Linux system, why do we need a windows server system? So Java essentially performed a dimensional reduction attack on C#.
Language is a tool for realizing business value. In ancient times, application architecture was more inclined toward monolithic applications. This monolithic application contained all the logic needed for the entire web program.
Enterprise development lies in business, and business development is an outward circle. So many websites eventually became huge aircraft carriers.
The Yellow Duck Deflated
As business expanded, the corresponding source code also expanded. Check-ins and check-outs became more frequent, and each code merge was a nightmare. So at this point, the drawbacks of monolithic applications began to show. Both development and deployment became huge engineering challenges.
So at this point, the little yellow duck deflated.
What to do after deflation? The conclusion is to split.
Becoming Little Ducks
Splitting in the business dimension is called service governance. This idea actually existed 10 years ago. It was called SOA. Microsoft’s system was called WCF. Occasionally, people would ask online how JAVA programs could access WCF services. That was actually the prototype of service governance.
In my view, the microservices hype in recent years is just old wine in new bottles. The fundamental idea hasn’t fundamentally changed. But having said that, the effect of splitting business is significant—people in each module only need to focus on their own business.
Operations Dimension
From the operations dimension, the application deployment model is slightly different.
The Era of Contending Schools
In this era, various languages took turns on stage. As operations personnel, you always needed to master the differences between Windows Server, Centos, and Ubuntu platforms. What’s worse, languages themselves are constantly developing, and sometimes multiple versions of languages would fight each other.
Beyond the software level, the hardware level is also a problem. Various hardware manufacturers want to create monopolies, so they create something only they have, apply for patents, call it “technological innovation,” and then sell it to customers. But from an operations perspective, this differentiation is very torturous.
Moreover, there needs to be an access layer between hardware and software, called drivers. Some hardware manufacturers are too lazy to make drivers for specific operating systems, so NVIDIA received Linus’s world-famous middle finger.
The Java Container Era
The reason Java is so popular is that it added another layer of abstraction on top of the operating system, eliminating platform differences through this abstraction. So I’ve always emphasized that Java is essentially a container technology, not a language.
So the question arises again: if you want to run multiple Java programs on one server, what do you do?
The Docker Container Era
This is where docker containers are even more brilliant—they abstract the “system” itself. At this level, you can allow any program, and it won’t affect other programs on the machine at all.
The “system” in the context of docker images is just a bunch of read-only files, and the program is a read-write layer of “files” on top. The emergence of docker made it possible to run multiple versions of Java programs on a single machine, and the brilliance of its design is that environments between containers are “isolated” (though server resources can’t actually be isolated). Its isolation means you can install whatever software you want in your virtual environment without affecting other containers.
At this point, operations just needs to tell development: “Give me an image. Whatever you give me, I just need to docker run to execute it.”
The Serverless Era
I previously said in the article “Guangzhou Metro”:
Current web is just a special case of Serverless (a very long-lived Serverless)
Continuity is a special state of discontinuity. Most people fail to recognize this.
In the Serverless era, containers are actually an ephemeral architecture that lives and dies quickly. This actually puts new demands on DevOps engineers—they need to design monitoring and logging systems well to adapt to this entirely new architecture.
Public Cloud Dimension
If you stand from the public cloud perspective, you’ll see another interesting scene.
The Black Internet Cafe Era
In the black internet cafe era, public clouds split actual physical machines through Xen or KVM virtualization, added billing rules, and then sold them to users.
Public clouds actually have always had an “overselling” mechanism. They sell you 2 cores 4G. Actually, they’re renting you a split virtual environment. The physical machine’s actual configuration is 96 cores 196G, but the total “server” configurations sold might be 200 cores 400G.
Overselling is reasonable because we observe that most server loads are regular and can’t run at full capacity 24 hours a day. So the slack here is the first principle condition for the overselling mechanism to work.
The Compute-Storage Separation Era
We know that home PC hard drives and CPUs are all on the same motherboard. But for public clouds, this is a bit troublesome. If a user wants a 2-core 4G machine but needs 4T of hard drive, and the entire 64-core 128G physical machine only has 4T of hard drive, what do you do?
So compute-storage separation is the trend. Because only with more flexible architecture can we better adapt to users’ diverse choices.
The Intensive Management Era
Kubernetes is a container scheduling system. From micro to macro, it abstracts applications, servers, networks, and other components. This huge operating system is actually equivalent to rebuilding a public cloud operating system.
For R&D, I just need to set my expectations, and the rest is left to DevOps engineers;
For DevOps engineers, it’s about building a smooth build pipeline, implementing code-to-image builds, then completing image-to-workload tasks. Finally, solve workload problems;
For public clouds, based on messages provided by Kubernetes, we can troubleshoot accordingly. Public clouds don’t sell servers—they sell computing resource pools.
The Serverless Era
ingress –> service –> deployment has already connected application-to-web frontend delivery. For public clouds, can we make it simpler? Don’t sell servers to users anymore. As long as users deliver a container to me, I can complete the entire application release?
This is the awesomeness of the Serverless era. Bro, I’m not selling servers, nor services, but an application release platform. Public clouds have become a Cloud Native Application Store.
Moreover, for public clouds, the Serverless era has a bigger benefit: eliminating virtualization overhead. For public clouds, as long as they do monitoring, resource limits, process isolation, and billing management well, they can directly run your program on a super-strong physical machine. Virtualization has overhead. If this overhead can be omitted, it’s actually a huge improvement for overall public cloud operational efficiency.
However, this is actually an idealized architecture. To achieve this goal, we first need to complete compute-storage separation for containers.
Routine Complaints
References
[1] A Brief History of Container Technology Development https://mp.weixin.qq.com/s/RZj26jdw-a_7QErPxOpyrg
[2] SOA Architecture Design Experience Sharing—Architecture, Responsibilities, Data Consistency https://www.cnblogs.com/wangiqngpei557/p/4486177.html
[3] Xen V.S. KVM Finally Draws a Perfect Period https://zhuanlan.zhihu.com/p/33324585
[4] Should Compute Be Separated from Storage? https://cloud.tencent.com/developer/article/1619383
kube-killerの中国語ドキュメントで、私はアプリケーションアーキテクチャの進化プロセスを簡単に紹介しました。
今日、私はより高いレベルから、複数の次元でアプリケーションアーキテクチャの進化プロセスを説明することにしました。
ビジネス次元
大きな黄色いアヒル
dockerがリリースされる前、コンテナ技術は実際に何年も探索されてきました。実際、Javaという言語はコンテナ化技術です。この不器用な言語がこれほど輝いたのは、仮想化を通じてオペレーティングシステムとハードウェアの違いを無視したためです。Javaと競合するC#は、Microsoftが独自のwindows serverを宣伝したかったため、プラットフォームに強くバインドされています。
では、無料のLinuxシステムがあるのに、なぜwindows serverシステムが必要なのでしょうか？だからJavaは本質的にC#に対して次元削減攻撃を行ったのです。
言語はビジネス価値を実現するためのツールです。古代では、アプリケーションアーキテクチャはモノリシックアプリケーションにより傾いていました。このモノリシックアプリケーションには、Webプログラム全体に必要なすべてのロジックが含まれていました。
企業の発展はビジネスにあり、ビジネスの発展は外向きの円です。だから多くのウェブサイトは最終的に巨大な航空母艦になりました。
黄色いアヒルがしぼんだ
ビジネスが拡大するにつれて、対応するソースコードも拡大しました。チェックインとチェックアウトがますます頻繁になり、コードマージのたびに悪夢でした。だからこの時点で、モノリシックアプリケーションの欠点が現れ始めました。開発もデプロイも巨大なエンジニアリングの課題になりました。
だからこの時点で、小さな黄色いアヒルはしぼみました。
しぼんだ後はどうすればよいでしょうか？結論は分割です。
小さなアヒルになる
ビジネス次元での分割はサービスガバナンスと呼ばれます。実際、10年前にこの考え方がありました。当時はSOAと呼ばれていました。MicrosoftのシステムはWCFと呼ばれていました。当時、JAVAプログラムがWCFサービスにアクセスする方法をオンラインで尋ねる人が時々いました。それが実際にはサービスガバナンスの原型でした。
私の見解では、近年のマイクロサービスの誇大宣伝は単に新瓶に古い酒を詰めただけです。根本的な考え方は根本的に変わっていません。しかし、言い換えれば、ビジネスの分割の効果は顕著です—各モジュールの人は自分のビジネスに集中するだけで済みます。
運用次元
運用次元から見ると、アプリケーションデプロイメントモデルは少し異なります。
百家争鳴の時代
この時代、さまざまな言語が交代で登場しました。運用担当者として、常にWindows Server、Centos、Ubuntuプラットフォーム間の違いを自分でマスターする必要がありました。さらに悪いことに、言語自体も絶えず発展しており、複数のバージョンの言語が互いに戦うことがありました。
ソフトウェアレベルを超えて、ハードウェアレベルも問題です。さまざまなハードウェアメーカーは独占を作りたいので、自分だけが持つものを作り、特許を申請し、「技術革新」と呼んで顧客に販売します。しかし、運用の観点から見ると、この差異は非常に苦痛です。
さらに、ハードウェアとソフトウェアの間にはアクセス層が必要で、これはドライバーと呼ばれます。一部のハードウェアメーカーは特定のオペレーティングシステムでドライバーを作るのが面倒なので、NVIDIAはLinusの世界的に有名な中指を受け取りました。
Javaコンテナ時代
Javaがこれほど人気がある理由は、オペレーティングシステムの上に別の抽象化レイヤーを追加し、この抽象化を通じてプラットフォームの違いを排除したためです。だから私は常に強調してきましたが、Javaは本質的にコンテナ技術であり、言語ではありません。
では、1台のサーバーで複数のJavaプログラムを実行したい場合、どうすればよいでしょうか？
Dockerコンテナ時代
これがdockerコンテナがさらに優れている点です—「システム」自体を抽象化します。このレベルでは、任意のプログラムを許可でき、マシン上の他のプログラムにまったく影響を与えません。
dockerイメージのコンテキストでは、「システム」は読み取り専用ファイルの束にすぎず、プログラムは上部の読み書き可能な「ファイル」レイヤーです。dockerの出現により、単一のマシンで複数のバージョンのJavaプログラムを実行することが可能になり、その設計の巧妙さは、コンテナ間の環境が「分離されている」（実際にはサーバーリソースは分離できませんが）ことです。その分離とは、仮想環境内で好きなソフトウェアをインストールしても、他のコンテナに影響を与えないことを意味します。
この時点で、運用は開発に言うだけです：「イメージをください。何をくれても、docker runで実行するだけです。」
Serverless時代
私は以前、「広州地下鉄」という記事で言いました：
現在のWebは、Serverlessの特殊なケースにすぎません（非常に長寿命のServerless）
連続性は不連続性の特殊な状態です。ほとんどの人はこれを認識できていません。
Serverless時代では、コンテナは実際には急速に生まれ死ぬ一時的なアーキテクチャです。これは実際にDevOpsエンジニアに新しい要求を課します—この全く新しいアーキテクチャに適応するために、監視とログシステムをうまく設計する必要があります。
パブリッククラウド次元
パブリッククラウドの観点から見ると、別の興味深い光景が見えます。
ブラックインターネットカフェ時代
ブラックインターネットカフェ時代、パブリッククラウドはXenまたはKVM仮想化を通じて実際の物理マシンを分割し、課金ルールを追加してからユーザーに販売しました。
パブリッククラウドは実際に常に「オーバーセール」メカニズムを持っています。彼らはあなたに2コア4Gを販売します。実際、分割された仮想環境をあなたにレンタルしています。物理マシンの実際の構成は96コア196Gですが、販売された「サーバー」構成の合計は200コア400Gかもしれません。
オーバーセールは合理的です。なぜなら、ほとんどのサーバーロードは規則的で、24時間フル容量で実行することはできないと観察されているためです。だから、ここでの余裕は、オーバーセールメカニズムが機能するための第一原理条件です。
コンピュートストレージ分離時代
家庭用PCのハードドライブとCPUはすべて同じマザーボード上にあることがわかっています。しかし、パブリッククラウドにとって、これは少し面倒です。ユーザーが2コア4Gのマシンを望むが、ハードドライブが4T必要で、64コア128Gの物理マシン全体に4Tのハードドライブしかない場合、どうすればよいでしょうか？
だから、コンピュートとストレージの分離はトレンドです。より柔軟なアーキテクチャでのみ、ユーザーの多様な選択により適応できるためです。
集約的管理時代
Kubernetesはコンテナスケジューリングシステムです。マイクロからマクロまで、アプリケーション、サーバー、ネットワーク、その他のコンポーネントを抽象化します。この巨大なオペレーティングシステムは、実際にはパブリッククラウドオペレーティングシステムを再構築することに相当します。
R&Dにとって、私は自分の期待値を設定するだけで、残りはDevOpsエンジニアに任せます。
DevOpsエンジニアにとって、それはスムーズなビルドパイプラインを構築し、コードからイメージへのビルドを実装し、イメージからワークロードへのタスクを完了することです。最後に、ワークロードの問題を解決します。
パブリッククラウドにとって、Kubernetesが提供するメッセージに基づいて、それに応じてトラブルシューティングできます。パブリッククラウドはサーバーを販売するのではなく、コンピューティングリソースプールを販売します。
Serverless無サーバー時代
ingress –> service –> deploymentはすでにアプリケーションからWebフロントエンドへの配信を接続しています。パブリッククラウドにとって、もっとシンプルにできるでしょうか？ユーザーにサーバーを販売しなくなり、ユーザーがコンテナを提供してくれれば、アプリケーション全体のリリースを完了できますか？
これがServerless無サーバー時代の素晴らしさです。兄さん、私はサーバーもサービスも販売していませんが、アプリケーションリリースプラットフォームを販売しています。パブリッククラウドはCloud Native Application Storeになりました。
さらに、パブリッククラウドにとって、Serverless時代にはより大きな利点があります：仮想化のオーバーヘッドを排除します。パブリッククラウドにとって、監視、リソース制限、プロセス分離、課金管理をうまく行えば、超強力な物理マシンで直接プログラムを実行できます。仮想化にはオーバーヘッドがあります。このオーバーヘッドを省略できれば、パブリッククラウド全体の運用効率にとって、実際には非常に大きな改善です。
ただし、これは実際には理想化されたアーキテクチャです。この目標を達成するには、まずコンテナのコンピュートとストレージの分離を完了する必要があります。
定期的な不満
参考リンク
[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
В китайской документации kube-killer я кратко представил процесс эволюции архитектуры приложений.
Сегодня я решил описать процесс эволюции архитектуры приложений с более высокого уровня, по нескольким измерениям.
Бизнес-измерение
Большая жёлтая утка
До выпуска docker технология контейнеров фактически исследовалась много лет. На самом деле, Java как язык — это технология контейнеризации. Причина, по которой этот неуклюжий язык так ярко сиял, заключается в том, что он игнорировал различия между операционными системами и оборудованием через виртуализацию. C#, который конкурирует с Java, сильно привязан к платформе, потому что Microsoft хотела продвигать свой собственный windows server.
Итак, раз есть бесплатная система Linux, зачем нужна система windows server? Так что Java по сути выполнила атаку снижения размерности на C#.
Язык — это инструмент для реализации бизнес-ценности. В древние времена архитектура приложений была более склонна к монолитным приложениям. Это монолитное приложение содержало всю логику, необходимую для всей веб-программы.
Развитие предприятия заключается в бизнесе, а развитие бизнеса — это внешний круг. Так что многие веб-сайты в конечном итоге стали огромными авианосцами.
Жёлтая утка сдулась
По мере расширения бизнеса соответствующий исходный код также расширялся. Проверки и извлечения становились всё более частыми, и каждое слияние кода было кошмаром. Так что на этом этапе недостатки монолитных приложений начали проявляться. И разработка, и развёртывание стали огромными инженерными проблемами.
Так что на этом этапе маленькая жёлтая утка сдулась.
Что делать после сдутия? Вывод — разделение.
Становление маленькими утками
Разделение в бизнес-измерении называется управлением сервисами. Эта идея фактически существовала 10 лет назад. Тогда это называлось SOA. Система Microsoft называлась WCF. Время от времени люди спрашивали в интернете, как программы JAVA могут получить доступ к сервисам WCF. Это был фактически прототип управления сервисами.
На мой взгляд, шумиха вокруг микросервисов в последние годы — это просто старое вино в новых бутылках. Фундаментальная идея не изменилась принципиально. Но, с другой стороны, эффект разделения бизнеса значителен — люди в каждом модуле должны сосредоточиться только на своём бизнесе.
Измерение операций
С точки зрения операций, модель развёртывания приложений немного отличается.
Эра соперничающих школ
В эту эру различные языки по очереди выходили на сцену. Как операционный персонал, вы всегда должны были овладеть различиями между платформами Windows Server, Centos и Ubuntu. Что хуже, сами языки постоянно развиваются, и иногда несколько версий языков сражаются друг с другом.
Помимо программного уровня, аппаратный уровень также является проблемой. Различные производители оборудования хотят создать монополии, поэтому они создают что-то, что есть только у них, подают заявку на патент, называют это “технологическими инновациями” и затем продают клиентам. Но с точки зрения операций, эта дифференциация очень мучительна.
Более того, между оборудованием и программным обеспечением нужен уровень доступа, называемый драйверами. Некоторые производители оборудования слишком ленивы, чтобы делать драйверы для конкретных операционных систем, поэтому NVIDIA получила всемирно известный средний палец Linus.
Эра контейнеров Java
Причина, по которой Java так популярна, заключается в том, что она добавила ещё один уровень абстракции поверх операционной системы, устраняя различия платформ через эту абстракцию. Поэтому я всегда подчёркивал, что Java по сути является технологией контейнеров, а не языком.
Итак, снова возникает вопрос: если вы хотите запустить несколько программ Java на одном сервере, что делать?
Эра контейнеров Docker
Вот где контейнеры docker ещё более блестящи — они абстрагируют саму “систему”. На этом уровне вы можете разрешить любую программу, и это вообще не повлияет на другие программы на машине.
“Система” в контексте образов docker — это просто набор файлов только для чтения, а программа — это уровень “файлов” для чтения-записи сверху. Появление docker сделало возможным запуск нескольких версий программ Java на одной машине, и блеск его дизайна заключается в том, что среды между контейнерами “изолированы” (хотя ресурсы сервера фактически не могут быть изолированы). Его изоляция означает, что вы можете установить любое программное обеспечение в своей виртуальной среде, не влияя на другие контейнеры.
На этом этапе операции просто нужно сказать разработке: “Дай мне образ. Что бы ты мне ни дал, мне просто нужно docker run для выполнения.”
Эра Serverless
Я ранее сказал в статье “Гуанчжоуское метро”:
Текущий веб — это просто особый случай Serverless (очень долгоживущий Serverless)
Непрерывность — это особое состояние прерывности. Большинство людей не могут это распознать.
В эру Serverless контейнеры фактически являются эфемерной архитектурой, которая быстро живёт и умирает. Это фактически предъявляет новые требования к инженерам DevOps — им нужно хорошо спроектировать системы мониторинга и логирования, чтобы адаптироваться к этой совершенно новой архитектуре.
Измерение публичного облака
Если вы стоите с точки зрения публичного облака, вы увидите другую интересную сцену.
Эра чёрных интернет-кафе
В эру чёрных интернет-кафе публичные облака разделяли фактические физические машины через виртуализацию Xen или KVM, добавляли правила выставления счетов, а затем продавали их пользователям.
Публичные облака фактически всегда имели механизм “перепродажи”. Они продают вам 2 ядра 4G. На самом деле они сдают вам разделённую виртуальную среду. Фактическая конфигурация физической машины — 96 ядер 196G, но общие конфигурации “серверов”, проданных, могут быть 200 ядер 400G.
Перепродажа разумна, потому что мы наблюдаем, что большинство нагрузок серверов регулярны и не могут работать на полную мощность 24 часа в сутки. Так что запас здесь — это условие первого принципа для работы механизма перепродажи.
Эра разделения вычислений и хранения
Мы знаем, что жёсткие диски и процессоры домашних ПК находятся на одной материнской плате. Но для публичных облаков это немного проблематично. Если пользователь хочет машину с 2 ядрами 4G, но нужен жёсткий диск 4T, а вся физическая машина с 64 ядрами 128G имеет только жёсткий диск 4T, что делать?
Так что разделение вычислений и хранения — это тенденция. Потому что только с более гибкой архитектурой мы можем лучше адаптироваться к разнообразному выбору пользователей.
Эра интенсивного управления
Kubernetes — это система планирования контейнеров. От микро до макро она абстрагирует приложения, серверы, сети и другие компоненты. Эта огромная операционная система фактически эквивалентна перестройке операционной системы публичного облака.
Для R&D мне просто нужно установить свои ожидания, а остальное оставить инженерам DevOps;
Для инженеров DevOps это создание плавного конвейера сборки, реализация сборок от кода к образу, затем выполнение задач от образа к рабочей нагрузке. Наконец, решение проблем рабочей нагрузки;
Для публичных облаков, основываясь на сообщениях, предоставляемых Kubernetes, мы можем устранять неполадки соответственно. Публичные облака не продают серверы — они продают пулы вычислительных ресурсов.
Эра Serverless без серверов
ingress –> service –> deployment уже соединил доставку от приложения к веб-интерфейсу. Для публичных облаков можем ли мы сделать это проще? Больше не продавать серверы пользователям. Пока пользователи доставят мне контейнер, могу ли я завершить весь релиз приложения?
Вот в чём крутость эры Serverless. Брат, я не продаю серверы, ни услуги, а платформу релиза приложений. Публичные облака стали Cloud Native Application Store.
Более того, для публичных облаков эра Serverless имеет большее преимущество: устранение накладных расходов виртуализации. Для публичных облаков, пока они хорошо выполняют мониторинг, ограничения ресурсов, изоляцию процессов и управление выставлением счетов, они могут напрямую запускать вашу программу на сверхмощной физической машине. Виртуализация имеет накладные расходы. Если эти накладные расходы можно опустить, это фактически огромное улучшение для общей операционной эффективности публичного облака.
Однако это фактически идеализированная архитектура. Для достижения этой цели нам сначала нужно завершить разделение вычислений и хранения для контейнеров.
Обычные жалобы
Ссылки
[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