理解應(yīng)用程序的輸入/輸出(I/O)模型，意味著其在計劃處理負(fù)載與殘酷的實際使用場景之間的差異。若應(yīng)用程序比較小，也沒有服務(wù)于很高的負(fù)載，也許它影響甚微。但隨著應(yīng)用程序的負(fù)載逐漸上漲，采用錯誤的I/O模型有可能會讓你到處踩坑，傷痕累累。

正如大部分存在多種解決途徑的場景一樣，重點不在于哪一種途徑更好，而是在于理解如何進(jìn)行權(quán)衡。讓我們來參觀下I/O的景觀，看下可以從中竊取點什么。

在這篇文章，我們將會結(jié)合Apache分別比較Node，Java，Go，和PHP，討論這些不同的語言如何對他們的I/O進(jìn)行建模，各個模型的優(yōu)點和缺點，并得出一些初步基準(zhǔn)的結(jié)論。如果關(guān)心你下一個Web應(yīng)用的I/O性能，那你就找對文章了。

I/O基礎(chǔ)知識：快速回顧

為了理解與I/O密切相關(guān)的因素，必須先來回顧在操作系統(tǒng)底層的概念。雖然不會直接處理這些概念的大部分，但通過應(yīng)用程序的運(yùn)行時環(huán)境你一直在間接地處理他們。而關(guān)鍵在于細(xì)節(jié)。

系統(tǒng)調(diào)用

首先，我們有系統(tǒng)調(diào)用，它可以描述成這樣：

你的程序(在“用戶區(qū)域”，正如他們所說的)必須讓操作系統(tǒng)內(nèi)核在它自身執(zhí)行I/O操作。

“系統(tǒng)調(diào)用”(syscall)意味著你的程序要求內(nèi)核做某事。不同的操作系統(tǒng)，實現(xiàn)系統(tǒng)調(diào)用的細(xì)節(jié)有所不同，但基本的概念是一樣的。這將會有一些特定的指令，把控制權(quán)從你的程序轉(zhuǎn)交到內(nèi)核(類似函數(shù)調(diào)用但有一些專門用于處理這種場景的特殊sauce)。通常來說，系統(tǒng)調(diào)用是阻塞的，意味著你的程序需要等待內(nèi)核返回到你的代碼。

內(nèi)核在我們所說的物理設(shè)備(硬盤、網(wǎng)卡等)上執(zhí)行底層的I/O操作，并回復(fù)給系統(tǒng)調(diào)用。在現(xiàn)實世界中，內(nèi)核可能需要做很多事情才能完成你的請求，包括等待設(shè)備準(zhǔn)備就緒，更新它的內(nèi)部狀態(tài)等，但作為一名應(yīng)用程序開發(fā)人員，你可以不用關(guān)心這些。以下是內(nèi)核的工作情況。

阻塞調(diào)用與非阻塞調(diào)用

好了，我剛剛在上面說系統(tǒng)調(diào)用是阻塞的，通常來說這是對的。然而，有些調(diào)用被分類為“非阻塞”，意味著內(nèi)核接收了你的請求后，把它放進(jìn)了隊列或者緩沖的某個地方，然后立即返回而并沒有等待實際的I/O調(diào)用。所以它只是“阻塞”了一段非常短的時間，短到只是把你的請求入列而已。

這里有一些有助于解釋清楚的(Linux系統(tǒng)調(diào)用)例子：-read()是阻塞調(diào)用——你傳給它一個文件句柄和一個存放所讀到數(shù)據(jù)的緩沖，然后此調(diào)用會在當(dāng)數(shù)據(jù)好后返回。注意這種方式有著優(yōu)雅和簡單的優(yōu)點。-epoll_create()，epoll_ctl()，和epoll_wait()這些調(diào)用分別是，讓你創(chuàng)建一組用于偵聽的句柄，從該組添加/刪除句柄，和然后直到有活動時才阻塞。這使得你可以通過一個線程有效地控制一系列I/O操作。如果需要這些功能，這非常棒，但也正如你所看到的，使用起來當(dāng)然也相當(dāng)復(fù)雜。

理解這里分時差異的數(shù)量級是很重要的。如果一個CPU內(nèi)核運(yùn)行在3GHz，在沒有優(yōu)化的情況下，它每秒執(zhí)行30億次循環(huán)(或者每納秒3次循環(huán))。非阻塞系統(tǒng)調(diào)用可能需要10納秒這樣數(shù)量級的周期才能完成——或者“相對較少的納秒”。對于正在通過網(wǎng)絡(luò)接收信息的阻塞調(diào)用可能需要更多的時間——例如200毫秒(0.2秒)。例如，假設(shè)非阻塞調(diào)用消耗了20納秒，那么阻塞調(diào)用消耗了200,000,000納秒。對于阻塞調(diào)用，你的程序多等待了1000萬倍的時間。

內(nèi)核提供了阻塞I/O(“從網(wǎng)絡(luò)連接中讀取并把數(shù)據(jù)給我”)和非阻塞I/O(“當(dāng)這些網(wǎng)絡(luò)連接有新數(shù)據(jù)時就告訴我”)這兩種方法。而使用何種機(jī)制，對應(yīng)調(diào)用過程的阻塞時間明顯長度不同。

調(diào)度

接下來第三件關(guān)鍵的事情是，當(dāng)有大量線程或進(jìn)程開始阻塞時怎么辦。

出于我們的目的，線程和進(jìn)程之間沒有太大的區(qū)別。實際上，最顯而易見的執(zhí)行相關(guān)的區(qū)別是，線程共享相同的內(nèi)存，而每個進(jìn)程則擁有他們獨(dú)自的內(nèi)存空間，使得分離的進(jìn)程往往占據(jù)了大量的內(nèi)存。但當(dāng)我們討論調(diào)度時，它最終可歸結(jié)為一個事件清單(線程和進(jìn)程類似)，其中每個事件需要在有效的CPU內(nèi)核上獲得一片執(zhí)行時間。如果你有300個線程正在運(yùn)行并且運(yùn)行在8核上，那么你得通過每個內(nèi)核運(yùn)行一段很短的時間然后切換到下一個線程的方式，把這些時間劃分開來以便每個線程都能獲得它的分時。這是通過“上下文切換”來實現(xiàn)的，使得CPU可以從正在運(yùn)行的某個線程/進(jìn)程切換到下一個。

這些上下文切換有一定的成本——它們消耗了一些時間。在快的時候，可能少于100納秒，但是根據(jù)實現(xiàn)的細(xì)節(jié)，處理器速度/架構(gòu)，CPU緩存等，消耗1000納秒甚至更長的時間也并不罕見。

線程(或者進(jìn)程)越多，上下文切換就越多。當(dāng)我們談?wù)摮汕先f的線程，并且每一次切換需要數(shù)百納秒時，速度將會變得非常慢。

然而，非阻塞調(diào)用本質(zhì)上是告訴內(nèi)核“當(dāng)你有一些新的數(shù)據(jù)或者這些連接中的任意一個有事件時才調(diào)用我”。這些非阻塞調(diào)用設(shè)計于高效地處理大量的I/O負(fù)載，以及減少上下文切換。

到目前為止你還在看這篇文章嗎？因為現(xiàn)在來到了有趣的部分：讓我們來看下一些流利的語言如何使用這些工具，并就在易用性和性能之間的權(quán)衡作出一些結(jié)論……以及其他有趣的點評。

請注意，雖然在這篇文章中展示的示例是瑣碎的(并且是不完整的，只是顯示了相關(guān)部分的代碼)，但數(shù)據(jù)庫訪問，外部緩存系統(tǒng)(memcache等全部)和需要I/O的任何東西，都以執(zhí)行某些背后的I/O操作而結(jié)束，這些和展示的示例一樣有著同樣的影響。同樣地，對于I/O被描述為“阻塞”(PHP，Java)這樣的情節(jié)，HTTP請求與響應(yīng)的讀取與寫入本身是阻塞的調(diào)用：再一次，更多隱藏在系統(tǒng)中的I/O及其伴隨的性能問題需要考慮。

為項目選擇編程語言要考慮的因素有很多。當(dāng)你只考慮性能時，要考慮的因素甚至有更多。但是，如果你關(guān)注的是程序主要受限于I/O，如果I/O性能對于你的項目至關(guān)重要，那這些都是你需要了解的。“保持簡單”的方法：PHP。

回到90年代的時候，很多人穿著匡威鞋，用Perl寫著CGI腳本。隨后出現(xiàn)了PHP，很多人喜歡使用它，它使得制作動態(tài)網(wǎng)頁更為容易。

PHP使用的模型相當(dāng)簡單。雖然有一些變化，但基本上PHP服務(wù)器看起來像：

HTTP請求來自用戶的瀏覽器，并且訪問了你的Apache網(wǎng)站服務(wù)器。Apache為每個請求創(chuàng)建一個單獨(dú)的進(jìn)程，通過一些優(yōu)化來重用它們，以便最大程度地減少其需要執(zhí)行的次數(shù)(創(chuàng)建進(jìn)程相對來說較慢)。Apache調(diào)用PHP并告訴它在磁盤上運(yùn)行相應(yīng)的.php文件。PHP代碼執(zhí)行并做一些阻塞的I/O調(diào)用。若在PHP中調(diào)用了file_get_contents()，那在背后它會觸發(fā)read()系統(tǒng)調(diào)用并等待結(jié)果返回。

當(dāng)然，實際的代碼只是簡單地嵌在你的頁面中，并且操作是阻塞的：

// 阻塞的文件I/O

$file_data = file_get_contents('/path/to/file.dat');

// 阻塞的網(wǎng)絡(luò)I/O

$curl = curl_init('http://example.com/example-microservice');

$result = curl_exec($curl);

// 更多阻塞的網(wǎng)絡(luò)I/O

$result = $db->query('SELECT id, data FROM examples ORDER BY id DESC limit 100');

?>

關(guān)于它如何與系統(tǒng)集成，就像這樣：

相當(dāng)簡單：一個請求，一個進(jìn)程。I/O是阻塞的。優(yōu)點是什么呢？簡單，可行。那缺點是什么呢？同時與20,000個客戶端連接，你的服務(wù)器就掛了。由于內(nèi)核提供的用于處理大容量I/O(epoll等)的工具沒有被使用，所以這種方法不能很好地擴(kuò)展。更糟糕的是，為每個請求運(yùn)行一個單獨(dú)的過程往往會使用大量的系統(tǒng)資源，尤其是內(nèi)存，這通常是在這樣的場景中遇到的第一件事情。

注意：Ruby使用的方法與PHP非常相似，在廣泛而普遍的方式下，我們可以將其視為是相同的。

多線程的方式：Java

所以就在你買了你的第一個域名的時候，Java來了，并且在一個句子之后隨便說一句“dot com”是很酷的。而Java具有語言內(nèi)置的多線程(特別是在創(chuàng)建時)，這一點非常棒。

大多數(shù)Java網(wǎng)站服務(wù)器通過為每個進(jìn)來的請求啟動一個新的執(zhí)行線程，然后在該線程中最終調(diào)用作為應(yīng)用程序開發(fā)人員的你所編寫的函數(shù)。

在Java的Servlet中執(zhí)行I/O操作，往往看起來像是這樣：

public void doGet(HttpServletRequest request,

HttpServletResponse response) throws ServletException, IOException

{

// 阻塞的文件I/O

InputStream fileIs = new FileInputStream("/path/to/file");

// 阻塞的網(wǎng)絡(luò)I/O

URLConnection urlConnection = (new URL("http://example.com/example-microservice")).openConnection();

InputStream netIs = urlConnection.getInputStream();

// 更多阻塞的網(wǎng)絡(luò)I/O

out.println("...");

}

由于我們上面的doGet方法對應(yīng)于一個請求并且在自己的線程中運(yùn)行，而不是每次請求都對應(yīng)需要有自己專屬內(nèi)存的單獨(dú)進(jìn)程，所以我們會有一個單獨(dú)的線程。這樣會有一些不錯的優(yōu)點，例如可以在線程之間共享狀態(tài)、共享緩存的數(shù)據(jù)等，因為它們可以相互訪問各自的內(nèi)存，但是它如何與調(diào)度進(jìn)行交互的影響，仍然與前面PHP例子中所做的內(nèi)容幾乎一模一樣。每個請求都會產(chǎn)生一個新的線程，而在這個線程中的各種I/O操作會一直阻塞，直到這個請求被完全處理為止。為了最小化創(chuàng)建和銷毀它們的成本，線程會被匯集在一起，但是依然，有成千上萬個連接就意味著成千上萬個線程，這對于調(diào)度器是不利的。

一個重要的里程碑是，在Java 1.4 版本(和再次顯著升級的1.7 版本)中，獲得了執(zhí)行非阻塞I/O調(diào)用的能力。大多數(shù)應(yīng)用程序，網(wǎng)站和其他程序，并沒有使用它，但至少它是可獲得的。一些Java網(wǎng)站服務(wù)器嘗試以各種方式利用這一點; 然而，絕大多數(shù)已經(jīng)部署的Java應(yīng)用程序仍然如上所述那樣工作。

Java讓我們更進(jìn)了一步，當(dāng)然對于I/O也有一些很好的“開箱即用”的功能，但它仍然沒有真正解決問題：當(dāng)你有一個嚴(yán)重I/O綁定的應(yīng)用程序正在被數(shù)千個阻塞線程狂拽著快要墜落至地面時怎么辦。

作為一等公民的非阻塞I/O：Node

當(dāng)談到更好的I/O時，Node.js無疑是新寵。任何曾經(jīng)對Node有過最簡單了解的人都被告知它是“非阻塞”的，并且它能有效地處理I/O。在一般意義上，這是正確的。但魔鬼藏在細(xì)節(jié)中，當(dāng)談及性能時這個巫術(shù)的實現(xiàn)方式至關(guān)重要。

本質(zhì)上，Node實現(xiàn)的范式不是基本上說“在這里編寫代碼來處理請求”，而是轉(zhuǎn)變成“在這里寫代碼開始處理請求”。每次你都需要做一些涉及I/O的事情，發(fā)出請求或者提供一個當(dāng)完成時Node會調(diào)用的回調(diào)函數(shù)。

在求中進(jìn)行I/O操作的典型Node代碼，如下所示：

http.createServer(function(request, response) {

fs.readFile('/path/to/file', 'utf8', function(err, data) {

response.end(data);

});

});

可以看到，這里有兩個回調(diào)函數(shù)。第一個會在請求開始時被調(diào)用，而第二個會在文件數(shù)據(jù)可用時被調(diào)用。

這樣做的基本上給了Node一個在這些回調(diào)函數(shù)之間有效地處理I/O的機(jī)會。一個更加相關(guān)的場景是在Node中進(jìn)行數(shù)據(jù)庫調(diào)用，但我不想再列出這個煩人的例子，因為它是完全一樣的原則：啟動數(shù)據(jù)庫調(diào)用，并提供一個回調(diào)函數(shù)給Node，它使用非阻塞調(diào)用單獨(dú)執(zhí)行I/O操作，然后在你所要求的數(shù)據(jù)可用時調(diào)用回調(diào)函數(shù)。這種I/O調(diào)用隊列，讓Node來處理，然后獲取回調(diào)函數(shù)的機(jī)制稱為“事件循環(huán)”。它工作得非常好。

然而，這個模型中有一道關(guān)卡。在幕后，究其原因，更多是如何實現(xiàn)JavaScript V8 引擎(Chrome的JS引擎，用于Node)1，而不是其他任何事情。你所編寫的JS代碼全部都運(yùn)行在一個線程中。思考一下。這意味著當(dāng)使用有效的非阻塞技術(shù)執(zhí)行I/O時，正在進(jìn)行CPU綁定操作的JS可以在運(yùn)行在單線程中，每個代碼塊阻塞下一個。 一個常見的例子是循環(huán)數(shù)據(jù)庫記錄，在輸出到客戶端前以某種方式處理它們。以下是一個例子，演示了它如何工作：

var handler = function(request, response) {

connection.query('SELECT ...', function (err, rows) {

if (err) { throw err };

for (var i = 0; i < rows.length; i++) {

// 對每一行紀(jì)錄進(jìn)行處理

}

response.end(...); // 輸出結(jié)果

})

};

雖然Node確實可以有效地處理I/O，但上面的例子中的for循環(huán)使用的是在你主線程中的CPU周期。這意味著，如果你有10,000個連接，該循環(huán)有可能會讓你整個應(yīng)用程序慢如蝸牛，具體取決于每次循環(huán)需要多長時間。每個請求必須分享在主線程中的一段時間，一次一個。

這個整體概念的前提是I/O操作是最慢的部分，因此最重要是有效地處理這些操作，即使意味著串行進(jìn)行其他處理。這在某些情況下是正確的，但不是全都正確。

另一點是，雖然這只是一個意見，但是寫一堆嵌套的回調(diào)可能會令人相當(dāng)討厭，有些人認(rèn)為它使得代碼明顯無章可循。在Node代碼的深處，看到嵌套四層、嵌套五層、甚至更多層級的嵌套并不罕見。

我們再次回到了權(quán)衡。如果你主要的性能問題在于I/O，那么Node模型能很好地工作。然而，它的阿喀琉斯之踵(譯者注：來自希臘神話，表示致命的弱點)是如果不小心的話，你可能會在某個函數(shù)里處理HTTP請求并放置CPU密集型代碼，最后使得每個連接慢得如蝸牛。

真正的非阻塞：Go

在進(jìn)入Go這一章節(jié)之前，我應(yīng)該披露我是一名Go粉絲。我已經(jīng)在許多項目中使用Go，是其生產(chǎn)力優(yōu)勢的公開支持者，并且在使用時我在工作中看到了他們。

也就是說，我們來看看它是如何處理I/O的。Go語言的一個關(guān)鍵特性是它包含自己的調(diào)度器。并不是每個線程的執(zhí)行對應(yīng)于一個單一的OS線程，Go采用的是“goroutines”這一概念。Go運(yùn)行時可以將一個goroutine分配給一個OS線程并使其執(zhí)行，或者把它掛起而不與OS線程關(guān)聯(lián)，這取決于goroutine做的是什么。來自Go的HTTP服務(wù)器的每個請求都在單獨(dú)的Goroutine中處理。

此調(diào)度器工作的示意圖，如下所示：

這是通過在Go運(yùn)行時的各個點來實現(xiàn)的，通過將請求寫入/讀取/連接/等實現(xiàn)I/O調(diào)用，讓當(dāng)前的goroutine進(jìn)入睡眠狀態(tài)，當(dāng)可采取進(jìn)一步行動時用信息把goroutine重新喚醒。

實際上，除了回調(diào)機(jī)制內(nèi)置到I/O調(diào)用的實現(xiàn)中并自動與調(diào)度器交互外，Go運(yùn)行時做的事情與Node做的事情并沒有太多不同。它也不受必須把所有的處理程序代碼都運(yùn)行在同一個線程中這一限制，Go將會根據(jù)其調(diào)度器的邏輯自動將Goroutine映射到其認(rèn)為合適的OS線程上。最后代碼類似這樣：

func ServeHTTP(w http.ResponseWriter, r *http.Request) {

// 這里底層的網(wǎng)絡(luò)調(diào)用是非阻塞的

rows, err := db.Query("SELECT ...")

for _, row := range rows {

// 處理rows

// 每個請求在它自己的goroutine中

}

w.Write(...) // 輸出響應(yīng)結(jié)果，也是非阻塞的

}

正如你在上面見到的，我們的基本代碼結(jié)構(gòu)像是更簡單的方式，并且在背后實現(xiàn)了非阻塞I/O。

在大多數(shù)情況下，這最終是“兩個世界中最好的”。非阻塞I/O用于全部重要的事情，但是你的代碼看起來像是阻塞，因此往往更容易理解和維護(hù)。Go調(diào)度器和OS調(diào)度器之間的交互處理了剩下的部分。這不是完整的魔法，如果你建立的是一個大型的系統(tǒng)，那么花更多的時間去理解它工作原理的更多細(xì)節(jié)是值得的; 但與此同時，“開箱即用”的環(huán)境可以很好地工作和很好地進(jìn)行擴(kuò)展。

Go可能有它的缺點，但一般來說，它處理I/O的方式不在其中。

謊言，詛咒的謊言和基準(zhǔn)

對這些各種模式的上下文切換進(jìn)行準(zhǔn)確的定時是很困難的。也可以說這對你來沒有太大作用。所以取而代之，我會給出一些比較這些服務(wù)器環(huán)境的HTTP服務(wù)器性能的基準(zhǔn)。請記住，整個端對端的HTTP請求/響應(yīng)路徑的性能與很多因素有關(guān)，而這里我放在一起所提供的數(shù)據(jù)只是一些樣本，以便可以進(jìn)行基本的比較。

對于這些環(huán)境中的每一個，我編寫了適當(dāng)?shù)拇a以隨機(jī)字節(jié)讀取一個64k大小的文件，運(yùn)行一個SHA-256哈希N次(N在URL的查詢字符串中指定，例如.../test.php?n=100)，并以十六進(jìn)制形式打印生成的散列。我選擇了這個示例，是因為使用一些一致的I/O和一個受控的方式增加CPU使用率來運(yùn)行相同的基準(zhǔn)測試是一個非常簡單的方式。

關(guān)于環(huán)境使用，更多細(xì)節(jié)請參考這些基準(zhǔn)要點。

首先，來看一些低并發(fā)的例子。運(yùn)行2000次迭代，并發(fā)300個請求，并且每次請求只做一次散列(N = 1)，可以得到：

時間是在全部并發(fā)請求中完成請求的平均毫秒數(shù)。越低越好。

很難從一個圖表就得出結(jié)論，但對于我來說，似乎與連接和計算量這些方面有關(guān)，我們看到時間更多地與語言本身的一般執(zhí)行有關(guān)，因此更多在于I/O。請注意，被認(rèn)為是“腳本語言”(輸入隨意，動態(tài)解釋)的語言執(zhí)行速度最慢。

但是如果將N增加到1000，仍然并發(fā)300個請求，會發(fā)生什么呢 —— 相同的負(fù)載，但是hash迭代是之前的100倍(顯著增加了CPU負(fù)載)：

時間是在全部并發(fā)請求中完成請求的平均毫秒數(shù)。越低越好。

忽然之間，Node的性能顯著下降了，因為每個請求中的CPU密集型操作都相互阻塞了。有趣的是，在這個測試中，PHP的性能要好得多(相對于其他的語言)，并且打敗了Java。(值得注意的是，在PHP中，SHA-256實現(xiàn)是用C編寫的，執(zhí)行路徑在這個循環(huán)中花費(fèi)更多的時間，因為這次我們進(jìn)行了1000次哈希迭代)。

現(xiàn)在讓我們嘗試5000個并發(fā)連接(并且N = 1)—— 或者接近于此。不幸的是，對于這些環(huán)境的大多數(shù)，失敗率并不明顯。對于這個圖表，我們會關(guān)注每秒的請求總數(shù)。越高越好：

每秒的請求總數(shù)。越高越好。

這張照片看起來截然不同。這是一個猜測，但是看起來像是對于高連接量，每次連接的開銷與產(chǎn)生新進(jìn)程有關(guān)，而與PHP + Apache相關(guān)聯(lián)的額外內(nèi)存似乎成為主要的因素并制約了PHP的性能。顯然，Go是這里的冠軍，其次是Java和Node，最后是PHP。

結(jié)論

綜上所述，很顯然，隨著語言的演進(jìn)，處理大量I/O的大型應(yīng)用程序的解決方案也隨之不斷演進(jìn)。

為了公平起見，暫且拋開本文的描述，PHP和Java確實有可用于Web應(yīng)用程序的非阻塞I/O的實現(xiàn)。 但是這些方法并不像上述方法那么常見，并且需要考慮使用這種方法來維護(hù)服務(wù)器的伴隨的操作開銷。更不用說你的代碼必須以與這些環(huán)境相適應(yīng)的方式進(jìn)行結(jié)構(gòu)化; “正常”的PHP或Java Web應(yīng)用程序通常不會在這樣的環(huán)境中進(jìn)行重大改動。

作為比較，如果只考慮影響性能和易用性的幾個重要因素，可以得到：

語言

線程或進(jìn)程

非阻塞I/O

易用性

PHP

進(jìn)程

否

Java

線程

可用

需要回調(diào)

Node.js

線程

是

需要回調(diào)

Go

線程(Goroutine)

是

不需要回調(diào)

線程通常要比進(jìn)程有更高的內(nèi)存效率，因為它們共享相同的內(nèi)存空間，而進(jìn)程則沒有。結(jié)合與非阻塞I/O相關(guān)的因素，當(dāng)我們向下移動列表到一般的啟動時，因為它與改善I/O有關(guān)，可以看到至少與上面考慮的因素一樣。如果我不得不在上面的比賽中選出一個冠軍，那肯定會是Go。

即便這樣，在實踐中，選擇構(gòu)建應(yīng)用程序的環(huán)境與你的團(tuán)隊對于所述環(huán)境的熟悉程度以及可以實現(xiàn)的總體生產(chǎn)力密切相關(guān)。因此，每個團(tuán)隊只是一味地扎進(jìn)去并開始用Node或Go開發(fā)Web應(yīng)用程序和服務(wù)可能沒有意義。事實上，尋找開發(fā)人員或內(nèi)部團(tuán)隊的熟悉度通常被認(rèn)為是不使用不同的語言和/或不同的環(huán)境的主要原因。也就是說，過去的十五年來，時代已經(jīng)發(fā)生了巨大的變化。

希望以上內(nèi)容可以幫助你更清楚地了解幕后所發(fā)生的事件，并就如何處理應(yīng)用程序現(xiàn)實世界中的可擴(kuò)展性為你提供的一些想法。快樂輸入，快樂輸出！

總結(jié)

以上是生活随笔為你收集整理的go java性能_服务端I/O性能大比拼：Node、PHP、Java和Go的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。