2022有哪些不容錯(cuò)過(guò)的后端技術(shù)趨勢(shì)(非常干!)
本文來(lái)源：騰訊技術(shù)工程（id：Tencent_TEG）
前言
最近幾年注定是不平凡的時(shí)間，雖疫情肆虐，但我國(guó)互聯(lián)網(wǎng)產(chǎn)業(yè)展現(xiàn)出巨大韌性，不僅為精準(zhǔn)有效防控疫情發(fā)揮了關(guān)鍵作用，還在數(shù)字基建、數(shù)字經(jīng)濟(jì)等方面取得了顯著進(jìn)展，成為我國(guó)應(yīng)對(duì)新挑戰(zhàn)、建設(shè)新經(jīng)濟(jì)的重要力量。
騰訊在線教育部后臺(tái)中心團(tuán)隊(duì)，作為在線教育行業(yè)的從業(yè)者，我們嘗試整理一下 后端技術(shù)要點(diǎn)，以此窺探后臺(tái)未來(lái)技術(shù)的發(fā)展趨勢(shì)：
- 云計(jì)算進(jìn)程提速，一切皆服務(wù)。
- 云上安全越來(lái)越受到企業(yè)的重視。
- 從資源云向業(yè)務(wù)云化轉(zhuǎn)變，最終全面云原生化。
- 微服務(wù)、DDD、中臺(tái)技術(shù)并非企業(yè)技術(shù)架構(gòu)設(shè)計(jì)的銀彈。
- Python、Go、Rust 成為后端未來(lái)最先考慮學(xué)習(xí)編程語(yǔ)言。
- Go 語(yǔ)言生態(tài)發(fā)展穩(wěn)健，越來(lái)越多企業(yè)在生產(chǎn)中使用 Go 語(yǔ)言落地業(yè)務(wù)。
- 疫情催化在線教育行業(yè)產(chǎn)品升級(jí)轉(zhuǎn)型，音視頻技術(shù)不斷迭代升級(jí)。
云原生
1. 業(yè)內(nèi)趨勢(shì)
云原生技術(shù)生態(tài)日趨完善，細(xì)分項(xiàng)目不斷涌現(xiàn)
云原生關(guān)鍵技術(shù)正在被廣泛采納，如 43.9%的用戶已在生產(chǎn)環(huán)境中采納容器技術(shù)，超過(guò)七成的用戶已經(jīng)或計(jì)劃使用微服務(wù)架構(gòu)進(jìn)行業(yè)務(wù)開(kāi)發(fā)部署。
容器云平臺(tái)將傳統(tǒng)云計(jì)算的 IaaS 層和 PaaS 層融合
從技術(shù)角度看，容器云平臺(tái)采用容器、容器編排、服務(wù)網(wǎng)格，無(wú)服務(wù)等技術(shù)構(gòu)建的一種輕量化 PaaS 平臺(tái)，為應(yīng)用提供了開(kāi)發(fā)、編排、發(fā)布、治理和運(yùn)維等全生命周期管理。
容器云平臺(tái)的整體架構(gòu)，自下而上包括交互(UI)層、接口(API)層、PaaS 服務(wù)層、基礎(chǔ)層。運(yùn)維和安全則涵蓋了從應(yīng)用層到容器云引擎層的部分：
- 交互層：提供界面供用戶使用
- 接口層：提供 OpenAPI 能力供第三方調(diào)用
- PaaS 服務(wù)層：提供數(shù)據(jù)服務(wù)、應(yīng)用服務(wù)（微服務(wù)、中間件）、DevOps、平臺(tái)管理、平臺(tái)運(yùn)營(yíng)、應(yīng)用管理能力，為實(shí)現(xiàn)業(yè)務(wù)應(yīng)用其自身的生命周期管理
- 基礎(chǔ)層：以 Kubernetes 為核心，包括服務(wù)網(wǎng)格（ServiceMesh）、無(wú)服務(wù)計(jì)算（Serverless）、容器引擎（Docker）、容器鏡像管理等，主要實(shí)現(xiàn)對(duì)計(jì)算、網(wǎng)絡(luò)和存儲(chǔ)資源的池化管理，以及以 Pod 為核心的調(diào)度和管理。
服務(wù)網(wǎng)格為微服務(wù)帶來(lái)新的變革
Mesh 化加速業(yè)務(wù)邏輯與非業(yè)務(wù)邏輯的解耦，將非業(yè)務(wù)功能從客戶端 SDK 中分離出來(lái)放入獨(dú)立進(jìn)程，利用 Pod 中容器共享資源的特性，實(shí)現(xiàn)用戶無(wú)感知的治理接管。
從資源云向業(yè)務(wù)云化轉(zhuǎn)變，最終全面云原生化
云原生技術(shù)通過(guò)標(biāo)準(zhǔn)化資源，輕量化彈性調(diào)度等特征，應(yīng)用場(chǎng)景較為廣泛，隨著技術(shù)和生態(tài)不斷成熟和完善，有效緩解企業(yè)上云顧慮，拉動(dòng)全行業(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)容器化的打包方式實(shí)現(xiàn)真正的應(yīng)用可移植）、研運(yùn)過(guò)程標(biāo)準(zhǔn)統(tǒng)一（DevOps 工具鏈標(biāo)準(zhǔn)統(tǒng)一），通過(guò)標(biāo)準(zhǔn)化后提整體研發(fā)運(yùn)維效能。
2. 在線教育實(shí)踐
enter image description here各類 PaaS 服務(wù)上云
2019 年我們完成了 IaaS、存儲(chǔ)層、直播、回放以及各類 PaaS 服務(wù)的上云。
服務(wù)全面容器化升級(jí)
2020 年我們重點(diǎn)進(jìn)行服務(wù)全面的容器化升級(jí)，目前已經(jīng)完成企鵝輔導(dǎo)和開(kāi)心鼠英語(yǔ)兩個(gè)產(chǎn)品的全面改造，到年底會(huì)完成騰訊課堂剩余部分的升級(jí)，實(shí)現(xiàn)全面完成改造。
完善 DevOps 流程
完善 CI/CD/CO、藍(lán)盾流水線、容器化、STKE、全鏈路監(jiān)控等，提高研發(fā)效率，降低現(xiàn)網(wǎng)運(yùn)營(yíng)難度
業(yè)務(wù)中臺(tái)架構(gòu)演進(jìn)
在整體架構(gòu)上，我們依托騰訊云，確定了教育業(yè)務(wù)中臺(tái)的架構(gòu)演進(jìn)方向，不斷的進(jìn)行重復(fù)模塊的抽象和整合。我們?cè)隍v訊云上實(shí)現(xiàn)部署了接入中臺(tái)、Push 中臺(tái)、支付中臺(tái)、音視頻中臺(tái)、運(yùn)營(yíng)中臺(tái)等服務(wù)，讓各個(gè)業(yè)務(wù)之間的相似能力得以復(fù)用。
存儲(chǔ)層上云
存儲(chǔ)層上云后，一方面穩(wěn)定性提高。
- 異地容災(zāi)。通過(guò)掛載異地的災(zāi)備機(jī)器，可以實(shí)現(xiàn) master 主機(jī)異地災(zāi)備。
- 負(fù)載均衡。服務(wù)連接 RO 組，RO 組的多個(gè)實(shí)例會(huì)對(duì)請(qǐng)求進(jìn)行負(fù)載均衡。
- 數(shù)據(jù)備份。RO 發(fā)生異常，將會(huì)被剔除 RO 組，恢復(fù)后自動(dòng)加入 RO 組，保證了 RO 組的可用性。
- 數(shù)據(jù)加密。提供透明數(shù)據(jù)加密（Transparent Data Encryption，TDE）功能，透明加密指數(shù)據(jù)的加解密操作對(duì)用戶透明，支持對(duì)數(shù)據(jù)文件進(jìn)行實(shí)時(shí) I/O 加密和解密，在數(shù)據(jù)寫(xiě)入磁盤(pán)前進(jìn)行加密，從磁盤(pán)讀入內(nèi)存時(shí)進(jìn)行解密，可滿足靜態(tài)數(shù)據(jù)加密的合規(guī)性要求。
另一方面運(yùn)營(yíng)能力也有所提升。
- 可以實(shí)時(shí)看到數(shù)據(jù)庫(kù)連接情況，慢查詢、全表掃描、查詢、更新、刪除、插入情況
- 實(shí)時(shí) CPU、內(nèi)存、磁盤(pán)使用情況，并根據(jù)設(shè)置閾值進(jìn)行告警優(yōu)化微服務(wù)架構(gòu)
下面是在線教育上云前后架構(gòu)對(duì)比
微服務(wù)
微服務(wù),Service Mesh 在過(guò)去的一年依舊保持著熱度。在已經(jīng)過(guò)去的 2020，微服務(wù)可以說(shuō)有堅(jiān)守也有破局，有對(duì)服務(wù)微化共識(shí)的形成也有對(duì)特殊場(chǎng)景的理性思考。我們可以看到服務(wù)框架依然在持續(xù)演進(jìn)，奔向云原生，擁抱云化。越來(lái)越多的企業(yè)開(kāi)始跟上服務(wù)化云化步伐。
微服務(wù)框架：加速奔向云原生
SpringCloud
2018 年開(kāi)始 Hystrix、Ribbon 等核心組件相繼進(jìn)入維護(hù)狀態(tài)，開(kāi)發(fā)者們一度變得憂心忡忡，時(shí)至今日我們回過(guò)頭來(lái)再看一下，Spring Cloud 已經(jīng)針對(duì)這些擔(dān)憂給出了解決方案，Zuul 由 Spring Cloud GateWay 子項(xiàng)目替代，Hystrix 由 Spring Cloud Circuit Breaker 替代，同時(shí)也給出了長(zhǎng)期的演進(jìn)方案。在經(jīng)歷了這段小小的波折后，Spring Cloud 也改變了策略，將這些企業(yè)貢獻(xiàn)的 OSS 庫(kù)獨(dú)立出來(lái)成為其子項(xiàng)目。目前我們可以看到有 Azure，Alibaba, Amazon 等 3 個(gè)帶有企業(yè)名字的子項(xiàng)目，這種策略在某種程度上可以說(shuō)解綁了企業(yè)開(kāi)源策略對(duì)開(kāi)源核心組件的影響。截至目前 Spring Cloud 下面的子項(xiàng)目已經(jīng)新增至 34 個(gè)，越來(lái)越龐大。供開(kāi)發(fā)者選擇的組件越來(lái)越多。
Dubbo
2019 年 05 月 20 日 Dubbo 畢業(yè)，成為 Apache 的頂級(jí)項(xiàng)目，在過(guò)去的一年社區(qū)還是非常努力的，一年 release 5 個(gè)版本，加速奔向云原生。在 2.7.5 版本中，其服務(wù)模型調(diào)整以及協(xié)議支持調(diào)整帶來(lái)的新舊版本兼容問(wèn)題，穩(wěn)定性等問(wèn)題值得我們持續(xù)關(guān)注。
Istio
記得 2019 年我們一直在談 istio 版本難產(chǎn)問(wèn)題，在 2020 年卻出乎意外的因?yàn)樯虡?biāo)問(wèn)題上了頭條，讓我們吃了個(gè)大瓜。Google 與 IBM 在商標(biāo)問(wèn)題上發(fā)生分歧，Istio 商標(biāo)被 Google 捐獻(xiàn)給 Open Usage Commons 組織，而非 CNCF。而這在加速了 Service Mesh 陣營(yíng)依舊的分化，各大軟件廠商紛紛發(fā)布了自己的 Service Mesh 產(chǎn)品，如微軟發(fā)布了 Open Service Mesh，Kong 推出了 Kuma，Nginx 也推出了 NGINX Service Mesh（NSM）。
企業(yè)微服務(wù)建設(shè)：長(zhǎng)期修行，苦練內(nèi)功
在微服務(wù)框架的演進(jìn)過(guò)程中我們看到都在朝著趨同的方向發(fā)展，主要聚焦于微服務(wù)治理形態(tài)上組件的差異化以及應(yīng)對(duì)場(chǎng)景的方案細(xì)化，可能你們家服務(wù)中心用的 ZK，我們家就自研。恰逢內(nèi)源的興起，似乎在企業(yè)內(nèi)部再造一次輪子，研發(fā)一套特定的框架來(lái)適配企業(yè)業(yè)務(wù)以及標(biāo)準(zhǔn)化企業(yè)內(nèi)部 IT 治理也是一件很容易的事情，基于這種寫(xiě)實(shí)的場(chǎng)景部分企業(yè)開(kāi)始涌現(xiàn)出了內(nèi)源的服務(wù)框架如，騰訊的 tRPC 框架。
enter image description here騰訊 tRPC 建設(shè)情況?目前 tRPC 在騰訊內(nèi)部已經(jīng)大面積推廣使用，覆蓋 5 個(gè) BG，40+部門(mén)，2700+服務(wù)，10000+容器，支持 c++,go,java,js,rust,python 6 種編程語(yǔ)言。其可插拔的插件化架構(gòu)，高性能，友好的架構(gòu)兼容特性正在吸引內(nèi)部越來(lái)越多的開(kāi)發(fā)者以及業(yè)務(wù)用戶。
在線教育業(yè)務(wù)也在積極的擁抱這套框架，逐步將各業(yè)務(wù)牽引到 tRPC 框架。在解決歷史技術(shù)架構(gòu)痛點(diǎn)的過(guò)程中，通過(guò)微服務(wù)構(gòu)筑，形成微服務(wù)群，構(gòu)筑穩(wěn)定的支付,音視頻等小中臺(tái)以及面向 C、B 端用戶的互聯(lián)網(wǎng)業(yè)務(wù)系統(tǒng)。
中臺(tái)
中臺(tái)，是最近幾年最火熱的技術(shù)名詞之一，關(guān)于中臺(tái)的討論，甚至是爭(zhēng)論，一直都沒(méi)有停止過(guò)。我們嘗試結(jié)合騰訊在線教育部在中臺(tái)方向的實(shí)踐經(jīng)驗(yàn)，談?wù)勚信_(tái)對(duì)我們的意義和建設(shè)情況。
騰訊在線教育部從 2018 年開(kāi)始規(guī)劃部門(mén)內(nèi)的中臺(tái)建設(shè)，2019 年基本完成組織架構(gòu)和技術(shù)架構(gòu)的中臺(tái)轉(zhuǎn)型。我們和大多數(shù)公司一樣，并不是從 0 開(kāi)始構(gòu)建中臺(tái)，而是在保證現(xiàn)有業(yè)務(wù)快速迭代的前提下，同時(shí)完成架構(gòu)的轉(zhuǎn)型，大家形象的稱這個(gè)過(guò)程是“開(kāi)著飛機(jī)換引擎”。對(duì)于一個(gè)風(fēng)險(xiǎn)看起來(lái)這么高的事情，在決定做之前，我們要回答好幾個(gè)問(wèn)題：
1. 我們?yōu)槭裁匆鲋信_(tái)，部門(mén)需要什么樣的中臺(tái)？
我們部門(mén)主要有三款產(chǎn)品：騰訊課堂——職業(yè)在線教育學(xué)習(xí)平臺(tái)，具有 2B 和 2C 的雙重屬性。支持教育機(jī)構(gòu)的入駐、直播上課、售賣、結(jié)算 等功能。騰訊企鵝輔導(dǎo)——騰訊自營(yíng)的，主打 K12 名師教學(xué)的學(xué)習(xí)應(yīng)用，為老師和學(xué)生提供了豐富的在線教學(xué)的功能。騰訊開(kāi)心鼠英語(yǔ)——主打 3-8 歲的少兒英語(yǔ)學(xué)習(xí)，通過(guò)生動(dòng)有趣的交互式學(xué)習(xí)設(shè)計(jì)，實(shí)現(xiàn)了邊玩邊學(xué)的有趣的學(xué)習(xí)體驗(yàn)。可以看到，這三個(gè)產(chǎn)品有不少類似的功能，例如直播、回放、支付、退款 等，因?yàn)檫@些共性，決定了他們會(huì)有很多相同的產(chǎn)品和技術(shù)需求。這些形成我們做中臺(tái)的業(yè)務(wù)基礎(chǔ)。
在產(chǎn)品發(fā)展的初期，由于時(shí)間窗口非常緊，需求變化也很頻繁。為了快速并行迭代，我們拉起了三個(gè)獨(dú)立的團(tuán)隊(duì)進(jìn)行研發(fā)，除了基礎(chǔ)設(shè)施外，業(yè)務(wù)邏輯部分完全是獨(dú)立的。這種組織架構(gòu)，在當(dāng)時(shí)確實(shí)為我們達(dá)成了上線時(shí)間的目標(biāo)，幫助產(chǎn)品實(shí)現(xiàn)了從 0 到 1 的突破。但是，隨著產(chǎn)品形態(tài)的成熟，3 個(gè)問(wèn)題越來(lái)越突出：第一個(gè)問(wèn)題，功能無(wú)法在不同的產(chǎn)品間快速?gòu)?fù)用。因?yàn)楠?dú)立的代碼和架構(gòu)，復(fù)用變得非常的困難，很多開(kāi)發(fā)同學(xué)反饋復(fù)用代碼還不如重寫(xiě)一遍更快。第二個(gè)問(wèn)題，同類的 Bug 的解決和技術(shù)優(yōu)化在不同的產(chǎn)品之間重復(fù)進(jìn)行，非常的浪費(fèi)人力。第三個(gè)問(wèn)題，不同的時(shí)期，我們需要發(fā)力的產(chǎn)品方向不一樣。當(dāng)一個(gè)產(chǎn)品面臨發(fā)展窗口期的時(shí)候，對(duì)研發(fā)人力的需求就會(huì)成倍的增長(zhǎng)。而獨(dú)立的研發(fā)模式，讓人力調(diào)配非常的困難。基于業(yè)務(wù)的模型，和團(tuán)隊(duì)碰到的痛點(diǎn)，我們提出了中臺(tái)化的解決方案。
我們需要的中臺(tái)應(yīng)該長(zhǎng)什么樣子？經(jīng)過(guò)前期的思考，我們總結(jié)出在線教育的中臺(tái)應(yīng)該包含 4 個(gè)部分。首先 是業(yè)務(wù)支持部分，這個(gè)很好理解，包含了各類共性的產(chǎn)品功能，例如前面提到的 直播、回放、支付 等等。其次 是技術(shù)支持部分，服務(wù)開(kāi)發(fā)過(guò)程中 必然會(huì)涉及到例如 技術(shù)棧怎么選擇，高可用怎么做 的共性技術(shù)問(wèn)題，我們希望這部分有一個(gè)統(tǒng)一的技術(shù)實(shí)現(xiàn)。接下來(lái) 是數(shù)據(jù)支持部分，數(shù)據(jù)上報(bào)、計(jì)算、匯總、分析 已經(jīng)是現(xiàn)在互聯(lián)網(wǎng)產(chǎn)品必不可少的能力，也具備很強(qiáng)的通用性。因此這部分也應(yīng)該有一個(gè)中臺(tái)來(lái)承載。最后，是研發(fā)效能部分，我們需要有一整套好用的工具來(lái)提高研發(fā)效率和保障研發(fā)質(zhì)量。到這里，我們對(duì)于中臺(tái)的模樣，應(yīng)該是比較清晰了。
根據(jù)這個(gè)規(guī)劃，我們畫(huà)出了我們中臺(tái)的組成圖。
2. 怎么保證中臺(tái)能做成功，最大的風(fēng)險(xiǎn)是什么？
很多人說(shuō)，中臺(tái)是“一把手工程”，意思是一定是自上而下推動(dòng)的，需要老板的鼎力支持，是因?yàn)樽鲋信_(tái)確實(shí)是非常的需要人力，并且很大程度上改變了團(tuán)隊(duì)的資源投入模式，在多個(gè)業(yè)務(wù)需求壓力都很大的情況下，做這么大的轉(zhuǎn)變，團(tuán)隊(duì)短期內(nèi)一定會(huì)碰到各種不適應(yīng)的問(wèn)題。雖然我們的中臺(tái)方案也得到了老板的支持，但是絕不是中臺(tái)優(yōu)先，畢竟保障業(yè)務(wù)的高速發(fā)展才是團(tuán)隊(duì)追求的結(jié)果。一開(kāi)始我們就意識(shí)到了困難的存在，為了不讓中臺(tái)死在半路，我們定了幾個(gè)原則：
控制人力占比：在人力有限的情況下，為了保障業(yè)務(wù)需求不受太大的進(jìn)度影響，中臺(tái)的人力投入原則上不超過(guò)總?cè)肆Φ?30%。
不做過(guò)度設(shè)計(jì)：中臺(tái)的設(shè)計(jì)目標(biāo)只控制在部門(mén)內(nèi)的需求（騰訊課堂、企鵝輔導(dǎo)、開(kāi)心鼠英語(yǔ)），不面向行業(yè)做完全通用化的設(shè)計(jì)，根據(jù)實(shí)際需求做決策。
完整規(guī)劃，逐步實(shí)施：在做好完整的技術(shù)方案設(shè)計(jì)之后，我們不追求一次性完成中臺(tái)的建設(shè)，而是結(jié)合業(yè)務(wù)產(chǎn)品需求的情況逐步實(shí)施，每半年也會(huì) review 一次方案是否需要調(diào)整。
以上的規(guī)則，可以說(shuō)很好的幫助我們保障了中臺(tái)平滑轉(zhuǎn)型的過(guò)程。另外，我們也在一個(gè)合適的時(shí)間點(diǎn)進(jìn)行了團(tuán)隊(duì)人員組織結(jié)構(gòu)的中臺(tái)化匹配升級(jí)，保證了技術(shù)架構(gòu)和組織架構(gòu)的一致。
3. 中臺(tái)建設(shè)的指導(dǎo)原則是什么，目標(biāo)是什么？
我們中臺(tái)服務(wù)設(shè)計(jì)的原則是什么，應(yīng)該做哪些，什么時(shí)候做，做到什么程度。這個(gè)在業(yè)務(wù)部門(mén)里面其實(shí)是一個(gè)非常棘手的問(wèn)題。很多時(shí)候我們需要在“時(shí)效性” 和 “擴(kuò)展性”方面做選擇。
最后我們總結(jié)出來(lái)的一套方法是這樣：對(duì)于一個(gè)新的需求，如果看到了可復(fù)用性，優(yōu)先讓業(yè)務(wù)團(tuán)隊(duì)自己做，一般這種需求時(shí)間緊、不明確，如果這時(shí)候討論宏大的中臺(tái)設(shè)計(jì)，往往效率低，耽誤上線時(shí)間，但是，我會(huì)在過(guò)方案的時(shí)時(shí)候問(wèn)大家“通用性是怎么考慮的”，最終在方案設(shè)計(jì)上做好通用型的前期 準(zhǔn)備即可。后面如果再次收到另外一個(gè)產(chǎn)品的類似需求，這時(shí)候我們就認(rèn)真考慮要把這個(gè)服務(wù)交接到中臺(tái)組來(lái)維護(hù)了，由中臺(tái)組安排人力來(lái)進(jìn)行中臺(tái)化。最后再有新的業(yè)務(wù)接入，就直接由中臺(tái)組來(lái)承接了，就會(huì)非常的簡(jiǎn)單，我們很多中臺(tái)服務(wù)都是這么跑出來(lái)的。
還有一個(gè)需要思考的問(wèn)題是，中臺(tái)服務(wù)的建設(shè)目標(biāo)是什么。提出這個(gè)問(wèn)題的背景是，我們希望給中臺(tái)團(tuán)隊(duì)一個(gè)統(tǒng)一的、清晰的階段性目標(biāo)，當(dāng)然也可以用來(lái)做團(tuán)隊(duì)考核。我們總結(jié)出來(lái)三個(gè)點(diǎn)：
- 功能的復(fù)用：這個(gè)是最基本的，也是提出中臺(tái)的初衷。具體到落地上，必須是一套代碼。
- 統(tǒng)一運(yùn)營(yíng)：要求中臺(tái)服務(wù)能分產(chǎn)品輸出標(biāo)準(zhǔn)化的實(shí)時(shí)監(jiān)控看板和報(bào)表郵件，讓業(yè)務(wù)一目了然。
- 容災(zāi)調(diào)度的能力：不同業(yè)務(wù)的多套部署之間，在緊急情況下可以互備。需要進(jìn)行實(shí)際的線上演習(xí)。
我們認(rèn)為，達(dá)成這三個(gè)目標(biāo)之后，才真正的發(fā)揮了中臺(tái)的威力，可以實(shí)現(xiàn) 1+1 大于 2 的效果。
DevOps
2020 年，在云原生的浪潮下，devops 相關(guān)的技術(shù)棧也在穩(wěn)步地向前演進(jìn)，下面將從以下幾個(gè)方面分別進(jìn)行闡述：
- 敏捷的應(yīng)用交付流程
- 監(jiān)控告警系統(tǒng)
- tracing 系統(tǒng)
- 云原生對(duì)提升 devops 的展望
1. 敏捷的應(yīng)用交付流程
業(yè)內(nèi)趨勢(shì)
當(dāng)前出現(xiàn)了一系列的基于 Kubernetes 的 CI/CD 工具，如 Jenkins-x、Gitkube，它提供了從代碼提交、自動(dòng)編譯、打包鏡像、配置注入、發(fā)布部署到 Kubernetes 平臺(tái)的一系列自動(dòng)化流程。甚至出現(xiàn)了像 ballerina 這樣的云原生編程語(yǔ)言，它的出現(xiàn)就是為了解決應(yīng)用開(kāi)發(fā)到服務(wù)集成之間的鴻溝。然后結(jié)合監(jiān)控告警系統(tǒng)實(shí)時(shí)掌握服務(wù)運(yùn)行情況，結(jié)合調(diào)用鏈系統(tǒng)進(jìn)行服務(wù)故障定位。
在線教育的實(shí)踐
藍(lán)盾是騰訊從業(yè)務(wù)安全出發(fā)，貫穿產(chǎn)品研發(fā)、測(cè)試和運(yùn)營(yíng)的全生命周期；助力業(yè)務(wù)平滑過(guò)渡到敏捷研發(fā)模式，打造的一站式研發(fā)運(yùn)維體系。它助力業(yè)務(wù)持續(xù)快速交付高質(zhì)量的產(chǎn)品。藍(lán)盾提供了豐富的特性：
可視化
一鍵式部署
和持續(xù)集成無(wú)縫集成
支持并行部署
架構(gòu)水平擴(kuò)展，相同邏輯的節(jié)點(diǎn)無(wú)主備關(guān)系
數(shù)據(jù)安全
小核心，大擴(kuò)展！可插件化擴(kuò)展，優(yōu)先添加所需要的流程控制部件，同時(shí)可方便的擴(kuò)展其他部件
可監(jiān)控，監(jiān)控一切異常的構(gòu)建并告警
灰度切換，達(dá)到切換時(shí)不影響正在構(gòu)建的流水線
2. 監(jiān)控告警系統(tǒng)
監(jiān)控系統(tǒng)事實(shí)上的標(biāo)準(zhǔn) prometheus
Prometheus 在度量領(lǐng)域的統(tǒng)治力雖然還暫時(shí)不如日志領(lǐng)域中 Elastic Stack 的統(tǒng)治地位那么穩(wěn)固，但在云原生時(shí)代里，基本也已經(jīng)能算是事實(shí)標(biāo)準(zhǔn)了。2020 年，對(duì) prometheus 來(lái)說(shuō)，是忙碌的一年：
grafana cloud agent 發(fā)布：為 grafana cloud 優(yōu)化的的一個(gè)輕量級(jí) prometheus 分支，它使用 prometheus 的代碼，保證 prometheus 生態(tài)依賴的一些屬性：數(shù)據(jù)完整性、數(shù)據(jù)過(guò)期處理等等。允許使用一種更靈活的方式定義從何處以什么方法拉取和傳輸數(shù)據(jù)，它已經(jīng)成為一種更受歡迎的方式將數(shù)據(jù)寫(xiě)入后端存儲(chǔ)。它的 remote_write 方式相比于傳統(tǒng) prometheus agent 的 remote_write，內(nèi)存使用降低了 40%；
v2.19.0 的發(fā)布：最核心的功能是，對(duì)于完整的 chunk，在內(nèi)存中使用 head 結(jié)構(gòu)映射磁盤(pán)中的 block，單就這一個(gè)點(diǎn)，內(nèi)存使用就降低了 20%-40%，并且使得 prometheus 的重啟速度更快；
v2.20.0 的發(fā)布：它為 Docker Swarm 和 DigitalOcean 支持了本地的服務(wù)發(fā)現(xiàn)；
提升批量插入一大批老數(shù)據(jù)到 prometheus 的效率；
Grafana Metrics Enterprise 的啟動(dòng)：提供針對(duì)大企業(yè)的 prometheus-as-a-service 的解決方案
在線教育的實(shí)踐
nginx 訪問(wèn)日志和服務(wù)間模塊調(diào)用相關(guān)信息都上報(bào)到全鏈路 es 集群
通過(guò)一個(gè) exporter 對(duì) es 中的數(shù)據(jù)按照項(xiàng)目和接口維度進(jìn)行匯聚，將相關(guān)的聚合數(shù)據(jù)存入 prometheus
全鏈路 es 和 prometheus 都可以作為 grafana 的數(shù)據(jù)源進(jìn)行數(shù)據(jù)展示和告警判斷
alert 模塊將告警信息發(fā)送到相應(yīng)的渠道
收到告警之后，去 grafana 查看對(duì)應(yīng)時(shí)間段的趨勢(shì)圖，去全鏈路 es 集群查看對(duì)應(yīng)時(shí)間段的原始日志
3. tracing 系統(tǒng)
比起日志與度量， tracing 這個(gè)領(lǐng)域的產(chǎn)品競(jìng)爭(zhēng)要相對(duì)激烈得多。一方面，目前還沒(méi)有像日志、度量那樣出現(xiàn)具有明顯統(tǒng)治力的產(chǎn)品。另一方面，幾乎市面上所有的追蹤系統(tǒng)都是以 Dapper 的論文為原型發(fā)展出來(lái)的，功能上并沒(méi)有太本質(zhì)的差距，卻又受制于實(shí)現(xiàn)細(xì)節(jié)，彼此互斥，很難搭配工作。
OpenTracing 規(guī)范
為了推進(jìn)追蹤領(lǐng)域的產(chǎn)品的標(biāo)準(zhǔn)化，2016 年 11 月，CNCF 技術(shù)委員會(huì)接受了 OpenTracing 作為基金會(huì)第三個(gè)項(xiàng)目。OpenTracing 是一套與平臺(tái)無(wú)關(guān)、與廠商無(wú)關(guān)、與語(yǔ)言無(wú)關(guān)的追蹤協(xié)議規(guī)范。
OpenCensus 規(guī)范
OpenTracing 規(guī)范公布后，幾乎所有業(yè)界有名的追蹤系統(tǒng)，譬如 Zipkin、Jaeger、SkyWalking 等都很快宣布支持 OpenTracing，但是 Google 自己卻在此時(shí)提出了與 OpenTracing 目標(biāo)類似的 OpenCensus 規(guī)范。OpenCensus 不僅涉及到追蹤，還把指標(biāo)度量也納入進(jìn)來(lái)。
OpenTelemetry 規(guī)范
2019 年，OpenTracing 和 OpenCensus 又共同發(fā)布了可觀測(cè)性的終極解決方案 OpenTelemetry，并宣布會(huì)各自凍結(jié) OpenTracing 和 OpenCensus 的發(fā)展。OpenTelemetry 野心頗大，不僅包括追蹤規(guī)范，還包括日志和度量方面的規(guī)范、各種語(yǔ)言的 SDK、以及采集系統(tǒng)的參考實(shí)現(xiàn)。
在線教育的實(shí)踐
騰訊基于 OpenTelemetry 規(guī)范，自研了天機(jī)閣系統(tǒng)。天機(jī)閣主要分為三大部分：
- 分布式追蹤（distributed tracing）
- 監(jiān)控（monitoring，metrics）
- 日志（logging）
與之對(duì)應(yīng)提供七大能力：
- 故障定位：天機(jī)閣中能夠提供整個(gè)請(qǐng)求全鏈路上下文信息，具體哪個(gè)環(huán)節(jié)出錯(cuò)一目了然
- 耗時(shí)分析：天機(jī)閣的耗時(shí)分布圖，可以快速了解全鏈路耗時(shí)情況
- 多維染色：在天機(jī)閣基于通用的設(shè)計(jì)理念下，天機(jī)閣提供的染色能力，不會(huì)局限在某個(gè)業(yè)務(wù)的具體字段，同樣也不會(huì)局限單個(gè)維度
- 架構(gòu)治理：天機(jī)閣架構(gòu)治理的核心功能是微服務(wù)架構(gòu)拓?fù)洌谖⒎?wù)架構(gòu)拓?fù)淇梢詷?gòu)建更加豐富更加具體的上層分析能力
- 全鏈路日志：天機(jī)閣核心建立在分布式追蹤方法論下，提供將分散在各個(gè)微服務(wù)的日志根據(jù)因果和時(shí)間有機(jī)進(jìn)行組合，達(dá)到提供全鏈路上下文日志的效果
- 服務(wù)監(jiān)控：天機(jī)閣在監(jiān)控領(lǐng)域?qū)?huì)重點(diǎn)推出如下幾大領(lǐng)域監(jiān)控（機(jī)器基礎(chǔ)指標(biāo)監(jiān)控、數(shù)據(jù)庫(kù)監(jiān)控、進(jìn)程監(jiān)控、模調(diào)監(jiān)控）
- 業(yè)務(wù)看板：主要用于業(yè)務(wù)定制化的數(shù)據(jù)指標(biāo)配置和展示
系統(tǒng)架構(gòu)圖
功能模塊圖
4.云原生對(duì)提升 devops 的展望
serverless 對(duì)提升 devops 的展望
- 降低運(yùn)維需求
- 縮短迭代周期、上線時(shí)間
- 快速試錯(cuò)
- 極致彈性
- 降低運(yùn)營(yíng)成本
service mesh 對(duì)提升 devops 的展望
- 更好發(fā)揮掌握不同編程語(yǔ)言的人才優(yōu)勢(shì)
- 框架的部分能力平臺(tái)化，加速應(yīng)用迭代速度
- 微服務(wù)軟件架構(gòu)從解決"拆"到解決"連"的加速落地
- 靈活的流量治理能力改善軟件的發(fā)布與回滾效率
音視頻
1. 音視頻技術(shù)回顧
隨著 AI 技術(shù)的興起、5G 時(shí)代的到來(lái)，音視頻技術(shù)不斷加速應(yīng)用發(fā)展，像直播、短視頻這樣的產(chǎn)品遍地開(kāi)花，火熱程度相信大家或多或少都接觸過(guò)。
音視頻技術(shù)的加速應(yīng)用依賴底層編解碼標(biāo)準(zhǔn)的發(fā)展，當(dāng)前主流的 H.264 編解碼技術(shù)已經(jīng)不能滿足未來(lái) 4K、8K 的需求，今年年中剛發(fā)布的 H266/VCC，與 H.265 相比進(jìn)一步提高了壓縮效率，這項(xiàng)耗時(shí) 3 年的標(biāo)準(zhǔn)，主要面向未來(lái)的 4K 和 8K，后續(xù)的落地應(yīng)用非常值得期待。
在實(shí)時(shí)音視頻技術(shù)領(lǐng)域，不得不提及谷歌的開(kāi)源項(xiàng)目 WebRTC，可以在瀏覽器上快速開(kāi)發(fā)出各種音視頻應(yīng)用，目前主流的瀏覽器包括 Chrome、Firefox、Safari 等都將 WebRTC 作為首選的實(shí)時(shí)音視頻方案。同時(shí)也催生了像聲網(wǎng)、即構(gòu)科技這樣的專門(mén)音視頻服務(wù)商。從 StackOverflow Trends 和 GoogleTrends 來(lái)看，未來(lái)關(guān)注度仍會(huì)持續(xù)上升，騰訊也是 WebRTC 應(yīng)用的主力軍。
目前直播后臺(tái)開(kāi)發(fā)主要分為三大塊：
- 標(biāo)準(zhǔn)直播：我們?nèi)粘Ｉ钪惺褂妙l率最高的直播，例如電視節(jié)目直播、游戲直播、直播帶貨。
- 快直播：標(biāo)準(zhǔn)直播在超低延遲直播場(chǎng)景基礎(chǔ)上的延伸，毫秒級(jí)超低延遲播放的同時(shí)，也兼顧了秒開(kāi)、卡頓等核心問(wèn)題，為用戶帶來(lái)超低延遲流暢度的直播體驗(yàn)。
- 慢直播：能夠提供更穩(wěn)定清晰的直播畫(huà)面，基本的使用場(chǎng)景都用于監(jiān)控領(lǐng)域，國(guó)內(nèi)疫情早期，4000 萬(wàn)人同時(shí)在線，通過(guò)一個(gè)固定機(jī)位觀看雷神山醫(yī)院建筑工地的現(xiàn)場(chǎng)直播，讓云監(jiān)工迅速火爆。2020 行至年終，各大機(jī)構(gòu)評(píng)選的網(wǎng)絡(luò)熱詞相繼出爐，其中，“云監(jiān)工”頻繁出沒(méi)于「十大網(wǎng)絡(luò)熱詞」榜單中，與之并列的多是“后浪”“網(wǎng)抑云”“打工人”等。
隨著網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，持續(xù)提供高質(zhì)量的視頻信號(hào)傳播已經(jīng)算不上浪費(fèi)網(wǎng)絡(luò)資源，即使一個(gè)直播無(wú)人觀看，未來(lái)慢直播具有極大的延伸價(jià)值以及發(fā)展前景，讓我們期待慢直播行業(yè)的蓬勃發(fā)展。
借助 5G 技術(shù)低時(shí)延、高速率、大容量等顯著優(yōu)勢(shì)，音視頻的大賽道，從目前的短視頻慢慢走向中長(zhǎng)視頻發(fā)展，這是未來(lái)的大風(fēng)口。
2. 平臺(tái)的新技術(shù)點(diǎn)
目前騰訊在線教育音視頻直播已完成整體上云，騰訊云的互動(dòng)直播也從早期的 opensdk 全面升級(jí)到 TRTC，TRTC 是騰訊實(shí)時(shí)音視頻[Tencent Real-Time Communication]，源自 QQ 音視頻團(tuán)隊(duì)，是基于 QQ 十幾年來(lái)的音視頻技術(shù)積累。
騰訊云提供 TRTC(全球延時(shí)<300ms)+WebRTC 快直播(上行走 RTMP 推流或 FLV、HLS、RTMP 回源，下行支持標(biāo)準(zhǔn) WebRTC 協(xié)議輸出，延時(shí) 500ms 左右）+標(biāo)準(zhǔn) LVB 直播(FLV/HLS/DASH，平均延時(shí) 3-5 秒)融合解決方案，如下圖中用戶可以針對(duì)自己的業(yè)務(wù)場(chǎng)景組合不同的直播解決方案。承載大規(guī)模帶寬、支撐高并發(fā)，保證客戶業(yè)務(wù)正常運(yùn)作，達(dá)到 99.9%以上的可用性，整體資源儲(chǔ)備及業(yè)務(wù)突發(fā)承接能力行業(yè)領(lǐng)先。
隨著全民抗疫，“停課不停學(xué)”的號(hào)召，在線教育也成為直播的主力軍，直播的進(jìn)房成功率/首幀延遲/卡頓率/音畫(huà)同步時(shí)延/分辨率等指標(biāo)直接影響用戶核心體驗(yàn)。站在云的肩膀上，在線教育直播業(yè)務(wù)通過(guò)組合云上多種直播模式，結(jié)合業(yè)務(wù)流控系統(tǒng)，對(duì)各端直播接入進(jìn)行多級(jí)流控及直播模式切換，在保證直播質(zhì)量的前提下支撐遠(yuǎn)超互動(dòng)直播極限的房間容量，下圖是具體的直播架構(gòu)。
3. 業(yè)務(wù)應(yīng)用新技術(shù)的能力擴(kuò)展
目前直播課普遍采用大班授課方式，老師在上課的時(shí)候，跟學(xué)生的互動(dòng)有限，學(xué)生的注意力和參與感有限。大班教室人數(shù)太多，老師無(wú)法提供足量的 presentation 機(jī)會(huì)，學(xué)生與學(xué)生之間缺少有效的學(xué)習(xí)互動(dòng)。
騰訊在線教育部推出如下圖的六人小班課，基于 TRTC 在互動(dòng)課堂場(chǎng)景下，為學(xué)員提供了穩(wěn)定優(yōu)質(zhì)的服務(wù)，延遲低至原來(lái)的 1/10，互動(dòng)效果得到很大提升。六人小班課給用戶帶來(lái)更多“被關(guān)注”的感覺(jué)，相比于大班課，家長(zhǎng)的價(jià)值感知更高。
接入網(wǎng)關(guān)
1. 網(wǎng)關(guān)發(fā)展歷程
接入網(wǎng)關(guān)有四大職能
- API 入口：作為所有 API 接口服務(wù)請(qǐng)求的接入點(diǎn)，負(fù)責(zé)請(qǐng)求的轉(zhuǎn)發(fā)。
- 業(yè)務(wù)聚合：網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個(gè)客戶端提供一個(gè)定制的 API。作為所有后端業(yè)務(wù)服務(wù)的聚合點(diǎn)，所有的業(yè)務(wù)服務(wù)都可以在這里被調(diào)用。
- 中介策略：身份驗(yàn)證、路由、過(guò)濾、流控、緩存、監(jiān)控、負(fù)載均衡、請(qǐng)求分片與管理、靜態(tài)響應(yīng)處理等策略，進(jìn)行一些必要的中介處理。
- 統(tǒng)一管理：提供統(tǒng)一的管理界面，提供配置管理工具，對(duì)所有 API 服務(wù)的調(diào)用生命周期和相應(yīng)的中介策略進(jìn)行統(tǒng)一管理
開(kāi)源網(wǎng)關(guān)發(fā)展迅速。從 nginx 橫空出世，到 openresty 解放程序員，更加專注解決業(yè)務(wù)需求，再到 kong 成為 api 網(wǎng)關(guān)的獨(dú)角獸，以及最近出現(xiàn)不久的 apisix，當(dāng)然也不能少了大名鼎鼎的 envoy。下面介紹主要的幾個(gè)網(wǎng)關(guān)。
nginx
2004 年 10 月 4 日發(fā)布的第一個(gè)公開(kāi)版本以來(lái)，nginx 已成為高性能 web 服務(wù)器、反向代理服務(wù)器的代名詞。相比 Apache，Nginx 使用更少的資源，支持更多的并發(fā)連接，能夠支持高達(dá) 50,000 個(gè)并發(fā)連接數(shù)的響應(yīng)。模塊化和將一個(gè)請(qǐng)求分為多個(gè)階段的設(shè)計(jì)，方便開(kāi)發(fā)人員擴(kuò)展。
openresty
OpenResty? 是一個(gè)基于 Nginx 與 Lua 的高性能 Web 平臺(tái)，其內(nèi)部集成了大量精良的 Lua 庫(kù)、第三方模塊以及大多數(shù)的依賴項(xiàng)。用于方便地搭建能夠處理超高并發(fā)、擴(kuò)展性極高的動(dòng)態(tài) Web 應(yīng)用、Web 服務(wù)和動(dòng)態(tài)網(wǎng)關(guān)。python、js、lua 三種語(yǔ)言中，lua 是解析器最小、性能最高的語(yǔ)言，而 LuaJIT 比 lua 又快數(shù) 10 倍，開(kāi)發(fā)人員和系統(tǒng)工程師可以使用 Lua 腳本語(yǔ)言調(diào)動(dòng) Nginx 支持的各種 C 以及 Lua 模塊，快速構(gòu)造出足以勝任 10K 乃至 1000K 以上單機(jī)并發(fā)連接的高性能 Web 應(yīng)用系統(tǒng)。
kong
kong 是 API 管理的強(qiáng)大效率工具，主要有 4 個(gè)特點(diǎn)
- 擴(kuò)展性：通過(guò)增添更多的服務(wù)器實(shí)例達(dá)到橫向擴(kuò)展
- 靈活性：可以部署在單個(gè)或多個(gè)數(shù)據(jù)中心環(huán)境的私有云或公有云上。支持大多數(shù)流行的操作系統(tǒng)，比如 Linux、Mac 和 Windows。包括許多實(shí)用技巧，以便針對(duì)大多數(shù)現(xiàn)代平臺(tái)完成安裝和配置工作
- 模塊性：可以與新的插件協(xié)同運(yùn)行，擴(kuò)展基本功能。可將 API 與許多不同的插件整合起來(lái)，以增強(qiáng)安全、分析、驗(yàn)證、日志及/或監(jiān)測(cè)機(jī)制
- 生態(tài)：開(kāi)源免費(fèi)使用，同時(shí)也能獲得企業(yè)版，此外還提供初始安裝、從第三方 API 管理工具來(lái)遷移、緊急補(bǔ)丁、熱修復(fù)程序及更多特性。
2. 在線教育網(wǎng)關(guān)實(shí)踐
在線教育網(wǎng)關(guān)發(fā)展過(guò)程中的包袱
通道 proxy 多語(yǔ)言, 多框架, 多協(xié)議功能無(wú)法服用，維護(hù)成本高
配置動(dòng)態(tài)加載能力和插件能力不統(tǒng)一
一個(gè)接口上線配置多次，驗(yàn)證多次。
缺乏完善的監(jiān)控
頻控，容災(zāi)、熔斷、下載等能力缺失
非云原生應(yīng)用，不支持自動(dòng)擴(kuò)縮容
tiny 網(wǎng)關(guān)
tiny 網(wǎng)關(guān)主要的能力如下：
- 提供 app 端, web, pc 端快速接入，統(tǒng)一 sdk 和協(xié)議
- 支持智能路由，支持按照 cmd, uid, roomid, cid 字段的路由
- 全房間和多維度組合推送策略
- 可靠 push 保障
- 業(yè)務(wù)級(jí)別的監(jiān)控告警
- 命令字配置集中管理，支持熱加載
- 支持插件化的能力，方便添加業(yè)務(wù)特性的插件
- 全面落地容器化，支持自動(dòng)擴(kuò)縮容
完整的架構(gòu)如下圖所示
go 語(yǔ)言
隨著云原生在互聯(lián)網(wǎng)行業(yè)的普及,golang 從眾多語(yǔ)言中,脫穎而出,成為了云原生時(shí)代的新秀。越來(lái)越多的開(kāi)源項(xiàng)目采用 golang 語(yǔ)言來(lái)實(shí)現(xiàn)。因此學(xué)習(xí)和掌握 golang 語(yǔ)言,越來(lái)越成為一種趨勢(shì)。本篇文章,主要圍繞 golang 語(yǔ)言的主要特性來(lái)展開(kāi)講解,希望對(duì)大家有幫助。
語(yǔ)法簡(jiǎn)單
golang 素以簡(jiǎn)單著稱,總共 25 個(gè)保留字,相比 c++的 82 個(gè),java 語(yǔ)言的 50 個(gè),少的不能再少了。golang 官方也比較吝于新增命令字。常見(jiàn)的結(jié)構(gòu)和判斷,對(duì)于 golang 來(lái)說(shuō),就只有 if,for,switch 等非常簡(jiǎn)單的命令字。自帶的 array,slice,map 等數(shù)據(jù)結(jié)構(gòu),基本可以 cover 大多數(shù)的使用場(chǎng)景。
部署方便
編譯好的 golang 程序,是一個(gè)獨(dú)立的二進(jìn)制程序,只依賴操作系統(tǒng)的一些基礎(chǔ)庫(kù),除此之外,沒(méi)有任何其他外部依賴。有使用過(guò) golang 語(yǔ)言開(kāi)發(fā)開(kāi)源軟件的同學(xué),應(yīng)該感觸。
靜態(tài)編譯
golang 是一門(mén)靜態(tài)強(qiáng)類型的編譯型語(yǔ)言,與 c++類似,golang 也是也有一個(gè)完整的編譯鏈接過(guò)程,并且有嚴(yán)格的編譯期的語(yǔ)法檢查過(guò)程。配合 golang 強(qiáng)大的工具鏈,在編譯期可以提前解決腳本語(yǔ)言運(yùn)行時(shí)才能發(fā)現(xiàn)的諸多問(wèn)題。
垃圾回收
一直以來(lái),c++程序員飽受內(nèi)存問(wèn)題的困擾,常見(jiàn)的比如內(nèi)存泄漏,溢出,double free 等問(wèn)題層出不窮,并且定位起來(lái)費(fèi)時(shí)費(fèi)力。c++官方為了降低使用成本,也在 c++0x 之后,引入了智能指針來(lái)解決內(nèi)存使用的問(wèn)題。但是內(nèi)存問(wèn)題依然存在。golang 跟 java 語(yǔ)言一樣,從語(yǔ)言層面提供了 GC 能力,自帶的垃圾回收機(jī)制,有效解決了內(nèi)存使用的諸多問(wèn)題。但是垃圾回收并非完美無(wú)缺, 不合理的內(nèi)存使用方式,依然會(huì)導(dǎo)致程序出現(xiàn)嚴(yán)重的 gc 問(wèn)題，從而導(dǎo)致程序出現(xiàn)性能問(wèn)題,因此也有一定的 trick 需要遵循。
工具鏈支持
除了 golang 語(yǔ)言自帶的編譯,安裝,單元測(cè)試等工具之外,c++的調(diào)試神器 gdb 也能夠使用。同時(shí)第三方提供的 delve 調(diào)試工具, 兼容性和易用性更好,同時(shí)還提供了遠(yuǎn)程調(diào)試的能力。原生自帶的 perf 工具,配合第三方的 go-torch 工具,生成的火焰圖,調(diào)試的時(shí)候非常方便, 讓性能瓶頸能夠一目了然。
泛型
golang 被人詬病的特性之一,就是不支持泛型。官方認(rèn)為雖然泛型很贊，但會(huì)使語(yǔ)言設(shè)計(jì)復(fù)雜度提升，所以并沒(méi)有把這個(gè)泛型支持作為緊急需要增加的特性，也許在不久的將來(lái), 會(huì)引入這個(gè)特性。現(xiàn)階段可以通過(guò)使用 Interface 作為中間層,起到抽象和適配的作用。一些第三方工具,比如 genny,通過(guò)模板化生成代碼,也可以作為泛型的一種解決方案。
錯(cuò)誤處理
golang 語(yǔ)言, 錯(cuò)誤處理從語(yǔ)言層面得到了支持, 基于 Error 接口來(lái)實(shí)現(xiàn),配合函數(shù)的多返回值機(jī)制,, ，一般情況下, 錯(cuò)誤碼也會(huì)作為函數(shù)的最后一個(gè)返回值。在 golang 中, 錯(cuò)誤處理非常重要, 語(yǔ)言的設(shè)計(jì)和規(guī)范,也鼓勵(lì)開(kāi)發(fā)人員顯示的檢查錯(cuò)誤。也正因?yàn)槿绱?golang 的錯(cuò)誤處理，也被很多人所詬病，覺(jué)得不像其他高級(jí)語(yǔ)言,比如 java 的錯(cuò)誤處理那么簡(jiǎn)潔。不過(guò)整體來(lái)說(shuō),golang 作者將錯(cuò)誤碼顯性化,目的是為了讓大家能夠重視錯(cuò)誤處理，所以應(yīng)該說(shuō)是各有特色。
包管理
golang 語(yǔ)言剛誕生的時(shí)候,并不支持版本管理。GOPATH 方式,也只能算是包管理基本的雛形。后來(lái)經(jīng)過(guò)一系列的演變，社區(qū)先后支持了 dodep,glide 的工具。直到 2016 年,官方才提出采用外部依賴包的方式,引入了 vendor 機(jī)制。2017 的時(shí)候推出的 dep 工具,基本可以作為準(zhǔn)官方的解決方案了。然而,直到 2019,go modules 的推出, golang 的包管理爭(zhēng)論才最終塵埃落定。基于 go mod 的版本管理機(jī)制,基本上可以說(shuō)是一統(tǒng)江湖。具體的 golang 包管理演進(jìn)過(guò)程,如下圖所示:
并發(fā)性能
golang 從語(yǔ)言層面就支持了并發(fā),大大簡(jiǎn)化了并發(fā)程序的編寫(xiě)。這也是 golang 廣受大家歡迎的原因之一。goroutine 是 golang 并發(fā)設(shè)計(jì)的核心, 本質(zhì)上講就是協(xié)程,也叫做用戶態(tài)線程,它比線程更易用,更高效,更輕便,占用內(nèi)存更小,并對(duì)開(kāi)發(fā)者屏蔽了底層的協(xié)程調(diào)度細(xì)節(jié)。提供的 go,select,channel 等關(guān)鍵字,易用性非常好。配合 golang 中提供的 sync 包,可以非常高效的實(shí)現(xiàn)并發(fā)控制能力。
常見(jiàn)網(wǎng)站
- golang 百科全書(shū): 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 在未來(lái)企業(yè)會(huì)有更多布道：Go Conference 一直都是 Gopher 關(guān)注的技術(shù)大會(huì)，20 年 11 月國(guó)內(nèi)的 Go Conferernce(https://github.com/gopherchina/conference)分享主題主要包括 Go 語(yǔ)言基礎(chǔ)（Go 編程模式、Go Module、Go 編譯器、組件包）和架構(gòu)落地實(shí)踐（微服務(wù)實(shí)踐、微服務(wù)框架、云原生實(shí)踐、大數(shù)據(jù)和高并發(fā)挑戰(zhàn)），側(cè)面也印證了 Go 語(yǔ)言在后端領(lǐng)域具備較強(qiáng)的業(yè)務(wù)實(shí)戰(zhàn)落地能力，對(duì)打算采用 Go 的互聯(lián)網(wǎng)企業(yè)，具有較強(qiáng)的指導(dǎo)和借鑒意義。
業(yè)界認(rèn)可度
golang 作為云原生的首選語(yǔ)言,在業(yè)界獲得廣泛的認(rèn)可。基于 golang 的很多明星項(xiàng)目,包括 docker,k8s,etcd,influxdb,tidb,prometheus,kibana,nsq 等覆蓋了容器化,容器編排,存儲(chǔ),監(jiān)控,消息隊(duì)列等各個(gè)場(chǎng)景, 在各大公司都獲得了大量的應(yīng)用。同時(shí)從 github 拉取數(shù)據(jù)查看語(yǔ)言流行程度, 我們對(duì)比了 java,c++,c,go 等語(yǔ)言發(fā)現(xiàn),golang 在 github 開(kāi)源庫(kù)的使用上越來(lái)越流行。如下圖所示的 golang 占比情況:
趨勢(shì)
全面轉(zhuǎn)到 Go Module：官方會(huì)終止對(duì) GOPATH 的開(kāi)發(fā)支持，全面轉(zhuǎn)到 Go Module。
2021年,golang 中的泛型還要持續(xù)打磨。
隨著云原生浪潮，越來(lái)越多的企業(yè)將會(huì)考慮將 Go 作為其主要后端開(kāi)發(fā)語(yǔ)言。
總結(jié)
2021年已經(jīng)過(guò)去，可以確定技術(shù)的發(fā)展是一分鐘也不會(huì)停滯。可以預(yù)見(jiàn)云原生、微服務(wù)等新技術(shù)依舊是后臺(tái)技術(shù)發(fā)展趨勢(shì)，2022年也會(huì)有更多創(chuàng)新出現(xiàn)。
/blog.csdn.net/yugemengjing/article/detai
END往期推薦