首页 文章 精选 留言 我的

精选列表

搜索[开启]，共10000篇文章
优秀的个人博客,低调大师

安卓定制系统IUNI OS开启公测 仅支持三星S4

2月17日上午消息，由金立投资的移动互联网品牌IUNI今日正式宣布启动IUNI OS公测，这是一款基于Android系统二次开发的手机操作系统，界面清爽，第三方应用零预装，将于24日提供下载，首批仅支持三星I9500机型。 IUNI OS是一款基于Android定制开发的ROM，该系统界面简洁、色彩清新淡雅，扁平化风格浓重。为了保证界面风格统一，首批设计了1000个第三方应用图标。同时，设计团队也为IUNI OS设计了诸多转场动画，包括每一次点击等待。 IUNI OS界面主要以横向分页屏组成，不过也隐藏了所有程序列表，在底部Dock区域从从右往左滑动可以调出“全部APP”的界面，以首字母A-Z排序，支持检索功能。同时，引入类似iOS控制中心的上拉界面，集成了诸多功能开关快捷键以及后台程序列表。 另外，在现场体验搭载IUNI OS的三星GALAXY S4手机时，我们也发现IUNI虽然是第三方ROM，但是兼容性表现不错，保留了三星部分特色功能，如智能屏幕、屏幕模式、省电模式等。 而该系统在去年首次露面时提出“生来纯净”的概念，系统第三方应用零预装，以保证应用的选择权完全在用户手里。IUNI科技经理何骁军表示，目前市场上大量的第三方应用预装，从本质上只是厂商自身商业图利行为，更消费者的需求无关。 IUNI OS此前已经推出五个内测版本，前期有200多位用户参与测试，而在本月24日开放下载后，将会经历大规则的用户考验。目前，首个公测版仅支持三星I9500，未来将适配包括小米3以及三星GALAXY Note 3的热门安卓手机。 除此之外，在此次发布会上也有消息透露，搭载IUNI OS的IUNI手机将于3月正式发布。 IUNI是由金立投资的独立互联网品牌，其产品主要以系统及手机终端为主，号称“以小米反小米”，将复制小米的互联网模式，渠道以电商和网络商城为主，据悉团队规模约100多人，均拥有互联网背景。 文章转载自 开源中国社区 [http://www.oschina.net]
2017-06-03
优秀的个人博客,低调大师

B850 AORUS ELITE-P ICE 主板首发特典活动开启

想要颜值与性能一步到位的玩家，现在有了绝佳选择。技嘉全新B850 AORUS ELITE-P ICE雕妹主板已登陆京东自营旗舰店，二次元颜值与硬核性能兼得，首发入手还能解锁专属特典。 作为雕妹系列首款 ATX 白色主板，它拥有 16+2+2 相供电设计，全面适配 AMD AM5 锐龙 9000 系列处理器。还有X3D 鸡血模式一键选择合适的性能优化，处理器性能最高提升 18%；再配合D5 黑科技 2.0，DDR5 内存超频可达 8200 MT/s，小白也能轻松上手一键超频。外观方面，纯白板身搭配LCD Edge View，睡衣雕妹眨眼动画点亮整机氛围。扩展同样厚道：4 条 M.2 插槽（含 1 条 PCI-E 5.0）、PCI-E 5.0 x16 金属加固显卡插槽和PCI-E 4.0 x4 插槽齐备。M.2 / 显卡 / WiFi 全部搭载技嘉快易拆设计，装机体验大幅升级。 现在入手更有满满福利。2026年7月20日20:00:00至8月31日23:59:59，在指定店铺购买这块主板，通过“AORUS俱乐部”小程序绑定产品，即可申请首发特典（包含雕妹擦手巾与睡衣雕妹抱枕），限量100份。前20名成功申请者，额外加赠“睡衣雕妹礼包”（内含雕妹吨吨杯及雕妹鼠标垫）。 萌力满载，现在即是购入最好时机！
2026-07-24
优秀的个人博客,低调大师

curl 项目即将开启“幸福之夏”，创始人宣布 7 月停止接受漏洞报告

开源世界最核心的基础设施之一——curl 项目，其创始人兼首席维护者 Daniel Stenberg 今日宣布了一项不同寻常的决定：curl 项目将在整个 2026 年 7 月暂停接受漏洞报告，这段时间被命名为"curl summer of bliss"（curl 幸福之夏）。这不是玩笑，也不是对安全的不重视，而是一个被持续高压压垮的开源维护者发出的求助信号。 curl 是什么？几乎每一台联网设备都在使用它。从路由器固件更新到汽车车载系统，从 Android 手机到云服务器，curl 是互联网数据传输的隐形骨架。这个被全球数十亿设备依赖的库，其核心维护团队实际上只有寥寥数人，而 Daniel Stenberg 本人已经在这个项目上工作了超过四分之一个世纪。 "过去大约四个月里，我承受着巨大的压力，以远超正常节奏的速度工作。"Stenberg 在博客中写道。这种压力并非来自单一事件，而是多个因素的叠加：curl 8.21.0 版本发布带来的问题、一系列需要修复的安全漏洞，以及大量积压的 GitHub issues 和 PR。对于一个小型开源维护团队来说，这种持续的高强度运转是不可持续的。 具体的安排是：从 2026 年 7 月 1 日到 8 月 3 日，curl 的 HackerOne 漏洞提交表单将被暂停，安全邮件列表也将被忽略。这一决定实际上是给 curl 的维护者们放一个真正的假期——不查看安全报告，不处理漏洞，不回应任何安全相关的邮件。这是维护者们为自己争取的一个喘息窗口。 与此同时，curl 8.22.0 版本也被推迟两周，从原定的 8 月中旬延后到 9 月 2 日发布。"我们需要时间恢复精力，"Stenberg 解释道，"这样才能以更健康的状态回归。"这种公开承认需要休息的姿态，在开源维护者中并不多见。更多的维护者选择默默退出，留下一封冰冷的弃坑邮件，或者干脆不辞而别——这在开源社区被称为"维护者倦怠"，是近年来困扰整个开源生态的顽疾。 值得注意的是，curl 项目并不会在此期间完全封闭。GitHub 上的 issues 和 pull requests 依然开放，代码贡献可以正常进行。商业支持合同的客户也不会受到影响——付费客户仍然可以获得完整的服务。这个区别很重要：curl 暂停的是无偿的安全响应工作，而非付费的商业服务。这实际上暴露了开源生态中一个根本性的矛盾：全球最大的科技公司都在免费使用 curl，但当维护者需要休息时，他们找不到人顶替。 Stenberg 的博客评论区中有开发者指出，curl 的处理方式实际上为整个开源社区提供了一个值得借鉴的模板。与其等到维护者彻底崩溃或愤而退出，不如主动规划休息时间，设立明确的边界。这听起来像是常识，但在"你的代码被数十亿人使用"的压力下，说"不"需要巨大的勇气。 当 curl 这样的基础设施项目的维护者公开说"我累了"时，整个技术行业都应该认真倾听。这不仅仅是一个休假公告，更是一个关于开源可持续性的警钟。如果连互联网最关键的组件之一的维护者都找不到合理的休息方式，那么整个开源生态的健康状况就值得担忧了。curl 的幸福之夏，或许是开源社区需要的一场关于人性化维护的对话的起点。 参考来源：curl summer of bliss - daniel.haxx.se
2026-06-15
优秀的个人博客,低调大师

玲珑商店社区版 2.0 时代开启 ！支持十余款发行版玲珑环境自动安装

如意玲珑应用商店社区版2.1.1已正式上线！ 由Linyaps Simple Store SIG团队打造的如意玲珑应用商店社区版2.1.1 版本正式发布。这是 2.0 系列的成熟稳定版，从内到外全面升级——Tauri 框架、性能优化、安装包精简、全新UI……一句话总结：更快、更轻、更好用。 2.0 系列核心亮点：不只是升级，是蜕变 全新UI重构，颜值与体验双在线 告别老旧界面，2.0 系列带来了现代化的视觉设计。更清晰的布局、更流畅的动画、更直观的操作逻辑——浏览、搜索、安装，一气呵成。 Tauri 框架加持，体积更小、性能更强 从 Electron 迁移到 Tauri 框架，这是一次技术架构的飞跃： 安装包体积大幅精简，下载更快、占用更少； 启动速度显著提升； Rust底层保障，安全性更高； 跨平台能力更强，为更多发行版适配打下基础。 功能全面升级，细节见真章 新增应用详情截图——安装前先看图，告别盲装； 新增应用启动功能——商店内一键启动已安装应用； 安装应用指定版本——版本轻松切换，一目了然； 基础设置与应用管理——查看进程、缓存清理、版本管理尽在掌控。 7000+ 应用等你探索 目前已收录超 7000个多场景玲珑应用，覆盖办公文档、游戏娱乐、开发工具、网络应用、AI工具……无论你是办公、开发还是娱乐，这里都有你想要的。 王炸功能：装商店 + 装环境，一次搞定 重点来了！2.0 系列最炸裂的功能——自动安装玲珑运行环境。 什么意思？ 以前，想在非 deepin 系统上用玲珑应用，你得先手动安装玲珑环境，步骤繁琐还容易踩坑；现在，只需要安装玲珑应用商店社区版 2.0 系列，它会帮你自动搞定玲珑环境！ 支持哪些发行版？ 目前已支持自动安装 10+主流 Linux 发行版的玲珑运行环境（包括 X86 和 ARM 架构）： 注意：1. UOS 20（1070）安装时需打开“开发者模式”；2. 以下两个发行版仍需要手动安装玲珑环境。 NixOS：需要手动配置，参考NixOS官方文档； 银河麒麟 V10：需要手动安装，请关闭安全中心对应用安装的限制。 部分发行版的玲珑环境由玲珑跨发行版 SIG的开发者们维护，感谢他们的贡献！ 如你也对玲珑发行版移植感兴趣，欢迎加入他们： https://linyaps.org.cn/linyaps-generic-linux-sig 安装有多简单？推荐使用安装器 一条命令，全自动安装玲珑应用商店社区版（玲珑格式）+ 如意玲珑运行环境： curl-fsSLhttps://gitee.com/hanplus/linglong-installer/releases/download/latest/linglong-store-installer.sh * LLI_PREFER_PKEXEC=1 bash 安装器会自动检测系统环境和架构，下载安装对应版本的玲珑运行环境和玲珑商店。 多种传统格式安装包，总有一款适合你 deb / rpm 格式安装也会自动下载安装玲珑运行环境： 具体安装介绍可查看玲珑社区官网 玲珑商店社区版安装说明 https://linyaps.org.cn/linyaps-appstore 提示：因 Tauri 2.0 框架对系统 glibc 版本要求较高，glibc 版本较低的系统（如UOS 1070）请使用安装器安装，玲珑版本的商店已针对性地解决了 Tauri 框架的依赖与 glibc 兼容性的问题。 项目地址 GitHub：https://github.com/SXFreell/linglong-store Gitee：https://gitee.com/Shirosu/linglong-store 如意玲珑商店极速版 另外，如果你的电脑性能巨差，或者你就是追求极致的速度，也可以安装由 SIG 开发者@mozixun 独立维护的如意玲珑商店极速版，同样支持 deb、rpm 两种格式、X86 及ARM 架构的下载： 下载地址：https://gitee.com/LFRon/Linyaps-Store-Minimalist/releases/latest
2026-02-13
优秀的个人博客,低调大师

【Xinference v0.13.1 正式发布】一键部署 AI 模型，开启智能推理新纪元！

Xorbits Inference（Xinference）是一个 性能强大且功能全面的 分布式 推理框架。可用于大语言模型（LLM），语音识别模型，多模态模型等各种模型的推理。通过 Xorbits Inference，你可以轻松地 一键部署你自己的模型或内置的前沿开源模型 - https://github.com/xorbitsai/inference。无论你是研究者，开发者，或是数据科学家，都可以通过 Xorbits Inference 与最前沿的 AI 模型，发掘更多可能。 Xinference的功能和亮点有： 🌟 模型推理，轻而易举：大语言模型，语音识别模型，多模态模型的部署流程被大大简化。一个命令即可完成模型的部署工作。 ⚡️ 前沿模型，应有尽有：框架内置众多中英文的前沿大语言模型，包括 baichuan，chatglm2 等，一键即可体验！内置模型列表还在快速更新中！ 🖥 异构硬件，快如闪电：通过 ggml，同时使用你的 GPU 与 CPU 进行推理，降低延迟，提高吞吐！ ⚙️ 接口调用，灵活多样：提供多种使用模型的接口，包括 OpenAI 兼容的 RESTful API（包括 Function Calling），RPC，命令行，web UI 等等。方便模型的管理与交互。 🌐 集群计算，分布协同: 支持分布式部署，通过内置的资源调度器，让不同大小的模型按需调度到不同机器，充分使用集群资源。 🔌 开放生态，无缝对接: 与流行的三方库无缝对接，包括 LangChain， LlamaIndex， Dify，以及 Chatbox。 🎉 Xinference v0.13.1 正式发布！ - 新增内置支持模型 📦 - glm4-chat gguf格式 📝 - 新功能 🚀 - 注册自定义模型接口可支持指定worker_ip。现在配合launch模型接口的worker_ip参数，可以在分布式场景下仅在一个worker上传模型文件，然后部署使用 🌐 - Launch模型接口支持download_hub参数，以最高优先级控制从哪里下载模型 📥 - 全新 Flexible 模型，支持部署任意模型（文本分类，情感识别等等），下个版本将发布相关使用文档 📚 - 移除对chatglm-cpp的支持，移除chatglm chatglm2 chatglm3的ggmlv3老模型格式的支持。glm系列推荐使用glm4。后续将持续移除一些ggmlv3的老模型 🗑️ - 移除对LLM模型create_embedding的支持 ❌ - BUG修复 🐛 - 修复chatTTS的若干问题。现在直接使用chatTTS自身的依赖，更加可靠 🔧 - 修复GPU docker镜像中无法安装最新版llama-cpp-python的问题。目前仅CPU docker镜像中因其自身问题仍保持旧版llama-cpp-python 🐍 - UI相关 💻 - 修复记忆上一次launch参数功能的一些问题 📝 - 修复一些模型页面上无法显示是否已cache的问题 📊 - Launch页面可选配置中可以选择模型下载来源 🔄 我们感谢每一位参与的社区伙伴对Xinference的帮助和支持，也欢迎更多使用者和开发者参与体验和使用Xinference。 欢迎您在https://github.com/xorbitsai/inference 给我们一个 星标，这样你就可以在GitHub上及时收到每个新版本的通知。
2024-07-18
优秀的个人博客,低调大师

云原生✖️ AI 时代的微服务架构最佳实践—— CloudWeGo 技术沙龙·上海站报名开启

活动介绍 CloudWeGo 开源两年多以来，社区发展迅速，生态日益丰富，落地企业用户已超过 40 家，涵盖 AI、电商、金融、游戏 、互联网等多个行业。同时，随着云原生技术和 AI 技术的持续蓬勃发展，我们发现企业用户也面临着越来越多性能、成本和稳定性方面的挑战，系统需要支持弹性伸缩和潮汐流量下的稳定性，因而也越发需要一套高性能、易扩展、功能丰富的微服务架构。 诚挚邀请企业用户和开发者共同参与 CloudWeGo 技术沙龙。活动将于2024年5月25日（周六）在上海举办，邀请广大技术同仁共同探讨在 云原生 xAI 浪潮之下，企业如何构建云原生微】服务架构，来支持产品的快速迭代与发展。 时间：2024年5月25日（周六）14:00-17:00 地点：上海 · 漕河泾中心D栋F2 议题简介 本次活动分享议题将聚焦 CloudWeGo 相关技术功能实现，以及如何借力 CloudWeGo 开源项目帮助企业构建微服务等议题，将携手 CSDN 、infoQ、稀土掘金、火山引擎开发者社区、字节跳动技术团队作为合作伙伴同步进行宣传和直播。多位 CloudWeGo 社区 Maintainer 和 Committer 将分享包括微服务框架的对比和落地实践，以及基于 cwgo 代码生成工具的工程化实践等主题。另外我们还邀请了多位 CloudWeGo 的用户代表进行分享他们基于 CloudWeGo 的落地实践经验等精彩话题。最后我们也会围绕微服务相关热点话题进行圆桌讨论，和现场观众进行互动。 主题演讲：微服务框架对比、测试与迁移 讲师：周启恒，CloudWeGo-Kitex Maintainer；李纪昀，CloudWeGo-Web&Doc Reviewer，CloudWeGo-Hertz Committer 大纲： CloudWeGo 提供了高性能、高可靠的 Go 语言 RPC 框架 Kitex 以及 HTTP 框架 Hertz，助力用户高效搭建完备的企业级微服务架构。本次分享中，我们将从功能和性能多方面对比 CloudWeGo 微服务框架与开源框架 ，展示 Kitex 与 gRPC，Hertz 与 Gin 的差异与优势。此外，我们将分享关于框架迁移的操作实践和迁移的真实收益。 主题演讲：基于 Hertz 的微服务落地实践 讲师：初泽良，字节跳动西瓜视频研发工程师 大纲： Hertz 是一个 Golang 微服务 HTTP 框架，具有高易用性、高性能、高扩展性等特点。在本次演讲中，我们将介绍西瓜视频基于 Hertz 的微服务落地实践。我们将介绍西瓜视频微服务架构设计、Hertz 框架介绍、西瓜视频迁移 Hertz 过程及踩坑经验、落地 Hertz 后的收益。 主题演讲：从0到1基于 Kitex + Istio 的微服务系统建设 讲师：Jason，Construct 服务端总监 大纲： 在本次演讲中，我们将展示如何使用 Kitex 和 Istio 从0到1构建微服务架构，探讨技术栈和架构选择的理由及其实施细节。内容将包括系统兼容性策略、自动化流程、泳道以及通过监控和分布式追踪技术确保微服务可观测性和稳定性。 主题演讲：基于 cwgo 代码生成工具的工程化实践 讲师：王鑫, CloudWeGo-Hertz Committer；鹿瑞超, CloudWeGo-Hertz Reviewer 大纲： cwgo 是 CloudWeGo All in one 代码生成工具，整合了各个组件(hz，kitex)的优势，以提高开发者的体验。在本次演讲中，我们将从代码生成能力和工程化实践两方面介绍cwgo，了解如何通过使用 cwgo 简化代码生成过程和提高开发效率，实现工程化开发体验的提升。 圆桌讨论 主持人：罗广明 圆桌嘉宾：初泽良、Jason、周启恒 大纲： 微服务框架和中间件技术选型关注哪些方面？ - 浅谈开源框架的易用性和其带来的研发效率在业务团队的价值 - 浅谈 AI 对微服务框架演进和业务研发带来的影响 - 现场 Q&A 立刻报名 访问[活动页面]即可报名注册，参与现场互动还有机会获得社区精美周边礼品。了解更多 CloudWeGo 项目相关信息请访问 www.cloudwego.cn 或 github.com/cloudwego 期待您的参与！ 重磅，由字节跳动服务框架团队联合 CloudWeGo 开源社区出品的 《CloudWeGo 技术白皮书: 字节跳动云原生微服务架构原理与开源实践》 现已正式对外发布！本书总结了字节跳动自 2018 年以来的微服务架构演进之路，讲述了字节微服务架构的难点、编程语言的选择和开发框架的演进，以及流量激增后的流量治理模式和服务网格全面落地。白皮书中还详细介绍了电商、AI、金融、游戏相关行业的落地案例，同时探讨了在降本增效压力下微服务的性能提升和成本优化解决方案。下载地址： https://www.cloudwego.cn/zh/ https://www.cloudwego.io/zh/
2024-04-26
优秀的个人博客,低调大师

KCD 2023 杭州站报名通道开启！聚焦云原生供应链、AI 基础设施

KCD 首次来杭，现已开放报名通道！ 在现场，你可以亲眼见证云原生技术的变革！现场学习干货满满的技术分享！与各路技术社区达人交流！battle 共话「AI/云原生」新命题～ 10 月 21 日 14:00，KCD 2023 杭州站等你来！ KCD 2023 活动介绍 KCDKubernetes Community Days（KCD）由云原生计算基金会（CNCF）发起，由全球各国当地的 CNCF 大使、CNCF 员工以及 CNCF 会员单位联合组织。目前 KCD 正在全球各个国家活跃地组织进行中，KCD 聚集了来自云原生领域开源社区的最终用户、贡献者和技术专家，这一系列的活动有助于提高 Kubernetes 社区的活跃度并完善其发展潜力，使更多用户能接触到云原生信息，也推动云原生技术在不同行业中更广泛的传播。 KCD 杭州 杭州是中国东南沿海中心城市之一、浙江省省会。美丽的西湖成就了“上有天堂，下有苏杭”的千古美誉。而今天，这张名片，似乎已经被“电商之都”所取代。杭州凭借着互联网电商经济成为了炙手可热的新一线城市，同时也吸引了很多大型互联网公司，并且具有浓厚的技术氛围。本次也是 Kubernetes Community Days 首次来到杭州，由 CNCF、蚂蚁开源、龙蜥社区、Dragonfly 社区、Harbor 社区联合发起。希望能够在这座充满活力的城市进一步推广云原生相关技术。 KCD 杭州站主页：https://community.cncf.io/e/myjve4/ KCD 2023 活动报名中如果你想与社区大佬、技术大牛线下交流，欢迎扫码提前报名抢位～ 也可点击🔗https://www.bagevent.com/event/8715561直达报名通道！ 活动日程 时间：2023 年 10 月 21 日 14:00 地点：浙江省杭州市滨江区网商路 699 号阿里巴巴 2 号楼 2F AI 基础设施论坛 云原生供应链论坛 KCD 2023社区伙伴持续招募中 杭州站社区共创伙伴火热招募中，邀您共同推动全球云原生技术发展与传播，成为科技浪潮中的助推手和受益者。合作方式多样，欢迎来咨询哦～社区合作请联系：13167455321（微信同） 主页持续更新中……
2023-10-11
优秀的个人博客,低调大师

LFX Mentorship 2023年第一期实习开启：构建云计算的未来基石

新年快乐，兔飞猛进! 根据最近 CNCF 对2000多名 IT 专业人士的 2022 年度调查，WebAssembly 将成为云原生技术栈的一个关键部分。 该调查主要发现 容器是新常态，而WebAssembly是未来的趋势。 WasmEdge 项目是一个开源的 WebAssembly 运行时，为云原生应用场景进行了优化。已经与 Docker Desktop 和 Fedora / Red Hat Linux 集成并分发。通过带薪的 LFX / CNCF 实习计划为 WasmEdge 做出贡献，为你的简历和技能加上闪亮一笔！ 通过 LFX Mentorship 计划为像 WasmEdge 这样的CNCF托管的项目做贡献，你将获得： 丰厚报酬。金额从3000美元到6600美元不等，取决于你的所在地区 通过一对一的指导学习新的开发技能。如果你被选中，将分配到一个来自 WasmEdge 项目的经验丰富的 Mentor。 有机会获得顶级软件公司的工作机会 加入繁荣的开源社区，获得自豪感和成就感 现在就申请加入 WasmEdge 的 LFX Mentorship 计划，在开源领域做出成绩，并获得从3000到6600美元不等的报酬！ WasmEdge 简介 WasmEdge 是一个WebAssembly 运行时，特别为服务器端和云原生应用优化。它提供了许多独特的功能，对云计算至关重要。例如，支持 完整的 WebAssembly 规范，以及新兴的规范，如线程、GC 和组件模型。 Advanced networking 如 HTTP/S 客户端和服务器，数据库连接，消息队列连接。 基于流行框架的AI推理，如 Tensorflow，OpenVino，PyTorch 高级语言应用，包括 JavaScript、Python、PHP和 Ruby。开发者可以运行完整的node.js应用程序。 多种 APIs 用 Rust, Go,C/C++, JavaScript 创建 Wasm 应用。 多种 SDKs，将 WasmEdge 嵌入到现有的以其他语言编写的应用程序。 此外，WasmEdge 提供了一个灵活的插件架构 允许开发者为其添加更多功能，并通过广泛的开源合作伙伴充分发掘众多集成和分发渠道。通过我们的技术亮点发现 WasmEdge 的全部潜力。 WasmEdge 得到了云原生生态中主要开发者工具和部署平台的支持。例如，WasmEdge 与 Docker Desktop 集成并分发，覆盖超过 1000 万开发者。 Fedora、Red Hat Linux 和 OpenShift 容器平台上的默认 WebAssembly 运行时。 加入我们，共建云原生技术栈的未来！ LFX Mentorship 项目 （2023 年 3 月至 5 月） 这次我们有四个 mentee 空缺。 为了更好地协作，每个申请者需先完成预测试，本次预测试的截止时间是2月20日。 1. Stream data processing with WasmEdge 这个项目中，你将使用 WasmEdge Rust SDK 将 WasmEdge 嵌入到用 Rust 编写的 Fluvio 项目中。这是两个很棒的开源项目之间的合作。我们寻找的 mentee 需了解 Rust 和 WebAssembly Rust SDK 。 详情 | 预测试 | 申请链接 2. A Rust library crate for mediapipe models for WasmEdge NN AI 训练和推理等计算密集型任务始终适用于 Rust 和 WebAssembly。WasmEdge 希望构建一个 Rust 库 crate，从而在 WasmEdge 应用程序中轻松集成 Mediapipe 模型。在这个项目中，你应该为Mediapipe的每个模型建立至少一套库函数。每个库函数都接受一个 media 对象并返回推理结果。我们寻找的 mentee 需要有 Rust 知识和一些机器学习经验。 详情 | 预测试 | 申请链接 3. WasmEdge C++ SDK 这个项目中，你将帮助添加基于 WasmEdge C API的 WasmEdge C++ SDK。WasmEdge C++ SDK 让开发者能轻松地将 WasmEdge 嵌入到他们的 C++ host app 里。我们寻找的 mentee 需要有 C++ 和 WebAssembly 的知识。 详情 | 预测试 | 申请链接 4. Unified WasmEdge tools 命令行是开发软件最常用的工具，WasmEdge 提供了两个工具供开发者使用：wasmedgec 和 wasmedge。可是提供太多的工具会导致使用起来比较麻烦。因此在本项目中，你需要使用 wasmedge 帮助统一 WasmEdge 工具。这项工作将影响所有 WasmEdge 用户。他们将使用你开发的命令行来运行 Wasm 应用程序。我们寻找的 mentee 需要有 C++ 和 WebAssembly 的知识。 详情 | 预测试 | 申请链接 下一步是遵循mentee 指南，在2023年2月14日前完成申请并在2月20日前完成 pretest。 期待你的加入！ 如有问题可公众号后台留言或者加入我们的 Discord。 同时，可以加入2月7日的 WasmEdge 社区会议，议题之一是 LXF mentorship 答疑。 延伸阅读 了解 sonder-joker's journey on WasmEdge LFX mentorship 了解 gusye1234's journey on WasmEdge LFX mentorship
2023-02-06
优秀的个人博客,低调大师

众安保险 x StarRocks | 全新实时分析能力开启数字化经营新局面

作为国内⾸家互联⽹保险公司，众安保险是一家以技术创新带动⾦融发展的⾦融科技公司。区别于传统保险公司的运营模式，众安保险业务流程全程在线，全国均不设任何分⽀机构，完全通过互联⽹进⾏承保和理赔服务。目前已服务超5亿用户，2021 年总保费突破 200 亿元，同比增长 21.9%。 由“保险+科技”双引擎驱动，众安保险专注于应用新技术重塑保险价值链，围绕健康、数字生活、消费金融、汽车四大生态，以科技服务新生代，为其提供个性化、定制化、智能化的新保险。 在科技赋能保险的同时，众安保险将经过业务验证的科技对外输出，海外合作伙伴包括日本历史最悠久的财产保险公司 SOMPO、东南亚领先的 O2O 平台Grab、新加坡最大的综合保险机构 Income 等知名企业。 近年来，众安保险致力于加速数据价值向业务价值转化，促使数据要素带来业务的提质增效。这既需要专业技术团队+成熟的数字化体系，还需要技术具来提供智能化解决案。 本文将以众安集智平台基于极速 MPP 分析型数据库系统 StarRocks 的应用实践，讲解集智平台如何解决极速查询和高并发等数据问题，提升整体的数据支持能力。 行业背景 在传统的保险售卖场景中，保险公司主要通过承保利润和投资收益两部分获得盈利，⽽保险⾦融的⾏业特殊性致使保司对公司整体的数据、安全、⻛控等持有⾼度敏感性，因此一款保险产品从市场投放到销售、核保及理赔，每个环节都需要严格监测业务⾛向和数据变化。 并且随着时间的沉淀和业务拓展，保司所涉及和积累的相关数据越来越多，其中既包含保司⾃营的业务数据，也有合作渠道的电商销售、医疗健康等数据以及第三⽅的信贷评级、核保⻛控等数据。在⽇益激烈的市场竞争和技术变⾰这两⼤背景下，基于⼤数据、⼈⼯智能等技术的商业模式创新，以及数字化转型升级已经成为保险机构的必然选择。 因此在以上背景下诞⽣了专门针对保险⾦融⾏业的相关技术和产品，通过⼤数据、⼈⼯智能等相关技术加持，保障保司在每个业务环节中做到费⽤可控数据可经营的⽬的。常⻅的例如营销场景中的渠道投放、⽤户触达、活动监控；信贷场景中的授信、⽀⽤、还款、防⽌逆选择⻛险等场景。 当然⾯对保险⾦融⾏业如此⼤的数据量和业务复杂度，既有挑战也有机遇，但需要将这些数据进⾏充分整合并有效利⽤，才能更好地使其转换为企业⾃⼰的数据资产，从传统的运营⽅式过渡到数字化在线经营。让数字反映出真实的运营状况，及时控制产品⻛险和策略调整，以实现保费收⼊的正向利润，达到精细化运营。 ⽽众安作为全球⾸家以技术创新带动⾦融发展的互联⽹保险公司，在互联⽹+保险⾦融的双轮驱动下，全程通过互联⽹进⾏承保和理赔服务。在以上双重背景下诞⽣了数字化转型中专门针对业务数据管理和分析的系统产品——集智。 本⽂将以集智基于 StarRocks 全⾯升级数字化经营能⼒的真实使⽤场景为例，讲述集智如何通过 StarRocks 解决极速查询和⾼并发等数据问题，提升集智平台整体的数据⽀持能⼒和市场竞争⼒。 集智平台介绍 集智是众安的一款可视化智慧经营分析平台产品，集成了⼈⼯智能+商业智能+可视化数据仓库技术，智能整合来⾃不同场景的数据，规范企业数据池，完成繁杂的数据治理和智能决策环节。 集智秉着“助⼒企业实现智慧经营”的愿景和“从数据到价值，从看⻅到预⻅”的理念，依托丰富的可视化图表组件以及底层的⼤数据处理能⼒，实现零代码拖拽式分析与亿级数据的秒级响应，帮助企业战略规划⼈员、财务企划⼈员、销售管理⼈员、业务运营⼈员及数据⼈员等全⾯提升信息效率、资源效率及决策效率。 ⽬前在众安内部，数字⽣活、健康险、⾦融、直营、⻋险各个业务线，以及 HR、运管、⻛控等中后台部门，超过3000⼈都在使⽤集智平台，平均⽇活可达2000+，提升超过50%的数据分析效率，降低了公司40%的⼈⼒成本。 业务背景 一款好的数据分析产品离不开底层的数据引擎，集智平台的⼏⼤使⽤场景对底层的数据架构提出了不同的要求 可视化分析→需要有丰富的函数库⽀持不同类型图表的数据计算； 交互式分析→需要分析结果的快速响应来保障⽤户流畅的分析思路； 多维透视分析→需要⼤数据量的明细数据来⽀撑不同维度的筛选和下钻； 实时数据分析→需要⽀持数据的实时写⼊、实时查询。 针对上述的⼏个需求，我们在平台建设的初期选⽤了 ClickHouse 作为底层统一的 OLAP 引擎，数据链路如下： 离线的数据会通过 DataX 统一采集到 MaxCompute 或 Hive 数仓，在离线数仓内部完成数据 ETL 的⼯作，数据加⼯完成之后，再次经由 DataX 输出到 ClickHouse 中，ClickHouse 中的数据直接提供给看板或者第三⽅系统做数据查询。 实时的数据会通过 Binlog 监听或者⽇志采集⼯具同步到 Kafka，再经由 Flink 完成实时的数据 ETL，最终落到 ClickHouse 中。值得一提的是，这⾥为了应对一些业务场景中数据需要实时按主键更新的需求，我们采⽤了 ClickHouse 的ReplacingReplicatedMergeTree引擎。由于 ClickHouse 对数据更新操作的⽀持还不够成熟，因此在使⽤ Replacing 引擎的过程中遇到很多问题，这也是我们寻求新的 OLAP 技术选型的主要原因。 平台现状 集智上线后采⽤的是 ClickHouse，并且已经伴随业务运⾏了一段时间，但随着使⽤平台的⽤户⽇渐增多，业务⽅需要查询的数据量也越来越⼤，业务场景变得复杂后，很多特定场景 ClickHouse ⽆法满⾜，⾯对不同⼈员⾓⾊的需求时也遇到一些瓶颈。同时我们分别从业务⽤户的⾓度，以及平台运维的⾓度发现了以下问题： 从⽤户⾓度 一⻚分析看板上往往有 6-8 个图表，这些图表的查询请求都是同时发给 ClickHouse 的。但是在多并发的场景，ClickHouse 的查询性能下降的很快，平时一个 1-2s 左右的查询，在 8 个并发下就可能把 CPU 吃满，平均响应时间退化 4 倍左右，降到 8-10s，对看板的⾸⻚加载时间，以及交互分析的体验影响都⽐较⼤； 平台⽀持数据表的关联查询，但是 ClickHouse 的多表关联查询性能⽋佳，涉及 Join 的查询往往都需要 10s 以上，数据量⼤的查询甚⾄直接超时⽆法返回结果。 从运维⾓度 ClickHouse不⽀持事务性的 DDL 与 DML 操作，⽽且多副本模式的元数据管理强依赖于 ZooKeeper，表结构变更时常常出现不同副本之间元数据不一致的问题，往往定位到最后都是 ZooKeeper 的原因，排查、运维的成本都⽐较⾼； 随着数据量的增多，集群需要扩容时，ClickHouse缺少⾃动的 Resharding 机制，横向扩容时需要借助第三⽅⼯具或者⼿动 Reshard，成本⽐较⾼。 针对前⾯提到的实时场景，我们在使⽤ ClickHouse 的 Replacing 引擎中也遇到一些痛点： 查询慢，Replacing 引擎使⽤的是 Merge-On-Read 的模式，数据写⼊时保存多个版本，在查询时需要指定 FINAL 关键字进⾏去重取出最新版本的数据。这导致对于 Replacing 引擎表的查询，SQL 中的谓词⽆法下推，同时在低版本的 ClickHouse 中，对于 FINAL 语义的查询也不⽀持多线程处理，⼏乎每次查询都需要单线程扫描全表数据，涉及 Replacing 引擎的查询响应时间往往在 10s 以上； Replacing 引擎只⽀持数据的更新，并不⽀持数据的删除。对于 Delete 操作，当前的做法是通过额外字段来标记当前数据是否已经被删除，同时借助 TTL 功能来定时清除已经被删除的数据。这样一⽅⾯需要额外的定制处理，另一⽅⾯新增的标记字段进一步拖慢了查询的性能； Replacing 引擎只能对同一分⽚上同一分区的数据去重，这意味着我们在设计表分区时，以及写⼊数据时，都需要做⼩⼼的处理，增加了开发的成本。 上⾯描述的问题中，有一些涉及 ClickHouse 底层的缺陷，有一些场景利⽤ ClickHouse 提供的其他引擎或者 MaterializedView 等特性可以做一些定制的优化，但是掣肘于平台分析查询场景的多样性，我们很难做一些通⽤性的优化。基于这样的情况，我们决定需求新的 OLAP 技术选型。 StarRocks comes to the rescue StarRocks 是新一代 MPP 型 OLAP 分析引擎。我们通过调研发现，对于许多遇到的痛点，StarRocks 都提供了对应的解决⽅案： ⽀持多并发查询，部分场景可以达到1 万以上 QPS； ⽀持 Shuffle Join，Colocate Join 等多种分布式 Join ⽅式，多表关联性能更优； ⽀持事务性的 DDL 与 DML 操作，兼容 MySQL 协议； FE、BE 架构简单，不依赖外部组件，运维更加简单； 数据⾃动均衡，集群随业务增⻓⽔平扩展⽅便。 对于实时的场景，StarRocks 在 1.19 版本发布了Primary Key模型。对⽐ ClickHouse 的 Replacing 引擎与 StarRocks ⾃⾝的 Unique Key 模型，Primary Key 模型通过在内存中维护主键索引，⽀持频繁实时更新的同时，保证同一个主键下仅存在一条记录，解决了 Merge-on-Read ⽅式读取时在线合并，并且谓词⽆法下推和索引失效的问题。通过牺牲微⼩的写⼊性能和内存占⽤提升了查询的性能，⾮常符合我们实时数仓的场景。 调研之后，我们也对 StarRocks 和 ClickHouse，使⽤SSB数据集做了相应的性能对⽐测试。一共使⽤到四台 8c32g 的机器：StarRocks 1FE/4BE 混部，ClickHouse 两分⽚双副本。StarRocks 使⽤的版本是 2.1.0，ClickHouse 使⽤的版本是 21.9.5。测试中为了屏蔽掉系统缓存的影响，对于⽆并发的场景，每次查询前都会通过往 drop_cache ⽂件中写⼊来清除缓存。 测试的结果验证了 StarRocks 在多并发与多表关联场景下强悍的性能，同时也发现了⽬前 StarRocks 不⾜的一些地⽅： 单表⽆并发的场景，除个别 SQL 外，StarRocks 的查询速度与 ClickHouse 基本持平，但是 StarRocks 的 CPU 负载偏低，是 ClickHouse 的 25%~50%； 单表多并发的场景，除个别 SQL 外，StarRocks 的平均查询速度⽐ ClickHouse 快1.8倍； 多表关联⽆并发的场景，StarRocks 平均⽐ ClickHouse 快1.8倍； 多表关联多并发的场景，StarRocks 平均⽐ ClickHouse 快8倍； 数据实时写⼊实时查询的场景，不同的查询场景下，StarRocks 的 Primary Key 模型查询速度⽐ ClickHouse 的 Replacing 引擎快3~10倍，且查询性能较 ClickHouse 更加稳定（Replacing 引擎由于后台不断地 Merge 操作，查询的性能会随底表数据量的起伏对应地波动）； 数据批量导⼊的场景，我们⽐较了不同批次⼤⼩下的写⼊性能，StarRocks 的写⼊速率平均⽐ ClickHouse 要慢20%~30%左右。 基于上述的⼏点考虑与测试的结果，我们决定在平台的 OLAP 架构中引⼊ StarRocks，并优先在实时数仓的场景落地应⽤。 在集智平台的实时数仓⾥，业务库的 Binlog 数据与⽇志、事件数据会⾸先经由采集⼯具发送到 Kafka ⾥，中间通过 Flink 完成初步的数据清洗、转换，再次输出到 Kafka 做为 DWD/DIM 层。这一层的数据再次经过 Flink 处理，完成数据的关联、聚合，最后在 DWS 层⽣成不同主题的多维度明细宽表与指标汇总宽表。DWS 层的宽表会同时实时同步在 OLAP 引擎⾥，通过实时看板提供给业务同学查询。 实时数仓的场景对 OLAP 引擎提出了许多挑战，也是之前我们基于 ClickHouse 架构遇到的一⼤难题场景 业务同学需要根据实时看板随时调整投放策略，要求看板数据实时更新，快速响应； 实时看板的查看频率⽐离线看板普遍⾼出 3~5 倍，并且查询结果⽆法做缓存处理； 为了联合查询不同主题的数据，DWS 层的宽表之间往往还需要在 OLAP 层做关联操作； 为了满⾜多维分析的需求，落在 OLAP 层的是明细数据，数据量⼤； 为了保障数据的可维护性与数据快速修正的能⼒，这些明细数据需要⽀持按主键更新。 本就不擅⻓多并发与多表关联查询的 ClickHouse，再叠上 Replacing 引擎的 Debuff，导致许多实时的看板常常需要⼗⼏秒才能返回查询结果，不能很好地满⾜业务的需求。同时给集群的 CPU 负载也造成了不⼩的压⼒，有时会造成集群整体查询性能的波动。 为此，我们计划使⽤ StarRocks 的 Primary Key 模型来替换 ClickHouse 的 Replacing 引擎，针对线上的实时看板，我们模拟了真实的场景，选取了一个 4 张宽表关联的复杂查询，对两种不同的引擎做了对⽐测试，结果如下： 从结果中可以看到，在没有并发的场景下，StarRocks 的查询速度是 ClickHouse 的 2 倍左右，在多并发的场景下，StarRocks 的查询速度是 ClickHouse 的 3~3.5 倍左右。 除了查询性能提升之外，Primary Key 模型也可以⽀持数据的删除，并且不⽤数据开发额外地维护分⽚与分区的写⼊规则，降低了数据开发的成本。 集智平台集成 StarRocks 的功能应用 为了提升集智在查询加载⽅⾯的性能，同时将StarRocks极速查询及⾼并发相关能⼒更好的赋能给业务同学，集智在产品侧深度集成了StarRocks，⽤户可以在平台上快速完成一站式的实时看板搭建。 在集智平台中，搭建一个分析看板前需要先创建数据模型，当数据开发同学⾯对业务⽅较为复杂或查询量较⼤的分析需求时，可在创建数据模型时选择 StarRocks 的优化⽅式，除了基础的索引字段、数据分布字段以及时间分区等字段外，还可选择对应的模型引擎以及填写数据保留的时⻓。 实时模型创建成功后，⽤户可以在模型的详情⻚拿到对应的StarRocks表连接信息，以及⾃动⽣成的Flink SQLSink语句。 之后，⽤户可以在平台的数据 ETL 模块新建一个实时 Flink 任务，往对应的实时模型中写⼊数据。 数据写⼊模型之后，⽤户就可以在搭建看板时使⽤了，可以在模型上做一些字段的数据格式调整、字段编辑、基于原始字段新增复合字段等操作，以及图表样式的调整，满⾜业务⽅不同场景下的业务⼝径与展⽰需求。 看板搭建完成后可以进⾏发布操作⽣成一个固定链接，就可以提供给业务同学使⽤啦。 集成 StarRocks 对于业务的提升 以保险产品中线上渠道投放场景为例，当保险产品开始对外发售前后，市场⼈员会将产品投放到多个渠道进⾏推⼴曝光，通过经营的核⼼报表实时核算每个渠道的投放成本以及其对应的 ROI，根据数据表现情况实时调整投放策略，控制渠道营销流程中的获客单价和投放费⽤。 因此数据反馈的快慢也会决定业务⼈员在定位问题、调整策略等事件上是否占据最佳时机。 ⽽集智使⽤ StarRocks 的模型作为实时报表的底层数据⽀撑后，在业务场景中的数据查询表现会怎么样，以下为真实场景测试结果： 1）在报表数据加载速度⽅⾯：过去业务⽅打开报表需要加载10s+，常常因为打开速度过慢致使业务偶尔在关键节点上⽆法及时得到事故反馈，导致投放成本难以控制，严重影响后续的投放策略； ⽽使⽤ StarRocks 后加载速度只需3s左右，超强的响应速度让业务同学可以很快抓准业务实时的变动节点，及时对活动策略做出调整优化。 2）在查询数据量⽀持⽅⾯：过去使⽤ ClickHouse 的实时更新模型只能⽀持千万级数据量，更⼤数据量的实时更新+查询常常超时，严重影响业务进展，也会因此错过一些关键时机； ⽽使⽤ StarRocks 后可⽀持近亿级数据量，能够适配更多⼤数据量下的业务场景，同时也能更好的维持业务稳定性，增加了业务同学对平台的信任和粘性，极⼤的提⾼了⽣产效率。 总结与规划 从以上的调研和测试结果来看，StarRocks 的单表查询性能和 ClickHouse 不相上下，在多并发与多表关联查询的场景下性能明显优于 ClickHouse，特别是针对实时数仓的⾼频更新场景，StarRocks 的 Primary Key 模型能很好地解决 ClickHouse 的 Replacing 引擎遇到的一些痛点。此外，StarRocks 的 DDL/DML和数据导入具备事务保证，兼容 MySQL 协议，集群相对 ClickHouse 也更容易运维，对于研运同学来说更加友好。 之后除了在实时数仓场景的应⽤落地之外，众安也计划在其他场景中逐步推进 StarRocks 的应⽤，例如以下场景： 离线场景的数据也逐步接⼊ StarRocks，⽤统一的 OLAP 引擎完成全场景，批流一体的数据分析； 探索 StarRocks 作为轻量级数仓，以及统一查询引擎的能⼒； 探索 StarRocks 在⽤户⾏为数据分析、⽤户画像等其他业务场景中的应⽤。 更多场景分享会持续更新，可关注“众安科技”公众号进⾏订阅，对集智感兴趣的同学也可加产品经理企微沟通哦。 4⽉13⽇众安将与 StarRocks 举办一场线上联合直播，直播中会详细讲解在集智平台落地 StarRocks 的过程及经验。 扫描下⽅海报⼆维码，提前锁定直播名额！
2022-04-07
优秀的个人博客,低调大师

软通动力 OpenHarmony 师资培训班隆重开启，聚焦高校教师赋能

2021 年 8 月 9 日-13 日，OpenAtom OpenHarmony（以下简称“OpenHarmony”）师资培训班将以线上直播授课的形式展开，诚邀各高校相关专业老师与会参加。 此次 OpenHarmony 师资培训班由 OpenHarmony 项目群工作委员会和北京软通动力教育科技有限公司联合主办，南京小熊派智能科技有限公司协办，开放原子开源基金会作为指导单位。旨在通过加深高校教师对 OpenHarmony 的学习与理解、紧跟行业发展趋势、提高实践教学能力。不断提升高校人才的培养和积累，通过更为深入的校企合作和产教融合，汇聚、培养、共建人才，赋能新技术的生态从诞生到成熟。 OpenHarmony 具备面向全场景、分布式、组件化等特点，是一款面向未来的根操作系统。众多开发合作伙伴将以开源社区为中心，分阶段快速迭代，不断完善系统能力，逐步构建起面向万物互联时代的 OpenHarmony 生态。作为国内自主研发、全新技术生态的全领域下一代开源操作系统，自 OpenHarmony 项目开源上线以来，已经成为国内最受欢迎的开源项目之一，得到了国内众多行业、厂商、高校的高度关注和持续加入。 培训议程 日期 时间 主题 内容 8.9 上午 开场典礼及领导致辞 主持人开场 开放原子开源基金会理事长 杨涛 致辞 软通动力集团副董事长 黄颖 致辞 OpenHarmony 高校开发者生态培育 OpenHarmony 项目群工作委员会成员、 华为HarmonyOS 开源与开发者运营总监 欧建深 演讲 软通教育介绍 软通教育高校人才培养方案介绍 下午 OpenHarmony 生态介绍 ICT 行业发展趋势介绍 OpenHarmony 生态及技术体系介绍 8.10 上午 OpenHarmony 操作系统内核类实验 开发环境搭建以及依赖组件的安装 多线程创建和使用 定时器创建和使用 事件的创建和使用 互斥锁的创建和使用 信号量的创建和使用 消息队列的创建和使用 下午 OpenHarmony 外设基础实验 LED 闪烁 LED 亮灭按键控制 LED 呼吸灯 读取电压 读取 NFC 串口自发自收 8.11 上午 OpenHarmony 驱动实验 烟雾传感器驱动 温湿度传感器驱动 光强传感器驱动 陀螺仪驱动 人体红外传感器驱动 下午 OpenHarmony 物联网基础实验 创建无线热点 无线联网 实现 UDP 客户端 实现 TCP 服务端 MQTT 连接实验 小熊派接入华为云 IOT 平台 8.12 上午 OpenHarmony 物联网案例实验 智慧消防案例 智慧路灯案例 智慧井盖案例 智慧人体感应案例 智慧农业案例 智慧物流案例 下午 物联网应用全场景 物联网体系架构介绍 物联网平台数据流转到消息队列 8.13 上午 物联网应用全场景 应用服务器拉取消息队列数据 客户端对接应用服务器 下午 OpenHarmony 分布式流转特性实验 分布式流转特性介绍 分布式视频播放器开发 培训安排 培训时间：2021 年 8 月 9 日至 8 月 13 日 培训形式：线上直播授课 培训人员：经软通教育及OpenHarmony教育工作组邀请的高校相关专业老师 考核发证：培训期满，经考核合格，颁发由软通教育及开放原子教育联合认证的师资培训结业证书 报名须知：免费线上培训，各位老师自行购买培训所需硬件设备 培训接口人： 梁程 15507710157 chenliangd@isoftstone.com 沈俊 17671606255 junshenj@isoftstone.com 直播路径 开放原子教育培训： https://app3gcjx6qa9693.h5.xiaoeknow.com/v1/course/column/p_610bac92e4b0cce271ba302f?type=3 扫码观看 软通云直播间： https://live.vhall.com/486938553 企业介绍 北京软通动力教育科技有限公司： 软通教育是软通动力集团旗下教育品牌，专注于ICT人才供给与培养，是软通动力进行校企合作、人才供给与发展、人才生态建设的平台。软通教育深耕高校，致力于产教融合，解决产教供需矛盾，弥补现有教育和市场脱节的问题，打通企业用人“最后一公里”。 南京小熊派智能科技有限公司： 南京小熊派智能科技有限公司是南京厚德物联网有限公司旗下全资子公司，“小熊派”是一个开源硬件平台，致力于IoT、5G、AI、OS等新技术领域的技术开源及推广；自主研发的IoT开发套件和HarmonyOS开发套件均销量全国第一；同时开展物联网教学套件研发和定制项目；旗下“小熊派开源社区”专注于为开发者免费提供技术开源资料及教程，服务数百万开发者，拥有数十万小熊派粉丝。 特别鸣谢 “小熊派”对OpenHarmony师资培训班的大力支持，在本次培训过程中每天送出5块小熊派BearPi-HM Nano开发板进行抽奖。 开放原子开源基金会及 OpenHarmony 介绍 开放原子开源基金会是中国首家以开源为主题的基金会，以“一切为了开发者，一切为了全世界”为使命，致力于为全球开发者搭建可持续的开源合作平台，基金会可为各类开源项目提供中立的知识产权托管服务以及战略咨询、法务咨询、项目运营和品牌营销服务。 OpenAtom OpenHarmony（以下简称“OpenHarmony”）是由开放原子开源基金会孵化及运营的开源项目，由开放原子开源基金会的 OpenHarmony 项目群工作委员会负责运作，遵循 Apache 2.0 等开源协议。由华为捐赠智能终端操作系统基础能力相关代码，多家单位及全球开发者共建的开源分布式操作系统。具备面向全场景、分布式、组件化等特点，是一款面向未来的根操作系统。众多开发合作伙伴将以开源社区为中心，分阶段快速迭代，不断完善系统能力，逐步构建起面向万物互联时代的 OpenHarmony 生态。 OpenHarmony Gitee 教育资源仓是高校教育生态的有力抓手，本仓由 OpenHarmony 共享技术文档、教育培训教材、实践解决方案、实验手册、教具方案等内容构成，意在给广大高校单位和个人提供公开平等的学习和贡献的环境，帮助院校进行体系化的人才培养，主动储备产业人才力量。调研数据显示，自从 2021 年 5 月 24 日 OpenHarmony 高校启航闭门研讨会以来，在全国已有 20 多所高校有意向开设 OpenHarmony 课程，希望通过产学研交叉赋能，加快完善 OpenHarmony 高校教育生态。
2021-08-06
优秀的个人博客,低调大师

MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章

作者简介： 马振军，花名古今，在基础架构领域耕耘多年，对 Service Mesh 有深度实践经验，目前在蚂蚁集团中间件团队负责 MOSN、Layotto 等项目的开发工作。 Layotto官方GitHub地址: https://github.com/mosn/layotto 点击链接即可观看现场视频：https://www.bilibili.com/video/BV1hq4y1L7FY/ Service Mesh 在微服务领域已经非常流行，越来越多的公司开始在内部落地，蚂蚁从 Service Mesh 刚出现的时候开始，就一直在这个方向上大力投入，到目前为止，内部的 Mesh 方案已经覆盖数千个应用、数十万容器并且经过了多次大促考验，Service Mesh 带来的业务解耦，平滑升级等优势大大提高了中间件的迭代效率。 在大规模落地以后，我们又遇到了新的问题，本文主要对 Service Mesh 在蚂蚁内部落地情况进行回顾总结，并分享对 Service Mesh 落地后遇到的新问题的解决方案。 一、Service Mesh 回顾与总结 A、Service Mesh 的初衷 在微服务架构下，基础架构团队一般会为应用提供一个封装了各种服务治理能力的 SDK，这种做法虽然保障了应用的正常运行，但缺点也非常明显，每次基础架构团队迭代一个新功能都需要业务方参与升级才能使用，尤其是 bugfix 版本，往往需要强推业务方升级，这里面的痛苦程度每一个基础架构团队成员都深有体会。 伴随着升级的困难，随之而来的就是应用使用的 SDK 版本差别非常大，生产环境同时跑着各种版本的 SDK，这种现象又会让新功能的迭代必须考虑各种兼容，就好像带着枷锁前进一般，这样随着不断迭代，会让代码维护非常困难，有些祖传逻辑更是一不小心就会掉坑里。 同时这种“重”SDK 的开发模式，导致异构语言的治理能力非常薄弱，如果想为各种编程语言都提供一个功能完整且能持续迭代的 SDK 其中的成本可想而知。 18 年的时候，Service Mesh 在国内持续火爆，这种架构理念旨在把服务治理能力跟业务解耦，让两者通过进程级别的通信方式进行交互。在这种架构模式下，服务治理能力从应用中剥离，运行在独立的进程中，迭代升级跟业务进程无关，这就可以让各种服务治理能力快速迭代，并且由于升级成本低，因此每个版本都可以全部升级，解决了历史包袱问题，同时 SDK 变“轻”直接降低了异构语言的治理门槛，再也不用为需要给各个语言开发相同服务治理能力的 SDK 头疼了。 B、Service Mesh 落地现状 蚂蚁很快意识到了 Service Mesh 的价值，全力投入到这个方向，用 Go 语言开发了 MOSN 这样可以对标 envoy 的优秀数据面，全权负责服务路由，负载均衡，熔断限流等能力的建设，大大加快了公司内部落地 Service Mesh 的进度。 现在 MOSN 在蚂蚁内部已经覆盖了数千个应用、数十万容器，新创建的应用默认接入 MOSN，形成闭环。而且在大家最关心的资源占用、性能损耗方面 MOSN 也交出了一份让人满意的答卷： 1. RT 小于 0.2ms 2. CPU 占用增加 0%~2% 3. 内存消耗增长小于 15M 由于 Service Mesh 降低了异构语言的服务治理门槛，NodeJS、C++等异构技术栈也在持续接入到 MOSN 中。 在看到 RPC 能力 Mesh 化带来的巨大收益之后，蚂蚁内部还把 MQ，Cache，Config 等中间件能力都进行了 Mesh 化改造，下沉到 MOSN，提高了中间件产品整体的迭代效率。 C、新的挑战 1. 应用跟基础设施强绑定 一个现代分布式应用，往往会同时依赖 RPC、Cache、MQ、Config 等各种分布式能力来完成业务逻辑的处理。 当初看到 RPC 下沉的红利以后，其他各种能力也都快速下沉。初期，大家都会以自己最熟悉的方式来开发，这就导致没有统一的规划管理，如上图所示，应用依赖了各种基础设施的 SDK，而每种 SDK 又以自己特有的方式跟 MOSN 进行交互，使用的往往都是由原生基础设施提供的私有协议，这直接导致了复杂的中间件能力虽然下沉，但应用本质上还是被绑定到了基础设施，比如想把缓存从 Redis 迁移到 Memcache 的话，仍旧需要业务方升级 SDK，这种问题在应用上云的大趋势下表现的更为突出，试想一下，如果一个应用要部署在云上，由于该应用依赖了各种基础设施，势必要先把整个基础设施搬到云上才能让应用顺利部署，这其中的成本可想而知。 因此如何让应用跟基础设施解绑，使其具备可移植能力，能够无感知跨平台部署是我们面临的第一个问题。 2. 异构语言接入成本高 事实证明 Service Mesh 确实降低了异构语言的接入门槛，但在越来越多的基础能力下沉到 MOSN 以后，我们逐渐意识到为了让应用跟 MOSN 交互，各种 SDK 里都需要对通信协议，序列化协议进行开发，如果再加上需要对各种异构语言都提供相同的功能，那维护难度就会成倍上涨， Service Mesh 让重 SDK 成为了历史，但对于现在各种编程语言百花齐放、各种应用又强依赖基础设施的场景来说，我们发现现有的 SDK 还不够薄，异构语言接入的门槛还不够低，如何进一步降低异构语言的接入门槛是我们面临的第二个问题。 二、Multi Runtime 理论概述 A、什么是 Runtime? 20 年初的时候，Bilgin lbryam 发表了一篇名为 Multi-Runtime Microservices Architecture 的文章，里面对微服务架构下一阶段的形态进行了讨论。 如上图所示，作者把分布式服务的需求进行了抽象，总共分为了四大类： 1. 生命周期（Lifecycle） 主要指应用的编译、打包、部署等事情，在云原生的大趋势下基本被 docker、kubernetes 承包。 2. 网络（Networking） 可靠的网络是微服务之间进行通信的基本保障，Service Mesh 正是在这方面做了尝试，目前 MOSN、envoy 等流行的数据面的稳定性、实用性都已经得到了充分验证。 3. 状态（State） 分布式系统需要的服务编排，工作流，分布式单例，调度，幂等性，有状态的错误恢复，缓存等操作都可以统一归为底层的状态管理。 4. 绑定（Binding） 在分布式系统中，不仅需要跟其他系统通信，还需要集成各种外部系统，因此对于协议转换，多种交互模型、错误恢复流程等功能也都有强依赖。 明确了需求以后，借鉴了 Service Mesh 的思路，作者对分布式服务的架构演进进行了如下总结： 第一阶段就是把各种基础设施能力从应用中剥离解耦，通通变成独立 sidecar 模型伴随着应用一起运行。 第二阶段是把各种 sidecar 提供的能力统一抽象成若干个 Runtime，这样应用从面向基础组件开发就演变成了面向各种分布式能力开发，彻底屏蔽掉了底层实现细节，而且由于是面向能力，除了调用提供各种能力的 API 之外，应用再也不需要依赖各种各样基础设施提供的 SDK 了。 作者的思路跟我们希望解决的问题一致，我们决定使用 Runtime 的理念来解决 Service Mesh 发展到现在所遇到的新问题。 B、Service Mesh vs Runtime 为了让大家对 Runtime 有一个更加清晰的认识，上图针对 Service Mesh 跟 Runtime 两种理念的定位、交互方式、通信协议以及能力丰富度进行了总结，可以看到相比 Service Mesh 而言，Runtime 提供了语义明确、能力丰富的 API，可以让应用跟它的交互变得更加简单直接。 三、MOSN 子项目 Layotto A、dapr 调研 dapr 是社区中一款知名的 Runtime 实现产品，活跃度也比较高，因此我们首先调研了 dapr 的情况，发现 dapr 具有如下优势： 1. 提供了多种分布式能力，API 定义清晰，基本能满足一般的使用场景。 2. 针对各种能力都提供了不同的实现组件，基本涵盖了常用的中间件产品，用户可以根据需要自由选择。 当考虑如何在公司内部落地 dapr 时，我们提出了两种方案，如上图所示： 1. 替换：废弃掉现在的 MOSN，用 dapr 进行替换，这种方案存在两个问题： a. dapr 虽然提供了很多分布式能力，但目前并不具备 Service Mesh 包含的丰富的服务治理能力。 b. MOSN 在公司内部已经大规模落地，并且经过了多次大促考验，直接用 dapr 来替换 MOSN 稳定性有待验证。 2. 共存：新增一个 dapr 容器，跟 MOSN 以两个 sidecar 的模式进行部署。这种方案同样存在两个问题： a. 引入一个新的 sidecar，我们就需要考虑它配套的升级、监控、注入等等事情，运维成本飙升。 b. 多维护一个容器意味着多了一层挂掉的风险，这会降低现在的系统可用性。 同样的，如果你目前正在使用 envoy 作为数据面，也会面临上述问题。 因此我们希望把 Runtime 跟 Service Mesh 两者结合起来，通过一个完整的 sidecar 进行部署，在保证稳定性、运维成本不变的前提下，最大程度复用现有的各种 Mesh 能力。此外我们还希望这部分 Runtime 能力除了跟 MOSN 结合起来之外，未来也可以跟 envoy 结合起来，解决更多场景中的问题，Layotto 就是在这样的背景下诞生。 B、Layotto 架构 如上图所示，Layotto 是构建在 MOSN 之上，在下层对接了各种基础设施，向上层应用提供了统一的，具有各种各样分布式能力的标准 API。对于接入 Layotto 的应用来说，开发者不再需要关心底层各种组件的实现差异，只需要关注应用需要什么样的能力，然后调用对应能力的 API 即可，这样可以彻底跟底层基础设施解绑。 对应用来说，交互分为两块，一个是作为 gRPC Client 调用 Layotto 的标准 API，一个是作为 gRPC Server 来实现 Layotto 的回调，得利于gRPC 优秀的跨语言支持能力，应用不再需要关心通信、序列化等细节问题，进一步降低了异构技术栈的使用门槛。 除了面向应用，Layotto 也向运维平台提供了统一的接口，这些接口可以把应用跟 sidecar 的运行状态反馈给运维平台，方便 SRE 同学及时了解应用的运行状态并针对不同状态做出不同的举措，该功能考虑到跟 k8s 等已有的平台集成，因此我们提供了 HTTP 协议的访问方式。 除了 Layotto 本身设计以外，项目还涉及两块标准化建设，首先想要制定一套语义明确，适用场景广泛的 API 并不是一件容易的事情，为此我们跟阿里、 dapr 社区进行了合作，希望能够推进 Runtime API 标准化的建设，其次对于 dapr 社区已经实现的各种能力的 Components 来说，我们的原则是优先复用、其次开发，尽量不把精力浪费在已有的组件上面，重复造轮子。 最后 Layotto 目前虽然是构建在 MOSN 之上，未来我们希望 Layotto 可以跑在 envoy 上，这样只要应用接入了 Service Mesh，无论数据面使用的是 MOSN 还是 envoy，都可以在上面增加 Runtime能力。 C、Layotto 的移植性 如上图所示，一旦完成 Runtime API 的标准化建设，接入 Layotto 的应用天然具备了可移植性，应用不需要任何改造就可以在私有云以及各种公有云上部署，并且由于使用的是标准 API，应用也可以无需任何改造就在 Layotto 跟 dapr 之间自由切换。 D、名字含义 从上面的架构图可以看出，Layotto 项目本身是希望屏蔽基础设施的实现细节，向上层应用统一提供各种分布式能力，这种做法就好像是在应用跟基础设施之间加了一层抽象，因此我们借鉴了 OSI 对网络定义七层模型的思路，希望 Layotto 可以作为第八层对应用提供服务，otto 是意大利语中8的意思，Layer otto 就是第八层的意思，简化了一下变成了 Layotto，同时项目代号 L8，也是第八层的意思，这个代号也是设计我们项目 LOGO 时灵感的来源。 介绍完项目的整体情况，下面对其中四个主要功能的实现细节进行说明。 E、配置原语 首先是分布式系统中经常使用的配置功能，应用一般使用配置中心来做开关或者动态调整应用的运行状态。Layotto 中配置模块的实现包括两部分，一个是对如何定义配置这种能力的 API 的思考，一个是具体的实现，下面逐个来看。 想要定义一个能满足大部分实际生产诉求的配置 API 并不是一件容易的事，dapr 目前也缺失这个能力，因此我们跟阿里以及 dapr 社区一起合作，为如何定义一版合理的配置 API 进行了激烈讨论。 目前讨论结果还没有最终确定，因此 Layotto 是基于我们提给社区的第一版草案进行实现，下面对我们的草案进行简要说明。 我们先定义了一般配置所需的基本元素： 1. appId：表示配置属于哪个应用 2. key：配置的 key 3. content：配置的值 4. group：配置所属的分组，如果一个 appId 下面的配置过多，我们可以给这些配置进行分组归类，便于维护。 此外我们追加了两种高级特性，用来适配更加复杂的配置使用场景： 1. label，用于给配置打标签，比如该配置属于哪个环境，在进行配置查询的时候，我们会使用 label+ key 来查询配置。 2. tags，用户给配置追加的一些附加信息，如描述信息、创建者信息，最后修改时间等等，方便配置的管理，审计等。 对于上述定义的配置 API 的具体实现，目前支持查询、订阅、删除、创建、修改五种操作，其中订阅配置变更后的推送使用的是 gRPC 的 stream 特性，而底层实现这些配置能力的组件，我们选择了国内流行的 apollo，后面也会根据需求增加其他实现。 F、Pub/Sub 原语 对于 Pub/Sub 能力的支持，我们调研了 dapr 现在的实现，发现基本上已经可以满足我们的需求，因此我们直接复用了 dapr 的 API 以及 components，只是在 Layotto 里面做了适配，这为我们节省了大量的重复劳动，我们希望跟 dapr 社区保持一种合作共建的思路，而不是重复造轮子。 其中 Pub 功能是 App 调用 Layotto 提供的 PublishEvent 接口，而 Sub 功能则是应用通过 gRPC Server 的形式实现了 ListTopicSubscriptions 跟 OnTopicEvent 两个接口，一个用来告诉 Layotto 应用需要订阅哪些 topic，一个用于接收 topic 变化时 Layotto 的回调事件。 dapr 对于 Pub/Sub 的定义基本满足我们的需求，但在某些场景下仍有不足，dapr 采用了 CloudEvent 标准，因此 Pub 接口没有返回值，这无法满足我们生产场景中要求 Pub 消息以后服务端返回对应的 messageID 的需求，这一点我们已经把需求提交给了 dapr 社区，还在等待反馈，考虑到社区异步协作的机制，我们可能会先社区一步增加返回结果，然后再跟社区探讨一种更好的兼容方案。 G、RPC 原语 RPC 的能力大家不会陌生，这可能是微服务架构下最最基础的需求，对于 RPC 接口的定义，我们同样参考了 dapr 社区的定义，发现完全可以满足我们的需求，因此接口定义就直接复用 dapr 的，但目前 dapr 提供的 RPC 实现方案还比较薄弱，而 MOSN 经过多年迭代，能力已经非常成熟完善，因此我们大胆把 Runtime 跟 Service Mesh 两种思路结合在一起，把 MOSN 本身作为我们实现 RPC 能力的一个 Component，这样 Layotto 在收到 RPC 请求以后交给 MOSN 进行实际数据传输，这种方案可以通过 istio 动态改变路由规则，降级限流等等设置，相当于直接复用了 Service Mesh 的各种能力，这也说明 Runtime 不是要推翻 Service Mesh，而是要在此基础上继续向前迈一步。 具体实现细节上，为了更好的跟 MOSN 融合，我们在 RPC 的实现上面加了一层 Channel，默认支持dubbo，bolt，http 三种常见的 RPC 协议，如果仍然不能满足用户场景，我们还追加了 Before/After 两种 Filter，可以让用户做自定义扩展，实现协议转换等需求。 H、Actuator 原语 在实际生产环境中，除了应用所需要的各种分布式能力以外，PaaS 等运维平台往往需要了解应用的运行状态，基于这种需求，我们抽象了一套 Actuator 接口，目前 dapr 还没有提供这方面的能力，因此我们根据内部的需求场景进行了设计，旨在把应用在启动期、运行期等阶段各种各样的信息暴露出去，方便 PaaS 了解应用的运行情况。 Layotto 把暴露信息分为两大类： 1. Health：该模块判断应用当前运行状态是否健康，比如某个强依赖的组件如果初始化失败就需要表示为非健康状态，而对于健康检查的类型我们参考了 k8s，分为： a. Readiness：表示应用启动完成，可以开始处理请求。 b. Liveness：表示应用存活状态，如果不存活则需要切流等。 2. Info：该模块预期会暴露应用的一些依赖信息出去，如应用依赖的服务，订阅的配置等等，用于排查问题。 Health 对外暴露的健康状态分为以下三种： 1. INIT：表示应用还在启动中，如果应用发布过程中返回该值，这个时候 PaaS 平台应该继续等待应用完成启动。 2. UP：表示应用启动正常，如果应用发布过程中返回该值，意味着 PasS 平台可以开始放入流量。 3. DOWN：表示应用启动失败，如果应用发布过程中返回该值，意味着 PaaS 需要停止发布并通知应用 owner。 到这里关于 Layotto 目前在 Runtime 方向上的探索基本讲完了，我们通过定义明确语义的 API，使用 gRPC 这种标准的交互协议解决了目前面临的基础设施强绑定、异构语言接入成本高两大问题。随着未来 API 标准化的建设，一方面可以让接入 Layotto 的应用无感知的在各种私有云、公有云上面部署，另一方面也能让应用在 Layotto，dapr 之间自由切换，提高研发效率。 目前 Serverless 领域也是百花齐放，没有一种统一的解决方案，因此 Layotto 除了在上述 Runtime 方向上的投入以外，还在 Serverless 方向上也进行了一些尝试，下面就尝试方案进行介绍。 四、WebAssembly 的探索 A、WebAssembly 简介 WebAssembly，简称 WASM，是一个二进制指令集，最初是跑在浏览器上来解决 JavaScript 的性能问题，但由于它良好的安全性，隔离性以及语言无关性等优秀特性，很快人们便开始让它跑在浏览器之外的地方，随着 WASI 定义的出现，只需要一个 WASM 运行时，就可以让 WASM 文件随处执行。 既然 WebAssembly 可以在浏览器以外的地方运行，那么我们是否能把它用在 Serverless 领域？目前已经有人在这方面做了一些尝试，不过如果这种方案真的想落地的话，首先要考虑的就是如何解决运行中的 WebAssembly 对各种基础设施的依赖问题。 B、WebAssembly 落地原理 目前 MOSN 通过集成 WASM Runtime 的方式让 WASM 跑在 MOSN 上面，以此来满足对 MOSN 做自定义扩展的需求。同时，Layotto 也是构建在 MOSN 之上，因此我们考虑把二者结合在一起，实现方案如下图所示： 开发者可以使用 Go/C++/Rust 等各种各样自己喜欢的语言来开发应用代码，然后把它们编译成 WASM 文件跑在 MOSN 上面，当 WASM 形态的应用在处理请求的过程中需要依赖各种分布式能力时就可以通过本地函数调用的方式调用 Layotto 提供的标准 API，这样直接解决了 WASM 形态应用的依赖问题。 目前 Layotto 提供了 Go 跟 Rust 版 WASM 的实现，虽然只支持 demo 级功能，但已经足够让我们看到这种方案的潜在价值。 此外，WASM 社区目前还处于初期阶段，有很多地方需要完善，我们也给社区提交了一些 PR共同建设，为 WASM 技术的落地添砖加瓦。 C、WebAssembly 落地展望 虽然现在 Layotto 中对 WASM 的使用还处于试验阶段，但我们希望它最终可以成为 Serverless 的一种实现形态，如上图所示，应用通过各种编程语言开发，然后统一编译成 WASM 文件，最后跑在 Layotto+MOSN 上面，而对于应用的运维管理统一由 k8s、docker、prometheus 等产品负责。 五、社区规划 最后来看下 Layotto 在社区的做的一些事情。 A、Layotto vs Dapr 上图列出了 Layotto 跟 dapr 现有的能力对比，在 Layotto 的开发过程中，我们借鉴 dapr 的思路，始终以优先复用、其次开发为原则，旨在达成共建的目标，而对于正在建设或者未来要建设的能力来说，我们计划优先在 Layotto 上落地，然后再提给社区，合并到标准 API，鉴于社区异步协作的机制，沟通成本较高，因此短期内可能 Layotto 的 API 会先于社区，但长期来看一定会统一。 B、API 共建计划 关于如何定义一套标准的 API 以及如何让 Layotto 可以跑在 envoy 上等等事项，我们已经在各个社区进行了深入讨论，并且以后也还会继续推进。 C、Roadmap Layotto 在目前主要支持 RPC、Config、Pub/Sub、Actuator 四大功能，预计在九月会把精力投入到分布式锁、State、可观测性上面，十二月份会支持 Layotto 插件化，也就是让它可以跑在 envoy 上，同时希望对 WebAssembly 的探索会有进一步的产出。 D、正式开源 前面详细介绍了 Layotto 项目，最重要的还是该项目今天作为 MOSN 的子项目正式开源，我们提供了详细的文档以及 demo 示例方便大家快速上手体验。 对于 API 标准化的建设是一件需要长期推动的事情，同时标准化意味着不是满足一两种场景，而是尽可能的适配大多数使用场景，为此我们希望更多的人可以参与到 Layotto 项目中，描述你的使用场景，讨论 API 的定义方案，一起提交给社区，最终达成 Write once, Run anywhere 的终极目标！
2021-06-26
优秀的个人博客,低调大师

高额奖池、院士评定，首届全球人工智能技术创新大赛开启征召！

随着新一轮科技革命和产业变革的来临，产业智能化升级与转型正迈进新的加速阶段。积淀的AI技术如何下沉到行业，如何构建良好的智能发展生态，如何在更深刻的层面影响大众生活，成为了当前关键问题。 在过去十几年的AI浪潮中，计算机视觉与自然语言处理技术的突破，为各行各业的发展带来了新的潜力。如今随着AI技术突破的放缓，我们需要认真思考，如何将这些技术突破应用金融、医疗、汽车、手机等各个领域，通过不断的开拓、创新，推动产业智能化变革。 此外，产业的智能化转型还需要人才。技术人才的能力和视野，直接决定了智能化转型的深度和高度。 为了推动AI技术的应用创新，促进人工智能领域的学术交流、人才培养，打造人工智能的人才交流平台与产业生态圈。首届全球人工智能技术创新大赛已于今年年初开赛。 此届大赛由中国人工智能学会和杭州市余杭区人民政府共同创办，杭州市未来科技城管委会、阿里云计算有限公司、清华-OPPO未来终端技术研究中心联合承办，力求打造具有“高层次、高价值、高奖励”三高特性的人工智能标志赛事，为菁英人才提供一个打破国界与领域限制的竞技舞台。 在赛题设置上，结合人工智能领域的技术发展，大赛设置医学影像报告异常检测、PANDA大场景多对象检测跟踪、小布助手对话短文本语义匹配三大赛题，邀请全球AI人才共同突破赛题中的关键技术瓶颈，推进下一代人工智能前瞻性研究发展。 此外，大赛设置150万元的高额奖金池，即日起至4月7日面向全球开放线上征召，不论你是高校在校生（包括高职高专、本科生、研究生），或是科研机构学者、企业技术开发者，不限年龄和国籍，均可报名角逐。 我们接下来就说下这场2021年最值得关注的AI技术创新大赛为何值得参赛。 三大赛题融合技术突破、行业应用 首先，该大赛三大赛题在设置上，既包含计算机视觉与NLP两大热点AI技术，又兼顾了算法突破与行业应用。 对于影像科的医生来说，观察医学影像并得出患者状况是一项的常见任务，这些观察结果可供临床医生得出诊断意见和进一步检查的建议。随着深度学习和计算机视觉等技术的发展和落地，「医学影像+AI」这一领域被寄予厚望。这项技术的应用推广不仅能在一定意义上减轻医生的日常工作量，也能够协助医生提高诊断准确率。 因此本次大赛赛题一的任务要求参赛队伍根据医生对CT的影像描述文本数据，判断身体若干目标区域是否有异常以及异常的类型。初赛阶段仅需判断各区域是否有异常；复赛阶段除了判断有异常的区域外，还需判断异常的类型。 赛题二是当前计算机视觉领域热点研究方向之一：大场景多对象检测跟踪，赛题包含大场景多目标检测、追踪等视觉任务，旨在推动人工智能在大场景多对象复杂关系上研究的发展。 赛题三聚焦NLP技术落地应用，解决产业实际问题。在智能移动终端普及的今天，「语音助手」俨然已经成为了很多人最熟悉、最亲近的家庭成员之一。意图识别是这类对话系统中的一个核心任务，而对话短文本语义匹配是意图识别的主流算法方案之一。本赛题以OPPO「小布助手」为基础，要求参赛队伍根据脱敏后的短文本query-pair预测它们是否属于同一语义。 与此同时，本次大赛由中国最具影响力的竞赛平台——阿里云天池平台提供平台和算力的支撑，助力AI人才的培养，丰富技术创新生态的建设。 豪华嘉宾阵容与高额奖金 除了考究的赛题设置，豪华的嘉宾评委阵容与高额奖金也是不得不参赛的原因。 中国工程院院士戴琼海、中国工程院院士陈杰、南京大学人工智能学院院长周志华教授等将为大赛提供最为专业的指导，为全球参赛选手们提供质量最高的同台竞技平台。 图：部分嘉宾评委 为方便更多技术人才参与，并有充分的准备时间，即日起至4月7日都可报名及组队。大赛在流程设计上分为初赛、复赛、总决赛三个赛程，层层把关，确保更公平、更严格的评选出优质项目。 在奖金方面，每个赛道奖金池总额分别为50万人民币，大赛总奖金池高达150万。此外，在每个赛道的初赛阶段，大赛设立周周星奖励。从初赛第三周开始，以每周一中午12点的排行榜为准，取前两名参赛队伍发放周周星特别礼物。 更多大赛详情，请参考官网（点击阅读原文）： https://gaiic.tianchi.aliyun.com/ 配套「AI青年说」，推动技术布道与科普公益 除了参赛，「吃瓜选手们」也可通过另一种方式参与该盛事。 在大赛进行期间，中国人工智能学会为扩大大赛影响力与社会关注度，推进人工智能技术发展与交流，特发起「AI青年说」系列活动，邀请知名青年学者，面向人工智能与前沿科技从业者与泛科技人群，探讨理论研究与应用实践中的热点话题，欢迎大家积极关注。
2021-03-18
优秀的个人博客,低调大师

浙江赛区总决赛即将开启，巅峰对决即将上演

8月21日，浙江赛区总决赛将在杭州国大雷迪森广场酒店举行，届时优选出的参赛队伍将会在活动现场进行路演答辩，对参赛作品进行详细讲解，同时还有资深技术评委坐镇现场，为参赛队伍进行打分，评选出获胜队伍后将现场进行颁奖。 壮大鲲鹏应用产业生态是我国计算产业发展的“振芯铸魂”的工程，也是浙江省数字经济高质量发展的重要抓手，推动鲲鹏计算产业生态发展需要立足于信息技术应用创新体系的建设。通过本次大赛，助力更硬的实力来推动浙江省信息化产业的进步和信息技术应用创新体系的发展。 大赛围绕“行业应用孵化，鲲鹏商用部署”进行，以具备能够商用落地的应用系统为报名前提条件，邀请广大高校及行业应用系统厂商组建参赛队伍参赛，征集各行业各类解决方案作品，吸引全产业开发者共同打造鲲鹏全栈解决方案，实现技术与商业创新应用。 作为全国十三大赛区的其中一环，浙江赛区自2020年7月1日开放报名通道起，一个月的时间里，浙江赛区吸引了近百支参赛队伍，近三百名开发者的报名。而走到总决赛的50支队伍更是精兵强将，以代码过招、用实力说话，争做技术的弄潮儿。为确保大赛的公平公正性，本次大赛将采取现场答辩形式选出获胜队伍。 值得一提的是，浙江赛区赛事激励总额高达70万，将在“金融”、“政府”、“大数据”、“ARM原生应用”和“开放命题”五大赛题下选出一、二、三等奖，获得一等奖的团队将有机会参加“华为开发者大赛·鲲鹏应用创新大赛 2020”全国赛，进行更加激烈的角逐。 信息化浪潮势不可挡，在这场对决中，作为参赛者，势必将此次大赛当做实践、创新的练兵场；作为观战者，时代的参与者，我们也将从中收获诸多感悟，并得以沉淀。生命不息，代码不断，创作不止，让我们一起期待这场代码与代码间的实力对决！ 【责任编辑： 张燕妮 TEL：（010）68476606】
2020-08-19
优秀的个人博客,低调大师

创客北京2020·鲲鹏应用创新专项赛总决赛即将开启，大赛桂冠花落谁家！

2020年8月20日，创客北京2020 · 鲲鹏应用创新专项赛将迎来激动人心的时刻。在备受瞩目的专家评审环节，主办方将在现场邀请入围选手参与大赛总决赛，专家评审小组将从方案创新性、技术领先性、商业前景、社会价值等多个维度进行评选，最终评选出优秀作品，评选结果将于8月24日正式发布。 自7月2日启动赛事以来，这场由工业和信息化部、财政部指导，北京市经济和信息化局、北京市财政局、中关村科学城管理委员会主办，北京市中小企业服务中心、北京市中小企业公共服务平台、北京创业投资创新服务联盟、北京鲲鹏联合创新中心、华为技术有限公司承办、北京市丰台区发展投资有限公司协办的大赛在北京地区引发了极大的关注，应者云集，历时45天，513位选手参赛，144个作品完成提交，大战一触即发！ 创客北京2020 · 鲲鹏应用创新专项赛设置了五大赛题，分别是“鲲鹏生态：使能金融行业”、“鲲鹏生态：使能数字政府”、“ARM原生创新应用”、“大数据创新解决方案”、“开放命题”。专家评审小组秉持着公平公正的原则，将分别在这五大赛题中评选出一等奖、二等奖、三等奖各五个团队。其中，一等奖每个团队奖励5万元现金和价值12500元华为终端大礼包，二等奖每个团队奖励3万现金+价值7500元华为终端大礼包，三等奖每个团队奖励3万元现金。增设鼓励奖15名，每个团队奖励1万现金，赛事奖项激励总额高达80万。 专家评审小组将从五个一等奖团队中，将评选出一个技术价值、应用价值和商业落地价值最高的1个团队给予额外的特别奖励。五大赛题一等奖团队还将被推选参加“华为开发者大赛@鲲鹏应用创新大赛2020”全国赛。 目前大赛评审已经进入倒计时阶段，评审专家和参赛选手都在积极准备，大战一触即发，让我们敬请期待鲲鹏大赛桂冠花落谁家！ 【责任编辑： 张燕妮 TEL：（010）68476606】
2020-08-18

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-04-11 大小: 1MB 下载: 9次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-04-24 大小: 189MB 下载: 6次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2025-12-17 大小: 5MB 下载: 1次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2025-12-03 大小: 9.84MB 下载: 39次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册