雲+社區技術沙龍丨解析騰訊最新開源項目背後的技術棧

12 月 21 日，由騰訊云云+社區和騰訊對外開源管理辦公室聯合主辦的技術沙龍在深圳騰訊大廈成功舉辦。本期活動的主題爲「騰訊開源技術」，多位來自騰訊的開源技術專家及工程師圍繞 Kona JDK、TencentOS tiny、TubeMQ 等開源項目的開發過程，分享了騰訊在開源之路上取得的最新成果以及過程當中所積累的實踐經驗，並深刻探討了開源技術在大數據、物聯網、醫療等不一樣場景下的發展趨勢。 
  

 
楊曉峯：《Kona JDK 在騰訊大數據領域的實踐和發展》
 
騰訊專家工程師、TEG JDK 團隊負責人楊曉峯，在演講中簡要介紹了 Kona JDK 項目的緣起，分析了當前 OpenJDK 的技術發展熱點，以及國內該領域的發展狀態和趨勢，對 Kona JDK 在騰訊大數據領域的需求痛點、實踐心得以及將來發展進行了分享。
 
Open JDK 是 Java SE 標準的免費和開源參考實現。2006 年，Sun 公司承諾逐步開源核心 Java 平臺。2007 年，Redhat 公司加入，併發布了 IcedTea。2010年，Oracle 收購 Sun 並接過了項目領導工做，IBM二、SAP 等廠商陸續加入。2014 年，JDK 8 發佈，成爲採納速度最快以及接受程度最高的版本。2017 年，JDK 9 發佈並隨後確立了半年週期發佈模式和新的收費模式。2019 年，Tencent Kona 宣佈開源。
 
Tencent Kona 具備這樣幾個特質，首先免費，使用零成本，其次騰訊會提供長期可靠的支持，第三生產就緒，它通過了騰訊內部超大規模的生產環境的考驗。而騰訊也將在將來秉承「最大化兼容性」，「逐步貢獻大數據、雲計算等領域先進特性」等原則，積極擁抱開源，持續貢獻社區。
 
從目前國內的 JDK 產品應用來看，Oracle JDK 仍佔約 70%，OpenJDK 佔 21% 但快速崛起中。從版本的維度，JDK 7/8 仍爲主流，但值得注意的是，JDK 11 已經獲得必定規模的生產實踐，國內廠商在 JVM 新技術革新與落地方面愈來愈深刻與自信。
聚焦於大數據領域，目前 Java/JVM 是當之無愧的無冕之王，這主要是得益於 JVM 具有的高生產力、高性能、高可靠性等優勢，提供了完美的跨平臺能力、完善的工具、海量的類庫和框架等。
 
但在騰訊大數據海量、苛刻的技術場景中，目前JVM的能力短板，逐漸成爲了部分前沿場景的瓶頸，體如今集羣規模、SLA、內存密度等多個方面。經典 GC 與特定應用場景存在錯配，診斷和調優設施仍有較大的能力不足。
 
與此同時，現代硬件突飛猛進，JVM 是當前算力的保證，但仍須要大量改進工做，才能更高效地利用向量化等技術，支撐將來持續性能提高的需求。騰訊將從多個技術層面持續進行 JVM 優化，改進相應的工具等，打造領域最佳 Java 運行環境和解決方案。
 
 
葉豐：《基於 TencentOS tiny 開源項目的實踐 ── 從零快速打造 IoT 小應用》
 
騰訊工程師葉豐在演講中主要介紹了 TencentOS tiny 的項目背景、軟件架構、IoT 解決方案、開發實踐等內容。
 
TencentOS Tiny 是騰訊開源的面向物聯網領域的精簡實時操做系統，它是騰訊物聯網產品矩陣底層的關鍵一環，做用是爲雲側海量數據平臺進行引流，下降開發門檻，提高開發效率，使物聯網終端設備及業務能快速接入騰訊雲物聯網平臺。
 
從 TencentOS tiny 的架構來看，它已經適配了主流的芯片和模組，提供了最精簡的 RTOS 內核，以及豐富的物聯網組件，集成了主流的物聯網協議。TencentOS tiny 具備小體積、低功耗、豐富的 IoT 組件、可靠的安全框架、良好的移植性、便捷的調試手段等特色，可以知足物聯網的差別化需求。
 
TencentOS tiny 是今年 9 月 18 日正式開源的，發佈一週時間就成爲了 GitHub 開源項目熱榜排行第二名，目前已得到 Star 3500+、Fork 800+，目前已與國內外主流 MCU 及硬件廠商合做，支持的硬件平臺數已經超過了 50個。
 
騰訊 TencentOS tiny 目前也有一些落地的物聯網解決方案，好比智能貨櫃解決方案與智慧種植解決方案。
 
在智能貨櫃解決方案中，TencentOS tiny 配合中控系統和 AI 識別服務，完成了掃碼開櫃、取物、關門自動結算流程，構建了一個無人售貨的場景。針對真實場景中不可控的狀況，好比因爲貨物的部分遮擋致使 AI 識別率下降等，TencentOS tiny 提供更多的感知能力：如重力感應等，輔助 AI 作決策，提升了 AI 的識別率。
 
而在智慧種植解決方案中，TencentOS tiny 主要服務於兩個環節 ── 即環境感知側與調節控制側。環境感知側經過採集溫溼度、土壤酸鹼度、含氧量等環境數據，並上報到 IoT 雲平臺，雲端的決策算法根據環境數據做出相關的溫室調節指令，最終由調節控制側完成溫室環境調節。同時 TencentOS tiny 採用了多方案網絡適配，支持 WiFi/NB-IoT/Lora，實現鏈路全加密，保證數據安全。
 
此外，爲了更深刻地瞭解 TencentOS tiny，現場結合 TencentOS tiny 定製開發板，完成了一個小型的端到端農業場景開發實踐，包括環境感知，設備控制，數據上雲，小程序對接。使用 TencentOS tiny 能夠簡化設備端開發，同時結合騰訊雲物聯網平臺和小程序雲開發，可以實現物聯網解決方案的快速、低成本的上線和迭代。
 
 
張國成：《TubeMQ 的 Apache 之路》
 
騰訊高級工程師、TubeMQ 項目負責人張國成在演講中闡述、分析了萬億級消息中間件 TubeMQ 的相關實現原理，並分享了針對項目後續發展方向等問題的思考。
 
TubeMQ 是來自騰訊的萬億級分佈式消息中間件，專一於海量數據場景下的存儲和傳輸，在穩定性、性能和低成本方面具備獨特優點。經過咱們實際應用場景定義的大數據場景測試方案測試，TubeMQ 可支持 14 萬 TPS 的吞吐量，消息延時能控制在 10 毫秒，甚至是 5 毫秒之內；系統已在公司內部持續迭代改進了 7 年時間，普遍應用於實時廣告推薦、海量數據上報、數據流處理、指標 & 監控等場景。
 
TubeMQ 系統架構的關鍵特色包括純 Java 實現、有 Master HA 協調節點、弱化 zk、offset 管理去中心化、支持服務端過濾、改進了消息存儲模式、調整了基於磁盤 RAID10 多副本 + 快速消費，而非多 Broker 節點多副本的數據可靠性方案等。
 
持續增加的接入量壓力是騰訊自研 TubeMQ 的內在動因：在數據量級不多，好比 10 億量級或如下時，用什麼消息隊列都沒問題，但數據到了百億、千億、萬億量級甚至以上的時候，就會出現不少制約因素，好比成本、穩定性、性能等，TubeMQ 的日均接入量從 2013 年初的 200 億到 2019 年 11 月的 35 萬億，這期間騰訊的消息隊列經歷了從引入到改進再到自研的實踐過程。
 
TubeMQ 於今年 9 月在 Apache Con 上宣佈開源並捐獻給了 Apache 基金會。之因此將 TubeMQ 進行開源，主要基於 3 點考慮：首先是響應公司的技術戰略，積極參與開源協同共建；其次是咱們但願 TubeMQ 對外開源能夠實際幫助到這一塊有須要的合做夥伴，能夠解決業務在這塊遇到的不少實際問題的；第三是經過擁抱開源，避免閉門造車，與外部的開源社區協做提高自身及系統。而選擇將 TubeMQ 貢獻給 Apache，既是但願經過中立的基金會的已成文的標準化孵化流程，使項目更加成熟，同時也由於 Apache 因大數據生態而聞名，咱們也受益於這個生態，基於受惠於開源回饋開源的考慮，將項目捐獻給 Apache 基金會。
 
TubeMQ 的後續發展，仍將繼續圍繞系統的穩定性、性能與低成本展開，同時計劃依靠社區力量共建 TubeMQ 項目，進一步完善項目，將 TubeMQ 接入到不一樣的上下游，融入大數據生態圈等，最終幫助到這塊有須要的團隊，促進項目的推廣使用。
 
陳思宏：《MedicalNet：3D 醫療影像專用預訓練模型實踐與應用》
 
騰訊高級研究員陳思宏在演講中介紹了醫療影像 AI 的基本概念，MedicalNet 與醫療影像 AI 行業痛點之間的關係，並針對 MedicalNet 的技術實現過程進行了講解。
 
醫療影像 AI 實際上解決的是「患者看病難，醫生診斷累」的全球廣泛問題。
 
因爲培養投入大，週期長，醫護人員的數量在短期內很難大幅度增長，而人工智能技術能夠輔助醫療工做，緩解當前醫護資源不足的情況。人工智能對於醫療領域來講，主要有兩個做用，一個是進行人羣基礎篩查，另外一個是提高診斷質量。對於一些簡單的疾病，人工智能能達到較高的診斷性能，用於人羣疾病初篩的工做上，在必定程度上緩解缺少醫護人員的問題。而一些治療難度較高的疾病，人工智能能夠爲醫生診斷提供參考依據，起到提醒做用。
醫療影像包含豐富的診斷信息，是醫療診斷中很是常見的手段。醫療影像 AI 的「製造」方法以下：收集標註數據，再經過這些數據來訓練人工智能模型，最終實如今系統中輸入患者影像，得到接近資深醫師的診斷結果。
 
近年來，圖像與視頻識別軟件的發展，爲醫療影像 AI 提供了很大幫助。但醫護人員資源有限，標註數據成爲了困難，致使可用於訓練的同分布標註數據很是少，與數據驅動的深度學習造成矛盾，這就是目前醫療影像 AI 的發展瓶頸所在。
 
所以對於醫療影像 AI 的研究來講，亟需找到大規模數據集以及相應的模型，爲大部分小數據醫療影像AI應用提供信息支持，而這也正是開發 MedicaNet 的動機。
儘管每一個同分布的醫療 3D 公開數據集數據量小，但多個醫療場景的數據集集合起來能造成較大規模數據集，MedicaNet 開發團隊就將這些場景的數據集收集起來，用來訓練不一樣的預訓練模型，再開源相關預訓練模型。這樣一來，當有用戶須要訓練一個新模型時，就能夠直接用 MedicaNet 模型進行遷移學習，即使新應用中數據量較小，用戶最終仍舊能夠訓練出模型。
 
不過，在 MedicaNet 的實現過程當中，也確實遇到了很多難題須要經過技術來解決，其中包括像素含義不一，範圍差別大，僞影頻繁，成像質量低，邊界模糊，對比度低；不一樣源數據，標註缺失；同一組織分辨率不一致，不一樣組織尺度差別大等等問題。
 
MedicaNet 開發團隊主要經過兩個方案來解決這些難題。首先是數據集篩選方案，主要目的是找出具有共通知識的數據集。具體作法以下：從每種場景的數據集中挑選少許數據，造成迷你數據集代理，經過代理快速訓練成小網絡，最後根據迷你數據集分割預測結果的好壞判斷哪些數據集可以保留下來。
 
篩選完數據集以後，採用聯合訓練方案進行訓練。先對數據進行空間和像素歸一化預處理。爲了獲取更多標註信息，MedicalNet 所有采用分割數據集。MedicalNet 由編碼和解碼部分組成，編碼部分爲開源的模型。爲了將更多的信息集中在編碼部分，因此就把大部分參數都集中在了編碼中。爲解決數據集與數據集之間標註不統一的問題，在解碼部分使用多任務形式對多個場景的標註數據進行隔離。在訓練過程當中，不一樣的 skip-connection 組合用於緩解梯度消失問題。訓練完成後，編碼部分可遷移到任意分割、分類以及檢測等多種任務的模型中。
 
最終的實驗結果證實，在 3D 醫療影像應用中，MedicalNet 能幫助小數據場景的網絡加快收斂速度，提高預測性能。
  
 
田甜：《Tars 與 GRPC 實戰場景應用》
 
Tars-Go 早期發起人及核心開發成員、騰訊高級工程師田甜在演講中主要分析了 Tars 與 GRPC 的架構體系及框架應用設計，並分享了在 Service Mesh 上的一些探索，爲微架構的設計工做提供選型思路與技術參考。
 
Tars 是騰訊從 2008 年至今一直在使用的後臺邏輯層的統一應用框架 TAF，是一個支持多語言，內嵌服務治理功能，與 DevOps 能很好協同的微服務框架，可幫助業務快速完成開發、部署、測試、灰度、上線。
 
目前的開源微服務框架能夠分爲四類，分別爲無服務治理，專一於通訊框架，RPC 或消息隊列模式，部分框架支持多語言開發；Service Mesh，支持服務治理，經過 Sidecar 模式解決多語言問題，目前處於發展成熟期；單語言帶服務治理類，在通訊框架的基礎上支持服務治理能力，單一編程語言實現，Java 語言爲主流；多語言帶服務治理類，主要爲 Tars，可在通訊框架的基礎上支持服務治理能力及多種編程語言。
 
Tars 的總體架構能夠分爲 DevOps、OSS、開發框架、語言等幾個部分，其中與 DevOps 相關的主要包括代碼管理、代碼編譯、自動化測試等等；OSS 主要是一些服務治理以及支持協議，包括負載均衡、熔斷、服務配置等等；在語言這部分主要支持 C++、Java、Node.js、PHP、GO 等等，將來還將拓展更多語言。
 
接着來看看 GRPC，GRPC 是谷歌發起的一個開源遠程過程調用系統，基於 HTTP/2 協議傳輸，使用 Protocol Buffers 做爲接口描述語言。Protocol Buffers 是谷歌推出的序列化框架，與開發語言、平臺無關，具備良好的可擴展性。Protocol Buffers 與全部的序列化框架同樣，均可以用於數據存儲、通信協議。
 
GRPC 的總體架構相對比較簡單，但若是要上線應用的話會有些困難，所以騰訊相關團隊採用了 GRPC 框架以後還作了不少事。好比腳手架生成代碼，經過腳手架自動生成可運行的框架服務代碼，業務只需填充業務邏輯實現；自動服務註冊，框架提供自動和手動的服務註冊，UI 管理服務實例的上下線；內置基礎服務中間件，日誌服務、服務調用跟蹤服務、基礎 ACL 實現、實時報表 Panic 恢復等內置在服務中間件；多語言客戶端代碼 & 服務端代碼生成，經過描述文件一鍵生成多語言客戶端和服務端代碼；HTTP、GRPC 協議互轉，服務同時提供 HTTP 和 GRPC 兩種協議出口，對應一套邏輯代碼；經常使用服務的 SDK 實現，訪問部門內、公司內的經常使用組件 SDK 化，下降使用成本。
 
上述這些內容主要都依賴於 PB 插件與 GRPC 攔截器實現，PB 插件可以自定義代碼生成規則，經過攔截器能夠實現微服務須要的主要功能，包括遠程日誌、監控上報、鏈路追蹤、鑑權服務、服務發現等等。
 
最後是 Service Mesh。Service Mesh 是一個相對底層的架構，能夠直接從底層去作一些鏈路追蹤等事情，這樣的應用下沉實際提升了適用性。傳統架構與 Service Mesh 架構相比，服務直連架構主要利用內嵌服務的代碼框架提供高性能的服務基礎設施，而 Service Mesh 架構可實現代碼零改動，以 Sidecar 代理網絡通訊的方式知足應用程序多樣化需求。
將來，傳統框架將會繼續存在，只是功能將會更加業務化。使用 Tars 能夠擁有完整的微服務體系，而使用 GRPC 則須要自行建設周邊體系。Service Mesh 會逐漸吸取框架的能力並慢慢進行替代，Service Mesh 技術將會持續下降微服務的治理成本，可是會讓網絡架構變得更加複雜，這也是下一代網絡架構的切入點。

 
近年來，騰訊在開源上的步伐不斷加快。截至 2019 年 12 月，騰訊共對外開源了 92 個項目，包含微信、騰訊雲、大數據、遊戲、AI、安全等領域，累計在 GitHub 上得到了超過 26 萬 Star，在全球開源企業的 Star 數排名中位居前列。
 
在不斷貢獻優質項目之餘，騰訊也積極貢獻開源社區，發揮中國科技企業的力量。截至目前，騰訊已加入 Linux、Apache 等 9 大開源基金會，深度合做成爲最高級別會員，並向開源基金會捐贈 3 大優秀開源項目。騰訊還積極參與各大基金會已有的開源項目建設，並作出重要貢獻。
 
雲+社區技術沙龍是「雲+社區」策劃主辦的線下技術沙龍活動，但願經過分享技術讓更多開發者學習和交流，成爲騰訊雲鏈接開發者的平臺，共同打造技術影響力。每期沙龍將圍繞不一樣的技術領域和方向，是開發者彙集和喜好的分享交流平臺。
2020 年會舉辦更多主題沙龍活動，請留意主辦方「雲+社區」相關動態信息。