Archer

這是「解密 Stack Overflow 架構(gòu)」系列的第一篇，本系列會有非常多的內(nèi)容。歡迎閱讀并保持關(guān)注。

為了便于理解本文涉及到的東西到底都干些了什么，讓我先從 Stack Overflow 每天平均統(tǒng)計量的變化開始。下面的數(shù)據(jù)數(shù)來自 2013 年 11 月 12 日的統(tǒng)計：

• 負載均衡器接受了148,084,833次HTTP請求
• 其中36,095,312次是加載頁面
• 833,992,982,627 bytes (776 GB) 的HTTP流量用于發(fā)送
• 總共接收了286,574,644,032 bytes (267 GB) 數(shù)據(jù)
• 總共發(fā)送了1,125,992,557,312 bytes (1,048 GB) 數(shù)據(jù)
• 334,572,103次SQL查詢（僅包含來自于HTTP請求的）
• 412,865,051次Redis請求
• 3,603,418次標簽引擎請求
• 耗時558,224,585 ms (155 hours) 在SQL查詢上
• 耗時99,346,916 ms (27 hours) 在Redis請求上
• 耗時132,384,059 ms (36 hours) 在標簽引擎請求上
• 耗時2,728,177,045 ms (757 hours) 在ASP.Net程序處理上
• 節(jié)選自@蔣生武 翻譯的《StackOverflow 這么大，究竟用在什么硬件設(shè)備？》

下方數(shù)據(jù)是到 2016 年 2 月 9 日時，統(tǒng)計數(shù)字發(fā)生的變化，你可以比較一下：

• 負載均衡器收到的 HTTP 請求：209,420,973 (+61,336,090)
• 66,294,789 (+30,199,477) 其中的頁面加載數(shù)量
• 發(fā)送的 HTTP 數(shù)據(jù)量：1,240,266,346,053 (+406,273,363,426) bytes (1.24 TB)
• 總共接收的數(shù)據(jù)量：569,449,470,023 (+282,874,825,991) bytes (569 GB)
• 總共發(fā)送的數(shù)據(jù)量：3,084,303,599,266 (+1,958,311,041,954) bytes (3.08 TB)
• SQL 查詢（僅來自于 HTTP 請求）：504,816,843 (+170,244,740)
• Redis 緩存命中數(shù)：5,831,683,114 (+5,418,818,063)
• Elastic 搜索數(shù)量：17,158,874 (not tracked in 2013)
• 標簽引擎（Tag Engine）請求數(shù)：3,661,134 (+57,716)
• 運行 SQL 查詢累計消耗的時間：607,073,066 (+48,848,481) ms (168 hours)
• Redis 緩存命中消耗的時間：10,396,073 (-88,950,843) ms (2.8 hours)
• 標簽引擎請求消耗的時間：147,018,571 (+14,634,512) ms (40.8 hours)
• 在 ASP.Net 處理中消耗的時間：1,609,944,301 (-1,118,232,744) ms (447 hours)
• 22.71 (-5.29) ms 49,180,275 個問題頁面平均的渲染時間（其中 19.12 ms 消耗在 ASP.Net 中）
• 11.80 (-53.2) ms 6,370,076 個首頁的平均渲染時間（其中 8.81 ms 消耗在 ASP.Net 中）

你可能會好奇為什么 ASP.Net 在每天多處理6100萬次請求的情況下，處理時間卻減少了757個小時（相比于在2013 年）。這主要歸功于在 2015 年初的時候我們對服務(wù)器進行的升級，以及大量的應(yīng)用內(nèi)的性能優(yōu)化工作。別忘了：性能依然是個賣點。如果你對具體的硬件配置細節(jié)更加好奇的話，別擔(dān)心，我很快就會在下一篇文章中以附錄的形式給出運行這些網(wǎng)站所用的服務(wù)器的具體硬件配置細節(jié)（到時候我會更新這個鏈接）。

所以這兩年來到底發(fā)生了哪些變化？不太多，只是替換掉一些服務(wù)器和網(wǎng)絡(luò)設(shè)備而已。下面是今天運行網(wǎng)站所用的服務(wù)器概覽（注意和 2013 年相比有什么變化）

• 4 臺 Microsoft SQL Server 服務(wù)器（其中 2 臺使用了新的硬件）
• 11 臺 IIS Web 服務(wù)器（新的硬件）
• 2 臺 Redis 服務(wù)器（新的硬件）
• 3 臺標簽引擎服務(wù)器（其中 2 臺使用了新的硬件）
• 3 臺 Elasticsearch 服務(wù)器（同上）
• 4 臺 HAProxy 負載均衡服務(wù)器（添加了 2 臺，用于支持 CloudFlare）
• 2 臺網(wǎng)絡(luò)設(shè)備（Nexus 5596 核心 + 2232TM Fabric Extender，所有設(shè)備都升級到 10Gbps 帶寬）
• 2 臺 Fortinet 800C 防火墻（取代了 Cisco 5525-X ASAs）
• 2 臺 Cisco ASR-1001 路由器（取代了 Cisco 3945 路由器）
• 2 臺 Cisco ASR-1001-x 路由器（新的！）

為了支撐Stack Overflow的運行，我們需要些什么？從 2013 年至今并沒有太多的變化，不過因為優(yōu)化以及上面提到的新硬件設(shè)備，我們現(xiàn)在只需要一臺 web 服務(wù)器了。我們已經(jīng)無意中測試過這種情況了，成功了好幾次。請注意：我只是說這是可行的，我可沒說這是個好主意。不過每次發(fā)生這種情況的時候都還挺有意思的。

現(xiàn)在我們已經(jīng)對服務(wù)器縮放的想法有了一些基線數(shù)字，來看看我們是如何制作這些炫酷網(wǎng)頁的。很少有系統(tǒng)是完全獨立存在的（當(dāng)然我們的也不例外），如果沒有一個全局眼光能把這些部分集成在一起的話，架構(gòu)規(guī)劃的意義就要大打折扣了。我們的目標，就是把握全局。后續(xù)會有很多文章深入到每個特定的領(lǐng)域中。本文只是一個關(guān)于重點硬件的邏輯結(jié)構(gòu)概要，下一篇文章會包含這些硬件的具體細節(jié)。

如果你們想看看今天這些硬件到底長什么樣子的話，這里有幾張在 2015 年 2 月升級服務(wù)器的時候，我拍攝的機柜A的照片（機柜B和它是完全一樣的）：

如果你想看更多這種東西的話，這里是那一周升級過程中完整的 256 張照片的相冊（沒錯，這個數(shù)字就是故意的哈哈）。現(xiàn)在，讓我們來深入架構(gòu)布局。以下是現(xiàn)有的主要系統(tǒng)的邏輯架構(gòu)概要：

（點擊看大圖）

基本原則

以下是一些通行的原則，不需要再依次介紹它們了：

• 所有東西都有冗余備份。
• 所有的服務(wù)器和網(wǎng)絡(luò)設(shè)備之間都至少有兩個 10Gbps 帶寬的連接。
• 所有服務(wù)器都有兩路電源，通過兩個 UPS 單元組、背后的兩臺發(fā)電機、兩臺電網(wǎng)電壓前饋來提供電力。
• 所有服務(wù)器都有一個冗余備份分別位于機柜A和機柜B中。
• 所有服務(wù)器和服務(wù)都有雙份的冗余備份，放在另外一個數(shù)據(jù)中心（位于科羅拉多），雖然這里我主要是在介紹紐約的情況。
• 所有東西都有冗余備份。

互聯(lián)網(wǎng)

首先你得找到我們的網(wǎng)站，這是 DNS 的事兒。查找網(wǎng)站速度得快，所以我們現(xiàn)在把這事兒包給了 CloudFlare，因為他們有遍布在全球各個角落的 DNS 服務(wù)器。我們通過 API 來更新 DNS 記錄，他們負責(zé)“管理”DNS。不過以我們的小人之心，因為還是有根深蒂固的信任問題，所以我們依然還是擁有自己的 DNS 服務(wù)器。當(dāng)世界末日的時候——可能因為 GPL、Punyon（譯注：Stack Overflow 團隊的一員）或者緩存問題——而人們依然想要通過編程來轉(zhuǎn)移注意力的話，我們就會切換到自己的 DNS 服務(wù)器。

你的瀏覽器找到了我們的藏身之所之后，來自我們四家網(wǎng)絡(luò)服務(wù)供應(yīng)商（紐約的 Level 3、Zayo、Cogent 和 Lightower）的 HTTP 流量就會進入我們四臺先進的路由器之一。我們使用邊界網(wǎng)關(guān)協(xié)議（BGP，非常標準的協(xié)議）來對等處理來自網(wǎng)絡(luò)供應(yīng)商的流量，以此來對其進行控制，并提供最高效的通路來訪問我們的服務(wù)。這些 ASR-1001 和 ASR-1001-X 路由器被分為兩組，每組應(yīng)都使用雙活的模式（active/active）來處理來自兩家網(wǎng)絡(luò)供應(yīng)商的流量——在這里是有冗余備份的。雖然都是擁有同樣的物理 10Gbps 的帶寬，來自外部的流量還是和外部 VLAN 的流量獨立開來，分別接入負載均衡。在流量通過路由器之后，你就會來到負載均衡器了。

我想現(xiàn)在可能是時候提到我們在兩個數(shù)據(jù)中心之間擁有 10Gbps 帶寬的 MPLS，雖然這其實和網(wǎng)站服務(wù)沒什么直接關(guān)系。我們使用這種技術(shù)來進行數(shù)據(jù)的異地復(fù)制和快速恢復(fù)，來應(yīng)對某些突發(fā)情況。“不過 Nick，這里面可沒有冗余！”好吧，從技術(shù)角度上你說的沒錯（正面意義上的沒錯），在這個層面上它確實是單點故障。不過等等！通過網(wǎng)絡(luò)供應(yīng)商，我們還額外擁有兩個 OSPF 故障轉(zhuǎn)移路由（MPLS是第一選擇，出于成本考慮這個是第二和第三選擇）。之前提到的每組設(shè)備都會相應(yīng)地接入科羅拉多的數(shù)據(jù)中心，在故障轉(zhuǎn)移的情況下來對網(wǎng)絡(luò)流量進行負載均衡。當(dāng)然我們本可以讓這兩組設(shè)備互相之間都連接在一起，這樣就有四組通路了，不過管它呢，讓我們繼續(xù)。

負載均衡（HAProxy）

負載均衡通過 HAProxy 1.5.15 實現(xiàn)，運行在 CentOS 7 上（我們最喜歡的 Linux 版本）。并在HAProxy上加入TLS（SSL）安全傳輸協(xié)議。我們還在密切關(guān)注 HAProxy 1.7，它馬上就會提供對 HTTP/2 協(xié)議的支持。

和其他擁有雙路 10Gbps LACP 網(wǎng)絡(luò)連接的服務(wù)器不同，每臺負載均衡都擁有兩套 10Gbps 的連接：其中一套對應(yīng)外部網(wǎng)絡(luò)，另一套對應(yīng) DMZ。這些服務(wù)器擁有 64GB 或者更多的內(nèi)存，來更有效地處理 SSL 協(xié)議層。當(dāng)我們可以在內(nèi)存中緩存和重用更多的 TLS 會話的時候，在連接到同一個客戶端時就會少消耗一些計算資源。這意味著我們能夠以更快、更便宜的方式來還原會話。內(nèi)存是如此廉價，所以這是個很容易做出的抉擇。

負載均衡本身搭建起來很容易。我們在多個不同的 IP（主要出于證書和 DNS 管理的考慮）上監(jiān)聽不同的網(wǎng)站，然后將流量路由到不同的后端（主要基于host header）。我們在這里做的唯一值得一提的事情就是限速和抓取部分 header 信息（來自 web 層）記錄到 HAProxy 的系統(tǒng)日志消息中，通過這種方式我們可以記錄每個請求的性能指標。我們會在后面詳細提到這一點。

Web 層（IIS 8.5、ASP.Net MVC 5.2.3 和 .Net 4.6.1）

負載均衡將流量分配到 9 臺我們所謂的主 web 服務(wù)器（01-09）中和 2 臺開發(fā) web 服務(wù)器（10-11，我們的測試環(huán)境）。主服務(wù)器運行著 Stack Overflow、Careers 以及所有的 Stack Exchange 網(wǎng)站，除此之外的meta.stackoverflow.com 和 meta.stackexchange.com 在是運行在另外兩臺服務(wù)器上的。主要的 Q&A 應(yīng)用本身就是多租戶（multi-tenant）形式的，也就是說一個單獨應(yīng)用處理了所有 Q&A 網(wǎng)站的請求。換句話說，我們可以在一臺服務(wù)器的一個應(yīng)用程序池上，運行整個的 Q&A 應(yīng)用。其它的應(yīng)用比如 Careers、API v2、Mobile API 等等，都是獨立的。下面是主服務(wù)器和開發(fā)服務(wù)器的 IIS 中看到的內(nèi)容：

下面是在 Opserver（我們內(nèi)部的監(jiān)控儀表板）中看到的 Stack Overflow 的 web 層分布情況：

（點擊查看大圖）

還有下面這個是這些 web 服務(wù)器的資源消耗情況（譯注：不是說好的 11 臺么）：

（點擊查看大圖）

我會在后續(xù)的文章中詳細提到為什么我們過度提供了這么多資源，重點在于：滾動構(gòu)建（rolling build）、留有余地、冗余。

服務(wù)層（IIS、ASP.Net MVC 5.2.3、.NET 4.6.1 和 HTTP.SYS）

緊挨著web層的是服務(wù)層。它們同樣運行在 Windows 2012R2 的 IIS 8.5 之上。這一層運行一些內(nèi)部服務(wù)，對生產(chǎn)環(huán)境的 web 層和其他內(nèi)部系統(tǒng)提供支持。兩個主要的服務(wù)包括：“Stack Server”，其中運行著標簽引擎，是基于 http.sys的（背后并非是 IIS）；Providence API（基于IIS）。一個有趣的事實：我不得不對著兩個進程進行相關(guān)性設(shè)置，讓它們連接到不同的 socket 上，因為 Stack Server 在以兩分鐘為間隔刷新問題列表的時候，會非常頻繁的訪問 L2 和 L3 級緩存。

運行這些服務(wù)的機器對于標簽引擎和后端的 API 有著舉足輕重的意義，因此它們必須是冗余的，不過并不需要 9 倍的冗余。舉例來說，我們會每隔 n 分鐘（目前是兩分鐘）就從數(shù)據(jù)庫中加載所有文章及其標簽，這個操作消耗并不低。我們可不想在 web 層把這個加載操作重復(fù) 9 次，3 次對我們來說就足夠安全了。我們同樣會對這些服務(wù)器采用不同的硬件配置，以便針對標簽引擎和 elastic 索引作業(yè)（同樣運行在這一層中）的計算和數(shù)據(jù)加載的特征進行更好的優(yōu)化。“標簽引擎”本身就是一個相對復(fù)雜的話題，會在專門的文章中進行介紹。基本的原理是：當(dāng)你訪問地址 /questions/tagged/java 的時候，你會訪問標簽引擎來獲取與之匹配的問題。該引擎處理了除 /search 之外的所有標簽匹配工作，所以包括新的導(dǎo)航在內(nèi)的所有地方都是通過這個服務(wù)來獲取數(shù)據(jù)的。

緩存 & 發(fā)布/訂閱（Redis）

我們在一些地方使用了 Redis，它擁有堅如磐石般地穩(wěn)定性。盡管每個月的操作有 1600 億次之多，每個實例的 CPU 也不會超過 2%，通常會更低：

（點擊查看大圖）

我們借助 Redis 用于 L1/L2 級別的緩存系統(tǒng)。“L1”級是 HTTP 緩存，在 web 服務(wù)器或者任何類似的應(yīng)用程序中起作用。“L2”級則是當(dāng)上一級緩存失效之后，通過 Redis 獲取數(shù)據(jù)。我們的數(shù)據(jù)是以 Protobuf 格式儲存的，通過 Marc Gravell 編寫的 protobuf-dot-net 實現(xiàn)。對于 Redis 客戶端，我們使用了 StackExchange.Redis 庫，這是一個內(nèi)部開發(fā)的開源庫。如果一臺 web 服務(wù)器在 L1 和 L2 緩存中都沒有命中，它就會從其數(shù)據(jù)源中獲取數(shù)據(jù)（數(shù)據(jù)庫查詢、API 調(diào)用等等），然后將結(jié)果保存到本地緩存和 Redis 中。下一臺服務(wù)器在獲取同樣數(shù)據(jù)的時候，可能會在 L1 緩存中缺失，但是它會在 L2/Redis 中獲取到數(shù)據(jù)，省去了數(shù)據(jù)庫查詢或者 API 調(diào)用的操作。

我們同樣運行著很多 Q&A 站點，每個站點都有其自己的 L1/L2 緩存：在 L1 緩存中使用 key 作為前綴，在 L2/Redis 緩存中使用數(shù)據(jù)庫 ID。我們會在未來的文章中深入探討這個話題。

除了運行著所有站點實例的兩臺主要的 Redis 服務(wù)器（一主一從）之外，我們還利用另外兩臺專用的從服務(wù)器搭建了一個用于機器學(xué)習(xí)的的實例（主要出于內(nèi)存考慮）。這組服務(wù)器用來提供首頁上的問題推薦、做出更優(yōu)的工作職位匹配等服務(wù)。這個平臺稱為 Providence，Kevin Montrose 曾撰文描述過它。

主要的 Redis 服務(wù)器擁有 256GB 內(nèi)存（大約使用了 90GB），Providence 服務(wù)器擁有 384GB 內(nèi)存（大約使用了 125GB）。

Redis 并非只用來做緩存，它同樣擁有一套發(fā)布和訂閱機制，一臺服務(wù)器可以發(fā)布一條消息，其他的訂閱服務(wù)器可以收到該消息（包括 Redis 從服務(wù)器上的下游客戶端）。我們利用這個機制來清除其他服務(wù)上的 L1 緩存，用來保持 web 服務(wù)器上的緩存一致性。不過它還有另外一個重要的用途：websocket。

Websockets（NetGain）

我們使用 websocket 向用戶推送實時的更新內(nèi)容，比如頂部欄中的通知、投票數(shù)、新導(dǎo)航數(shù)、新的答案和評論等等。

socket 服務(wù)器本身在 web 層上運行，使用原生的 socket。這是一個基于我們的開源庫實現(xiàn)的非常小型的應(yīng)用程序：StackExchange.NetGain。在高峰時刻，我們大約有 50 萬個并發(fā)的 websocket 連接，這可是一大堆瀏覽器。一個有趣的事實：其中一些瀏覽器已經(jīng)打開超過 18 個月了，得找人去看看那些開發(fā)者是不是還活著。下面這張圖是本周 websocket 并發(fā)量的模式：

（點擊查看大圖）

為什么用 websocket？在我們這個規(guī)模下，它比輪詢要有效率得多。通過這種方式，我們可以簡單地使用更少資源來推送更多數(shù)據(jù)，而且對用戶而言實時性也更高。不過這種方式也并非沒有問題：臨時端口、負載均衡上的文件句柄耗盡，都是非常有趣的問題，我們稍后會提到它們。

搜索（Elasticsearch）

劇透：這里沒多少讓人興奮的東西。web層使用了Elasticsearch 1.4 ，并實現(xiàn)了超輕量級、高性能的 StackExchange.Elastic 客戶端。和大多數(shù)東西不同的是，我們并沒有計劃把這部分內(nèi)容開源，簡單來說，是因為它只暴露了非常少量的我們需要使用的 API 的子集。我確信把它公開出來是得不償失的，只會讓開發(fā)者感到困惑。我們在這些地方用到了 elastic：/search、計算相關(guān)問題、提問時給出相關(guān)建議。

每個 Elastic 集群（每個數(shù)據(jù)中心各有一個）包含 3 個節(jié)點，每個站點都擁有各自的索引。Careers 站點還有一些額外的索引。在 elastic 圈子里，我們的配置中稍微不那么標準的地方是，我們 3 臺服務(wù)器的集群比通常的配置要更強大一些：每臺服務(wù)器都使用了 SSD 存儲、192GB 內(nèi)存、雙路 10Gbps 帶寬的網(wǎng)絡(luò)。

在 Stack Server 的同一個應(yīng)用程序域（沒錯，我們在這個地方被 .Net Core 折騰慘了）里面還宿主著標簽引擎，它同樣使用了 Elasticsearch 進行連續(xù)索引。這里我們用了些小花招，比如使用 SQL Server（數(shù)據(jù)來源）中的 ROWVERSION 和 Elastic 中的“最后位置”文檔進行比較。因為從表觀上看它是順序的，這樣如果內(nèi)容在最后一次訪問后被修改的話，我們就很容易對其進行抓取和索引了。

我們使用 Elasticsearch 代替如 SQL 全文檢索這類技術(shù)的主要原因，就是它的可擴展性和性價比。SQL 的 CPU 相對而言非常昂貴，而 Elastic 則便宜得多，并且最近有了非常多的新特性。為什么不用 Solr？我們需要在整個網(wǎng)絡(luò)中進行搜索（同時有多個索引），在我們進行決策的時候 Solr 還不支持這種場景。我們還沒有使用 2.x 版本的原因，是因為 2.x 版本中類型（types）有了很大的變化，這意味著想要升級的話我們得重新索引所有內(nèi)容。我只是沒有足夠的時間來制定需求變更和遷移的計劃。

數(shù)據(jù)庫（SQL Server）

我們使用 SQL Server 作為單一的數(shù)據(jù)源（single source of truth）。Elastic 和 Redis 中的所有數(shù)據(jù)都來自 SQL Server。我們有兩個 SQL Server 集群，并配置了 AlwaysOn 可用性組。每個集群都在紐約有一臺主服務(wù)器（承擔(dān)了幾乎全部負載）和一臺副本服務(wù)器，此外還有一個在科羅拉多（我們的災(zāi)備數(shù)據(jù)中心）的副本服務(wù)器。所有的復(fù)制操作都是異步的。

第一個集群是一組 Dell R720xd 服務(wù)器，每臺擁有 384GB 內(nèi)存，4TB 空間的 PCIe SSD，和兩個 12 核 CPU。它包含了 Stack Overflow、Sites（這是個壞名字，稍后我會解釋它）、PRIZM 以及 Mobile 的數(shù)據(jù)庫。

第二個集群是一組 Dell R730xd 服務(wù)器，每臺擁有 768GB 內(nèi)存，6TB 空間的 PCIe SSD，和兩個 8 核 CPU。這個集群包含了所有其它數(shù)據(jù)庫，包括 Careers、Open ID、Chat、異常日志，以及其他的 Q&A 網(wǎng)站（比如 Super User、Server Fault 等）。

在數(shù)據(jù)庫層上，我們希望讓 CPU 利用率保持在一個非常低的級別，不過實際上在一些計劃緩存問題（我們正在排查）發(fā)生的時候，CPU 占用率會稍高一些。目前，NY-SQL02 和 04 是主服務(wù)器，01 和 03 是副本服務(wù)器，我們今天因為 SSD 升級剛剛重啟過它們。以下是它們在過去 24 小時內(nèi)的表現(xiàn)：

（點擊查看大圖）

我們對 SQL 的使用非常簡單。簡單就意味著快速。雖然有些查詢語句會很變態(tài)，我們對 SQL 本身的交互還是通過相當(dāng)原生的方式進行的。我們有一些遺留的 Linq2Sql，不過所有新開發(fā)的內(nèi)容都使用了 Dapper，這是我們開源的微型 ORM 框架，使用了 POCO。讓我換一種方式來解釋一下：Stack Overflow 的數(shù)據(jù)庫中只有一個存儲過程，而且我打算把這個最后殘留的存儲過程也干掉，換成代碼。

庫

好吧讓我們換個思路，這里是更直接能幫到你的東西。在前面我已經(jīng)提到過一些了，不過我會給出一個列表，其中包含了很多由我們維護的、大家都在使用的開源 .Net 類庫。我們把它們開源，因為其中并不涉及到核心的商業(yè)價值，但是可以幫助世界上的開發(fā)者們。我希望你們?nèi)缃衲苡玫剿鼈儯?/p>

• Dapper (.Net Core) – 高性能的微型 ORM 框架，用于 ADO.Net
• StackExchange.Redis – 高性能的 Redis 客戶端
• MiniProfiler – 輕量的分析探查器（profiler），我們在每個頁面上都使用了它（同樣支持 Ruby、Go 和 Node）
• Exceptional – 用于 SQL、JSON、MySQL 等的錯誤日志記錄
• Jil – 高性能的 JSON 序列化和反序列化器
• Sigil – .Net CIL 生成幫助器（在 C# 不夠快的時候使用）
• NetGain – 高性能的 websocket 服務(wù)器
• Opserver – 監(jiān)控儀表板，可以直接輪詢大多數(shù)系統(tǒng)，并且可以從 Orion、Bosun 或 WMI 中獲取信息
• Bosun – 后臺的監(jiān)控系統(tǒng)，使用 Go 編寫

下一篇內(nèi)容：目前我們所使用硬件的詳細配置清單。再之后，我們會按照列表依次撰文。敬請期待。