12月21日，由腾讯云云+社区和腾讯对外开源管理办公室联合主办的技术沙龙在深圳腾讯大厦成功举办。本期活动的主题为「腾讯开源技术」，多位来自腾讯的开源技术专家及工程师围绕KonaJDK、TencentOStiny、TubeMQ等开源项目的开发过程，分享了腾讯在开源之路上取得的最新成果以及过程中所积累的实践经验，并深入探讨了开源技术在大数据、物联网、医疗等不同场景下的发展趋势。
杨晓峰：《KonaJDK在腾讯大数据领域的实践和发展》
腾讯专家工程师、TEGJDK团队负责人杨晓峰，在演讲中简要介绍了KonaJDK项目的缘起，分析了当前OpenJDK的技术发展热点，以及国内该领域的发展状态和趋势，对KonaJDK在腾讯大数据领域的需求痛点、实践心得以及未来发展进行了分享。
OpenJDK是JavaSE标准的免费和开源参考实现。年，Sun公司承诺逐步开源核心Java平台。年，Redhat公司加入，并发布了IcedTea。年，Oracle收购Sun并接过了项目领导工作，IBM2、SAP等厂商陆续加入。年，JDK8发布，成为采纳速度最快以及接受程度最高的版本。年，JDK9发布并随后确立了半年周期发布模式和新的收费模式。年，TencentKona宣布开源。
TencentKona具有这样几个特质，首先免费，使用零成本，其次腾讯会提供长期可靠的支持，第三生产就绪，它经过了腾讯内部超大规模的生产环境的考验。而腾讯也将在未来秉承「最大化兼容性」，「逐步贡献大数据、云计算等领域先进特性」等原则，积极拥抱开源，持续贡献社区。
从目前国内的JDK产品应用来看，OracleJDK仍占约70%，OpenJDK占21%但快速崛起中。从版本的维度，JDK7/8仍为主流，但值得注意的是，JDK11已经得到一定规模的生产实践，国内厂商在JVM新技术革新与落地方面越来越深入与自信。
聚焦于大数据领域，目前Java/JVM是当之无愧的无冕之王，这主要是得益于JVM具备的高生产力、高性能、高可靠性等优点，提供了完美的跨平台能力、完善的工具、海量的类库和框架等。
但在腾讯大数据海量、苛刻的技术场景中，目前JVM的能力短板，逐渐成为了部分前沿场景的瓶颈，体现在集群规模、SLA、内存密度等多个方面。经典GC与特定应用场景存在错配，诊断和调优设施仍有较大的能力不足。
与此同时，现代硬件日新月异，JVM是当前算力的保证，但仍需要大量改进工作，才能更高效地利用向量化等技术，支撑未来持续性能提升的需求。
腾讯将从多个技术层面持续进行JVM优化，改进相应的工具等，打造领域最佳Java运行环境和解决方案。
叶丰：《基于TencentOStiny开源项目的实践──从零快速打造IoT小应用》
腾讯工程师叶丰在演讲中主要介绍了TencentOStiny的项目背景、软件架构、IoT解决方案、开发实践等内容。
TencentOSTiny是腾讯开源的面向物联网领域的精简实时操作系统，它是腾讯物联网产品矩阵底层的关键一环，作用是为云侧海量数据平台进行引流，降低开发门槛，提升开发效率，使物联网终端设备及业务能快速接入腾讯云物联网平台。
从TencentOStiny的架构来看，它已经适配了主流的芯片和模组，提供了最精简的RTOS内核，以及丰富的物联网组件，集成了主流的物联网协议。TencentOStiny具有小体积、低功耗、丰富的IoT组件、可靠的安全框架、良好的移植性、便捷的调试手段等特点，能够满足物联网的差异化需求。
TencentOStiny是今年9月18日正式开源的，发布一周时间就成为了GitHub开源项目热榜排行第二名，目前已获得Star+、Fork+，目前已与国内外主流MCU及硬件厂商合作，支持的硬件平台数已经超过了50个。
腾讯TencentOStiny目前也有一些落地的物联网解决方案，比如智能货柜解决方案与智慧种植解决方案。
在智能货柜解决方案中，TencentOStiny配合中控系统和AI识别服务，完成了扫码开柜、取物、关门自动结算流程，构建了一个无人售货的场景。针对真实场景中不可控的情况，比如由于货物的部分遮挡导致AI识别率降低等，TencentOStiny提供更多的感知能力：如重力感应等，辅助AI做决策，提高了AI的识别率。
而在智慧种植解决方案中，TencentOStiny主要服务于两个环节──即环境感知侧与调节控制侧。环境感知侧通过采集温湿度、土壤酸碱度、含氧量等环境数据，并上报到IoT云平台，云端的决策算法根据环境数据作出相关的温室调节指令，最终由调节控制侧完成温室环境调节。同时TencentOStiny采用了多方案网络适配，支持WiFi/NB-IoT/Lora，实现链路全加密，保证数据安全。
此外，为了更深入地了解TencentOStiny，现场结合TencentOStiny定制开发板，完成了一个小型的端到端农业场景开发实践，包括环境感知，设备控制，数据上云，小程序对接。使用TencentOStiny可以简化设备端开发，同时结合腾讯云物联网平台和小程序云开发，能够实现物联网解决方案的快速、低成本的上线和迭代。
张国成：《TubeMQ的Apache之路》
腾讯高级工程师、TubeMQ项目负责人张国成在演讲中阐述、分析了万亿级消息中间件TubeMQ的相关实现原理，并分享了针对项目后续发展方向等问题的思考。
TubeMQ是来自腾讯的万亿级分布式消息中间件，专注于海量数据场景下的存储和传输，在稳定性、性能和低成本方面具有独特优势。通过我们实际应用场景定义的大数据场景测试方案测试，TubeMQ可支持14万TPS的吞吐量，消息延时能控制在10毫秒，甚至是5毫秒以内；系统已在公司内部持续迭代改进了7年时间，广泛应用于实时广告推荐、海量数据上报、数据流处理、指标监控等场景。
TubeMQ系统架构的关键特点包括纯Java实现、有MasterHA协调节点、弱化zk、offset管理去中心化、支持服务端过滤、改进了消息存储模式、调整了基于磁盘RAID10多副本+快速消费，而非多Broker节点多副本的数据可靠性方案等。
持续增长的接入量压力是腾讯自研TubeMQ的内在动因：在数据量级很少，比如10亿量级或以下时，用什么消息队列都没问题，但数据到了百亿、千亿、万亿量级甚至以上的时候，就会出现很多制约因素，比如成本、稳定性、性能等，TubeMQ的日均接入量从年初的亿到年11月的35万亿，这期间腾讯的消息队列经历了从引入到改进再到自研的实践过程。
TubeMQ于今年9月在ApacheCon上宣布开源并捐献给了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的架构体系及框架应用设计，并分享了在ServiceMesh上的一些探索，为微架构的设计工作提供选型思路与技术参考。
Tars是腾讯从8年至今一直在使用的后台逻辑层的统一应用框架TAF，是一个支持多语言，内嵌服务治理功能，与DevOps能很好协同的微服务框架，可帮助业务快速完成开发、部署、测试、灰度、上线。
目前的开源微服务框架可以分为四类，分别为无服务治理，专注于通信框架，RPC或消息队列模式，部分框架支持多语言开发；ServiceMesh，支持服务治理，通过Sidecar模式解决多语言问题，目前处于发展成熟期；单语言带服务治理类，在通信框架的基础上支持服务治理能力，单一编程语言实现，Java语言为主流；多语言带服务治理类，主要为Tars，可在通信框架的基础上支持服务治理能力及多种编程语言。
Tars的整体架构可以分为DevOps、OSS、开发框架、语言等几个部分，其中与DevOps相关的主要包括代码管理、代码编译、自动化测试等等；OSS主要是一些服务治理以及支持协议，包括负载均衡、熔断、服务配置等等；在语言这部分主要支持C++、Java、Node.js、PHP、GO等等，未来还将拓展更多语言。
接着来看看GRPC，GRPC是谷歌发起的一个开源远程过程调用系统，基于HTTP/2协议传输，使用ProtocolBuffers作为接口描述语言。ProtocolBuffers是谷歌推出的序列化框架，与开发语言、平台无关，具有良好的可扩展性。ProtocolBuffers与所有的序列化框架一样，都可以用于数据存储、通讯协议。
GRPC的整体架构相对比较简单，但如果要上线应用的话会有些困难，因此腾讯相关团队采用了GRPC框架之后还做了很多事。比如脚手架生成代码，通过脚手架自动生成可运行的框架服务代码，业务只需填充业务逻辑实现；自动服务注册，框架提供自动和手动的服务注册，UI管理服务实例的上下线；内置基础服务中间件，日志服务、服务调用跟踪服务、基础ACL实现、实时报表Panic恢复等内置在服务中间件；多语言客户端代码服务端代码生成，通过描述文件一键生成多语言客户端和服务端代码；HTTP、GRPC协议互转，服务同时提供HTTP和GRPC两种协议出口，对应一套逻辑代码；常用服务的SDK实现，访问部门内、公司内的常用组件SDK化，降低使用成本。
上述这些内容主要都依赖于PB插件与GRPC拦截器实现，PB插件能够自定义代码生成规则，通过拦截器可以实现微服务需要的主要功能，包括远程日志、监控上报、链路追踪、鉴权服务、服务发现等等。
最后是ServiceMesh。ServiceMesh是一个相对底层的架构，可以直接从底层去做一些链路追踪等事情，这样的应用下沉实际提高了适用性。传统架构与ServiceMesh架构相比，服务直连架构主要利用内嵌服务的代码框架提供高性能的服务基础设施，而ServiceMesh架构可实现代码零改动，以Sidecar代理网络通信的方式满足应用程序多样化需求。
未来，传统框架将会继续存在，只是功能将会更加业务化。使用Tars可以拥有完整的微服务体系，而使用GRPC则需要自行建设周边体系。ServiceMesh会逐渐吸收框架的能力并慢慢进行替代，ServiceMesh技术将会持续降低微服务的治理成本，但是会让网络架构变得更加复杂，这也是下一代网络架构的切入点。
近年来，腾讯在开源上的步伐不断加快。截至年12月，腾讯共对外开源了92个项目，包含