2022 有哪些不容錯過的後端技術趨勢

本文來源：騰訊技術工程（id：Tencent_TEG）

前言

最近幾年註定是不平凡的時間，雖疫情肆虐，但我國互聯網產業展現出巨大韌性，不僅爲精準有效防控疫情發揮了關鍵作用，還在數字基建、數字經濟等方面取得了顯著進展，成爲我國應對新挑戰、建設新經濟的重要力量。

騰訊在線教育部後臺中心團隊，作爲在線教育行業的從業者，我們嘗試整理一下 後端技術要點，以此窺探後臺未來技術的發展趨勢：

1. 雲計算進程提速，一切皆服務。

2. 雲上安全越來越受到企業的重視。

3. 從資源雲向業務雲化轉變，最終全面雲原生化。

4. 微服務、DDD、中臺技術並非企業技術架構設計的銀彈。

5. Python、Go、Rust 成爲後端未來最先考慮學習編程語言。

6. Go 語言生態發展穩健，越來越多企業在生產中使用 Go 語言落地業務。

7. 疫情催化在線教育行業產品升級轉型，音視頻技術不斷迭代升級。

雲原生

1. 業內趨勢

雲原生技術生態日趨完善，細分項目不斷湧現

雲原生關鍵技術正在被廣泛採納，如 43.9% 的用戶已在生產環境中採納容器技術，超過七成的用戶已經或計劃使用微服務架構進行業務開發部署。

容器雲平臺將傳統雲計算的 IaaS 層和 PaaS 層融合

從技術角度看，容器雲平臺採用容器、容器編排、服務網格，無服務等技術構建的一種輕量化 PaaS 平臺，爲應用提供了開發、編排、發佈、治理和運維等全生命週期管理。

容器雲平臺的整體架構，自下而上包括交互 (UI) 層、接口 (API) 層、PaaS 服務層、基礎層。運維和安全則涵蓋了從應用層到容器雲引擎層的部分：

• 交互層：提供界面供用戶使用

• 接口層：提供 OpenAPI 能力供第三方調用

• PaaS 服務層：提供數據服務、應用服務（微服務、中間件）、DevOps、平臺管理、平臺運營、應用管理能力，爲實現業務應用其自身的生命週期管理

• 基礎層：以 Kubernetes 爲核心，包括服務網格（ServiceMesh）、無服務計算（Serverless）、容器引擎（Docker）、容器鏡像管理等，主要實現對計算、網絡和存儲資源的池化管理，以及以 Pod 爲核心的調度和管理。

服務網格爲微服務帶來新的變革

Mesh 化加速業務邏輯與非業務邏輯的解耦，將非業務功能從客戶端 SDK 中分離出來放入獨立進程，利用 Pod 中容器共享資源的特性，實現用戶無感知的治理接管。

從資源雲向業務雲化轉變，最終全面雲原生化

雲原生技術通過標準化資源，輕量化彈性調度等特徵，應用場景較爲廣泛，隨着技術和生態不斷成熟和完善，有效緩解企業上雲顧慮，拉動全行業的上雲程度。

雲原生技術棧的標準統一化

架構標準統一（微服務之間標準 API 接口通信）、交付標準統一（標準容器化的打包方式實現真正的應用可移植）、研運過程標準統一（DevOps 工具鏈標準統一），通過標準化後提整體研發運維效能。

2. 在線教育實踐

enter image description here

各類 PaaS 服務上雲

2019 年我們完成了 IaaS、存儲層、直播、回放以及各類 PaaS 服務的上雲。

服務全面容器化升級

2020 年我們重點進行服務全面的容器化升級，目前已經完成企鵝輔導和開心鼠英語兩個產品的全面改造，到年底會完成騰訊課堂剩餘部分的升級，實現全面完成改造。

完善 DevOps 流程

完善 CI/CD/CO、藍盾流水線、容器化、STKE、全鏈路監控等，提高研發效率，降低現網運營難度

業務中臺架構演進

在整體架構上，我們依託騰訊雲，確定了教育業務中臺的架構演進方向，不斷的進行重複模塊的抽象和整合。我們在騰訊雲上實現部署了接入中臺、Push 中臺、支付中臺、音視頻中臺、運營中臺等服務，讓各個業務之間的相似能力得以複用。

存儲層上雲

存儲層上雲後，一方面穩定性提高。

• 異地容災。通過掛載異地的災備機器，可以實現 master 主機異地災備。

• 負載均衡。服務連接 RO 組，RO 組的多個實例會對請求進行負載均衡。

• 數據備份。RO 發生異常，將會被剔除 RO 組，恢復後自動加入 RO 組，保證了 RO 組的可用性。

• 數據加密。提供透明數據加密（Transparent Data Encryption，TDE）功能，透明加密指數據的加解密操作對用戶透明，支持對數據文件進行實時 I/O 加密和解密，在數據寫入磁盤前進行加密，從磁盤讀入內存時進行解密，可滿足靜態數據加密的合規性要求。

另一方面運營能力也有所提升。

• 可以實時看到數據庫連接情況，慢查詢、全表掃描、查詢、更新、刪除、插入情況

• 實時 CPU、內存、磁盤使用情況，並根據設置閾值進行告警優化微服務架構

下面是在線教育上雲前後架構對比

微服務

微服務, Service Mesh 在過去的一年依舊保持着熱度。在已經過去的 2020，微服務可以說有堅守也有破局，有對服務微化共識的形成也有對特殊場景的理性思考。我們可以看到服務框架依然在持續演進，奔向雲原生，擁抱雲化。越來越多的企業開始跟上服務化雲化步伐。

微服務框架：加速奔向雲原生

SpringCloud

2018 年開始 Hystrix、Ribbon 等核心組件相繼進入維護狀態，開發者們一度變得憂心忡忡，時至今日我們回過頭來再看一下，Spring Cloud 已經針對這些擔憂給出瞭解決方案，Zuul 由 Spring Cloud GateWay 子項目替代，Hystrix 由 Spring Cloud Circuit Breaker 替代，同時也給出了長期的演進方案。在經歷了這段小小的波折後，Spring Cloud 也改變了策略，將這些企業貢獻的 OSS 庫獨立出來成爲其子項目。目前我們可以看到有 Azure，Alibaba, Amazon 等 3 個帶有企業名字的子項目，這種策略在某種程度上可以說解綁了企業開源策略對開源核心組件的影響。截至目前 Spring Cloud 下面的子項目已經新增至 34 個，越來越龐大。供開發者選擇的組件越來越多。

Dubbo

2019 年 05 月 20 日 Dubbo 畢業，成爲 Apache 的頂級項目，在過去的一年社區還是非常努力的，一年 release 5 個版本，加速奔向雲原生。在 2.7.5 版本中，其服務模型調整以及協議支持調整帶來的新舊版本兼容問題，穩定性等問題值得我們持續關注。

Istio

記得 2019 年我們一直在談 istio 版本難產問題，在 2020 年卻出乎意外的因爲商標問題上了頭條，讓我們吃了個大瓜。Google 與 IBM 在商標問題上發生分歧，Istio 商標被 Google 捐獻給 Open Usage Commons 組織，而非 CNCF。而這在加速了 Service Mesh 陣營依舊的分化，各大軟件廠商紛紛發佈了自己的 Service Mesh 產品，如微軟發佈了 Open Service Mesh，Kong 推出了 Kuma，Nginx 也推出了 NGINX Service Mesh（NSM）。

企業微服務建設：長期修行，苦練內功

在微服務框架的演進過程中我們看到都在朝着趨同的方向發展，主要聚焦於微服務治理形態上組件的差異化以及應對場景的方案細化，可能你們家服務中心用的 ZK，我們家就自研。恰逢內源的興起，似乎在企業內部再造一次輪子，研發一套特定的框架來適配企業業務以及標準化企業內部 IT 治理也是一件很容易的事情，基於這種寫實的場景部分企業開始湧現出了內源的服務框架如，騰訊的 tRPC 框架。

enter image description here

騰訊 tRPC 建設情況 目前 tRPC 在騰訊內部已經大面積推廣使用，覆蓋 5 個 BG，40 + 部門，2700 + 服務，10000 + 容器，支持 c++,go,java,js,rust,python 6 種編程語言。其可插拔的插件化架構，高性能，友好的架構兼容特性正在吸引內部越來越多的開發者以及業務用戶。

在線教育業務也在積極的擁抱這套框架，逐步將各業務牽引到 tRPC 框架。在解決歷史技術架構痛點的過程中，通過微服務構築，形成微服務羣，構築穩定的支付, 音視頻等小中臺以及面向 C、B 端用戶的互聯網業務系統。

中臺

中臺，是最近幾年最火熱的技術名詞之一，關於中臺的討論，甚至是爭論，一直都沒有停止過。我們嘗試結合騰訊在線教育部在中臺方向的實踐經驗，談談中臺對我們的意義和建設情況。

騰訊在線教育部從 2018 年開始規劃部門內的中臺建設，2019 年基本完成組織架構和技術架構的中臺轉型。我們和大多數公司一樣，並不是從 0 開始構建中臺，而是在保證現有業務快速迭代的前提下，同時完成架構的轉型，大家形象的稱這個過程是 “開着飛機換引擎”。對於一個風險看起來這麼高的事情，在決定做之前，我們要回答好幾個問題：

1. 我們爲什麼要做中臺，部門需要什麼樣的中臺？

我們部門主要有三款產品：騰訊課堂——職業在線教育學習平臺，具有 2B 和 2C 的雙重屬性。支持教育機構的入駐、直播上課、售賣、結算 等功能。騰訊企鵝輔導——騰訊自營的，主打 K12 名師教學的學習應用，爲老師和學生提供了豐富的在線教學的功能。騰訊開心鼠英語——主打 3-8 歲的少兒英語學習，通過生動有趣的交互式學習設計，實現了邊玩邊學的有趣的學習體驗。可以看到，這三個產品有不少類似的功能，例如直播、回放、支付、退款 等，因爲這些共性，決定了他們會有很多相同的產品和技術需求。這些形成我們做中臺的業務基礎。

在產品發展的初期，由於時間窗口非常緊，需求變化也很頻繁。爲了快速並行迭代，我們拉起了三個獨立的團隊進行研發，除了基礎設施外，業務邏輯部分完全是獨立的。這種組織架構，在當時確實爲我們達成了上線時間的目標，幫助產品實現了從 0 到 1 的突破。但是，隨着產品形態的成熟，3 個問題越來越突出：第一個問題，功能無法在不同的產品間快速複用。因爲獨立的代碼和架構，複用變得非常的困難，很多開發同學反饋複用代碼還不如重寫一遍更快。第二個問題，同類的 Bug 的解決和技術優化在不同的產品之間重複進行，非常的浪費人力。第三個問題，不同的時期，我們需要發力的產品方向不一樣。當一個產品面臨發展窗口期的時候，對研發人力的需求就會成倍的增長。而獨立的研發模式，讓人力調配非常的困難。基於業務的模型，和團隊碰到的痛點，我們提出了中臺化的解決方案。

我們需要的中臺應該長什麼樣子？經過前期的思考，我們總結出在線教育的中臺應該包含 4 個部分。首先 是業務支持部分，這個很好理解，包含了各類共性的產品功能，例如前面提到的 直播、回放、支付 等等。其次 是技術支持部分，服務開發過程中 必然會涉及到例如 技術棧怎麼選擇，高可用怎麼做 的共性技術問題，我們希望這部分有一個統一的技術實現。接下來 是數據支持部分，數據上報、計算、彙總、分析 已經是現在互聯網產品必不可少的能力，也具備很強的通用性。因此這部分也應該有一箇中臺來承載。最後，是研發效能部分，我們需要有一整套好用的工具來提高研發效率和保障研發質量。到這裏，我們對於中臺的模樣，應該是比較清晰了。

根據這個規劃，我們畫出了我們中臺的組成圖。

2. 怎麼保證中臺能做成功，最大的風險是什麼？

很多人說，中臺是 “一把手工程”，意思是一定是自上而下推動的，需要老闆的鼎力支持，是因爲做中臺確實是非常的需要人力，並且很大程度上改變了團隊的資源投入模式，在多個業務需求壓力都很大的情況下，做這麼大的轉變，團隊短期內一定會碰到各種不適應的問題。雖然我們的中臺方案也得到了老闆的支持，但是絕不是中臺優先，畢竟保障業務的高速發展纔是團隊追求的結果。一開始我們就意識到了困難的存在，爲了不讓中臺死在半路，我們定了幾個原則：

1. 控制人力佔比：在人力有限的情況下，爲了保障業務需求不受太大的進度影響，中臺的人力投入原則上不超過總人力的 30%。

2. 不做過度設計：中臺的設計目標只控制在部門內的需求（騰訊課堂、企鵝輔導、開心鼠英語），不面向行業做完全通用化的設計，根據實際需求做決策。

3. 完整規劃，逐步實施：在做好完整的技術方案設計之後，我們不追求一次性完成中臺的建設，而是結合業務產品需求的情況逐步實施，每半年也會 review 一次方案是否需要調整。

以上的規則，可以說很好的幫助我們保障了中臺平滑轉型的過程。另外，我們也在一個合適的時間點進行了團隊人員組織結構的中臺化匹配升級，保證了技術架構和組織架構的一致。

3. 中臺建設的指導原則是什麼，目標是什麼？

我們中臺服務設計的原則是什麼，應該做哪些，什麼時候做，做到什麼程度。這個在業務部門裏面其實是一個非常棘手的問題。很多時候我們需要在 “時效性” 和 “擴展性” 方面做選擇。

最後我們總結出來的一套方法是這樣：對於一個新的需求，如果看到了可複用性，優先讓業務團隊自己做，一般這種需求時間緊、不明確，如果這時候討論宏大的中臺設計，往往效率低，耽誤上線時間，但是，我會在過方案的時時候問大家 “通用性是怎麼考慮的”，最終在方案設計上做好通用型的前期 準備即可。後面如果再次收到另外一個產品的類似需求，這時候我們就認真考慮要把這個服務交接到中臺組來維護了，由中臺組安排人力來進行中臺化。最後再有新的業務接入，就直接由中臺組來承接了，就會非常的簡單，我們很多中臺服務都是這麼跑出來的。

還有一個需要思考的問題是，中臺服務的建設目標是什麼。提出這個問題的背景是，我們希望給中臺團隊一個統一的、清晰的階段性目標，當然也可以用來做團隊考覈。我們總結出來三個點：

1. 功能的複用：這個是最基本的，也是提出中臺的初衷。具體到落地上，必須是一套代碼。

2. 統一運營：要求中臺服務能分產品輸出標準化的實時監控看板和報表郵件，讓業務一目瞭然。

3. 容災調度的能力：不同業務的多套部署之間，在緊急情況下可以互備。需要進行實際的線上演習。

我們認爲，達成這三個目標之後，才真正的發揮了中臺的威力，可以實現 1+1 大於 2 的效果。

DevOps

2020 年，在雲原生的浪潮下，devops 相關的技術棧也在穩步地向前演進，下面將從以下幾個方面分別進行闡述：

• 敏捷的應用交付流程

• 監控告警系統

• tracing 系統

• 雲原生對提升 devops 的展望

1. 敏捷的應用交付流程

業內趨勢

當前出現了一系列的基於 Kubernetes 的 CI/CD 工具，如 Jenkins-x、Gitkube，它提供了從代碼提交、自動編譯、打包鏡像、配置注入、發佈部署到 Kubernetes 平臺的一系列自動化流程。甚至出現了像 ballerina 這樣的雲原生編程語言，它的出現就是爲了解決應用開發到服務集成之間的鴻溝。然後結合監控告警系統實時掌握服務運行情況，結合調用鏈系統進行服務故障定位。

在線教育的實踐

藍盾是騰訊從業務安全出發，貫穿產品研發、測試和運營的全生命週期；助力業務平滑過渡到敏捷研發模式，打造的一站式研發運維體系。它助力業務持續快速交付高質量的產品。藍盾提供了豐富的特性：

• 可視化

• 一鍵式部署

• 和持續集成無縫集成

• 支持並行部署

• 架構水平擴展，相同邏輯的節點無主備關係

• 數據安全

• 小核心，大擴展！可插件化擴展，優先添加所需要的流程控制部件，同時可方便的擴展其他部件

• 可監控，監控一切異常的構建並告警

• 灰度切換，達到切換時不影響正在構建的流水線

2. 監控告警系統

監控系統事實上的標準 prometheus

Prometheus 在度量領域的統治力雖然還暫時不如日誌領域中 Elastic Stack 的統治地位那麼穩固，但在雲原生時代裏，基本也已經能算是事實標準了。2020 年，對 prometheus 來說，是忙碌的一年：

grafana cloud agent 發佈：爲 grafana cloud 優化的的一個輕量級 prometheus 分支，它使用 prometheus 的代碼，保證 prometheus 生態依賴的一些屬性：數據完整性、數據過期處理等等。允許使用一種更靈活的方式定義從何處以什麼方法拉取和傳輸數據，它已經成爲一種更受歡迎的方式將數據寫入後端存儲。它的 remote_write 方式相比於傳統 prometheus agent 的 remote_write，內存使用降低了 40%；

v2.19.0 的發佈：最核心的功能是，對於完整的 chunk，在內存中使用 head 結構映射磁盤中的 block，單就這一個點，內存使用就降低了 20%-40%，並且使得 prometheus 的重啓速度更快；

v2.20.0 的發佈：它爲 Docker Swarm 和 DigitalOcean 支持了本地的服務發現；

提升批量插入一大批老數據到 prometheus 的效率；

Grafana Metrics Enterprise 的啓動：提供針對大企業的 prometheus-as-a-service 的解決方案

在線教育的實踐

nginx 訪問日誌和服務間模塊調用相關信息都上報到全鏈路 es 集羣

通過一個 exporter 對 es 中的數據按照項目和接口維度進行匯聚，將相關的聚合數據存入 prometheus

全鏈路 es 和 prometheus 都可以作爲 grafana 的數據源進行數據展示和告警判斷

alert 模塊將告警信息發送到相應的渠道

收到告警之後，去 grafana 查看對應時間段的趨勢圖，去全鏈路 es 集羣查看對應時間段的原始日誌

3. tracing 系統

比起日誌與度量， tracing 這個領域的產品競爭要相對激烈得多。一方面，目前還沒有像日誌、度量那樣出現具有明顯統治力的產品。另一方面，幾乎市面上所有的追蹤系統都是以 Dapper 的論文爲原型發展出來的，功能上並沒有太本質的差距，卻又受制於實現細節，彼此互斥，很難搭配工作。

OpenTracing 規範

爲了推進追蹤領域的產品的標準化，2016 年 11 月，CNCF 技術委員會接受了 OpenTracing 作爲基金會第三個項目。OpenTracing 是一套與平臺無關、與廠商無關、與語言無關的追蹤協議規範。

OpenCensus 規範

OpenTracing 規範公佈後，幾乎所有業界有名的追蹤系統，譬如 Zipkin、Jaeger、SkyWalking 等都很快宣佈支持 OpenTracing，但是 Google 自己卻在此時提出了與 OpenTracing 目標類似的 OpenCensus 規範。OpenCensus 不僅涉及到追蹤，還把指標度量也納入進來。

OpenTelemetry 規範

2019 年，OpenTracing 和 OpenCensus 又共同發佈了可觀測性的終極解決方案 OpenTelemetry，並宣佈會各自凍結 OpenTracing 和 OpenCensus 的發展。OpenTelemetry 野心頗大，不僅包括追蹤規範，還包括日誌和度量方面的規範、各種語言的 SDK、以及採集系統的參考實現。

在線教育的實踐

騰訊基於 OpenTelemetry 規範，自研了天機閣系統。天機閣主要分爲三大部分：

• 分佈式追蹤（distributed tracing）

• 監控（monitoring，metrics）

• 日誌（logging）

與之對應提供七大能力：

• 故障定位：天機閣中能夠提供整個請求全鏈路上下文信息，具體哪個環節出錯一目瞭然

• 耗時分析：天機閣的耗時分佈圖，可以快速瞭解全鏈路耗時情況

• 多維染色：在天機閣基於通用的設計理念下，天機閣提供的染色能力，不會侷限在某個業務的具體字段，同樣也不會侷限單個維度

• 架構治理：天機閣架構治理的核心功能是微服務架構拓撲，基於微服務架構拓撲可以構建更加豐富更加具體的上層分析能力

• 全鏈路日誌：天機閣核心建立在分佈式追蹤方法論下，提供將分散在各個微服務的日誌根據因果和時間有機進行組合，達到提供全鏈路上下文日誌的效果

• 服務監控：天機閣在監控領域將會重點推出如下幾大領域監控（機器基礎指標監控、數據庫監控、進程監控、模調監控）

• 業務看板：主要用於業務定製化的數據指標配置和展示

系統架構圖

功能模塊圖

4. 雲原生對提升 devops 的展望

serverless 對提升 devops 的展望

• 降低運維需求

• 縮短迭代週期、上線時間

• 快速試錯

• 極致彈性

• 降低運營成本

service mesh 對提升 devops 的展望

• 更好發揮掌握不同編程語言的人才優勢

• 框架的部分能力平臺化，加速應用迭代速度

• 微服務軟件架構從解決 "拆" 到解決 "連" 的加速落地

• 靈活的流量治理能力改善軟件的發佈與回滾效率

音視頻

1. 音視頻技術回顧

隨着 AI 技術的興起、5G 時代的到來，音視頻技術不斷加速應用發展，像直播、短視頻這樣的產品遍地開花，火熱程度相信大家或多或少都接觸過。

音視頻技術的加速應用依賴底層編解碼標準的發展，當前主流的 H.264 編解碼技術已經不能滿足未來 4K、8K 的需求，今年年中剛發佈的 H266/VCC，與 H.265 相比進一步提高了壓縮效率，這項耗時 3 年的標準，主要面向未來的 4K 和 8K，後續的落地應用非常值得期待。

在實時音視頻技術領域，不得不提及谷歌的開源項目 WebRTC，可以在瀏覽器上快速開發出各種音視頻應用，目前主流的瀏覽器包括 Chrome、Firefox、Safari 等都將 WebRTC 作爲首選的實時音視頻方案。同時也催生了像聲網、即構科技這樣的專門音視頻服務商。從 StackOverflow Trends 和 GoogleTrends 來看，未來關注度仍會持續上升，騰訊也是 WebRTC 應用的主力軍。

目前直播後臺開發主要分爲三大塊：

1. 標準直播：我們日常生活中使用頻率最高的直播，例如電視節目直播、遊戲直播、直播帶貨。

2. 快直播：標準直播在超低延遲直播場景基礎上的延伸，毫秒級超低延遲播放的同時，也兼顧了秒開、卡頓等核心問題，爲用戶帶來超低延遲流暢度的直播體驗。

3. 慢直播：能夠提供更穩定清晰的直播畫面，基本的使用場景都用於監控領域，國內疫情早期，4000 萬人同時在線，通過一個固定機位觀看雷神山醫院建築工地的現場直播，讓雲監工迅速火爆。2020 行至年終，各大機構評選的網絡熱詞相繼出爐，其中，“雲監工”頻繁出沒於「十大網絡熱詞」榜單中，與之並列的多是 “後浪”“網抑雲”“打工人” 等。

隨着網絡技術的不斷髮展，持續提供高質量的視頻信號傳播已經算不上浪費網絡資源，即使一個直播無人觀看，未來慢直播具有極大的延伸價值以及發展前景，讓我們期待慢直播行業的蓬勃發展。

藉助 5G 技術低時延、高速率、大容量等顯著優勢，音視頻的大賽道，從目前的短視頻慢慢走向中長視頻發展，這是未來的大風口。

2. 平臺的新技術點

目前騰訊在線教育音視頻直播已完成整體上雲，騰訊雲的互動直播也從早期的 opensdk 全面升級到 TRTC，TRTC 是騰訊實時音視頻 [Tencent Real-Time Communication]，源自 QQ 音視頻團隊，是基於 QQ 十幾年來的音視頻技術積累。

騰訊雲提供 TRTC(全球延時 < 300ms)+WebRTC 快直播 (上行走 RTMP 推流或 FLV、HLS、RTMP 回源，下行支持標準 WebRTC 協議輸出，延時 500ms 左右）+ 標準 LVB 直播(FLV/HLS/DASH，平均延時 3-5 秒) 融合解決方案，如下圖中用戶可以針對自己的業務場景組合不同的直播解決方案。承載大規模帶寬、支撐高併發，保證客戶業務正常運作，達到 99.9% 以上的可用性，整體資源儲備及業務突發承接能力行業領先。

隨着全民抗疫，“停課不停學” 的號召，在線教育也成爲直播的主力軍，直播的進房成功率 / 首幀延遲 / 卡頓率 / 音畫同步時延 / 分辨率等指標直接影響用戶核心體驗。站在雲的肩膀上，在線教育直播業務通過組合雲上多種直播模式，結合業務流控系統，對各端直播接入進行多級流控及直播模式切換，在保證直播質量的前提下支撐遠超互動直播極限的房間容量，下圖是具體的直播架構。

3. 業務應用新技術的能力擴展

目前直播課普遍採用大班授課方式，老師在上課的時候，跟學生的互動有限，學生的注意力和參與感有限。大班教室人數太多，老師無法提供足量的 presentation 機會，學生與學生之間缺少有效的學習互動。

騰訊在線教育部推出如下圖的六人小班課，基於 TRTC 在互動課堂場景下，爲學員提供了穩定優質的服務，延遲低至原來的 1/10，互動效果得到很大提升。六人小班課給用戶帶來更多 “被關注” 的感覺，相比於大班課，家長的價值感知更高。

接入網關

1. 網關發展歷程

接入網關有四大職能

• API 入口：作爲所有 API 接口服務請求的接入點，負責請求的轉發。

• 業務聚合：網關封裝了系統內部架構，爲每個客戶端提供一個定製的 API。作爲所有後端業務服務的聚合點，所有的業務服務都可以在這裏被調用。

• 中介策略：身份驗證、路由、過濾、流控、緩存、監控、負載均衡、請求分片與管理、靜態響應處理等策略，進行一些必要的中介處理。

• 統一管理：提供統一的管理界面，提供配置管理工具，對所有 API 服務的調用生命週期和相應的中介策略進行統一管理

開源網關發展迅速。從 nginx 橫空出世，到 openresty 解放程序員，更加專注解決業務需求，再到 kong 成爲 api 網關的獨角獸，以及最近出現不久的 apisix，當然也不能少了大名鼎鼎的 envoy。下面介紹主要的幾個網關。

nginx

2004 年 10 月 4 日發佈的第一個公開版本以來，nginx 已成爲高性能 web 服務器、反向代理服務器的代名詞。相比 Apache，Nginx 使用更少的資源，支持更多的併發連接，能夠支持高達 50,000 個併發連接數的響應。模塊化和將一個請求分爲多個階段的設計，方便開發人員擴展。

openresty

OpenResty® 是一個基於 Nginx 與 Lua 的高性能 Web 平臺，其內部集成了大量精良的 Lua 庫、第三方模塊以及大多數的依賴項。用於方便地搭建能夠處理超高併發、擴展性極高的動態 Web 應用、Web 服務和動態網關。python、js、lua 三種語言中，lua 是解析器最小、性能最高的語言，而 LuaJIT 比 lua 又快數 10 倍，開發人員和系統工程師可以使用 Lua 腳本語言調動 Nginx 支持的各種 C 以及 Lua 模塊，快速構造出足以勝任 10K 乃至 1000K 以上單機併發連接的高性能 Web 應用系統。

kong

kong 是 API 管理的強大效率工具，主要有 4 個特點

• 擴展性：通過增添更多的服務器實例達到橫向擴展

• 靈活性：可以部署在單個或多個數據中心環境的私有云或公有云上。支持大多數流行的操作系統，比如 Linux、Mac 和 Windows。包括許多實用技巧，以便針對大多數現代平臺完成安裝和配置工作

• 模塊性：可以與新的插件協同運行，擴展基本功能。可將 API 與許多不同的插件整合起來，以增強安全、分析、驗證、日誌及 / 或監測機制

• 生態：開源免費使用，同時也能獲得企業版，此外還提供初始安裝、從第三方 API 管理工具來遷移、緊急補丁、熱修復程序及更多特性。

2. 在線教育網關實踐

在線教育網關發展過程中的包袱

• 通道 proxy 多語言, 多框架, 多協議功能無法服用，維護成本高

• 配置動態加載能力和插件能力不統一

• 一個接口上線配置多次，驗證多次。

• 缺乏完善的監控

• 頻控，容災、熔斷、下載等能力缺失

• 非雲原生應用，不支持自動擴縮容

  tiny 網關

tiny 網關主要的能力如下：

• 提供 app 端, web, pc 端快速接入，統一 sdk 和協議

• 支持智能路由，支持按照 cmd, uid, roomid, cid 字段的路由

• 全房間和多維度組合推送策略

• 可靠 push 保障

• 業務級別的監控告警

• 命令字配置集中管理，支持熱加載

• 支持插件化的能力，方便添加業務特性的插件

• 全面落地容器化，支持自動擴縮容

完整的架構如下圖所示

go 語言

隨着雲原生在互聯網行業的普及, golang 從衆多語言中, 脫穎而出, 成爲了雲原生時代的新秀。越來越多的開源項目採用 golang 語言來實現。因此學習和掌握 golang 語言, 越來越成爲一種趨勢。本篇文章, 主要圍繞 golang 語言的主要特性來展開講解, 希望對大家有幫助。

語法簡單

golang 素以簡單著稱, 總共 25 個保留字, 相比 c++ 的 82 個, java 語言的 50 個, 少的不能再少了。golang 官方也比較吝於新增命令字。常見的結構和判斷, 對於 golang 來說, 就只有 if,for,switch 等非常簡單的命令字。自帶的 array,slice,map 等數據結構, 基本可以 cover 大多數的使用場景。

部署方便

編譯好的 golang 程序, 是一個獨立的二進制程序, 只依賴操作系統的一些基礎庫, 除此之外, 沒有任何其他外部依賴。有使用過 golang 語言開發開源軟件的同學, 應該感觸。

靜態編譯

golang 是一門靜態強類型的編譯型語言, 與 c++ 類似, golang 也是也有一個完整的編譯鏈接過程, 並且有嚴格的編譯期的語法檢查過程。配合 golang 強大的工具鏈, 在編譯期可以提前解決腳本語言運行時才能發現的諸多問題。

垃圾回收

一直以來, c++ 程序員飽受內存問題的困擾, 常見的比如內存泄漏, 溢出, double free 等問題層出不窮, 並且定位起來費時費力。c++ 官方爲了降低使用成本, 也在 c++0x 之後, 引入了智能指針來解決內存使用的問題。但是內存問題依然存在。golang 跟 java 語言一樣, 從語言層面提供了 GC 能力, 自帶的垃圾回收機制, 有效解決了內存使用的諸多問題。但是垃圾回收並非完美無缺, 不合理的內存使用方式, 依然會導致程序出現嚴重的 gc 問題，從而導致程序出現性能問題, 因此也有一定的 trick 需要遵循。

工具鏈支持

除了 golang 語言自帶的編譯, 安裝, 單元測試等工具之外, c++ 的調試神器 gdb 也能夠使用。同時第三方提供的 delve 調試工具, 兼容性和易用性更好, 同時還提供了遠程調試的能力。原生自帶的 perf 工具, 配合第三方的 go-torch 工具, 生成的火焰圖, 調試的時候非常方便, 讓性能瓶頸能夠一目瞭然。

泛型

golang 被人詬病的特性之一, 就是不支持泛型。官方認爲雖然泛型很贊，但會使語言設計複雜度提升，所以並沒有把這個泛型支持作爲緊急需要增加的特性，也許在不久的將來, 會引入這個特性。現階段可以通過使用 Interface 作爲中間層, 起到抽象和適配的作用。一些第三方工具, 比如 genny, 通過模板化生成代碼, 也可以作爲泛型的一種解決方案。

錯誤處理

golang 語言, 錯誤處理從語言層面得到了支持, 基於 Error 接口來實現, 配合函數的多返回值機制,, ，一般情況下, 錯誤碼也會作爲函數的最後一個返回值。在 golang 中, 錯誤處理非常重要, 語言的設計和規範, 也鼓勵開發人員顯示的檢查錯誤。也正因爲如此, golang 的錯誤處理，也被很多人所詬病，覺得不像其他高級語言, 比如 java 的錯誤處理那麼簡潔。不過整體來說, golang 作者將錯誤碼顯性化, 目的是爲了讓大家能夠重視錯誤處理，所以應該說是各有特色。

包管理

golang 語言剛誕生的時候, 並不支持版本管理。GOPATH 方式, 也只能算是包管理基本的雛形。後來經過一系列的演變，社區先後支持了 dodep,glide 的工具。直到 2016 年, 官方纔提出採用外部依賴包的方式, 引入了 vendor 機制。2017 的時候推出的 dep 工具, 基本可以作爲準官方的解決方案了。然而, 直到 2019,go modules 的推出, golang 的包管理爭論才最終塵埃落定。基於 go mod 的版本管理機制, 基本上可以說是一統江湖。具體的 golang 包管理演進過程, 如下圖所示:

併發性能

golang 從語言層面就支持了併發, 大大簡化了併發程序的編寫。這也是 golang 廣受大家歡迎的原因之一。goroutine 是 golang 併發設計的核心, 本質上講就是協程, 也叫做用戶態線程, 它比線程更易用, 更高效, 更輕便, 佔用內存更小, 並對開發者屏蔽了底層的協程調度細節。提供的 go,select,channel 等關鍵字, 易用性非常好。配合 golang 中提供的 sync 包, 可以非常高效的實現併發控制能力。

常見網站

• golang 百科全書: https://awesome-go.com/

• golang developer roadmap: https://github.com/Alikhll/golang-developer-roadmap

• sql2go 工具: http://stming.cn/tool/sql2go.html

• toml2go 工具: https://xuri.me/toml-to-go/

• curl2go 工具: https://mholt.github.io/curl-to-go/

• json2go 工具: https://mholt.github.io/json-to-go/

• 泛型工具: https://github.com/cheekybits/genny

生態

Go 在未來企業會有更多佈道：Go Conference 一直都是 Gopher 關注的技術大會，20 年 11 月國內的 Go Conferernce(https://github.com/gopherchina/conference) 分享主題主要包括 Go 語言基礎（Go 編程模式、Go Module、Go 編譯器、組件包）和架構落地實踐（微服務實踐、微服務框架、雲原生實踐、大數據和高併發挑戰），側面也印證了 Go 語言在後端領域具備較強的業務實戰落地能力，對打算採用 Go 的互聯網企業，具有較強的指導和借鑑意義。

業界認可度

golang 作爲雲原生的首選語言, 在業界獲得廣泛的認可。基於 golang 的很多明星項目, 包括 docker,k8s,etcd,influxdb,tidb,prometheus,kibana,nsq 等覆蓋了容器化, 容器編排, 存儲, 監控, 消息隊列等各個場景, 在各大公司都獲得了大量的應用。同時從 github 拉取數據查看語言流行程度, 我們對比了 java,c++,c,go 等語言發現, golang 在 github 開源庫的使用上越來越流行。如下圖所示的 golang 佔比情況:

趨勢

全面轉到 Go Module：官方會終止對 GOPATH 的開發支持，全面轉到 Go Module。

2021 年, golang 中的泛型還要持續打磨。

隨着雲原生浪潮，越來越多的企業將會考慮將 Go 作爲其主要後端開發語言。

總結

2021 年已經過去，可以確定技術的發展是一分鐘也不會停滯。可以預見雲原生、微服務等新技術依舊是後臺技術發展趨勢，2022 年也會有更多創新出現。

/blog.csdn.net/yugemengjing/article/detai

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/mS1O8PrBq-WNqFgLozxQLg