AI十级「找茬」选手，非这个书生莫属，节后开源！

企业IT解决方案之餐饮APP解决方案

2022-01-23

随着互联网+餐饮的发展，实体电商与移动支付联姻已然成为一种潮流。根据重庆雪印网络科技市场调研人员计数统计，整个餐饮业的O2O市场国模接近千亿，移动互联网快速的发展，这就需要餐饮企业具有快速的演化能力，及时更上时代步伐。一方面，餐饮企业在硬件上需要打通线上业务和后台系统包括会员管理电子菜谱等应用的优化，另一方面，需要对线上线下的服务进行升级。

餐饮APP IT解决方案

餐厅介绍

餐饮APP对餐饮的创立者，创立历史故事、创意来源，餐厅设计理念，餐厅服务理念进行详细的介绍，了解餐厅文化，让餐厅就餐的客人感受到餐厅的文化

美食展示

讲餐厅的每一道菜品展示到美食栏目，餐厅制作美味佳肴，然后使用像素高的相机拍下每一道经过精心烹饪的食物，经过后期修图，将色香味俱全的美食全部展现在美食app上，让客人在等待上菜的时候能够浏览美食图片，交集等待的心情让他们更加对餐厅的美食充满期待。

资讯导航

在餐饮APP上设置资讯导航栏目，让客人轻松找到自己感兴趣的栏目

手机定位

餐饮APP还可以装置LBS定位系统，让用户手机定位，计算出用户距离餐厅的距离，还需要走多少路。

订位点餐

有了订位点餐功能，客人只需要在手机上下单预定餐厅位子，以及定好当天就餐品类，手机APP下单，方便快捷，为客人解决了预定餐厅位子难，选菜时间长等问题。

用餐点在餐饮APPA上还可以进行详细的点评及商户互动，点评作为反馈信息回馈给餐厅，餐饮企业能根据客人的点评改善餐厅运营情况，提升自己的的市场竞争能力，帮助餐厅树立亲民形象

优惠推送

定期发布优惠信息，并且推送到用户手机中，利用每周的优惠活动或者每日团购等优惠促销手段做好优惠信息推送，利用点评信息分析最受欢迎的彩色，推出客人喜闻乐见的菜市优惠信息

一键呼叫

这个功能用于到场就餐的客人，在用餐过程中，需要服务的时候可以直接点击手机客户端的一键呼叫功能，再也不用挥手大叫“waiter”

以上就是重庆雪印网络科技针对餐饮行业用户需求，提供个性信息化的APP解决方案。

来源：雪印网络

https://www.xuey.net/contents/24/618.html

https://www.xuey.net/contents/24/615.html

https://www.xuey.net/channels/industry-news.html

相关内容[ { "imageUrlCount": 0, "videoUrlCount": 0, "fileUrlCount": 0, "channelId": 24, "siteId": 1, "adminId": 2, "lastEditAdminId": 2, "userId": 0, "taxis": 419, "groupNames": [], "tagNames": [ "书生", "AI", "开源" ], "sourceId": 0, "referenceId": 0, "templateId": 0, "checked": true, "checkedLevel": 0, "hits": 0, "hitsByDay": 0, "hitsByWeek": 0, "hitsByMonth": 0, "lastHitsDate": null, "downloads": 0, "title": "AI十级「找茬」选手，非这个书生莫属，节后开源！", "subTitle": "", "seoTitle": null, "imageUrl": "@upload/images/2022/1/16a2f33a242830a6.jpg", "videoUrl": "", "fileUrl": "", "keywords": "书生AI,开源", "description": "AI十级「找茬」选手，非这个书生莫属，节后开源！", "body": "

$\"\"$

新智元报道

编辑：好困桃子

为了测试，研发团队的大哥都爬树上了！什么模型竟然只需 10% 的训练数据，性能就能超越同行，还会免费开源？

考验你眼力的时候到了！

只看一眼，看出什么了嘛？

$\"\"$

一块木地板？

只答对了一半，其实图中还有一只喵。

下一个问题，这是什么品种的猫？啊...这...

$\"\"$

承认吧，你是辨别不出来的，但是这个 AI「一眼」就搞定了。

而这么厉害的 AI 还有个诗意的名字，叫「书生」。

更厉害的是，基于「书生」的通用视觉开源平台 OpenGVLab 将会在春节后全部公开！

通用？视觉？

近几年，语言模型的发展可谓是相当迅猛，百花齐放。

小到 3.54 亿参数的 BERT，大到 5300 亿参数的威震天-图灵，以及 1.6 万亿参数的混合模型 Switch Transformer，顺便还有首次常识问答超越人类的 KEAR。

$\"\"$

那么，视觉模型这边又如何呢？

目前的 CV 领域主要是图像匹配文本 CLIP 和文本生成图像 DALL·E这种单一模型。

但是 NLP 方向的各种成绩都表明，发展预训练大模型不仅仅能够处理多种复杂任务、适用多种场景和模态，而且能够增加模型的复用率，减少了模型定制化开发的开销进而也降低了成本。

而且，通用模型也是通往通用人工智能的必经之路。

$\"\"$

和通用语言模型类似，通用视觉模型的出发点和训练思路也需要事先通过收集海量的无监督数据。然后通过自监督等方式来训练，得到通用的预训练模型。最后根据具体的下游任务再将通用预训练模型迁移到具体任务上去解决具体问题。

不过，从任务角度看，通用视觉模型主要还是解决纯视觉任务，也涉及一些视觉语言相关的多模态任务，而通用语言模型主要在解决语言相关的任务。而从模型训练角度看，两者的模型结构存在一些差异，具体训练的监督形式也不一样。

但是想要实现模型的通用性，很难。

首当其冲的就是，训练数据不够用。

$\"\"$

训练一个性能合格的深度学习模型，所需的数据采集量，少则十几万，多则千百万张图片，比如自动驾驶和人脸识别，对于数据的需求，达到十亿级别，但性能仍未饱和。

在现实应用中，AI 需要大量业务数据和用户互联网行为数据的融合，而企业可以应用的数据则非常有限。

数据都采集不到，就更不用提什么「高质量」了。

此外，模型对于数据的学习效率又低，无疑又是雪上加霜。

于是，N个任务就需要开发N个高度定制的模型同时，每个模型在训练的时候又需构建标注数据集进行专项训练，并持续进行权重和参数优化。

时间、人力以及资源的成本直接拉满。

$\"\"$

即便如此，依然有人想要挑战一番。

2021 年 11 月，上海人工智能实验室联合商汤科技 SenseTime、香港中文大学、上海交通大学共同发布了新一代通用视觉技术体系——「书生」（INTERN）。

$\"\"$

论文地址：https://arxiv.org/abs/2111.08687

通才是如何练成？

作为通用视觉技术体系的「书生」有三个基础设施模块，分别为：

通用视觉数据系统（GV-Dataset）
通用视觉网络结构（GV-Architecture）
通用视觉评测基准（GV-Benchmark）

$\"\"$

这三个基础模块有什么作用？

它们就像「百科全书」、「高楼基底」一样。「书生」通才的道路上学到的海量知识和建模、评测等基础能力就靠这三个基础模块了。

$\"\"$

具体点讲，其中，在通用视觉数据系统中包含了大量的高质量数据集：

1. 超大量级精标注数据：除了整合现有开源数据集，还进行了大规模数据图像标注任务，涵盖了图像分类，目标检测以及图像分割等任务，数据总量级达到 40M。

分类任务数据量级为 71M，其中包含 9 个公开数据集 28M，以及自标注数据 43M。目标检测任务数据量级为 4M，其中包含 3 个公开数据集 3M，以及自标注数据 1M。

2. 超大标签体系：总标签量级达到 119K，几乎覆盖了所有现有开源数据集，在此基础上扩充了大量细粒度标签。

极大地丰富了图像任务的标签，提供了更为合理的组织方式，以及可扩展的标签延伸策略。

3. 首次提出视界（realm）概念：结合「书生」标签体系，可以极大提升预训练模型的性能。

$\"\"$

在通用视觉网络结构中，MetaNet 是一种自研的模型搜索网络，它最大的变种包含百亿的参数量，是当今最大的视觉网络之一。

这个网络结构结合了视觉卷积和前沿的视觉自关注机制，通过大规模强化学习网络结构搜索算法，取得最佳算子组合，达到模型效率和效用的最大化。

在相同的资源限制的情况下，「书生」的视觉网络获得在不同视觉任务下更优异的精度。

在获得超大规模的视觉神经网络以赋能计算机视觉社区的研究的同时，「书生」的网络支持灵活地进行不同规模的调整，以适应不同程度的工业化落地时的运算能力需求，赋能视觉算法的工业落地。

有了这样的网络结构之后，就可以对其进行了从「基础模型-专家-通才」模型的训练策略，极大地增强这种网络结构的泛化能力。

$\"\"$

第三个便是视觉评测基准，它就像是一个「擂台」，收集了 4 种类型共 26 个下游任务。

不仅包括常规分类任务还包括细粒度分类任务，还包括医疗图像等特殊领域的分类任务、行人检测等热门检测任务，扩展到分割与深度任务，可以很好地衡量模型的泛化能力。

这一视觉评测基准还引入了百分比样本（percentage-shot）的设置。

亮点在于，下游任务训练数据被压缩的同时，还可以很好地保留原始数据集的长尾分布等属性。

$\"\"$

「书生」除了这三个基础设施模块之外，还有四个训练阶段模块。

$\"\"$

在「书生」（INTERN）的四个训练阶段中，前三个阶段位于该技术链条的上游，在模型的表征通用性上发力。

第一阶段，「基础能力」的培养需要经过一个跨模态的预训练过程，通过大量的图像-文本对进行通用模型的预训练，让其学到广泛的基础常识，为后续学习阶段打好基础；

第二阶段，培养「专家能力」，即多个专家模型各自学习某一领域的专业知识，让每一个专家模型高度掌握该领域技能，成为专家；

第三阶段，培养「通用能力」，此时的通才模型继承了大规模多模态的预训练信息，也融合了多样的感知任务的信息，「书生」在各个技能领域都展现优异水平，并具备快速学会新技能的能力。

通过前三个模块阶梯式的学习，「书生」具备了高度的通用性和良好的泛化能力。

当进化到位于下游的第四阶段时，系统将具备「迁移能力」，此时「书生」学到的通用知识可以应用在某一个特定领域的不同任务中。

$\"\"$

从实验结果来看，相较于当前最强 CV 模型 CLIP，「书生」在准确率和数据使用效率上均取得了大幅提升。

具体来讲，在分类识别、目标检测、语义分割及深度估计四大任务 26 个数据集上，「书生」的平均错误率分别降低了 40.2%、47.3%、34.8% 和 9.4%。

$\"\"$

同时，「书生」只需要1/10 的下游数据，就干翻了 CLIP 基于完整下游数据的准确度。

$\"\"$

书生不是「书呆子」

光学不去练，不会用，还是没啥本事。

要明确的是，商汤的「书生」可不是一个书呆子。

怎么讲？

首先，它能够举一反三。

举个形象点的栗子，比如让「书生」识别花的种类，每一类只需要提供 2 个训练样本，识别准确率高达 99.7%。

$\"\"$

这个花卉数据集由 102 种英国常见的花组成，每个类别有 40 至 258 张图片。其中包含有很大的比例、姿势和光线变化。

$\"\"$

它不仅有触类旁通的能力，而且在自动驾驶、智慧城市、智慧医疗等场景均已经实现了落地应用。

就拿自动驾驶来说吧，要想不成为马路杀手，一套 CV 模型需要能够识别各种物体，包括交通标志，车道线识别等，还得预测出与障碍物的距离，行人检测等等。

$\"\"$

对于这些任务，单一视觉模型是无法胜任的。

而「书生」技术体系从数据、模型等各个方面出发，对自动驾驶感知模型，尤其是长尾类别和场景非常友好，在小样本甚至是零样本的应用场景下表现明显优于既往模型。

其实，在实际场景应用中，数据都存在长尾分布的现象，少量类别占据大多数样本，而大量类别仅有少量样本。

在智慧城市中也是同样的道理，面对很多长尾、碎片化场景就不得不祭出通才「书生」了。

生活中，我们经常会见到城市街道上的井盖频频丢失的问题。

$\"\"$

如果 CV 模型没有关注城市治理的长尾问题，偷井盖问题很难得到解决。况且，井盖也有很多种样子。

但是，这对于通才「书生」来讲都是小 case。只要每一类提供 2 个训练样本，问题不就搞定了吗。

$\"\"$

因为它已经在训练阶段被「喂下」大量数据成为通才，只需要看到少量样本，就具备了举一反三的能力。

有了「书生」的加持，不仅可以预防井盖丢失，还能实现事后追责的精细化管理。

$\"\"$

此外，智慧制造、智慧医疗等应用中还会存在很多类似的长尾场景，而通用视觉「书生」的推出能够让业界以更低的成本获得拥有处理多种下游任务能力的 AI 模型。

并以其强大的泛化能力支撑实际场景中大量小数据、零数据等样本缺失的细分和长尾场景需求。

$\"\"$

书生（INTERN）技术体系可以让 AI 模型处理多样化的视觉任务

这些暴力计算下的 AI 场景需要强大的算力作为支撑，这时候 SenseCore 商汤 AI 大装置正好就派上用场了。

AI 大装置正是通过超强的算力基础，为人工智能的研发、创新和应用提供源动力。

$\"\"$

正如商汤科技研究院院长王晓刚所提到的那样：

「书生」通用视觉技术体系是商汤在通用智能技术发展趋势下前瞻性布局的一次尝试，也是 SenseCore 商汤 AI 大装置背景下的一次新技术路径探索。「书生」承载了让人工智能参与处理多种复杂任务、适用多种场景和模态、有效进行小数据和非监督学习并最终具备接近人的通用视觉智能的期盼。希望这套技术体系能够帮助业界更好地探索和应用通用视觉 AI 技术，促进 AI 规模化落地。

不过，想要成为一个优秀的通用视觉模型，「书生」还有三个挑战需要解决：

1. 模型优化速度的提升

对于一个好的预训练模型，往往需要更大更好的网络结构，以及大规模的数据，这就会导致几天甚至几周的模型训练时间，如何在保持表征能力的同时，大幅度加速模型的训练过程，具有非常重大的现实意义。

2. 更大范围内的通用能力仍待探索

书生模型，可以很好地在常见的视觉任务里达到通用的效果。在跨度较大的领域，比如超分等底层视觉任务，书生模型还有很大的进步空间。

3. 大模型到小模型的转变

将大模型的表征能力无损失的迁移到可部署到终端设备上的小模型，对于预训练模型的推广有非常大的价值。

One More Thing

要问这个模型好不好做？

研发急得都直「爬树」！

$\"\"$

为了测试模型在 zero-shot 下的精度如何，书生研发团队的模型科学家都亲自上演了「爬树」特别节目。通过创造特殊场景，以随机生成图片，去考验模型能力。

（研究需要，大家请勿模仿^_^）

「书生」看到后，歪嘴一笑。

这不就是「爬树」嘛，置信度 0.96 给你。

$\"\"$

而且有趣的是，「书生」模型还注意到了树上人眼都很容易忽略的绳子。

可能，这就是「明察秋毫」吧！

$\"\"$

未来，「书生」要做的一件事情：

基于「书生」的通用视觉开源平台 OpenGVLab 也将在今年年初正式开源，产学研一道共创通用 AI 生态！

$\"\"$

而即将开源的 OpenGVLab，正是基于「书生」的通用视觉开源平台。

其中的网络结构除了商汤自研的 MetaNet，还包含大家普遍使用的 ResNet, MobileNet, ViT， EfficientNet 等，以满足不同场景的应用，赋能计算机视觉。

然而，「书生」的布局不止于此。

OpenGVLab 将与上海人工智能实验室此前发布的 OpenMMLab、OpenDILab 一道，共同构筑开源体系 OpenXLab，持续推进通用人工智能的技术突破和生态构建。

「书生」研发团队的一位成员调侃道，「随着书生模型精度越来越高，我们的办公楼层越来越高。」

$\"\"$

开源的「书生」，前景广阔。

", "summary": "基于「书生」的通用视觉开源平台 OpenGVLab 也将在今年年初正式开源，产学研一道共创通用 AI 生态！", "author": "", "source": "新智元", "top": false, "recommend": false, "hot": false, "color": false, "linkUrl": null, "addDate": "2022-01-23 08:59:00", "price": 0.0, "oldPrice": 0.0, "stockQuantity": 0, "priceUnit": null, "isMainContent": true, "allowAddSubContent": false, "relatedContentId": 0, "subContentNum": 0, "mainContent": null, "subContents": null, "attributeIds": null, "attributeValueIds": null, "id": 617, "guid": "12a596f5-b4cf-4c56-8f56-0002d0cca680", "createdDate": "2022-01-23 09:01:27", "lastModifiedDate": "2022-01-23 09:01:27" }, { "imageUrlCount": 0, "videoUrlCount": 0, "fileUrlCount": 0, "channelId": 24, "siteId": 1, "adminId": 2, "lastEditAdminId": 2, "userId": 0, "taxis": 408, "groupNames": [], "tagNames": [ "阿里云", "开源", "云原生", "AppActive" ], "sourceId": 0, "referenceId": 0, "templateId": 0, "checked": true, "checkedLevel": 0, "hits": 0, "hitsByDay": 0, "hitsByWeek": 0, "hitsByMonth": 0, "lastHitsDate": null, "downloads": 0, "title": "阿里云开源业内首个应用多活项目 AppActive，与社区共建云原生容灾标准", "subTitle": "", "seoTitle": null, "imageUrl": "@upload/images/2022/1/660e937c3970198a.webp", "videoUrl": "", "fileUrl": "", "keywords": "阿里云,开源,AppActive,云原生", "description": "阿里云开源业内首个应用多活项目 AppActive，与社区共建云原生容灾标准", "body": "

作者：中西（github @zhongxig），AppActive 负责人，来自阿里云云原生高可用架构团队，从事容灾架构和故障快恢的研发和开源工作。

摘要：继高可用架构团队的 Sentinel、Chaosblade 开源后，第三个重磅高可用产品：应用多活 AppActive 正式开源，形成高可用的三架马车，帮助企业构建稳定可靠的企业级生产系统，提高企业面对容灾、容错、容量等问题的稳态系统建设能力。

$\"\"$

1 月 11 日，在上海的云原生实战峰会上，阿里云智能研究员丁宇发布了“应用多活技术白皮书”，同时为了推动业界容灾的发展，建立云原生业务容灾标准，阿里云对外开源“应用多活”中间件：AppActive。

$\"\"$

什么是 AppActive

“业务大规模扩展机房资源不可用怎么办？机房挂了怎么办？业务突然奔溃怎么办？台风地震导致断电怎么办？”

2013 年，当时淘宝完成去 O 没多久，双十一的规模较上年进一步飞增。阿里的工程师正面临着上述的这一系列问题，一方面是机房资源非常紧张，容量不足，另一方面是杭州出现罕见的高温天气，机房面临断电的风险。异地多活架构在这个背景下孵化出来，它的载体是集团版本的 UnitRouter&UnitBrain 。

随着淘宝的业务规模演进，异地多活也从近距离同城双机房到远距离异地双活，再到三地四单元、多地多活，沉淀了丰富的机房级应用多活经验。

2019 年，阿里巴巴系统全面上云，异地多活架构也跟着上云的节奏孵化出阿里云云产品 AHAS-MSHA，服务集团和云上客户

2022 年 1 月 11 日，AHAS-MSHA 代码正式开源，命名为 AppActive 。

AppActive 是一个面向业务应用构建云原生高可用多活容灾架构的开源中间件，它的主要价值：

分钟级 RTO。恢复时间快，阿里内部生产级别恢复时间平均在 30s 以内，外部客户生产系统恢复时间平均在 1 分钟。
资源充分利用。资源不存在闲置的问题，多机房多资源充分利用，避免资源浪费。
切换成功率高。依托于成熟的多活技术架构和可视化运维平台，相较于现有容灾架构，切换成功率高，阿里内部年切流数千次的成功率高达 99.9% 以上。
流量精准控制。应用多活支持流量自顶到底封闭，依托精准引流能力将特定业务流量打入对应机房，企业可基于此优势能力孵化全域灰度、重点流量保障等特性。

为什么开源

通过服务阿里集团近 9 年实战经验及服务云上客户 2 年多的商业化迭代积累，AHAS-MSHA 已经在涵盖阿里的十余家大型企业的容灾场景中落地，使用量在持续增长，代码的稳定性和功能特性也经过充分的检验。

2021 年，国内外多家知名公司、云平台出现较严重服务中断、宕机事件。这也为企业敲响警钟，越来越多的企业把容灾建设提上日程。在解决容灾问题的同时，为了保持对成本的控制、支撑未来的多云架构演进和灾难容灾的确定性，许多企业选择以多活容灾的方式进行尝试。

但是业内对于多活没有统一的认知，对于“多活”这个词不同企业有不同的定义，很多企业往往以为已经实现了“多活”，可当故障来临的时候，才发现当前系统的故障逃逸能力非常弱，业务恢复和故障定位无法解耦，拖累了企业生产，造成了外部舆情、资金损失等问题；另外，有的企业在了解“多活”之后，下意识想要企业内部先投入资源进行技术预演，但由于缺少经验，往往会造成人力物力等资源的重复浪费。随着云原生技术发展，越来越多的客户采用云原生技术进行系统构建。如何在云原生上构建稳定高可用的系统，是一个核心挑战。“多活”的认知偏差会加剧企业在基础设施成本、应用改造成本、运维成本等成本面的投入，但存在效率低下、错用甚至无用或者不用的问题，从而享受不到“多活”带来的稳定性红利。因此“多活”需要一个相对统一的标准与认知，加深使用者对它的理解和使用，从而提高业务系统的稳定性。

在当前云原生发展的现状和市场认知下，AppActive 的项目负责人中西表示，应用多活的开源和解读，可以初步定义“多活”的标准和实现，帮助开发者形成统一的“多活”认知。在企业构建多活架构时，基于应用多活共享已有的成熟经验，避免多余的资源浪费。同时，不同的企业具备不同的业务场景和优势，反向推动应用多活进一步完善和演进成熟的多活形态及能力。希望依靠社区的力量，让“多活”成为一项事实意义的普惠技术，而不是望而却步的部分人可用技术，帮助更多的企业和个人构建生产级别的高可用架构。

开源的内容

AppActive 标准介绍

$\"\"$

在应用多活的标准定义里有 LRA（同城多活）、UDA（异地多活）、HCA（混合云多活）和 BFA（业务流量多活），详细见《应用多活技术白皮书》。在 AppActive v0.1 版本中，我们优先实现 BFA 和 UDA 的基础能力，在后续版本中完善 BFA 和 UDA 的同时，新增 LRA、HCA 能力。本文重点介绍 BFA、UDA。

1. 业务流量多活（BFABusiness Flow Active）

BFA，指的是应用多活的最终呈现是业务，多活容灾系统具备按照业务特征进行生产流量的精细化调配。

$\"\"$

AppActive 在 BFA 指标中，支持流量自动纠偏，强路由到指定机房自闭环，属于流量的精细化调配。

在非法流量打入机房时，机房的各层插件均会依托于统一的调度规则进行处理：

接入层识别错误流量，自动纠错到正确的机房。
服务层识别错误流量，自动纠错到正确的机房。
数据层识别错误流量，为保证数据质量，抛出异常，写入失败。

2. 异地多活（UDA，Ultra Distance Active）

UDA，指的是在超远距离（机房间距超过 300 公里）时，业务系统仍具备较好的访问性能。进入容灾态时，RTO、RPO 在分钟级。

$\"\"$

AppActive 在 UDA 指标中，支持访问性能良好。

在接入层支持流量解析，将请求流量进行解析，将流量打入机房的应用机器。基于应用侧 Servlet 插件、Dubbo 插件、MySQL 插件的能力，业务流量请求在单一机房里面自闭环，最终读写到本机房的数据库。

在超远距离场景下，由于流量封闭在机房内部，因此业务系统仍旧具备较好的访问性能。

进入容灾态的 RPO 由开源数据同步组件或商业化同步工具进行保障，RTO 在 AppActive 0.1 版本中仅提供初级的流量切换能力，后续版本会演进到生产级别 RTO 保障工具。

AppActive 模块介绍

AppActive 属于应用多活的一种定义和实现，它有数据平面和管控平面的整体实现。数据平面分为 4 部分，均支持在不变更原有企业使用技术组件基础上，以插件的形式增加能力：

接入网关。接入网关作为业务流量打入机房的第一跳，负责应用多活入口流量的识别和分发，具备机房路由和应用路由两个核心能力。
服务层。业务流量在机房内部和跨机房的同步调用方式，一般有 Consumer、Provider、注册中心等角色，具备流量路由、流量保护、故障隔离三个核心能力，避免调用错误导致的数据脏写，加速切流期间的业务恢复。
消息层。业务流量在机房内部和跨机房的异步调用方式，基于消息削峰填谷，一般有 Producer、Consumer、Broker 等角色，具备流量路由、流量保护、故障隔离三个核心能力，避免消息错投导致的数据脏写，保护切流期间消息不丢。
数据层：涵盖业务应用数据读写、数据存储和数据同步，其具备流量路由、数据一致性保护、数据同步三个核心能力。

管控平面核心涵盖多活容灾规则的日常运维和灾难场景的流量切换。

$\"\"$

当前 AppActive 处于 v0.1 版本，开源：

上述的数据平面所有层的定义基础实现。
接入层网关的 Nginx 插件实现。
服务层 Dubbo2.x 插件实现。
数据层开源 MySQL 插件实现。
管控平面流量切换的基础能力。

开发者可基于 v0.1 的能力，进行应用多活的基本功能运行和验证。

AppActive 后续规划

丰富接入层、服务层、数据层插件，支持更多技术组件到 AppActive 支持的列表中。
增加消息层的插件实现，支持消息应用多活能力。
增加其他层在应用多活的标准和实现。
支持 Web 白屏化，follow 应用多活 UDA 的标准，提升 RTO。
遵循应用多活 HCA 标准支持混合云多活形态。
遵循应用多活 LRA 标准支持同城多活形态

起点

“异地多活”和“单元化”源于阿里，也受到了业界的认可。阿里也一直希望应用多活的产品生态可以做到标准和开放，对业界做出贡献。

基于应用多活的标准技术，业务应用在不同的云厂商之间，不同的基础设施之间，不同的芯片之间都可以实现互通互联。业务应用在资源充分利用的同时，达到分钟级甚至秒级的 RTO 指标，真正意义的做到不惧故障。

今天，AppActive 开源的第一个版本只是应用多活领域的一个起点，欢迎大家参与进来一起共建应用多活生态。想要了解更多 AppActive，钉钉搜索群号：34222602，加入 AppActive 开源讨论群参与讨论吧！

$\"\"$

点击此处，立即前往下载《应用多活技术白皮书》。

", "summary": "继高可用架构团队的 Sentinel、Chaosblade 开源后，第三个重磅高可用产品：应用多活 AppActive 正式开源，形成高可用的三架马车，帮助企业构建稳定可靠的企业级生产系统，提高企业面对容灾、容错、容量等问题的稳态系统建设能力。", "author": "", "source": "oschina", "top": false, "recommend": false, "hot": false, "color": false, "linkUrl": null, "addDate": "2022-01-20 17:42:00", "price": 0.0, "oldPrice": 0.0, "stockQuantity": 0, "priceUnit": null, "isMainContent": true, "allowAddSubContent": false, "relatedContentId": 0, "subContentNum": 0, "mainContent": null, "subContents": null, "attributeIds": null, "attributeValueIds": null, "id": 593, "guid": "1dfd72f1-ac81-4b1e-9984-4fe6f1ae022c", "createdDate": "2022-01-20 17:44:38", "lastModifiedDate": "2022-01-20 17:44:38" }, { "imageUrlCount": 0, "videoUrlCount": 0, "fileUrlCount": 0, "channelId": 24, "siteId": 1, "adminId": 2, "lastEditAdminId": 2, "userId": 0, "taxis": 364, "groupNames": [], "tagNames": [ "微软", "IndexNow", "搜索引擎" ], "sourceId": 0, "referenceId": 0, "templateId": 0, "checked": true, "checkedLevel": 0, "hits": 0, "hitsByDay": 0, "hitsByWeek": 0, "hitsByMonth": 0, "lastHitsDate": null, "downloads": 0, "title": "微软发布 IndexNow 开源插件，自动将网站变化推送到搜索引擎", "subTitle": "", "seoTitle": null, "imageUrl": "@upload/images/2022/1/a60362665871a5c6.jpg", "videoUrl": "", "fileUrl": "", "keywords": "微软,IndexNow,搜索引擎", "description": "微软发布 IndexNow 开源插件，自动将网站变化推送到搜索引擎", "body": "

微软日前发布了一个名为「IndexNow Plugin」的 WordPress 插件，让开发者/作者的 WordPress 网站/博客能够与 IndexNow 协议更加轻松地进行整合。目前该插件已可在 WordPress 官网的插件菜单中找到。

IndexNow 本身是微软 Bing 与俄罗斯 Yandex 一同推出的协议，可以让网站所有者在网站内容出现变化后通知搜索引擎，让搜索引擎立即索引这些页面和内容。这是一个开放的协议，任何搜索引擎都能使用，但目前只有 Bing 和 Yandex 采用了该协议。

IndexNow 使用起来也非常简单，仅需三个步骤：

使用在线密钥生成工具生成一个 IndexNow 协议所支持的密钥；
在网站根目录中，以文本文件来托管该密钥，并以密钥的值命名；
当 URL 被创建、更新或删除时，开始提交 URL。你可以在 API 每次被调用时提交一个 URL 或一组 URL。

进行上述操作后，搜索引擎就能够迅速在其搜索结果中反映这一变化。

$\"\"$

而微软日前所发布的 IndexNow Plugin 则是一个针对 WordPress 开发的插件，IndexNow Plugin 能够让上述已经足够简单的步骤变得更加“傻瓜式”，完全不需要进行额外的设置。

该插件能够自动将 WordPress 网站的 URL 提交给支持 IndexNow 协议的搜索引擎。一旦安装，该插件将自动生成并在你的网站上托管 API 密钥。它会自动检测 WordPress 中的页面创建、更新或删除，并在后台提交 URL。

IndexNow Plugin 插件还包含更多方便用户使用的功能：

查看插件中最近提交的 URL 列表；
从最近的提交列表中重试任何失败的提交；
下载最近提交的 URL 以供分析；
最近成功和失败提交的状态；
……

IndexNow Plugin 已被微软开源，以 GPLv2 协议托管在微软的 GitHub 仓库。向搜索引擎提供网站的最新内容也是 SEO 的一个重要任务，IndexNow 协议和此次发布的最新插件将大幅简化这项工作。

", "summary": "微软日前发布了一个名为「IndexNow Plugin」的 WordPress 插件，让开发者/作者的 WordPress 网站/博客能够与 IndexNow 协议更加轻松地进行整合。目前该插件已可在 WordPress 官网的插件菜单中找到。", "author": "", "source": "oschina", "top": false, "recommend": false, "hot": false, "color": false, "linkUrl": null, "addDate": "2022-01-09 19:09:00", "price": 0.0, "oldPrice": 0.0, "stockQuantity": 0, "priceUnit": null, "isMainContent": true, "allowAddSubContent": false, "relatedContentId": 0, "subContentNum": 0, "mainContent": null, "subContents": null, "attributeIds": null, "attributeValueIds": null, "id": 545, "guid": "6fac9baf-c704-4a1c-84c1-5f7e62a511ce", "createdDate": "2022-01-09 19:11:44", "lastModifiedDate": "2022-01-09 19:11:44" }, { "imageUrlCount": 0, "videoUrlCount": 0, "fileUrlCount": 0, "channelId": 24, "siteId": 1, "adminId": 2, "lastEditAdminId": 2, "userId": 0, "taxis": 340, "groupNames": [], "tagNames": [ "log4j", "开源", "安全治理" ], "sourceId": 0, "referenceId": 0, "templateId": 0, "checked": true, "checkedLevel": 0, "hits": 0, "hitsByDay": 0, "hitsByWeek": 0, "hitsByMonth": 0, "lastHitsDate": null, "downloads": 0, "title": "log4j 2漏洞爆发，开源软件安全治理正当时！", "subTitle": "", "seoTitle": null, "imageUrl": "@upload/images/2021/12/2ed2634f57ed5ac4.jpg", "videoUrl": "", "fileUrl": "", "keywords": "log4j,开源,安全治理", "description": "log4j 2漏洞爆发，开源软件安全治理正当时！", "body": "

近年来，随着云计算、AI、IOT 等技术的不断发展，IT 等信息技术领域也有了新的突破，可以更好的赋能关键信息基础设施建设。然而，安全作为主旋律，一直是备受关注的焦点。一方面，传统安全防护措施的缺失，对于新型高级威胁缺少防护壁垒；另一方面，开源趋势下，事后防御的手段已不满足安全需求，“安全左移”下提出了更高的安全需求。

尤其是，近日影响力巨大的 log4j 2.x 的漏洞事件，引起了轩然大波。包括之前的 solarwinds 事件、Apace Strust2 等漏洞事件都为我们敲响了安全警钟。如何做好此类事件的威胁防护、开源安全的风险治理是需要大家积极探讨的新命题。

12 月 30 日，由悬镜安全、OpenSCA 联合主办的全球首款企业级 OpenSCA 技术开源发布会在北京举行，会议现场，针对“开源软件”、“供应链安全”等热点带来不同角度的学术探讨与实践分享，共同探讨开源产业生态下的安全新态势。

用开源的方式做开源风险治理

大会现场，悬镜安全创始人兼 CEO 子芽围绕“开源”、“风险治理”、“OpenSCA”等关键词分享了如何用开源的方式做开源风险治理。

$\"log4j$
悬镜安全创始人兼 CEO 子芽分享

子芽表示，应用开源是大势所趋，但是避免不了 Web 通用漏洞、业务逻辑漏洞、开源成分的缺陷及后门等漏洞问题，而用开源的方式做开源风险治理，可以让开源用多样性拥抱不确定性，形成开源新范式。

此次，悬镜安全对外发布 OpenSCA 开源技术，是为了解决看不清、摸不透、跟不上、防不住的治理难题。OpenSCA 作为悬镜安全旗下商业级 SCA 产品源鉴 OSS 开源威胁管控平台的开源版本，它继承了源鉴 OSS 的多源 SCA 开源应用安全缺陷检测核心能力。悬镜把 OpenSCA 技术开源，对于守护中国软件供应链安全有着重要的意义。

据了解，悬镜安全数十位来自北大的科研人员、行业专家智库，历时 26280 个小时潜心打磨，提出了“用开源的方式做开源风险治理”，用简单的配置即可完成对开源组件所使用的成分进行检测，深度挖掘组件中潜藏的各类安全漏洞及开源协议风险，进而助力企业进行开源风险的识别及治理。

开源软件下软件供应链安全如何治理

log4j 2 漏洞是近期圈内和圈外讨论热度都较高的话题，Apache Log4j 是一个基于 Java 的日志记录工具，基本 70% 以上的企业都有使用的开源代码。log4j 2 漏洞的爆发给我们带来的警示是什么？开源的软件如何保证安全？log4j 2 究竟是“黑天鹅”还是“灰犀牛”？

$\"log4j$

基于以上问题国家信息技术安全研究中心总师组专家杨韬认为：“这是一个大事，但并不是新鲜事。对于应对漏洞，产品和服务的提供者以及网络运营者，需要在未来很长的一段时间之内做好心理准备和 0day 漏洞共存。”

北京赛博英杰科技有限公司创始人兼董事长表示：“企业要敢于盘家底，要排查有多少系统用了该工具，所有配置设置都要了解清楚。”

随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。其中，开源软件的安全问题尤其值得关注。

东方通集团副总裁朱木林认为：“开源社区难以管理，开源代码的漏洞很多，因此要积极拥抱开源，如果厂商、监管以及国家三方合力形成一种机制，一起营运管理开源软件的安全生态。”

“log4j 2 漏洞的爆发，站在战略投资的角度来说，让安全领域成为了资本所青睐的对象”，同时国家也会有更多的政策倾斜到这一领域。”百度工程效能部效率云技术总监及开源中国联席产品主席张伟军如是说。

悬镜安全 CTO 宁戈则认为开源的风险治理是比较严重的问题，因为开源组件的维护都是社区自发的，安全力量投入不足，另外开源社区的发展是无序进化的状态，对于安全治理也是比较难的。

“黑天鹅”一般指那些出乎意料发生的小概率风险事件；“灰犀牛”指那些经常被提示却没有得到充分重视的大概率风险事件。相对于开源软件来说，面对的“黑犀牛”的威胁是更多的，因此安全治理必须要考虑。

据不完全统计，全球 97% 的软件开发者和 99% 的企业使用开源软件，基础软件、工业软件、新兴平台软件大多基于开源，开源软件已经成为软件产业创新源泉和“标准件库”。与此同时，开源许可证的兼容性问题、开源项目的合规问题、开源安全漏洞问题和开源知识产权的侵权等问题也日趋凸显。

未来，悬镜安全将依托软件供应链安全技术，布局开源安全产业生态，以前瞻性产业视角视角构筑行业安全生产线，不断拓展人类认知实践的边界，在更大的范围帮助更多的企业实现开源风险治理，助力开源生态健康有序发展。

如何参与 OpenSCA 开源项目

一、OpenSCA 官网：

https://opensca.xmirror.cn/

二、OpenSCA 开源项目地址

1. 本地检测工具

GitHub：

https://github.com/XmirrorSecurity/OpenSCA-cli

Gitee：

https://gitee.com/XmirrorSecurity/OpenSCA-cli

2. IDEA 插件

GitHub：

https://github.com/XmirrorSecurity/OpenSCA-intellij-plugin

Gitee：

https://gitee.com/XmirrorSecurity/OpenSCA-intellij-plugin

", "summary": "近年来，随着云计算、AI、IOT 等技术的不断发展，IT 等信息技术领域也有了新的突破，可以更好的赋能关键信息基础设施建设。然而，安全作为主旋律，一直是备受关注的焦点。", "author": "", "source": "雷锋网", "top": false, "recommend": false, "hot": false, "color": false, "linkUrl": null, "addDate": "2021-12-31 23:32:00", "price": 0.0, "oldPrice": 0.0, "stockQuantity": 0, "priceUnit": null, "isMainContent": true, "allowAddSubContent": false, "relatedContentId": 0, "subContentNum": 0, "mainContent": null, "subContents": null, "attributeIds": null, "attributeValueIds": null, "id": 518, "guid": "6255d0f6-d5d1-4705-860e-a30451875445", "createdDate": "2021-12-31 23:35:05", "lastModifiedDate": "2021-12-31 23:35:05" }, { "imageUrlCount": 0, "videoUrlCount": 0, "fileUrlCount": 0, "channelId": 24, "siteId": 1, "adminId": 2, "lastEditAdminId": 2, "userId": 0, "taxis": 222, "groupNames": [], "tagNames": [ "前端", "开源", "复选框" ], "sourceId": 0, "referenceId": 0, "templateId": 0, "checked": true, "checkedLevel": 0, "hits": 0, "hitsByDay": 0, "hitsByWeek": 0, "hitsByMonth": 0, "lastHitsDate": null, "downloads": 0, "title": "前端小哥玩HTML复选框上瘾，能画logo做视频，还开源成JS库", "subTitle": "", "seoTitle": null, "imageUrl": "@upload/images/2021/10/e3ce8e5ec071b00e.png", "videoUrl": "", "fileUrl": "", "keywords": "前端,开源，复选框", "description": "前端小哥玩HTML复选框上瘾，能画logo做视频，还开源成JS库", "body": "

量子位报道公众号 QbitAI

万万没想到，如此普通的复选框，竟也能玩出这种高度！

例如点一下复选框，屏幕就像被投入石子的水面泛出波纹：

$\"\"$

设定好初始状态，就可以开始展示《生命游戏》的演化过程；

$\"\"$

控制上下左右，还能还原经典游戏《贪吃蛇》；

$\"\"$

这就是一位做前端开发的小哥 Bryan，近期在自己的网站上发布的有关checkbox（复选框）的新玩法。

这个项目在 Hacker News 上引来了大量网友评论。

$\"\"$

高赞评论已经给小朋友安排得明明白白了~

而面对一些诸如“为什么要用复选框，普通像素就可以达到这种效果”的质疑，也有人为 Bryan 说话：

回到这件事本身，其实在去年早些时候，他就建了一个名为 Checkboxland 的 JavaScript 库。

它可以将任何内容呈现为 HTML 复选框。

$\"\"$

还有更厉害的玩法

讲真，刚才展示的复选框效果，只能说是“开胃菜”。

不仅仅是简单的动画，日常拍下的照片，记录的生活 vlog，一样可以成为“复选框”的素材。

小哥本人也一度以为灵感耗尽，但在参阅了一篇关于将图像转化为 ASCII 的文章之后，Bryan 将耐克和苹果的 logo 转化了出来（不建议转化迪士尼的 logo）。

$\"\"$

小哥本人也是老二次元了，《Bad Apple》也是信手拈来：

$\"\"$

随后，自嘲“the CheckBox guy”的小哥赋予了复选框更多的可能，他又拓展了 Checkboxland API，用来加载任何视频并生成复选框版本。

下面这个看起来就像进入了《星际穿越》的五维立方体。

$\"\"$

而此刻你如果打开摄像头，Bryan 还可以带领你半只脚踏进《黑客帝国》~

$\"\"$

赶快学起来，说不定还能用来画心形图，成为你的表白神器（不是）！

复选框花式玩法，什么原理？

看似炫酷的效果实际制作过程只需分为两大步，手把手教你！

1. 做出原本的图像。

2. 将图像转化为 ASCII 文本输出。

以水波为例，首先要生成这样动态的水波。

$\"\"$

想要生成它，需要以中心为原点，在 xy 平面上建立正弦函数。

z 轴垂直屏幕向外，把z轴的数值转化为灰度，白色为波峰，黑色为波谷。

$\"\"$

然后在图形计算器 desmos 上让水波动起来，这样第一步就完成了。

$\"\"$

第二步，将第一步的成果转化为 ASCII 码输出。

这一步的转化主要涉及到将彩色对应灰度。

采用这个公式，即使是彩色的图片，也只不过是五彩斑斓的灰罢了~

GrayScale = 0.21 R + 0.72 G + 0.07 B

提取原图的 RGB 色彩，输出为灰度：

const toGrayScale = (r, g, b) => 0.21 * r + 0.72 * g + 0.07 * b;

const convertToGrayScales = (context, width, height) => {

const imageData = context.getImageData (0, 0, width, height);

const grayScales = [];

for (let i = 0 ; i < imageData.data.length ; i += 4) {

const r = imageData.data[i];

const g = imageData.data[i + 1];

const b = imageData.data[i + 2];

const grayScale = toGrayScale (r, g, b);

imageData.data[i] = imageData.data[i + 1] = imageData.data[i + 2] = grayScale;

grayScales.push (grayScale);

context.putImageData (imageData, 0, 0);

return grayScales;

然后为每个像素赋灰度值：

const grayRamp = '$@B%8&WM#*oahkbdpqwmZO0QLCJUYXzcvunxrjft/()1{}[]?-_+~<>i!lI;:,"^`\\'. ';

const rampLength = grayRamp.length;

const getCharacterForGrayScale = grayScale => grayRamp[Math.ceil ((rampLength - 1) * grayScale / 255)];

const asciiImage = document.querySelector ('pre#ascii');

const drawAscii = (grayScales) => {

const ascii = grayScales.reduce ((asciiImage, grayScale) => {

return asciiImage + getCharacterForGrayScale (grayScale);

}， '');

asciiImage.textContent = ascii;

最后调整一下图片大小就大功告成了~更多详细内容见文后链接~

$\"\"$

在线可玩，快来试试

在最近的更新中，Bryan 称，他创造新天地的事情将暂时告一段落。

但是他不仅留下了复选框新玩法原理的详细介绍，还有自制的丰富的 demos。这些足以让你探索创造。

简单的动画，贪吃蛇，通过摄像头实时生成复选框版图像（demos 中的 webcam）…

点击即可试玩，以贪吃蛇和 webcam 为例：

点击 snake，键盘上下左右即可控制贪吃蛇：

$\"\"$

点击 webcam，打开前置摄像头，可以看到自己的实时动态：

$\"\"$

根据网友的反馈，似乎在安卓系统中打开会白屏，但是在 Mac Safari, iPhone Safari, 桌面 Chrome 上都可以使用。

感兴趣的小伙伴，快来试试吧~

[1]https://www.bryanbraun.com/2021/09/21/i-keep-making-things-out-of-checkboxes/

[2]https://news.ycombinator.com/item?id=28826018

[3]https://www.jonathan-petitcolas.com/2017/12/28/converting-image-to-ascii-art.html

[4]https://www.bryanbraun.com/checkboxland/#demos

[5]https://github.com/bryanbraun/checkboxland

", "summary": "万万没想到，如此普通的复选框，竟也能玩出这种高度！", "author": "行早", "source": "凹非寺", "top": false, "recommend": false, "hot": false, "color": false, "linkUrl": null, "addDate": "2021-10-25 11:55:00", "price": 0.0, "oldPrice": 0.0, "stockQuantity": 0, "priceUnit": null, "isMainContent": true, "allowAddSubContent": false, "relatedContentId": 0, "subContentNum": 0, "mainContent": null, "subContents": null, "attributeIds": null, "attributeValueIds": null, "id": 382, "guid": "fcaffda3-90f8-4e02-984a-b24794172131", "createdDate": "2021-10-25 11:57:23", "lastModifiedDate": "2021-10-25 11:57:23" }, { "imageUrlCount": 0, "videoUrlCount": 0, "fileUrlCount": 0, "channelId": 24, "siteId": 1, "adminId": 2, "lastEditAdminId": 2, "userId": 0, "taxis": 221, "groupNames": [], "tagNames": [ "开源", "微软", ".NET" ], "sourceId": 0, "referenceId": 0, "templateId": 0, "checked": true, "checkedLevel": 0, "hits": 0, "hitsByDay": 0, "hitsByWeek": 0, "hitsByMonth": 0, "lastHitsDate": null, "downloads": 0, "title": "在开源社区的强烈抗议下微软逆转了有争议的.NET变化", "subTitle": "", "seoTitle": null, "imageUrl": "", "videoUrl": "", "fileUrl": "", "keywords": "开源,微软,.NET", "description": "在开源社区的强烈抗议下微软逆转了有争议的.NET变化", "body": "

在开源社区的公开抗议下，微软正在改变从其即将发布的 .NET 6 中删除一个关键功能的决定。本周早些时候，微软因为商业利益原因在即将发布的 .NET 6 中删除了 Hot Reload（热重载）的一个关键部分，从而激怒了 .NET 开源社区，该功能允许开发者在应用运行时修改源代码，并立即看到结果。

$\"hotreload.gif\"$

这是一个许多人一直期待在 Visual Studio Code 和多个平台上使用的功能，直到微软在最后一刻做出了一个有争议的决定，将其锁定在 Visual Studio 2022，这是一个仅限于 Windows 的付费产品，据透露，最后一刻的改变是由微软开发者部门的负责人 Julia Liuson 做出的，是一个以商业利益为考量的举措。

"微软承认它犯了一个错误"

在引起反响后，微软现在已经推翻了这一改变，微软自己的许多员工在公司内部也很愤怒。"我们在执行我们的决定时犯了一个错误，花了比预期更长的时间来回应社区，".NET 项目管理主任 Scott Hunter 解释说。微软现在已经批准了社区的拉动请求，重新启用这一功能，它将在 .NET 6 SDK 的最终版本中提供。

媒体要求微软对一位高管下令改变这一事实进行评论，但该公司不想讨论这一有争议的决定。"我们已经采取措施来解决我们的一些 OSS 社区成员遇到的问题，"微软发言人在一份声明中说。"热重载功能将出现在 11 月 8 日提供的 .NET 6 SDK 的一般可用性构建中。"

不过，微软的博客文章并没有谈到这个有争议的决定。相反，它表明删除代码而不是简单地禁用它只是一个错误，而不是一个商业决定。亨特说："在我们努力扩大范围的过程中，我们无意中最终删除了源代码，而不是仅仅不调用该代码路径，"。

虽然对 .NET 社区来说，这种逆转是值得欢迎的，但对那些重视这种决策透明度的人来说，围绕这一事件的解释和情况不会让他们感到轻松。

亨特说："就像许多公司一样，我们正在学习平衡开放源码软件社区的需求和作为 .NET 的企业赞助商，有时我们不能正确地处理这个问题。当我们没有做到这一点时，我们能做的就是从我们的错误中学习，并更好地向前迈进。"

这一事件发生在 .NET 社区因微软参与 .NET 基金会而产生的数周动荡之后。该基金会是在 2014 年微软将 .NET 开源时创建的，它应该是一个独立的组织，其存在是为了改善 .NET 的开源软件开发和合作。一位辞职的董事会成员最近对 .NET 基金会的作用提出质疑，他问道："在这里是为了执行微软对 .NET 开源的意志，还是为了帮助培养和促进一个健康的社区？"

最近的一场争论也导致了 .NET 基金会执行董事 Claire Novotny 最近辞职，还有人质疑鉴于微软在其中的特权以及 .NET 基金会的独立性。微软的这一转折无疑损害了它十年来所建立的一些开源工作，该公司在改善与 .NET 社区的关系以及围绕其对 .NET 基金会的影响的问题上仍有许多工作要做。

$\"1.jpg\"$