當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

2022有哪些不容错过的后端技术趋势

發(fā)布時間：2024/4/11 编程问答 32 豆豆

生活随笔收集整理的這篇文章主要介紹了 2022有哪些不容错过的后端技术趋势小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

本文來源：騰訊技術(shù)工程（id：Tencent_TEG）

前言

最近幾年注定是不平凡的時間，雖疫情肆虐，但我國互聯(lián)網(wǎng)產(chǎn)業(yè)展現(xiàn)出巨大韌性，不僅為精準(zhǔn)有效防控疫情發(fā)揮了關(guān)鍵作用，還在數(shù)字基建、數(shù)字經(jīng)濟等方面取得了顯著進展，成為我國應(yīng)對新挑戰(zhàn)、建設(shè)新經(jīng)濟的重要力量。

騰訊在線教育部后臺中心團隊，作為在線教育行業(yè)的從業(yè)者，我們嘗試整理一下后端技術(shù)要點，以此窺探后臺未來技術(shù)的發(fā)展趨勢：

云計算進程提速，一切皆服務(wù)。

云上安全越來越受到企業(yè)的重視。

從資源云向業(yè)務(wù)云化轉(zhuǎn)變，最終全面云原生化。

微服務(wù)、DDD、中臺技術(shù)并非企業(yè)技術(shù)架構(gòu)設(shè)計的銀彈。

Python、Go、Rust 成為后端未來最先考慮學(xué)習(xí)編程語言。

Go 語言生態(tài)發(fā)展穩(wěn)健，越來越多企業(yè)在生產(chǎn)中使用 Go 語言落地業(yè)務(wù)。

疫情催化在線教育行業(yè)產(chǎn)品升級轉(zhuǎn)型，音視頻技術(shù)不斷迭代升級。

云原生

1. 業(yè)內(nèi)趨勢

云原生技術(shù)生態(tài)日趨完善，細(xì)分項目不斷涌現(xiàn)

云原生關(guān)鍵技術(shù)正在被廣泛采納，如 43.9%的用戶已在生產(chǎn)環(huán)境中采納容器技術(shù)，超過七成的用戶已經(jīng)或計劃使用微服務(wù)架構(gòu)進行業(yè)務(wù)開發(fā)部署。

容器云平臺將傳統(tǒng)云計算的 IaaS 層和 PaaS 層融合

從技術(shù)角度看，容器云平臺采用容器、容器編排、服務(wù)網(wǎng)格，無服務(wù)等技術(shù)構(gòu)建的一種輕量化 PaaS 平臺，為應(yīng)用提供了開發(fā)、編排、發(fā)布、治理和運維等全生命周期管理。

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

交互層：提供界面供用戶使用
接口層：提供 OpenAPI 能力供第三方調(diào)用
PaaS 服務(wù)層：提供數(shù)據(jù)服務(wù)、應(yīng)用服務(wù)（微服務(wù)、中間件）、DevOps、平臺管理、平臺運營、應(yīng)用管理能力，為實現(xiàn)業(yè)務(wù)應(yīng)用其自身的生命周期管理
基礎(chǔ)層：以 Kubernetes 為核心，包括服務(wù)網(wǎng)格（ServiceMesh）、無服務(wù)計算（Serverless）、容器引擎（Docker）、容器鏡像管理等，主要實現(xiàn)對計算、網(wǎng)絡(luò)和存儲資源的池化管理，以及以 Pod 為核心的調(diào)度和管理。

服務(wù)網(wǎng)格為微服務(wù)帶來新的變革

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

從資源云向業(yè)務(wù)云化轉(zhuǎn)變，最終全面云原生化

云原生技術(shù)通過標(biāo)準(zhǔn)化資源，輕量化彈性調(diào)度等特征，應(yīng)用場景較為廣泛，隨著技術(shù)和生態(tài)不斷成熟和完善，有效緩解企業(yè)上云顧慮，拉動全行業(yè)的上云程度。

云原生技術(shù)棧的標(biāo)準(zhǔn)統(tǒng)一化

架構(gòu)標(biāo)準(zhǔn)統(tǒng)一（微服務(wù)之間標(biāo)準(zhǔn) API 接口通信）、交付標(biāo)準(zhǔn)統(tǒng)一（標(biāo)準(zhǔn)容器化的打包方式實現(xiàn)真正的應(yīng)用可移植）、研運過程標(biāo)準(zhǔn)統(tǒng)一（DevOps 工具鏈標(biāo)準(zhǔn)統(tǒng)一），通過標(biāo)準(zhǔn)化后提整體研發(fā)運維效能。

2. 在線教育實踐

enter image description here

各類 PaaS 服務(wù)上云

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

服務(wù)全面容器化升級

2020 年我們重點進行服務(wù)全面的容器化升級，目前已經(jīng)完成企鵝輔導(dǎo)和開心鼠英語兩個產(chǎn)品的全面改造，到年底會完成騰訊課堂剩余部分的升級，實現(xiàn)全面完成改造。

完善 DevOps 流程

完善 CI/CD/CO、藍盾流水線、容器化、STKE、全鏈路監(jiān)控等，提高研發(fā)效率，降低現(xiàn)網(wǎng)運營難度

業(yè)務(wù)中臺架構(gòu)演進

在整體架構(gòu)上，我們依托騰訊云，確定了教育業(yè)務(wù)中臺的架構(gòu)演進方向，不斷的進行重復(fù)模塊的抽象和整合。我們在騰訊云上實現(xiàn)部署了接入中臺、Push 中臺、支付中臺、音視頻中臺、運營中臺等服務(wù)，讓各個業(yè)務(wù)之間的相似能力得以復(fù)用。

存儲層上云

存儲層上云后，一方面穩(wěn)定性提高。

異地容災(zāi)。通過掛載異地的災(zāi)備機器，可以實現(xiàn) master 主機異地災(zāi)備。
負(fù)載均衡。服務(wù)連接 RO 組，RO 組的多個實例會對請求進行負(fù)載均衡。
數(shù)據(jù)備份。RO 發(fā)生異常，將會被剔除 RO 組，恢復(fù)后自動加入 RO 組，保證了 RO 組的可用性。
數(shù)據(jù)加密。提供透明數(shù)據(jù)加密（Transparent Data Encryption，TDE）功能，透明加密指數(shù)據(jù)的加解密操作對用戶透明，支持對數(shù)據(jù)文件進行實時 I/O 加密和解密，在數(shù)據(jù)寫入磁盤前進行加密，從磁盤讀入內(nèi)存時進行解密，可滿足靜態(tài)數(shù)據(jù)加密的合規(guī)性要求。

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

可以實時看到數(shù)據(jù)庫連接情況，慢查詢、全表掃描、查詢、更新、刪除、插入情況
實時 CPU、內(nèi)存、磁盤使用情況，并根據(jù)設(shè)置閾值進行告警優(yōu)化微服務(wù)架構(gòu)

下面是在線教育上云前后架構(gòu)對比

微服務(wù)

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

微服務(wù)框架：加速奔向云原生

SpringCloud

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

Dubbo

2019 年 05 月 20 日 Dubbo 畢業(yè)，成為 Apache 的頂級項目，在過去的一年社區(qū)還是非常努力的，一年 release 5 個版本，加速奔向云原生。在 2.7.5 版本中，其服務(wù)模型調(diào)整以及協(xié)議支持調(diào)整帶來的新舊版本兼容問題，穩(wěn)定性等問題值得我們持續(xù)關(guān)注。

Istio

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

企業(yè)微服務(wù)建設(shè)：長期修行，苦練內(nèi)功

在微服務(wù)框架的演進過程中我們看到都在朝著趨同的方向發(fā)展，主要聚焦于微服務(wù)治理形態(tài)上組件的差異化以及應(yīng)對場景的方案細(xì)化，可能你們家服務(wù)中心用的 ZK，我們家就自研。恰逢內(nèi)源的興起，似乎在企業(yè)內(nèi)部再造一次輪子，研發(fā)一套特定的框架來適配企業(yè)業(yè)務(wù)以及標(biāo)準(zhǔn)化企業(yè)內(nèi)部 IT 治理也是一件很容易的事情，基于這種寫實的場景部分企業(yè)開始涌現(xiàn)出了內(nèi)源的服務(wù)框架如，騰訊的 tRPC 框架。

enter image description here

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

在線教育業(yè)務(wù)也在積極的擁抱這套框架，逐步將各業(yè)務(wù)牽引到 tRPC 框架。在解決歷史技術(shù)架構(gòu)痛點的過程中，通過微服務(wù)構(gòu)筑，形成微服務(wù)群，構(gòu)筑穩(wěn)定的支付,音視頻等小中臺以及面向 C、B 端用戶的互聯(lián)網(wǎng)業(yè)務(wù)系統(tǒng)。

中臺

中臺，是最近幾年最火熱的技術(shù)名詞之一，關(guān)于中臺的討論，甚至是爭論，一直都沒有停止過。我們嘗試結(jié)合騰訊在線教育部在中臺方向的實踐經(jīng)驗，談?wù)勚信_對我們的意義和建設(shè)情況。

騰訊在線教育部從 2018 年開始規(guī)劃部門內(nèi)的中臺建設(shè)，2019 年基本完成組織架構(gòu)和技術(shù)架構(gòu)的中臺轉(zhuǎn)型。我們和大多數(shù)公司一樣，并不是從 0 開始構(gòu)建中臺，而是在保證現(xiàn)有業(yè)務(wù)快速迭代的前提下，同時完成架構(gòu)的轉(zhuǎn)型，大家形象的稱這個過程是“開著飛機換引擎”。對于一個風(fēng)險看起來這么高的事情，在決定做之前，我們要回答好幾個問題：

1. 我們?yōu)槭裁匆鲋信_，部門需要什么樣的中臺？

我們部門主要有三款產(chǎn)品：騰訊課堂——職業(yè)在線教育學(xué)習(xí)平臺，具有 2B 和 2C 的雙重屬性。支持教育機構(gòu)的入駐、直播上課、售賣、結(jié)算等功能。騰訊企鵝輔導(dǎo)——騰訊自營的，主打 K12 名師教學(xué)的學(xué)習(xí)應(yīng)用，為老師和學(xué)生提供了豐富的在線教學(xué)的功能。騰訊開心鼠英語——主打 3-8 歲的少兒英語學(xué)習(xí)，通過生動有趣的交互式學(xué)習(xí)設(shè)計，實現(xiàn)了邊玩邊學(xué)的有趣的學(xué)習(xí)體驗?？梢钥吹?#xff0c;這三個產(chǎn)品有不少類似的功能，例如直播、回放、支付、退款等，因為這些共性，決定了他們會有很多相同的產(chǎn)品和技術(shù)需求。這些形成我們做中臺的業(yè)務(wù)基礎(chǔ)。

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

我們需要的中臺應(yīng)該長什么樣子？經(jīng)過前期的思考，我們總結(jié)出在線教育的中臺應(yīng)該包含 4 個部分。首先是業(yè)務(wù)支持部分，這個很好理解，包含了各類共性的產(chǎn)品功能，例如前面提到的直播、回放、支付等等。其次是技術(shù)支持部分，服務(wù)開發(fā)過程中必然會涉及到例如技術(shù)棧怎么選擇，高可用怎么做的共性技術(shù)問題，我們希望這部分有一個統(tǒng)一的技術(shù)實現(xiàn)。接下來是數(shù)據(jù)支持部分，數(shù)據(jù)上報、計算、匯總、分析已經(jīng)是現(xiàn)在互聯(lián)網(wǎng)產(chǎn)品必不可少的能力，也具備很強的通用性。因此這部分也應(yīng)該有一個中臺來承載。最后，是研發(fā)效能部分，我們需要有一整套好用的工具來提高研發(fā)效率和保障研發(fā)質(zhì)量。到這里，我們對于中臺的模樣，應(yīng)該是比較清晰了。

根據(jù)這個規(guī)劃，我們畫出了我們中臺的組成圖。

2. 怎么保證中臺能做成功，最大的風(fēng)險是什么？

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

控制人力占比：在人力有限的情況下，為了保障業(yè)務(wù)需求不受太大的進度影響，中臺的人力投入原則上不超過總?cè)肆Φ?30%。

不做過度設(shè)計：中臺的設(shè)計目標(biāo)只控制在部門內(nèi)的需求（騰訊課堂、企鵝輔導(dǎo)、開心鼠英語），不面向行業(yè)做完全通用化的設(shè)計，根據(jù)實際需求做決策。

完整規(guī)劃，逐步實施：在做好完整的技術(shù)方案設(shè)計之后，我們不追求一次性完成中臺的建設(shè)，而是結(jié)合業(yè)務(wù)產(chǎn)品需求的情況逐步實施，每半年也會 review 一次方案是否需要調(diào)整。

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

3. 中臺建設(shè)的指導(dǎo)原則是什么，目標(biāo)是什么？

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

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

還有一個需要思考的問題是，中臺服務(wù)的建設(shè)目標(biāo)是什么。提出這個問題的背景是，我們希望給中臺團隊一個統(tǒng)一的、清晰的階段性目標(biāo)，當(dāng)然也可以用來做團隊考核。我們總結(jié)出來三個點：

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

統(tǒng)一運營：要求中臺服務(wù)能分產(chǎn)品輸出標(biāo)準(zhǔn)化的實時監(jiān)控看板和報表郵件，讓業(yè)務(wù)一目了然。

容災(zāi)調(diào)度的能力：不同業(yè)務(wù)的多套部署之間，在緊急情況下可以互備。需要進行實際的線上演習(xí)。

我們認(rèn)為，達成這三個目標(biāo)之后，才真正的發(fā)揮了中臺的威力，可以實現(xiàn) 1+1 大于 2 的效果。

DevOps

2020 年，在云原生的浪潮下，devops 相關(guān)的技術(shù)棧也在穩(wěn)步地向前演進，下面將從以下幾個方面分別進行闡述：

敏捷的應(yīng)用交付流程
監(jiān)控告警系統(tǒng)
tracing 系統(tǒng)
云原生對提升 devops 的展望

1. 敏捷的應(yīng)用交付流程

業(yè)內(nèi)趨勢

當(dāng)前出現(xiàn)了一系列的基于 Kubernetes 的 CI/CD 工具，如 Jenkins-x、Gitkube，它提供了從代碼提交、自動編譯、打包鏡像、配置注入、發(fā)布部署到 Kubernetes 平臺的一系列自動化流程。甚至出現(xiàn)了像 ballerina 這樣的云原生編程語言，它的出現(xiàn)就是為了解決應(yīng)用開發(fā)到服務(wù)集成之間的鴻溝。然后結(jié)合監(jiān)控告警系統(tǒng)實時掌握服務(wù)運行情況，結(jié)合調(diào)用鏈系統(tǒng)進行服務(wù)故障定位。

在線教育的實踐

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

可視化
一鍵式部署
和持續(xù)集成無縫集成
支持并行部署
架構(gòu)水平擴展，相同邏輯的節(jié)點無主備關(guān)系
數(shù)據(jù)安全
小核心，大擴展！可插件化擴展，優(yōu)先添加所需要的流程控制部件，同時可方便的擴展其他部件
可監(jiān)控，監(jiān)控一切異常的構(gòu)建并告警
灰度切換，達到切換時不影響正在構(gòu)建的流水線

2. 監(jiān)控告警系統(tǒng)

監(jiān)控系統(tǒng)事實上的標(biāo)準(zhǔn) prometheus

Prometheus 在度量領(lǐng)域的統(tǒng)治力雖然還暫時不如日志領(lǐng)域中 Elastic Stack 的統(tǒng)治地位那么穩(wěn)固，但在云原生時代里，基本也已經(jīng)能算是事實標(biāo)準(zhǔn)了。2020 年，對 prometheus 來說，是忙碌的一年：

grafana cloud agent 發(fā)布：為 grafana cloud 優(yōu)化的的一個輕量級 prometheus 分支，它使用 prometheus 的代碼，保證 prometheus 生態(tài)依賴的一些屬性：數(shù)據(jù)完整性、數(shù)據(jù)過期處理等等。允許使用一種更靈活的方式定義從何處以什么方法拉取和傳輸數(shù)據(jù)，它已經(jīng)成為一種更受歡迎的方式將數(shù)據(jù)寫入后端存儲。它的 remote_write 方式相比于傳統(tǒng) prometheus agent 的 remote_write，內(nèi)存使用降低了 40%；

v2.19.0 的發(fā)布：最核心的功能是，對于完整的 chunk，在內(nèi)存中使用 head 結(jié)構(gòu)映射磁盤中的 block，單就這一個點，內(nèi)存使用就降低了 20%-40%，并且使得 prometheus 的重啟速度更快；

v2.20.0 的發(fā)布：它為 Docker Swarm 和 DigitalOcean 支持了本地的服務(wù)發(fā)現(xiàn)；

提升批量插入一大批老數(shù)據(jù)到 prometheus 的效率；

Grafana Metrics Enterprise 的啟動：提供針對大企業(yè)的 prometheus-as-a-service 的解決方案

在線教育的實踐

nginx 訪問日志和服務(wù)間模塊調(diào)用相關(guān)信息都上報到全鏈路 es 集群

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

全鏈路 es 和 prometheus 都可以作為 grafana 的數(shù)據(jù)源進行數(shù)據(jù)展示和告警判斷

alert 模塊將告警信息發(fā)送到相應(yīng)的渠道

收到告警之后，去 grafana 查看對應(yīng)時間段的趨勢圖，去全鏈路 es 集群查看對應(yīng)時間段的原始日志

3. tracing 系統(tǒng)

比起日志與度量， tracing 這個領(lǐng)域的產(chǎn)品競爭要相對激烈得多。一方面，目前還沒有像日志、度量那樣出現(xiàn)具有明顯統(tǒng)治力的產(chǎn)品。另一方面，幾乎市面上所有的追蹤系統(tǒng)都是以 Dapper 的論文為原型發(fā)展出來的，功能上并沒有太本質(zhì)的差距，卻又受制于實現(xiàn)細(xì)節(jié)，彼此互斥，很難搭配工作。

OpenTracing 規(guī)范

為了推進追蹤領(lǐng)域的產(chǎn)品的標(biāo)準(zhǔn)化，2016 年 11 月，CNCF 技術(shù)委員會接受了 OpenTracing 作為基金會第三個項目。OpenTracing 是一套與平臺無關(guān)、與廠商無關(guān)、與語言無關(guān)的追蹤協(xié)議規(guī)范。

OpenCensus 規(guī)范

OpenTracing 規(guī)范公布后，幾乎所有業(yè)界有名的追蹤系統(tǒng)，譬如 Zipkin、Jaeger、SkyWalking 等都很快宣布支持 OpenTracing，但是 Google 自己卻在此時提出了與 OpenTracing 目標(biāo)類似的 OpenCensus 規(guī)范。OpenCensus 不僅涉及到追蹤，還把指標(biāo)度量也納入進來。

OpenTelemetry 規(guī)范

2019 年，OpenTracing 和 OpenCensus 又共同發(fā)布了可觀測性的終極解決方案 OpenTelemetry，并宣布會各自凍結(jié) OpenTracing 和 OpenCensus 的發(fā)展。OpenTelemetry 野心頗大，不僅包括追蹤規(guī)范，還包括日志和度量方面的規(guī)范、各種語言的 SDK、以及采集系統(tǒng)的參考實現(xiàn)。

在線教育的實踐

騰訊基于 OpenTelemetry 規(guī)范，自研了天機閣系統(tǒng)。天機閣主要分為三大部分：

分布式追蹤（distributed tracing）
監(jiān)控（monitoring，metrics）
日志（logging）

與之對應(yīng)提供七大能力：

故障定位：天機閣中能夠提供整個請求全鏈路上下文信息，具體哪個環(huán)節(jié)出錯一目了然
耗時分析：天機閣的耗時分布圖，可以快速了解全鏈路耗時情況
多維染色：在天機閣基于通用的設(shè)計理念下，天機閣提供的染色能力，不會局限在某個業(yè)務(wù)的具體字段，同樣也不會局限單個維度
架構(gòu)治理：天機閣架構(gòu)治理的核心功能是微服務(wù)架構(gòu)拓?fù)?#xff0c;基于微服務(wù)架構(gòu)拓?fù)淇梢詷?gòu)建更加豐富更加具體的上層分析能力
全鏈路日志：天機閣核心建立在分布式追蹤方法論下，提供將分散在各個微服務(wù)的日志根據(jù)因果和時間有機進行組合，達到提供全鏈路上下文日志的效果
服務(wù)監(jiān)控：天機閣在監(jiān)控領(lǐng)域?qū)攸c推出如下幾大領(lǐng)域監(jiān)控（機器基礎(chǔ)指標(biāo)監(jiān)控、數(shù)據(jù)庫監(jiān)控、進程監(jiān)控、模調(diào)監(jiān)控）
業(yè)務(wù)看板：主要用于業(yè)務(wù)定制化的數(shù)據(jù)指標(biāo)配置和展示

系統(tǒng)架構(gòu)圖

功能模塊圖

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

serverless 對提升 devops 的展望

降低運維需求
縮短迭代周期、上線時間
快速試錯
極致彈性
降低運營成本

service mesh 對提升 devops 的展望

更好發(fā)揮掌握不同編程語言的人才優(yōu)勢
框架的部分能力平臺化，加速應(yīng)用迭代速度
微服務(wù)軟件架構(gòu)從解決"拆"到解決"連"的加速落地
靈活的流量治理能力改善軟件的發(fā)布與回滾效率

音視頻

1. 音視頻技術(shù)回顧

隨著 AI 技術(shù)的興起、5G 時代的到來，音視頻技術(shù)不斷加速應(yīng)用發(fā)展，像直播、短視頻這樣的產(chǎn)品遍地開花，火熱程度相信大家或多或少都接觸過。

音視頻技術(shù)的加速應(yīng)用依賴底層編解碼標(biāo)準(zhǔn)的發(fā)展，當(dāng)前主流的 H.264 編解碼技術(shù)已經(jīng)不能滿足未來 4K、8K 的需求，今年年中剛發(fā)布的 H266/VCC，與 H.265 相比進一步提高了壓縮效率，這項耗時 3 年的標(biāo)準(zhǔn)，主要面向未來的 4K 和 8K，后續(xù)的落地應(yīng)用非常值得期待。

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

目前直播后臺開發(fā)主要分為三大塊：

標(biāo)準(zhǔn)直播：我們?nèi)粘Ｉ钪惺褂妙l率最高的直播，例如電視節(jié)目直播、游戲直播、直播帶貨。

快直播：標(biāo)準(zhǔn)直播在超低延遲直播場景基礎(chǔ)上的延伸，毫秒級超低延遲播放的同時，也兼顧了秒開、卡頓等核心問題，為用戶帶來超低延遲流暢度的直播體驗。

慢直播：能夠提供更穩(wěn)定清晰的直播畫面，基本的使用場景都用于監(jiān)控領(lǐng)域，國內(nèi)疫情早期，4000 萬人同時在線，通過一個固定機位觀看雷神山醫(yī)院建筑工地的現(xiàn)場直播，讓云監(jiān)工迅速火爆。2020 行至年終，各大機構(gòu)評選的網(wǎng)絡(luò)熱詞相繼出爐，其中，“云監(jiān)工”頻繁出沒于「十大網(wǎng)絡(luò)熱詞」榜單中，與之并列的多是“后浪”“網(wǎng)抑云”“打工人”等。

隨著網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，持續(xù)提供高質(zhì)量的視頻信號傳播已經(jīng)算不上浪費網(wǎng)絡(luò)資源，即使一個直播無人觀看，未來慢直播具有極大的延伸價值以及發(fā)展前景，讓我們期待慢直播行業(yè)的蓬勃發(fā)展。

借助 5G 技術(shù)低時延、高速率、大容量等顯著優(yōu)勢，音視頻的大賽道，從目前的短視頻慢慢走向中長視頻發(fā)展，這是未來的大風(fēng)口。

2. 平臺的新技術(shù)點

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

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

隨著全民抗疫，“停課不停學(xué)”的號召，在線教育也成為直播的主力軍，直播的進房成功率/首幀延遲/卡頓率/音畫同步時延/分辨率等指標(biāo)直接影響用戶核心體驗。站在云的肩膀上，在線教育直播業(yè)務(wù)通過組合云上多種直播模式，結(jié)合業(yè)務(wù)流控系統(tǒng)，對各端直播接入進行多級流控及直播模式切換，在保證直播質(zhì)量的前提下支撐遠(yuǎn)超互動直播極限的房間容量，下圖是具體的直播架構(gòu)。

3. 業(yè)務(wù)應(yīng)用新技術(shù)的能力擴展

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

騰訊在線教育部推出如下圖的六人小班課，基于 TRTC 在互動課堂場景下，為學(xué)員提供了穩(wěn)定優(yōu)質(zhì)的服務(wù)，延遲低至原來的 1/10，互動效果得到很大提升。六人小班課給用戶帶來更多“被關(guān)注”的感覺，相比于大班課，家長的價值感知更高。

接入網(wǎng)關(guān)

1. 網(wǎng)關(guān)發(fā)展歷程

接入網(wǎng)關(guān)有四大職能

API 入口：作為所有 API 接口服務(wù)請求的接入點，負(fù)責(zé)請求的轉(zhuǎn)發(fā)。
業(yè)務(wù)聚合：網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個客戶端提供一個定制的 API。作為所有后端業(yè)務(wù)服務(wù)的聚合點，所有的業(yè)務(wù)服務(wù)都可以在這里被調(diào)用。
中介策略：身份驗證、路由、過濾、流控、緩存、監(jiān)控、負(fù)載均衡、請求分片與管理、靜態(tài)響應(yīng)處理等策略，進行一些必要的中介處理。
統(tǒng)一管理：提供統(tǒng)一的管理界面，提供配置管理工具，對所有 API 服務(wù)的調(diào)用生命周期和相應(yīng)的中介策略進行統(tǒng)一管理

開源網(wǎng)關(guān)發(fā)展迅速。從 nginx 橫空出世，到 openresty 解放程序員，更加專注解決業(yè)務(wù)需求，再到 kong 成為 api 網(wǎng)關(guān)的獨角獸，以及最近出現(xiàn)不久的 apisix，當(dāng)然也不能少了大名鼎鼎的 envoy。下面介紹主要的幾個網(wǎng)關(guān)。

nginx

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

openresty

OpenResty? 是一個基于 Nginx 與 Lua 的高性能 Web 平臺，其內(nèi)部集成了大量精良的 Lua 庫、第三方模塊以及大多數(shù)的依賴項。用于方便地搭建能夠處理超高并發(fā)、擴展性極高的動態(tài) Web 應(yīng)用、Web 服務(wù)和動態(tài)網(wǎng)關(guān)。python、js、lua 三種語言中，lua 是解析器最小、性能最高的語言，而 LuaJIT 比 lua 又快數(shù) 10 倍，開發(fā)人員和系統(tǒng)工程師可以使用 Lua 腳本語言調(diào)動 Nginx 支持的各種 C 以及 Lua 模塊，快速構(gòu)造出足以勝任 10K 乃至 1000K 以上單機并發(fā)連接的高性能 Web 應(yīng)用系統(tǒng)。

kong

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

擴展性：通過增添更多的服務(wù)器實例達到橫向擴展
靈活性：可以部署在單個或多個數(shù)據(jù)中心環(huán)境的私有云或公有云上。支持大多數(shù)流行的操作系統(tǒng)，比如 Linux、Mac 和 Windows。包括許多實用技巧，以便針對大多數(shù)現(xiàn)代平臺完成安裝和配置工作
模塊性：可以與新的插件協(xié)同運行，擴展基本功能?？蓪?API 與許多不同的插件整合起來，以增強安全、分析、驗證、日志及/或監(jiān)測機制
生態(tài)：開源免費使用，同時也能獲得企業(yè)版，此外還提供初始安裝、從第三方 API 管理工具來遷移、緊急補丁、熱修復(fù)程序及更多特性。

2. 在線教育網(wǎng)關(guān)實踐

在線教育網(wǎng)關(guān)發(fā)展過程中的包袱

通道 proxy 多語言, 多框架, 多協(xié)議功能無法服用，維護成本高
配置動態(tài)加載能力和插件能力不統(tǒng)一
一個接口上線配置多次，驗證多次。
缺乏完善的監(jiān)控
頻控，容災(zāi)、熔斷、下載等能力缺失
非云原生應(yīng)用，不支持自動擴縮容
tiny 網(wǎng)關(guān)

tiny 網(wǎng)關(guān)主要的能力如下：

提供 app 端, web, pc 端快速接入，統(tǒng)一 sdk 和協(xié)議
支持智能路由，支持按照 cmd, uid, roomid, cid 字段的路由
全房間和多維度組合推送策略
可靠 push 保障
業(yè)務(wù)級別的監(jiān)控告警
命令字配置集中管理，支持熱加載
支持插件化的能力，方便添加業(yè)務(wù)特性的插件
全面落地容器化，支持自動擴縮容

完整的架構(gòu)如下圖所示

go 語言

隨著云原生在互聯(lián)網(wǎng)行業(yè)的普及,golang 從眾多語言中,脫穎而出,成為了云原生時代的新秀。越來越多的開源項目采用 golang 語言來實現(xiàn)。因此學(xué)習(xí)和掌握 golang 語言,越來越成為一種趨勢。本篇文章,主要圍繞 golang 語言的主要特性來展開講解,希望對大家有幫助。

語法簡單

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

部署方便

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

靜態(tài)編譯

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

垃圾回收

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

工具鏈支持

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

泛型

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

錯誤處理

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

包管理

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

并發(fā)性能

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

常見網(wǎng)站

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

生態(tài)

Go 在未來企業(yè)會有更多布道：Go Conference 一直都是 Gopher 關(guān)注的技術(shù)大會，20 年 11 月國內(nèi)的 Go Conferernce(https://github.com/gopherchina/conference)分享主題主要包括 Go 語言基礎(chǔ)（Go 編程模式、Go Module、Go 編譯器、組件包）和架構(gòu)落地實踐（微服務(wù)實踐、微服務(wù)框架、云原生實踐、大數(shù)據(jù)和高并發(fā)挑戰(zhàn)），側(cè)面也印證了 Go 語言在后端領(lǐng)域具備較強的業(yè)務(wù)實戰(zhàn)落地能力，對打算采用 Go 的互聯(lián)網(wǎng)企業(yè)，具有較強的指導(dǎo)和借鑒意義。

業(yè)界認(rèn)可度

golang 作為云原生的首選語言,在業(yè)界獲得廣泛的認(rèn)可?；?golang 的很多明星項目,包括 docker,k8s,etcd,influxdb,tidb,prometheus,kibana,nsq 等覆蓋了容器化,容器編排,存儲,監(jiān)控,消息隊列等各個場景, 在各大公司都獲得了大量的應(yīng)用。同時從 github 拉取數(shù)據(jù)查看語言流行程度, 我們對比了 java,c++,c,go 等語言發(fā)現(xiàn),golang 在 github 開源庫的使用上越來越流行。如下圖所示的 golang 占比情況:

趨勢

全面轉(zhuǎn)到 Go Module：官方會終止對 GOPATH 的開發(fā)支持，全面轉(zhuǎn)到 Go Module。

2021年,golang 中的泛型還要持續(xù)打磨。

隨著云原生浪潮，越來越多的企業(yè)將會考慮將 Go 作為其主要后端開發(fā)語言。

總結(jié)

2021年已經(jīng)過去，可以確定技術(shù)的發(fā)展是一分鐘也不會停滯。可以預(yù)見云原生、微服務(wù)等新技術(shù)依舊是后臺技術(shù)發(fā)展趨勢，2022年也會有更多創(chuàng)新出現(xiàn)。

- END -

看完一鍵三連在看，轉(zhuǎn)發(fā)，點贊

是對文章最大的贊賞，極客重生感謝你

總結(jié)

以上是生活随笔為你收集整理的2022有哪些不容错过的后端技术趋势的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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