云+社区技术沙龙丨解析腾讯最新开源项目背后的技术栈

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 并接过了项目领导工作，IBM2、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 年会举办更多主题沙龙活动，请留意主办方「云+社区」相关动态信息。