寫程序離不開運行時，但是有很多伙伴卻并沒有搞清楚運行時到底是什么。運行時的概念之所以容易被混淆，是因為運行時有兩層不同的含義：run time 和 runtime，先賢們在翻譯的時候可能忽略了中間的空格，導致運行時一詞代表了兩種含義：運行時期和運行環境/系統。

運行時期（Run time）在計算機科學中代表一個程序從開始執行到終止執行的運作時期，與之相對的其他時期包括：設計時期（design time）、編譯時期（compile time）、鏈接時期（link time）與載入時期（load time）。

runtime 是一個通用抽象的術語，指的是計算機程序運行的時候所需要的一切代碼庫，框架，平臺等。它包括了程序的執行環境和執行狀態，以及程序在運行時所產生的各種數據和結果。runtime主要是為了實現程序設計語言的執行模型，在每種語言有著不同的實現。runtime的概念在編程中非常重要，它關系到程序的正確性、穩定性和性能等方面。

run time 和 runtime 就有區別又有聯系，都是軟件設計的基礎。run time 是從程序自身的視角來看的，而runtime 則是從程序的執行環境和依賴的視角來看的。因此，在我們討論運行時的時候，一定要明確上下文，才能理解運行時的真正含義，并通過運行時的相關技術讓我們的軟件系統更加靈活可靠。

運行時：run time——運行時期

運行時期（run time）是程序生命周期的一個階段，是代碼在執行時的行為。編譯時期（compile time）是指程序設計中，編譯器在編譯源代碼時的行為，包括語法分析、語義分析、類型檢查、模板實例化、代碼生成等。編程語言通常會指出源程序必須滿足的編譯時期要求。有些編程語言在鏈接時期或運行時期才執行一部分編譯，例如即時編譯（Just-in-time compilation）。

程序執行中的某些問題只能在運行時期才能進行檢測，例如邏輯錯誤或數組邊界檢查等。因此，用戶也會遇到諸如運行時錯誤之類的信息。

運行時期的驗證

運行時驗證是一種輕量級的驗證技術。它是傳統驗證技術，是模型檢測和測試的一個有效補充。它最重要的一個特征是其驗證對象為被監控系統的實際運行，從而使得檢測到錯誤時能及時采取相應的調整行為，以達到避免軟件失效發生或阻止軟件失效進一步傳播的目的。

運行時驗證關注于檢測程序的運行軌跡是否滿足或違背監控的性質。當程序的運行滿足或違背監控性質時，運行時驗證技術一般不會對被監控的系統進行調整。也就是說，運行時驗證技術是關于程序運行軌跡是否滿足監控性質的判別技術。基于AOP的監控器具有高效（不需要進行環境切換）、容易部署（不涉及到對虛擬機和操作系統的修改）和準確（基于AOP的監控器能夠獲取被監控程序更多的狀態信息）的特點。

程序在編譯時期和運行時間的不同體現

這里以多態為例來描述一下程序特性在編譯時期和運行時間的不同體現。

先簡要澄清一下多態。多態指同一個實體同時具有多種形式，是面向對象程序設計（OOP）的一個重要特征。也就是說，同一操作作用于不同的對象，可以有不同的解釋，產生不同的執行結果。在運行時，可以通過指向基類的指針，來調用實現派生類中的方法。如果一個語言只支持類而不支持多態，只能說明它是基于對象的，而不面向對象的。

多態分為兩種情況：編譯時多態與運行時多態。編譯時多態即在編譯時就能夠確定調用哪個方法。而運行時多態則相反，只有在運行時才能確定調用哪個方法。在方法重載時，都是編譯時多態。在編譯期可根據參數的數據類型、個數以及次序來確定調用方法。當子類對象引用自身類實例方法時，也為編譯時多態。但是當父類對象引用子類實例方法時，是運行時多態，因為此時只有在運行時才可以去匹配到對應方法進行調用。

運行時期的軟件配置

運行時期的軟件配置是軟件配置的一種形式，增加了軟件系統的靈活性和適應性。

軟件配置可以分為運行時期配置(run time configuration) 和編譯時配置 (compile time configuration). 運行時配置是軟件的重要接口, 可以定制不同的功能、管理資源的分配、適應環境的變化以及滿足不同用戶的需求, 主要面向軟件管理員和用戶, 無需重新編譯部署即可實現軟件調整. 而編譯時配置也稱軟件生產線配置(software product line configuration, SPL configuration),主要用于軟件構建和部署時期決定特定功能模塊是否加入可執行程序中, 以此決定軟件的最終形態, 主要面向軟件開發和部署人員, 必須重新編譯才能使用。

運行時期的編譯優化

一般地，軟件的優化技術分成兩類：靜態優化和動態優化。其中，動態優化目前主要集中在對動態語言程序如 Java、Ruby、Python 等的優化。運行時期的軟件優化大多通過動態編譯技術來實現。

動態編譯技術又可以分為兩大類：①選擇性編譯：主要關注何時選擇程序哪一部分代碼進行動態編譯和優化；②基于反饋的優化：利用剖析信息來指導動態編譯器來做何種級別的編譯優化。動態編譯器通常支持兩種執行方式：一種是解釋執行或無優化的編譯器編譯執行；一種是優化編譯，對熱點路徑進行重點優化。動態編譯器中的編譯優化工作是在程序運行時期中進行，編譯開銷包含在程序的運行開銷中。

動態編譯器不僅可以選擇對哪些代碼做編譯或者優化編譯，而且還可以在程序的運行中采集程序的運行信息，主要包括程序的循環深度、程序輸入以及運行環境（操作系統、體系結構）等。利用這些運行時信息，動態編譯器可以更好地決定采用何種編譯優化策略對程序進行編譯優化。動態剖析技術使得多級優化編譯成為可能，每一級采用特定的優化策略，熱點的性
能更容易得到提升，這就是基于反饋的動態優化技術）。

基于反饋的動態優化技術主要通過對程序插樁，利用插入的代碼收集需要的程序信息，然后將它們按照一定的格式組織起來進行分析， 從而指導優化器進行重編譯。

運行時：runtime——運行時環境/運行時系統

runtime 或者 run-time是指運行環境，又稱為“運行時系統”，簡稱“運行時”，是執行碼在目標機器上運行的環境。它有可能是由操作系統提供，或由執行此程序的父程序提供。通常由操作系統負責處理程序的載入：利用加載器（loader）讀入程序執行碼，進行基本的內存配置，并視需要鏈接此程序指定的所有動態鏈接庫。有些編程語言也會由此語言提供的運行環境處理上述工作。

運行環境可以解決許多問題，包括應用程序內存的管理、程序如何訪問變量、程序之間傳遞參數的機制、與操作系統的接口等問題。編譯器根據具體的運行時系統做出假設，以生成正確的代碼。通常情況下，運行時系統將承擔一些設置和管理堆棧的責任，并可能包括諸如垃圾回收、線程或其他內置于語言中的動態功能。

對于很多傳統高級語言尤其是動態語言而言，?運行時系統基本上就是程序和硬件的橋梁。一般地，運行時系統實際上提供了一個動態語言得以執行的統一的虛擬計算機，這樣一個虛擬機完全屏蔽了硬件的具體特征?從而極大的提高了軟件的開發效率。但是正因為這個虛擬機完全屏蔽了程序員接觸硬件特性的可能，虛擬機本身必須承擔起充分利用硬件特性來高效執行動態語言程序的責任。

運行時模型與運行時體系結構

每種語言都有一個特定的執行模型（Execution Model），而這個執行模型就需要運行時系統的支撐。運行時系統除了提供程序運行機制之外，一般還提供內存管理機制和并發機制。

運行時模型是關聯系統的因果關系自述，從問題空間的角度強調系統的結構、行為或目標，運行時模型提供了運行時現象的抽象，利用運行時模型能夠修復設計錯誤或將新的設計決策折疊到正在運行的系統中， 以支持受控的在線設計。同時，運行時模型作為軟件演化和適應行為的基礎 ，也是解決復雜系統運行時管理問題的關鍵 。 

運行時模型分為運行時結構模型和運行時行為模型。其中， 運行時結構模型側重于描述系統的組成及配置， 即強調軟件的構建方式，如面向對象而言，結構模型描述的是繼承關系和調用途徑、組件及其連接 等；運行時行為模型側重于描述組件間動態交互信息，強調根據事件或跟蹤流程的系統執行，或者事件的發生及其執行途徑，如行為模型描述事件的到達、排隊、選擇、調度等信息。 

運行時軟件體系結構是控制運行時系統復雜性、輔助系統運行時管理的有效途徑.作為系統運行時刻的動態描述,運行時體系結構刻畫了系統當前時刻的構成元素、各元素內部的屬性以及元素之間的關系。運行時體系結構與目標系統之間具有“因果關聯”,即系統發生變化時,體系結構隨之改變;而體系結構被修改后,系統也將隨之改變，這種動態的因果關聯保證了系統管理者可以通過讀寫體系結構中的元素、屬性以及連接關系,實現對目標系統的監測和調整。運行時體系結構抽象了系統的運行時數據,并以符合管理視角的方式對這些數據進行組織,同時對外提供簡單、一致的操作方式.

運行時體系結構與設計階段體系結構最大的不同在于：運行時體系結構與運行時系統間存在因果聯系，而設計階段體系結構不具備這一屬性。運行時體系結構模型側重如何通過模型來描述運行時系統當前時刻的結構和配置 。

運行時的實現與分類

在編程語言中，runtime通常是由編譯器和運行時庫共同實現的。編譯器負責將源代碼編譯成可執行代碼，而運行時庫則負責在程序運行時提供各種運行時支持和服務。運行時庫通常包括了各種系統庫和標準庫，以及一些特定于編程語言的庫和框架。

在C語言中，runtime的實現通常是由C庫和操作系統共同提供的。C庫提供了各種常用的函數和數據類型，而操作系統則提供了一些底層的系統調用和服務。在Java語言中，runtime的實現則是由Java虛擬機（JVM）和Java類庫共同提供的。JVM負責將Java字節碼編譯成可執行代碼，并提供各種運行時支持和服務，而Java類庫則提供了各種常用的類和函數。

根據運行時系統實現的不同，可以將運行時系統初步分成三類：

第一種是是原生運行時，例如C/C++/Rust，這些語言的運行時系統是依賴操作系統的，操作系統也可以認為是一種“運行時環境”。

第二種是輕運行時，例如Golang，它的運行時是和代碼打包到一起的，相對輕量一些。

第三種是重運行時，例如Java(JVM)，Python(CPython)，還有 C#(.NET Runtime)。它們的運行時環境是需要單獨安裝的，而且一般還不小，幾十兆上百兆都是正常的。

其中，在C/C++里你可以不引用任何庫，Rust里有一個專門的特性叫 no_std，脫離標準庫提供了一個很牛的能力，就是直接和硬件交互。也就是說，C/C++/Rust是可以用來編寫操作系統內核的。

運行時庫

運行時庫（runtime library），在計算機程序設計領域中，是指編程語言程序運行時（執行）所需要的一種特殊的計算機程序庫，編譯器會調用運行時庫至已編譯的可執行二進制代碼中。這種庫一般包括基本的輸入輸出或是內存管理等，一般是一群支持正在執行程序的函數，與操作系統合作提供諸如數學運算、輸入輸出等功能，讓開發者不需要“重新發明輪子”，并使用操作系統提供的功能。

運行時庫提供了程序執行時的最基本需要。比如Visual Basic需要復雜的運行時庫支持而C的運行時庫則相對簡單。運行時庫中的函數可能對程序員透明，也可能不透明，這是由編譯器廠商根據語言執行環境的需求而決定的。

許多近代語言設計了更強大的運行時環境并添加了更多功能，很多面向對象語言也包含了分派器與類別讀取器，Java虛擬機（JVM）便是此類的典型執行環境，而.NET架構也是另外一個運行時庫的實例。異常處理（Exception handling）是專門處理執行期錯誤的語言機制，使開發者可以完全捕捉非預期錯誤，或沒有適當處理的錯誤結果。

動態鏈接庫或靜態鏈接庫與運行時庫的分類角度不同，運行時庫就是程序運行的時候所需要依賴的庫文件.

C和C++運行時庫

為了提高C語言的開發效率，C標準定義了一系列常用的函數，稱為C庫函數。C標準僅僅定義了函數原型，并沒有提供實現。因此這個任務留給了各個支持C語言標準的編譯器。每個編譯器通常實現了標準C的超集，稱為C運行時庫（C Run Time Library），簡稱CRT。C標準庫就是任何平臺都可以使用的基本C語言庫。而CRT除了將C標準庫加入所屬范圍外，還擴展了與平臺相關的接口庫，這些接口實現根據不同平臺調用不同平臺的操作系統API。 

與C語言類似，C++也定義了自己的標準，同時提供相關支持庫，稱為C++運行時庫或C++標準庫。由于C++對C的兼容性，C++標準庫包括了C標準庫，除此之外還包括了IO流和標準模板庫STL。

圖片

VC+按照C和C++標準定義的函數原型實現了上述運行時庫。為了方便有不同需求的客戶使用，VC++分別實現了動態鏈接庫DLL版本和靜態鏈接庫LIB版本。同時為了支持程序調試且不影響程序的性能，又分別提供了對應的調試版本。使用DLL版的C和C++運行庫，程序在運行時動態的加載對應的DLL。程序體積變小，但一個很大的問題就是一旦找不到對應DLL,程序將無法運行。

在windows上開發多線程程序時，需要選擇MT、MTd、MD、MDd其中的一個。對于MT/MTd，由于連接運行時庫是LIBCMT.lib/LIBCMTD.lib，這兩個庫是靜態庫，所以此種方式編譯的程序，移到另一臺機器上面也可以正常運行，所以這種方式，不會產生缺少動態庫的報錯。但是對于MD/MDd，連接的是動態庫，所以如果另一臺機器上沒有MSVCRT.dll/MSVCRTD.dll時，就提示缺少動態庫這樣的錯誤。對用戶自己寫的庫或其他第三方庫，其連接方式取決于代碼（顯示連接動態庫Loadlibrary）或所提供的lib文件，移動程序到別的機器上時，還是要帶上所需要的動態庫的。在多工程開發時，最好所有的工程使用同一種運行時庫。

運行時安全

近年來出現的運行時應用程序自我保護技術（Runtime Application Self-Protection，簡稱RASP），是一種解決應用程序漏洞問題并為IT基礎架構增加額外安全層的方法。根據Ｇartner的說法，運行時應用程序自我保護是“建立在或鏈接到應用程序運行時環境的安全技術，它能夠控制應用程序的執行，并且檢測和阻止實時攻擊。”

運行時應用程序自我保護是預防性的，它可以采取多種措施來阻止黑客破壞系統，在出現問題時控制應用程序。除了檢測惡意代碼，RASP還可以：

• 突然結束用戶會話
• 關閉應用程序或系統
• 標記異常事件的管理員和安全人員
• 向系統用戶發送警告

RASP一般與應用程序集成，并通過監視和分析流量以及用戶行為來防止程序運行時受到攻擊，這使它們可以在應用程序中看到功能級別的代碼。這種可見性使其能夠更準確地識別攻擊，減少誤報并報告或阻止構成合法威脅的那些動作。

常見的運行時環境

這里，我們來了解不同編程語言的運行時環境，包括C語言的操作系統運行機制、Apache Portable Runtime、Common Language Runtime、Java Runtime Environment、Android Runtime、iOS Runtime、JavaScript引擎與運行時環境以及小程序的運行時環境。進而，思考各個運行時環境的特點和優劣，以及它們在不同平臺上的表現。

C/C++運行時

C 語言最主要的運行時，實際上就是操作系統。C 語言和現代的各種操作系統可以說是伴生關系，就像 Java 和 JVM 是伴生關系一樣。

在程序執行機制方面，C 語言編譯完畢的程序是完全按照操作系統的運行機制來執行的。在內存管理方面，C 語言使用了操作系統提供的線程棧，操作系統能夠自動幫助程序管理內存。程序也可以從堆里申請內存，但必須自己負責釋放，沒有自動內存管理機制。在并發機制方面，當然也是直接用操作系統提供的線程機制。如果操作系統沒有提供協程和 Actor 機制，所以 C 語言也沒有提供這種并發機制。

APR

Apache可移植運行時（Apache Portable Runtime，簡稱APR）是Apache HTTP服務器的支持庫，提供了一組映射到下層操作系統的API。如果操作系統不支持某個特定的功能，APR將提供一個模擬實現。這樣程序員使用APR編寫真正可在不同平臺上移植的程序。

APR使得平臺細節的處理進行下移。對于應用程序而言，它們根本就不需要考慮具體的平臺，不管是Unix、Linux還是Window，應用程序執行的接口基本都是統一一致的。因此對于APR而言，可移植性和統一的上層接口是其考慮的一個重點。而最初，APR是作為Apache HTTP服務器的一部分而存在的，但是Apache軟件基金會將其延伸成一個單獨的項目，其他的應用程序可以使用APR來實現平臺無關性。APR的目標則是希望安全合并所有的能夠合并的代碼而不需要犧牲性能。

CLR

通用語言執行平臺（Common Language Runtime，簡稱CLR）是微軟為他們的.NET的虛擬機所選用的名稱。它是微軟對通用語言架構（CLI）的實例，它定義了一個程式碼執行的環境。CLR執行一種稱為通用中間語言的字節碼，運行在Windows操作系統上。

.NET 運行時安裝在計算機上，供依賴該框架的應用程序使用。該運行時具有一個廣泛的標準類庫集，稱為運行時框架庫或基類庫 (BCL)。此外，還有運行時庫的擴展，這些庫為許多常見和特定于與應用的類型、算法和實用程序功能提供實現。

JRE

JRE 是 Java 程序的運行環境，其中包含一個 JAVA 虛擬機以及一些標準的函數類庫。也就是說，JRE（Java Runtime Environment）一種能夠執行Java字節碼的虛擬機，以堆棧結構來實現的。JVM有自己完善的硬體架構，如處理器、堆棧、寄存器等，還具有相應的指令系統。JRE屏蔽了與具體操作系統平臺相關的信息，使得Java程序只需生成在Java虛擬機上運行的字節碼，就可以在多種平臺上不加修改地運行。

作為一種編程語言的虛擬機，JVM實際上不只是專用于Java語言，只要生成的編譯文件符合JVM對載入編譯文件格式要求，任何語言都可以在JRE上運行。

ART

Android Runtime（縮寫為ART），是一種在Android操作系統上的運行環境，由Google公司研發，并在2013年作為Android 4.4系統中的一項測試功能正式對外發布，在Android 5.0及后續Android版本中作為正式的運行時庫取代了以往的Dalvik虛擬機。ART能夠把應用程序的字節碼轉換為機器碼，是Android所使用的一種新的虛擬機。

圖片

與Dalvik虛擬機不同的是，ART引入了AOT這種預編譯技術，在應用程序安裝的過程中，ART就已經將所有的字節碼重新編譯成了機器碼。應用程序運行過程中無需進行實時的編譯工作，只需要進行直接調用。因此，ART極大地提高了應用程序的運行效率，同時也減少了手機的電量消耗，提高了移動設備的續航能力，在垃圾回收等機制上也有了較大的提升。為了保證向下兼容，ART使用了相同的Dalvik字節碼文件（dex），即在應用程序目錄下保留了dex文件供舊程序調用，然而.odex文件則替換成了可執行與可鏈接格式（ELF）可執行文件。一旦一個程序被ART的dex2oat命令編譯，那么這個程序將會只通過ELF可執行文件來運行。因此，相對于Dalvik虛擬機模式，ART模式下Android應用程序的安裝需要消耗更多的時間，同時也會占用更大的內部儲存空間，用于儲存編譯后的代碼，但節省了很多Dalvik虛擬機用于實時編譯的時間。

iOS Runtime

在iOS中，通常將 Runtime 理解成實現Obj-C語言動態的 API。Obj-C的動態性就是運行時機制，其中最主要的是消息機制。

在iOS Runtime的支持下，動態類型和動態綁定使得選擇那個接收者以及調用哪個方法都可以在運行時決定;應用可以根據需要加載可執行代碼以及資源，而不是在啟動時就加載所有資源;iOS在編譯的時候會根據方法的名字(包括參數序列),生成一個用來區分這個方法的唯一的ID，這個ID是SEL類型的，只要方法的名字（包括參數序列）相同，那么它們的ID都是相同的。通過 dlopen 把動態庫文件載入運行的 App 里，接下來 dlsym 會得到動態庫的符號地址，然后就可以處理類的替換工作。整個過程無需重新編譯和重載 App，使用動態庫方式極速調試的目的就達成了。

JS引擎與運行時

JavaScript 引擎是一個解釋 JavaScript 代碼的程序，該引擎負責執行代碼。任何 JavaScript 引擎通常都包含一個調用棧和一個堆。調用棧是代碼執行的地方，堆是一個非結構化的內存池，用于存儲應用程序所需的所有對象。當代碼片段進入運行時環境時，代碼首先被讀取，隨后被解析為叫作抽象語法樹（AST）的數據結構。生成的樹被用來來創建機器代碼。

JavaScript 運行時環境包含了運行 JavaScript 所需的所有組件，包括 JavaScript 引擎、Web API 和回調隊列。

圖片

瀏覽器運行時和 Node.js 是JS運行時環境的具體例子。當 JavaScript 在 Web 瀏覽器中執行時，它是在瀏覽器的運行時環境中運行的。瀏覽器運行時環境提供對 DOM 的訪問，從而實現了與網頁元素的交互，處理事件，以及對頁面結構的操作。Node.js 提供了一個服務器端運行時環境，它在瀏覽器外部執行 JavaScript，所以它不能訪問 Web API。Node.js 運行時環境將其替換為叫作 C++ 綁定和線程池的東西。每個主流的瀏覽器都有一個可以執行 JavaScript 代碼的 JavaScript 引擎。最流行的是谷歌瀏覽器 Chrome 的 V8 引擎，同時為 Chrome 和 Node.js 提供了支持。

小程序的運行時

小程序的運行時環境可以看作JS運行時環境的特例。不同運行平臺上，小程序的運行時環境有所不同，性能表現也存在差異：

• 在 iOS、iPadOS 和 Mac OS 上，小程序的 JavaScript 代碼運行在 JavaScriptCore 中，；
• 在 Android 上，小程序的 JavaScript 代碼運行在 V8 中；
• 在 Windows 上，小程序JavaScript 使用 Chromium 內核；
• 在 開發工具上，小程序 JavaScript 代碼一般運行在 NW.js 中。

其中，JavaScriptCore 無法開啟 JIT 編譯，同等條件下的運行性能要明顯低于其他平臺。

盡管各運行環境是十分相似的，但是還是有些許區別，那就是JavaScript 語法和 API 支持存在不一致，開發者可以通過開啟 ES6 轉 ES5 的功能來規避。

運行時的云應用

容器運行時負責運行容器并設置命名空間和控制組，如Docker、containerd、rkt、Kata Container、CRI-O等；FaaS的運行時支持多種語言，每個主要編程語言版本都有單獨的運行時，可以使用Lambda提供的運行時或構建自己的運行時，也可以自定義運行時為Shell腳本或可在Linux可執行的二進制文件。

容器運行時

容器運行時更側重于運行容器，為容器設置命名空間和控制組（cgroup），也被稱為底層容器運行時。高層的容器運行時或容器引擎專注于格式、解包、管理和鏡像共享。它們還為開發者提供 API，這種情況下的容器運行時相當于一個可獨立運行的模塊，可以將它視為功能性的 Native 類庫使用。

Docker是目前最廣泛的容器引擎技術。當然，隨著容器生態圈的日益繁榮，業界慢慢也出現了其他各種運行時工具，如containerd、rkt、Kata Container、CRI-O等。這些工具提供的功能不盡相同，有些只有容器運行的功能，有些除運行容器外還提供了容器鏡像的管理功能。

圖片

低層運行時主要負責與宿主機操作系統打交道，根據指定的容器鏡像在宿主機上運行容器的進程，并對容器的整個生命周期進行管理。常見的低層運行時系統的種類有：

• runc：傳統的運行時環境，基于Linux Namespace和Cgroups技術實現，代表實現Docker
• runv：基于虛擬機管理程序的運行時環境，通過虛擬化 guest kernel，將容器和主機隔離開來，使得其邊界更加清晰，代表實現是Kata Container和Firecracker
• runsc：runc + safety ，通過攔截應用程序的所有系統調用，提供安全隔離的輕量級容器運行時沙箱，代表實現是谷歌的gVisor

Kubernetes利用Docker作為容器運行時管理工具，后來又添加了對rkt的支持。但隨著容器技術的蓬勃發展，越來越多的運行時工具出現，提供對所有運行時工具的支持，顯然是一項龐大的工程。如果直接將運行時的集成內置于Kubernetes，對Kubernetes代碼本身也是一種負擔，每次更新，都需要考慮對所有容器運行時的兼容適配。因此，Kubernetes將對容器的操作抽象為一個接口，將此接口作為kubelet與運行時工具之間的橋梁，kubelet通過發送接口請求對容器進行啟動和管理，各個容器工具通過實現這個接口即可接入Kubernetes。這個統一的容器操作接口，就是容器運行時接口(Container Runtime Interface, CRI)。

FaaS的運行時

Lambda 通過使用運行時支持多種語言。運行時系統提供特定于語言的環境，用于在 Lambda 與函數之間中繼調用事件、上下文信息和響應。我們可以使用 Lambda 提供的運行時，或構建您自己的運行時。

每個主要編程語言版本都有單獨的運行時，并具有唯一的運行時標識符，例如 python3.10 或 nodejs18.x。要將某個云端的函數計算配置為使用新的主要語言版本，需要更改運行時系統標識符。對于定義為容器映像的函數，可以在創建容器映像時選擇運行時系統和 Linux 發行版。要更改運行時，需要創建一個新的容器映像。

在將 .zip 文件存檔作為部署程序包的時候，需要在創建函數時選擇運行時。要更改運行時，需要更新云端函數計算的配置。云服務的底層執行環境提供了可通過函數代碼訪問的額外的庫和環境變量。

自定義的運行時可以是Shell腳本，也可以是可在linux可執行的二進制文件。

小結

本文首先澄清了運行時的核心概念，然后介紹了不同類型的運行時環境，包括Android的ART和Dalvik虛擬機、iOS的Runtime、JavaScript引擎和運行時環境、小程序的運行時環境、以及云應用的容器運行時和FaaS的運行時。對于容器運行時，了解了常見的低層運行時種類以及Kubernetes如何通過容器運行時接口（CRI）實現對所有容器運行時的支持。對于FaaS的運行時，介紹了Lambda如何通過使用運行時支持多種語言，并提供特定于語言的環境，用于在Lambda與函數之間中繼調用事件、上下文信息和響應。