作者 | 王路

編輯 | 王瑞平

本文整理自知乎云原生架構(gòu)負(fù)責(zé)人王路在WOT2023大會(huì)上的主題分享，更多精彩內(nèi)容及現(xiàn)場(chǎng)PPT，請(qǐng)關(guān)注51CTO技術(shù)棧公眾號(hào)，發(fā)消息【W(wǎng)OT2023PPT】即可直接領(lǐng)取。

日前，在51CTO主辦的WOT全球技術(shù)創(chuàng)新大會(huì)上，王路帶來(lái)了主題演講《知乎云原生的架構(gòu)實(shí)踐》，為大眾呈現(xiàn)出全新視角。

云原生是一種新興的軟件架構(gòu)和開(kāi)發(fā)模式，它旨在實(shí)現(xiàn)高度可擴(kuò)展、可靠和可持續(xù)的應(yīng)用程序部署與管理。它的核心理念是將應(yīng)用程序設(shè)計(jì)為可運(yùn)行于云計(jì)算環(huán)境中的微服務(wù)，并采用容器化、自動(dòng)化管理和彈性伸縮等技術(shù)手段來(lái)優(yōu)化應(yīng)用程序的開(kāi)發(fā)、交付和運(yùn)維過(guò)程。主要特點(diǎn)包括：容器化、微服務(wù)架構(gòu)、自動(dòng)化運(yùn)維、持續(xù)交付、彈性伸縮等。

文章摘選自王路WOT期間演講的精彩內(nèi)容，主要講述了知乎云原生架構(gòu)演進(jìn)的歷程和云原生架構(gòu)的實(shí)踐。

云原生的出現(xiàn)使軟件開(kāi)發(fā)人員能夠更好地利用云計(jì)算、容器技術(shù)和自動(dòng)化運(yùn)維等先進(jìn)的技術(shù)手段，構(gòu)建出高效、可靠和可擴(kuò)展的應(yīng)用程序。它為企業(yè)提供了更靈活、高效的應(yīng)用交付和管理方式，也推動(dòng)了云計(jì)算和微服務(wù)架構(gòu)的發(fā)展。

與此同時(shí)，云原生也帶來(lái)了一系列的挑戰(zhàn)和變革，需要組織和開(kāi)發(fā)團(tuán)隊(duì)進(jìn)行相應(yīng)的技術(shù)轉(zhuǎn)型和組織變革，以適應(yīng)云原生時(shí)代的發(fā)展需求。

王路2016年加入知乎，目前擔(dān)任公司內(nèi)部云原生團(tuán)隊(duì)負(fù)責(zé)人，負(fù)責(zé)知乎內(nèi)部在線基礎(chǔ)設(shè)施原生架構(gòu)的建設(shè)工作，并親歷了知乎云原生架構(gòu)演進(jìn)和實(shí)踐的全過(guò)程。

1、重新認(rèn)識(shí)云原生：架構(gòu)演進(jìn)

云原生就像一個(gè)筐，什么東西都可以裝進(jìn)去，但又很難解釋清云原生究竟是什么。王路以云原生架構(gòu)演進(jìn)為切入點(diǎn)，重新解讀了云原生的概念?，F(xiàn)在簡(jiǎn)單了解一下云原生架構(gòu)的演進(jìn)歷程：

圖片

如圖所示，業(yè)務(wù)的演變經(jīng)歷了從單體架構(gòu)到SOA架構(gòu)再到微服務(wù)架構(gòu)?；A(chǔ)設(shè)施則經(jīng)歷了從物理機(jī)到虛擬機(jī)再到容器的演進(jìn)過(guò)程。最終，雙劍合璧，云原生時(shí)代終于到來(lái)！

而伴隨著云原生的出現(xiàn)，業(yè)務(wù)架構(gòu)和基礎(chǔ)架構(gòu)的聯(lián)系也比以往更密切了。具體表現(xiàn)在：基礎(chǔ)架構(gòu)能夠更細(xì)致地解決業(yè)務(wù)問(wèn)題，真正關(guān)注業(yè)務(wù)痛點(diǎn)而不是基礎(chǔ)設(shè)施問(wèn)題。

圖片

云原生計(jì)算基金會(huì)官方對(duì)于云原生技術(shù)棧的定義包括以下幾個(gè)部分：一、容器；二、不可變基礎(chǔ)設(shè)施；三、聲明式API；四、服務(wù)網(wǎng)格，最后一個(gè)是微服務(wù)。

其中，微服務(wù)屬于業(yè)務(wù)架構(gòu)，其它4個(gè)屬于基礎(chǔ)架構(gòu)。在實(shí)踐過(guò)程中，需要將幾個(gè)技術(shù)圍繞微服務(wù)劃分成幾個(gè)方向，比如，微服務(wù)部署、調(diào)度以及編排。

另一個(gè)比較重要的方向則是微服務(wù)的流量管理能力，既包括服務(wù)網(wǎng)格，也包含消息隊(duì)列。并且，服務(wù)網(wǎng)格只處理東西向流量管理問(wèn)題，其實(shí)還有南北向流量管理問(wèn)題。

這些方向最終都需要落地到業(yè)務(wù)或者使業(yè)務(wù)受益于云原生基礎(chǔ)設(shè)施，為此，必須提供DevOps平臺(tái)，使業(yè)務(wù)受益于云原生架構(gòu)。

2、越早改變，成本越低：知乎云原生架構(gòu)的演進(jìn)歷程

知乎進(jìn)行云原生改造時(shí)間較早，2014和2015年開(kāi)始在業(yè)務(wù)方面進(jìn)行微服務(wù)改造以及容器化。演進(jìn)歷程大概分以下幾個(gè)階段：

2016年，知乎完成了全部業(yè)務(wù)的容器化。當(dāng)時(shí)，知乎的流量和規(guī)模較小，改造成本也相對(duì)較低。

圖片

2016年，知乎完成全部業(yè)務(wù)的容器化，當(dāng)時(shí)用的是Mesos加自研framework的組合形式。服務(wù)發(fā)現(xiàn)、注冊(cè)還有通信用的是注冊(cè)中心HAproxy。

該階段過(guò)后過(guò)渡到下一階段。2018-2019年，Mesos被替換成了Kubernetes，還將中間件容器化，主要是將HAProxy和卡夫卡都進(jìn)行了容器化。

下一個(gè)階段是2021年，最大的改變是引入了Service Mesh，部分替換掉原來(lái)的注冊(cè)中心+HAProxy服務(wù)的發(fā)現(xiàn)和注冊(cè)方式。另一個(gè)比較大的變化是數(shù)據(jù)庫(kù)已完成容器化，主要是TIDB和Redis。

如今，知乎主要變成了私有云狀態(tài)，相當(dāng)于云建設(shè)主要由自己進(jìn)行；但是，該能力已轉(zhuǎn)移至公有云，并提供了更大資源的彈性能力。另一塊比較大的變化就是離在線混部，目前，已獲得階段性進(jìn)展。

以上就是知乎云原生架構(gòu)全部的演進(jìn)歷程。

3、基本架構(gòu)：調(diào)度編排和Kubernetes的流量管理

上圖是簡(jiǎn)單的云原生架構(gòu)圖，相對(duì)來(lái)講比較簡(jiǎn)單。從下向上主要是物理機(jī)、虛擬化層，上面則是調(diào)度編排層，再往上還構(gòu)建出了Kubernetes的核心基礎(chǔ)服務(wù)。

圖片

比如，流量管理主要是服務(wù)網(wǎng)格、服務(wù)網(wǎng)關(guān)和消息隊(duì)列，而對(duì)應(yīng)的服務(wù)網(wǎng)格則是東西向的流量管理。

而微服務(wù)網(wǎng)關(guān)則是南北向的流量管理，消息隊(duì)列是異步流量管理。中間件有一部分和流量管理重合，比如，Kafka和Pulsar，可能承載了部分流量管理、消息隊(duì)列的能力，還有TIDB和Redis也都承載于Kubernetes之上。

重點(diǎn)是調(diào)度編排層、Kubernetes、流量管理以及可觀測(cè)、建設(shè)在基礎(chǔ)設(shè)施之上的平臺(tái)應(yīng)用，比如，部署平臺(tái)、服務(wù)網(wǎng)格平臺(tái)、網(wǎng)關(guān)平臺(tái)還有可觀測(cè)平臺(tái)。

4、知乎云原生架構(gòu)實(shí)踐：調(diào)度編排Kubernetes

知乎在云原生實(shí)踐過(guò)程中針對(duì)調(diào)度編排Kubernetes有哪些實(shí)踐經(jīng)驗(yàn)?zāi)兀?/p>

圖片

上圖涵蓋了知乎的全部業(yè)務(wù)。如果這個(gè)架構(gòu)出現(xiàn)任何問(wèn)題，影響的將是知乎整體業(yè)務(wù)。而Kubernetes在這個(gè)架構(gòu)圖里處于一個(gè)承上啟下的位置，是整個(gè)云原生架構(gòu)的基石。

如果Kubernetes出了任何問(wèn)題，影響幾乎是災(zāi)難性的，因此，穩(wěn)定性至關(guān)重要。

接下來(lái)，列舉兩個(gè)Kubernetes穩(wěn)定性建設(shè)核心經(jīng)驗(yàn)：第一個(gè)是控制集群規(guī)模；第二個(gè)是保護(hù)好API server。

首先，控制集群規(guī)模對(duì)于Kubernetes集群管理來(lái)講有兩個(gè)主要方向：第一個(gè)是超大規(guī)模集群；另一個(gè)是多個(gè)小規(guī)模集群。

從知乎的角度看來(lái)，維護(hù)超大規(guī)模集群需要付出巨額的成本，比如，運(yùn)維成本。而運(yùn)維3個(gè)規(guī)模相對(duì)較小的集群和維護(hù)大集群的運(yùn)維成本相對(duì)來(lái)說(shuō)更低，因?yàn)椋笠?guī)模集群面臨的性能問(wèn)題較多。其次是研發(fā)成本，如果運(yùn)維一萬(wàn)家節(jié)點(diǎn)或五千家節(jié)點(diǎn)以上，可能需要付出研發(fā)成本和對(duì)原生組件進(jìn)行改造。

另一個(gè)比較關(guān)鍵的點(diǎn)是故障的影響。業(yè)務(wù)如果完全放置于大集群，故障發(fā)生時(shí)的爆炸半徑也是極大的。但是，如果分散在多個(gè)集群之中，即使某個(gè)集群完全崩潰，影響也微乎其微，而不是災(zāi)難性的。

從知乎的實(shí)踐經(jīng)驗(yàn)來(lái)看，多個(gè)小規(guī)模Kubernetes集群更實(shí)用，而不是大規(guī)模的超大集群。

圖片

但是，如果使用多集群，可能需要解決如下問(wèn)題：第一個(gè)是進(jìn)行多集群應(yīng)如何劃分；第二個(gè)是多集群之間資源需要如何調(diào)度；第三個(gè)是多集群間如何進(jìn)行服務(wù)發(fā)現(xiàn)和通信。

在維護(hù)API server穩(wěn)定性方面。知乎發(fā)生過(guò)幾次相關(guān)故障，比如，將異常流量“打掛”后會(huì)直接導(dǎo)致“血崩”。此時(shí)，需要復(fù)用內(nèi)部網(wǎng)關(guān)能力，進(jìn)行七層限流，可以限制異常流量，將關(guān)鍵組件流量保護(hù)住，使Apiserver能夠快速恢復(fù)。

5、流量管理實(shí)踐：服務(wù)網(wǎng)格、消息隊(duì)列、網(wǎng)關(guān)

流量管理主要包含3個(gè)組件：服務(wù)網(wǎng)格、消息隊(duì)列、網(wǎng)關(guān)。

首先解釋下一個(gè)關(guān)鍵問(wèn)題，在流量管理的過(guò)程中為什么要將東西向流量管理、異步流量管理以及南北向流量管理放在一起呢？

第一，隨著業(yè)務(wù)發(fā)展，微服務(wù)之間的通信變得越來(lái)越復(fù)雜。對(duì)此提出過(guò)很多的治理能力需求，比如，自動(dòng)配置限流能力和熔斷能力等。

第二，現(xiàn)有方案改造，其實(shí)就是HAProxy+注冊(cè)中心方式。理論上來(lái)說(shuō)，你完全可以基于HA進(jìn)行一整套治理能力的改進(jìn)，但是研發(fā)成本較高。

第三，服務(wù)網(wǎng)格方案istio，提供了豐富的標(biāo)準(zhǔn)化流量治理能力。這相當(dāng)于滿足業(yè)務(wù)需求或業(yè)務(wù)對(duì)基礎(chǔ)架構(gòu)能力的需求。

圖片

從架構(gòu)方面來(lái)看，性能上的優(yōu)化或遇到的最大性能挑戰(zhàn)是推送性能。istiod需要將所有配置都推送到Sidecar上。這既需要配置方面的優(yōu)化，也需要架構(gòu)上的優(yōu)化。

現(xiàn)在，知乎自研了一整套限流組件，提供了本地限流能力，包括：全球限流能力，也遇到了負(fù)載均衡問(wèn)題。

實(shí)踐證明，中心化負(fù)載均衡效果較好，但是，當(dāng)切換到Mesh或sidecar模式，每個(gè)sidecar和每個(gè)客戶端都缺乏全局負(fù)載信息，使負(fù)載效果在某些業(yè)務(wù)方面就變得極差。

知乎也針對(duì)這些方面做出過(guò)一些改進(jìn)。如果缺少全局信息，就需要將sidecar提上去，然后將一組實(shí)例當(dāng)作單獨(dú)的負(fù)載均衡集群，實(shí)現(xiàn)較為均衡的效果。該方案與之前的HAProxy最大的區(qū)別是它可以完整獲取現(xiàn)有istiod的治理能力。    

6、可觀測(cè)實(shí)踐：Metric、Logging、Tracing

在可觀測(cè)上實(shí)踐方面，知乎的底層統(tǒng)一使用Victorial Metrics作為存儲(chǔ)系統(tǒng)，而上層都是以Promesql格式進(jìn)行存儲(chǔ)的，既提供了原生的Promesql格式查詢，也提供了自研的組件。

圖：可觀測(cè)指標(biāo)系統(tǒng)

可觀測(cè)性比較簡(jiǎn)單，F(xiàn)ilebeat是收集端，存儲(chǔ)是自研的，搜索依賴于存儲(chǔ)，全量日志則是通過(guò)Flink落地HDFS。

Tracing統(tǒng)一使用Open Telemetry收集端。ClickHouse則用于存儲(chǔ)和查詢。性能相對(duì)來(lái)說(shuō)可以滿足需求。

7、寫(xiě)在最后：時(shí)刻關(guān)注業(yè)務(wù)需求和穩(wěn)定性

基礎(chǔ)架構(gòu)要時(shí)刻關(guān)注業(yè)務(wù)架構(gòu)的需求。架構(gòu)升級(jí)一定為業(yè)務(wù)服務(wù)，而不是升級(jí)。你需要考慮架構(gòu)升級(jí)有沒(méi)有給業(yè)務(wù)帶來(lái)好處，或者業(yè)務(wù)開(kāi)發(fā)效率和穩(wěn)定性是否因?yàn)榧軜?gòu)升級(jí)變得更好。另外一點(diǎn)，架構(gòu)升級(jí)的時(shí)機(jī)要好。

此外，穩(wěn)定性永遠(yuǎn)是第一位的。如果保障不了穩(wěn)定性，所有的架構(gòu)升級(jí)都是空中樓閣。

未來(lái)，知乎會(huì)更多關(guān)注多云多活和離在線混部，繼續(xù)在全時(shí)離在線混部上投入，實(shí)現(xiàn)全時(shí)混部，并且，Serverless也是未來(lái)的發(fā)展方向。