云原生

<article class=“article fmt article-content”><h2>01 构建面向 AI、大数据、容器的可观测体系</h2><h3>（一）智算服务可观测详情</h3><p>对于越来越火爆的人工智能畛域来说，MLOps 是解决这一畛域的系统工程，它联合了所有与机器学习相干的工作和流程，从数据管理、建模、继续部署的到运行时计算和资源管理。下图是开源 ML-Ops 平台 MLReef 在 2021 年公布的 ML 市场相干工具和平台玩家。时至今日，相干工具与平台玩家数量放弃着继续高速增长。以后，随着大语言模型（LLM）从新兴技术倒退为支流技术，以大模型为核心技术的产品将迎来全新迭代。</p><p></p><p>近期，阿里云策略进行了肯定调整，确立“AI 驱动，私有云优先”外围策略。在 AI 畛域有哪些产品布局呢？</p><ul><li>基础设施及服务 IaaS 层</li></ul><p>在计算、存储、网络、平安产品中提供以“灵骏”智算服务为特色的软硬件一体化的算力集群服务；</p><ul><li>容器即服务 CaaS 层</li></ul><p>laaS 层之上以 Kubernetes 为代表的容器技术，已成为云计算的新界面，“ACK 灵骏托管集群”+“云原生 AI 套件”产品组合能够高效治理异构资源，提供 AI、HPC 等高性能计算场景下的云原生加强能力；</p><ul><li>平台即服务 PaaS 层</li></ul><p>CaaS 之上的平台即服务 PaaS 层构建了以“人工智能平台 PAI”为外围，提供一站式机器学习解决方案；</p><ul><li>模型即服务 MaaS 层</li></ul><p>提供“灵机模型服务 DashScope”、通义大模型和各行业生态大模型、企业专属定制大模型及 ModelScope 魔搭社区供业内交换，围绕 AI 各畛域模型，通过标准化 API 提供模型推理、模型微调训练在内的多种服务。</p><p></p><p>AI 时代下有新技术栈，包含新技术、新数据类型及新工作流。目前可观测畛域产品更多服务于利用开发者，针对 ML 开发者也须要配套的工具来更好地进行调试、运维及公布模型服务。为了更好的帮忙大家了解，咱们先讲讲可观测行业头部企业 DataDog 如何做 AI 可观测。所谓的 AI 端到端可观测即从 Infrastructure，Vector Database 再到 Model 和 orchestration framework。DataDog 早已推出了 OpenAI 即 model 这一层的可观测能力，包含 api 费用、接口响应及 prompt，播种了十分多小客户。</p><p>本次 2023 Dash 大会将模型从 OpenAI GPT 模型延长到了更多模型，基本上实现下面所有模型的可观测能力。随着各种大模型不断丰富，每一次申请波及到的链路会非常复杂，对于应用方来说都是黑盒。因而 DataDog 推出 LLM Model Catalog，不便开发者去观测链路上各个节点的异样，界面十分相似 APM 服务列表和链路查问性能。基于 Catalog，不仅能够依照模型提供方维度，服务维度，环境维度等进行浏览，清晰看到不同模型性能、申请提早、申请量以及费用。还能够针对 prompt 进行监控，减少了对立的反馈性能，来对 prompt 后果对立剖析。接下来，咱们看看国内厂商针对 AI 场景在做进行哪些摸索。</p><p></p><h3>（二）Prometheus 云产品可观测监控生态</h3><p>既然围绕 AI 的可观测要有一套规范体系，谁来做 AI 可观测更为适合呢？咱们的答复是 Prometheus，因为他天生符合了云原生架构，在开源畛域 Prometheus 处于 Metrics 事实标准的市场位置。</p><p>当今多种行业都在做云原生化革新背景下，Prometheus 在架构、性能维度与 Kubernetes 人造集成。它具备主动服务发现、多层次采集能力、生态弱小、通用多模指标模型及弱小的 PromQL 查问语法等特点。下图是阿里云所提供的全栈可观测能力，外面囊括了上百款阿里云产品的监控，笼罩基础设施、容器、中间件、利用等各个层面，而这些产品监控都由 Prometheus 撑持。</p><p></p><p>阿里云 Prometheus 集成的泛滥云产品业务指标，针对云产品多租需要提供了一整套残缺的解决方案。每个阿里云云产品除对产品本身指标监控外，同时须要对产品售卖租户指标进行监控。云产品针对租户资源划分次要分为租户独占资源、租户共享资源两种模式，能够给资源打租户标签或云产品自行添加租户信息形式来辨别租户。</p><p>阿里云Prometheus 监控绝对开源 Prometheus 采纳采集、存储查问拆散架构，采集端具备多租辨认和散发能力，存储端内置多租能力，租户之间资源是齐全隔离的。阿里云 Prometheus 会每个阿里云用户创立一个 Prometheus 云服务实例来存储用户对应的阿里云产品指标，真正解决了以往监控零碎数据扩散造成数据孤岛的问题，同时为每个云产品提供了深度定制、开箱即用的大盘和告警能力。</p><p></p><p>下图是阿里云 Prometheus 接入云产品监控的残缺架构，蕴含以 Pull 模式为主、Push 模式为辅的全场景笼罩。Pull 模式反对云产品以 Kubernetes 或 ECS 部署模式，通过指标裸露、日志或云监控形式来对接；Push 模式反对以 Prometheus 规范的 Pushgateway、Remote Write 协定将指标推送过去，所有接入模式均反对云产品面向本身和租户的两层监控能力。我前面讲到的阿里云 AI 产品可观测就是综合使用了多种接入模式实现相干产品可观测监控接入的。</p><p></p><h3>（三）阿里云 AI 可观测最佳实际</h3><p>上面我具体讲下阿里云 AI 产品体系如何做端到端可观测体系建设。</p><p>最底层 IaaS 层，阿里云以“灵骏”智算服务为特色的软硬件一体化设计的算力集群服务，灵骏底层硬件外围由磐久服务器以及高性能 RDMA 网络两局部组成，这外面就包含提供 NAVIDIA A100 高性能 GPU 服务器。灵骏自身是以节点交付的，灵骏集群内能够划分多个分组，分组内蕴含计算节点。</p><p>节点上的计算资源 GPU、RDMA、Nimitz 等组件监控数据本身以 Pushgateway 协定上报的 Prometheus，指标中携带租户标来实现多个租户的隔离。内置的监控大盘反对集群级、节点级 GPU、RDMA 等资源的监控能力，涵盖 IaaS 层惯例 CPU、Mem、Disk、Net 以及算力方面的一千余个指标。</p><p></p><p>高性能算力之上 CaaS 层，ACK 灵骏托管集群提供全托管和高可用的管制面的规范 Kubernetes 集群服务，它作为反对机器学习平台 PAI 的云原生底座。ACK 灵骏集群会默认启用云原生 AI 套件，向下封装对各类异构资源的对立治理，向上提供规范 K8s 集群环境，提供高效、灵便的一站式 AI 平台。</p><p>ACK 灵骏托管集群反对对灵骏节点治理，纳入到灵骏节点池。AI 套件加强对异构资源调度，通过 GPU 共享调度和 GPU 拓扑感知调度能够高效地治理 GPU 程序以及 GPU 隔离。GPU 监控 2.0 基于 NVIDIA DCGM 来构建。ACK 灵骏集群内置 Prometheus 监控集成，能够一键获取整个 K8s 集群全副资源、组件的监控采集。节点上装置了 ACK 团队加强的 gpu-exporter 将 DCGM 服务以指标裸露进去，并内置了集群、节点、Pod 维度 GPU 大盘。</p><p>这里有一点须要阐明，惯例 GPU 利用率指标采纳 nvidia-smi 查问到整张卡的 GPU 利用率。但 GPU 利用率目前存在一些局限性，如不能告知用户有多少 SM 在应用，用户写的代码到底是真忙还是假忙，代码到底在做单双精度浮点运算（FP32/64）还是在拷贝数据？此时就须要做一些 Profiling 指标，去查看更细粒度的指标信息。</p><p></p><p>在 PaaS 层，阿里云人工智能平台 PAI，提供了一站式机器学习解决方案。他蕴含基础设施，计算引擎和容器，计算框架，ML 从数据筹备、模型开发与训练及模型部署阶段的全流程产品，利用于金融、医疗、教育等各畛域。</p><p>PAI 的可观测也是最简单的，咱们须要囊括 PAI 各自产品、容器、节点等相应层面的监控笼罩，每一层的架构、部署形式都有极大差别，接入形式也各不相同。但 Prometheus 存储、查问侧咱们做到了统一的解决方案，以各子产品为隔离粒度的面向租户的存储，垂直造成一个租户逻辑实例，单实例反对 100w/s 写入，每个产品能够依据业务状况切分实例独自扩容，逻辑实例能够付费升级成租户独享实例反对用户定义更长存储周期和更高的隔离粒度确保稳定性。如果用户想要所有 PAI 产品的监控数据还能够定义全局聚合实例会返回所有产品监控信息而不占用存储空间。</p><p></p><p>咱们实现了 PAI 产品的全栈可观测能力，反对 EAS 在线推理指标，DLC 训练作业级、节点级、LRN 级资源指标的透出，以及容器组件、节点、Pod 等集群所有资源指标，还有底层基础设施算力节点的全副监控数据采集、存储、展现等全方位能力。</p><p></p><p>最上层 MaaS 层，模型服务灵机 DashScope 围绕 AI 各畛域模型，通过标准化 API 提供模型推理、模型微调训练在内的多种模型服务。内置包含通义千问、白川开源大语言模型在内的 20+ LLM，反对模型推理、定制，并联合 ModelScope 魔搭社区打造下一代模型及服务共享平台。</p><p>灵积的监控是通过日志直达形式实现的，灵机将各种 LLM 大模型以及业务网关监控数据写到日志零碎，Prometheus 通过外部的流式 ETL 工具实时将日志转成指标数据散发到各租户名下，造成了灵机模型 API 层面的监控笼罩。</p><p></p><p>正如后面讲到的 AI 时代下有新技术栈，目前的可观测畛域产品更多服务于利用开发。以后的 AI 可观测尽管做到了 IaaS、CaaS、PaaS、MaaS 不同层面外围产品笼罩，但整套 AI 体系还有更多可观测须要开掘和笼罩的场景，真正做到 AI 端到端全栈可观测任重而道远。</p><h2>02 实现本身数据的深刻洞察</h2><h3>（一）Smart Metrics</h3><p>可观测离不开告警，告警里有两个外围痛点。一是有效告警太多，AIOps 对告警数据做了统计之后发现实在用意的告警比例仅为 3.05%，典型有效告警配置包含用固定阈值遍历所有利用/接口，敞口告警可能最后配置没问题，运行一段时候后业务变动了告警就生效了。二是告警难配，典型的告警页面仅反对配动态阈值，而实在的指标（比方 QPS）往往是随着业务周期变动的，基于动态阈值的告警配置难、保护难。</p><p></p><p>Smart Metrics 为了解决上述告警痛点而生，基于历史数据中学习 Metrics 特色，并对将来一段时间内 Metrics 失常变动范畴做出预测，生成高低基线。他具备开箱即用免运维、成果可视、准确率高，反对 Grafana 原生告警能力等特色。</p><p>事实上用繁多模型是难以满足多种曲线类型的，咱们采纳自研分类算法 + 多模型交融形式，用户能够自定义灵敏度事件等，多模型能够为每种曲线寻找最合适的算法，让咱们的产品足够“Smart”。</p><p></p><p>这里简略介绍两个应用场景。</p><p>场景 1：针对 QPS 波动性显著指标，动态阈值是没法配置的，智能算法能够一键产生高低边界，超出边界的值咱们才认为是能够报警的，这样就帮用户解决了如 QPS 等起伏不定指标的告警难配问题。</p><p></p><p>场景 2：CPU 使用率等个别安稳型指标，会随着新利用上线产生较大变动。传统做法须要对公布后更新阈值，Smart Metrics 能够每天自动更新模型，主动学习新环境，主动生成高低边界，无效缩小“敞口告警”问题产生。</p><p></p><h3>（二）Text2PromQL 问答机器人</h3><p>如果说用算法预测监控曲线基本上成为每款监控产品的必备能力，那 Text2PromQL 则是应用 LLM 解决可观测提效问题的利器。</p><p>为什么咱们须要自然语言转 PromQL 的智能机器人？PromQL 是 Prometheus 专属查询语言，和传统 SQL 有实质的不同。PromQL 是简直所有 K8s 利用的运维工程师最常常应用的查问语句，没有之一。写 PromQL 不是一件简略的事，用三个 C 来形容它的复杂性。第一个"C"是"Complex"，PromQL 语法其实是比较复杂的；第二个"C"是"Confusing"， PromQL 是由指标名、算子和 label 组成，指标名有时候会十分难懂。</p><p>每个公司都有本人的命名形式，甚至有一些指标是用户自定义的。监控畛域关注的指标又多又杂，有时候看文档都看不明确那些指标到底什么意思；第三个"C"是"Commenly"，PromQL 是一个十分罕用的查询语言。它不仅能提供运维相干的指标，也能够统计点击率、转换率、SLA 等业务指标，运维、开发、产品、经营都能够用它。综上，PromQL 语法不好学、指标名又简单，日常工作中用得又多，为了加重 SRE 工作、升高服务工单，也为了 Promethues、K8s 的推广，咱们须要一款自然语言转 PromQL 的机器人。</p><p></p><p>咱们第一步要做的事件是，先看看 ChatGPT 是不是就能够实现自然语言到 PromQL 的翻译了。如果大模型自身就能够很好地实现这个工作，那咱们不必开发了。就等着通义千问做大做强，咱们间接调用他们的 API 就行。咱们做了一些试验，发现 ChatGPT 和通义千问，都不能很好地实现这个工作。以 ChatGPT 为例，我问他“给我写个 PromQL，帮我查一下过来 5min，均匀响应工夫最长的 10 个利用是啥”。</p><p>它给我的答复是：topk(10,avg_over_time(application_response_time_seconds[5m]))</p><p></p><p>咱们看下它哪里错了，首先是指标名的事件，在咱们的零碎中，基本没有一个叫"application_response_time_seconds"的指标。其次，对均匀响应工夫的了解也是不对的，正确的例子：</p><p>topk(10,sum by (service)(sum_over_time(arms_http_requests_seconds{}[5m]))/sum by (service)(sum_over_time(arms_http_requests_count{}[5m])))</p><p>总的来说，通用的 LLM：</p><ol><li>它给的 PromQL 语法上是正确的。</li><li>它对咱们的零碎无所不知，不晓得咱们的指标名，当然它对别的公司提供的监控零碎也不晓得。3. 它其实不大理解用户问这个问题真正的用意，因为它在这里的背景常识太少了。</li></ol><p>也就是说，看起来 LLM 须要更多的常识……</p><p></p><p>为了给 LLM 灌常识，咱们也做了一些调研。总的来说，有 2 种计划：</p><p>第一种是 Fine-tuning：就是你用足够的语料，对大模型进行微调，这里的微调指的是，你曾经改了模型自身的一些参数，或者你在大模型外接了一个小模型，总之除了 LLM 自身自带的参数之外，曾经有了你本人工作相干的神经网络和参数了。</p><p>第二种计划是 Prompt Engineering，提醒词工程：就是咱们不会减少或批改大模型自身任意一个参数，咱们做的只是在用户问问题的时候，给它带一点上下文，作为额定的常识，来晋升答复的准确性。</p><p>这两种计划自身没有优劣之分，咱们画了一颗决策树，心愿能给想要做 LLM-based 利用的同行们一些咱们的教训。</p><p>既然抉择了 Prompt Engineering 提醒词工程，下一个问题就是，什么样的提醒词是有用的。</p><p>咱们花了好几个月的工夫，尝试了 5 种的提醒词，终于，把 Text2PromQL 准确率从 5% 以下，晋升到了百分之 70-80%。咱们的摸索过程应用过 PromQL 官网文档、Stack Overflow 社区问答、阿里云 ARMS 外部客户 QA 问答（这里蕴含了咱们本人零碎的指标名信息）、ARMS 外部 PromQL 问答示例 + ChatGPT 生成的 PromQL 解释等伎俩准确率能够到 20% 左右。</p><p>直到引入 Chain-of-Thought 格局 PromQL 问答示例，准确率一下子晋升到 60-70%，终于迎来了第一个拐点。最初咱们基于 Chain-of-Thought 格局 PromQL 问答+通义千问，准确率原地涨了 10%，达到 80% 左右。即便不齐全对的场景，也给了指标名、该用的算子等十分有用的信息，而且语法根本不会错了。通义千问的确很厉害！</p><p></p><p>Chain-of-Thought 是 Google Brain 实验室提出来算法，原本用来加强 LLM 推理能力的，它的提醒词是带有推理步骤的常识。推理过程很像解小学数学题。</p><p></p><p>一般提醒词：</p><p>Q：Roger 有 5 个羽毛球，他又买了 2 桶，每桶有 3 个，那他当初有几个。</p><p>A：答案是 11。</p><p>实践上，LLM 应该能照葫芦画瓢答复进去，然而他的答案是谬误的。</p><p>Google 给的 Chain-of-Thought 提醒词：</p><p>Q：Roger 有 5 个羽毛球，他又买了 2 桶，每桶有 3 个，那他当初有几个。</p><p>A：Roger 原本有 5 个球，买了 2 桶，每桶 3 个的球，也就是 6 个球。5+6=11。所以答案是 11。</p><p>这里就是给了例子中的推导过程。</p><p>而后，奇观产生了，GPT 竟然就会了，给了正确的答案。</p><p></p><p>上面咱们来介绍 CoT 算法，在 Text2PromQL 场景下是怎么应用的。</p><p>这是咱们的架构图，咱们领有一个离线零碎和一个在线零碎。在离线零碎中，咱们将 ARMS 多年积淀的，大量用户对于 Text2PromQL 的问答示例，通过 Chain-of-Chain Prompting 算法，转换成 Chain-of-thought 格局 Q&A 示例，而后进行文本切割，失去 Q&A 示例。而后通过 embedding，将文字转换为数字组成的向量。再把这些向量存到数据库中；在线零碎中，当一个用户发问，比方写一个 PromQL，查均匀响应工夫最长的 10 个利用，咱们会把这些文字通过 embedding 转换成数字组成的向量。</p><p>当初咱们领有了用户问题转换进去的向量以及离线零碎中数据库中一系列向量。那么，咱们就能够在数据库中检索和以后用户问题最类似的 topk 个向量，把这个 k+1个数字组成的向量还原为文字，而后把用户的问题以及 k 个最类似的历史 Q&A 作为提醒词输出到大模型中，从而能够失去最终 PromQL。能够看到，咱们这个零碎初始的输出是用户的 PromQL 问答示例，所以当用户问得越多，咱们能笼罩的场景也越多，准确率也会越高，总的来说，咱们的机器人会越问越聪慧。</p><p></p><p>咱们以后笼罩了 20+ 场景，准确率 76.9%。即便在没有笼罩的场景下，也能给出十分多有用的信息。更重要的是，因为咱们是 Prompt Engineering，通过给提醒词减少模型的准确率，所以笼罩新场景十分快，只有给它生成 CoT 格局的提醒词就好。目前 Smart Metrics 和 Text2PromQL 曾经在阿里云可观测可视化 Grafana 版上线，欢送开发者体验。</p><p></p><h2>03 每月 50GB 收费额度让 Prometheus 老本更低、更可控</h2><p></p><p>近期，可观测监控 Prometheus 版公布新计费模式，屏蔽原有上报指标采样点数量、存储时长等计费项，以理论写入数据量（GB）进行计费。</p><p></p><p>新计费模式单价 & 收费额度：</p><p></p><p>Prometheus 蕴含根底指标、自定义指标。其中，根底指标以容器服务产生的根底指标举例，默认存储 7 天且收费，不占用 50GB 收费额度。自定义指标以云服务器 ECS 实例举例，每日上报指标量 24.5 万/实例，每日数据写入量约 0.093GB/实例。</p><blockquote>计算器：https://armsnext.console.aliyun.com/price-gb#/overview</blockquote><p>老用户如何基于新计费模式进行老本预估</p><p>1）根本条件</p><p>1 条上报指标约 0.5KB；</p><p>注：不同应用模式下存在肯定数据量差别，理论应用时请关注。</p><p>2）新老比照</p><p>以中小企业通常每日上报自定义指标 15000 万条 ，数据保留 30 天举例。</p><ul><li>新计费（按量付费）每月老本：150000000（条） <em> 0.00000048 （GB/条） </em> 0.4（元/GB）* 30（天）= 864 元</li><li>旧计费（按量付费）</li></ul><p>1.阶梯一部分：50000000 条 <em> 0.0000008（元/条）</em> 30（天）= 1200元<br/>2.阶梯二局部：100000000 条 <em> 0.00000065（元/条）</em> 30（天）= 1950元<br/>3.总计老本：1200 + 1950 = 3150元</p><p>比照两种计费形式，新计费节俭 70% 以上。</p><p>作者：蓟北</p><p><strong>原文链接</strong></p><p><strong>本文为阿里云原创内容，未经容许不得转载。</strong></p></article> ...

背景上篇文章咱们说了 Volcano 控制器原理，这篇文章来看下调度器外围逻辑。 调度器简介接着终于到了 Volcano 的外围控制器局部。其实上局部 Controller 所有的调谐，最终都是为了能做好批调度。和其余文章一样，先看看官网的形容：官网形容： 客户端提交的Job被scheduler察看到并缓存起来;周期性的开启会话，一个调度周期开始；将没有被调度的Job发送到会话的待调度队列中；遍历所有的待调度Job，依照定义的秩序顺次执行enqueue、allocate、preempt、reclaim、backfill等动作，为每个Job找到一个最合适的节点。将该Job 绑定到这个节点。action中执行的具体算法逻辑取决于注册的plugin中各函数的实现敞开本次会话。艰深点：Volcano 调度过程中会执行一系列的 Action，Action 中执行什么算法逻辑，就取决于注册进去的 plugins。具体如何配置 Actions 和 Plugins，这须要扒扒源码了。次要其实代码中多了个 shuffle Action，官网文档有些落后了。 调度器源码实现从控制器 CRD 到调度器，调度器如何辨认 PodGroup此时必须要留神，调度器代码中的 JobInfo 并非 控制器所辨认的 Volcano Job，而是对 PodGroup 的封装。咱们先到调度器的 main 入口来看，除了框架类的代码外，只有一个 Run 函数。而 Run 函数中有个 NewScheduler 办法。NewScheduler 办法中有个 schedcache.New() 办法...。顺着代码，终于来到了配角 addEventHandler()（此处只是为了看 PodGroup 到 TaskInfo 的映射，讲的比拟粗，细节后续会再提到）。 // cmd/scheduler/main.gofunc main() { // ... if err := app.Run(s); err != nil { // ... }}// cmd/scheduler/app/server.go// Run the volcano scheduler.func Run(opt *options.ServerOption) error { // ... sched, err := scheduler.NewScheduler(config, opt) // ...}// pkg/scheduler/scheduler.go// NewScheduler returns a Schedulerfunc NewScheduler(config *rest.Config, opt *options.ServerOption) (*Scheduler, error) { // ... cache := schedcache.New(config, opt.SchedulerNames, opt.DefaultQueue, opt.NodeSelector, opt.NodeWorkerThreads, opt.IgnoredCSIProvisioners) scheduler := &Scheduler{ schedulerConf: opt.SchedulerConf, fileWatcher: watcher, cache: cache, schedulePeriod: opt.SchedulePeriod, dumper: schedcache.Dumper{Cache: cache, RootDir: opt.CacheDumpFileDir}, } return scheduler, nil}// pkg/scheduler/cache/cache.go// New returns a Cache implementation.func New(config *rest.Config, schedulerNames []string, defaultQueue string, nodeSelectors []string, nodeWorkers uint32, ignoredProvisioners []string) Cache { return newSchedulerCache(config, schedulerNames, defaultQueue, nodeSelectors, nodeWorkers, ignoredProvisioners)}// pkg/scheduler/cache/cache.gofunc newSchedulerCache(config *rest.Config, schedulerNames []string, defaultQueue string, nodeSelectors []string, nodeWorkers uint32, ignoredProvisioners []string) *SchedulerCache { // ... // add all events handlers sc.addEventHandler() // ...}从 addEventHandler() 中能够看到调度器监听了好多资源，包含 PodGroup，次要看看其中的 AddFunc，也就是 pkg/scheduler/cache/event_handlers.go 中的 AddPodGroupV1beta1 办法。此时会看到一个 schedulingapi.PodGroup 构造体，留神该构造体并非控制器中的 PodGroup crd，而是一个 Wrapper。 ...

在云原生畛域工作了 1.5 年，总是被各种业务压着，都没工夫好好回头看看总结下。心愿可能通过平台来记些笔记，也算是对本人的认可吧。 一、Volcano 背景先来看看官网形容： Volcano 是 CNCF 下首个也是惟一的基于 Kubernetes 的容器批量计算平台，次要用于高性能计算场景。它提供了 Kubernetes 目前短少的一套机制，这些机制通常是机器学习大数据利用、科学计算、特效渲染等多种高性能工作负载所需的。作为一个通用批处理平台，Volcano 与简直所有的支流计算框 架无缝对接，如 Spark 、TensorFlow 、PyTorch 、 Flink 、Argo 、MindSpore 、 PaddlePaddle 等。它还提供了包含基于各种支流架构的 CPU、GPU 在内的异构设施混合调度能力。Volcano 的设计理念建设在 15 年来多种零碎和平台大规模运行各种高性能工作负载的应用教训之上，并联合来自开源社区的最佳思维和实际。简略点说，Volcano 是一个批调度器，且定义了一些资源，用以反对批调度。本文旨在从源码上剖析 Volcano 调度机制（所有剖析以开源 tag v1.9.0-alpha.0 为准）。若读者对 Volcano 基本概念不理解，请自行浏览官网文档 Volcano 官网文档。 二、源码剖析2.1 核心理念QueueQueue 用于治理和优先级排序工作。它容许用户依据业务需要或优先级，将作业分组到不同的队列中，各个队列所能应用的资源由用户自定义。这有助于更好地管制资源分配和调度优先级，确保高优先级的工作能够优先获取资源。 PodGroup一组相干的 Pod 汇合。次要解决 Kubernetes 原生调度器中单个 Pod 调度的限度。通过将相干的 Pod 组织成 PodGroup，Volcano 可能更无效地解决那些须要多个 Pod 协同工作的简单工作。PodGroup 是调度器辨认的根本单位。理论调度过程中由 Volcano 调度的 Pod，都通过 annotation 与 PodGroup 建设关联，且 spec.schedulerName 均为 Volcano 调度器。 VolcanoJobVolcanoJob (前期简称 Job)不仅包含了 Kubernetes Job 的所有个性，还退出了对批处理作业的额定反对，使得 Volcano 可能更好地适应高性能和大规模计算工作的需要。Job Controller 会依据 Job 中定义的 Task 创立出 PodGroup 和 Pod。 ...

<article class=“article fmt article-content”><p>Sealos 私有云（https://cloud.sealos.io）简直打爆了市面上所有支流的开源网关，本文能够给大家很好的避坑，在网关选型方面做一些参考。</p><h2>Sealos Cloud 的简单场景</h2><p>Sealos 私有云上线以来，用户呈爆发式增长，目前总共注册用户 8.7w，每个用户都去创立利用，每个利用都须要有本人的拜访入口，就导致整个集群路由条目十分微小，须要有撑持数十万条 Ingress 的能力。</p><p>另外，在公网提供共享集群的服务，对多租户要求极为刻薄，用户之间的路由必须不能相互影响，须要十分好的隔离性，以及流量控制能力。</p><p>私有云的受攻击面是很大的，黑客会攻打云上跑的用户利用，也会间接攻打平台的进口网络，安全性上也有十分大的挑战。</p><p>对控制器的性能和稳固要求都比拟高，很多控制器路由条目一多时耗费资源会十分大，甚至 OOM 导致网关奔溃。</p><h2>排除 Nginx Ingress</h2><p>咱们最早用的就是 Nginx Ingress，最初发现有几个外围问题无奈解决：</p><ul><li>reload 问题，每次有 ingress 变更会导致断连一小会，而一个集群用户一多的时候，ingress 的创立变更会是个频繁事件，就会导致网络常常不稳固。</li><li>长链接不稳固，也是因为变更，在用的长链接会常常断。</li><li>性能不行，失效工夫慢，耗费资源多。</li></ul><p>所以简直排除掉了很多底层用 Nginx 实现的网关。咱们实测下来基于 Envoy 实现的网关性能彪悍太多，简直管制面和数据面都不怎么耗费性能。</p><p>这是 Envoy 的：</p><p></p><p>这是 Nginx 的：</p><p></p><p>差距十分之大，所以咱们就能够排除掉 Nginx 系列选项了，彻底拥抱 Envoy。</p><h2>对于 APISIX</h2><p>APISIX 自身是个优良我的项目，解决了 Nginx reload 的一些问题，所以咱们 Laf 晚期也用了 APISIX，然而很可怜 APISIX 的 Ingress Controller 并不是很稳固，管制面解体给造成了咱们好几次大的故障，还呈现过控制器 OOM 等问题，咱们原本真的很想用，然而最终还是因为故障问题被强制劝退，当然 APISIX 社区也在始终跟进这些问题，心愿能越做越好。</p><p>总结一下就是：APISIX 自身稳定性很好，然而控制器须要优化的货色还很多，稳定性也有待进步。社区反对力度也很大，无奈咱们线上问题迫在眉睫没法依照社区的节奏缓缓迭代，只能先切成别的网关了。</p><h2>Cilium Gateway</h2><p>Sealos 的 CNI 很早就切换成 Cilium 了，的确很强，所以咱们想着网关也对立用 Cilium 得了，然而事实很骨感。</p><p>Cilium Gateway 只反对 LB 模式，这样就强依赖云厂商的 LB，而咱们也有一些私有化的场景，所以不心愿耦合，稳定性方面也遇到了路由十分多的时候，Ingress 失效特地慢的问题，须要分钟级失效，这样用户的体验就很差了，咱们能承受的是 5s 内路由失效。所以论断就是只能再等等。</p><h2>Envoy Gateway</h2><p>从 K8s 规范的倒退来看，会逐步从 Ingress 迁徙到 Gateway 的规范，而咱们底层又更偏向应用 Envoy，那 Envoy Gateway 的实现仿佛是一个很好的抉择，所以咱们调研了 Envoy Gateway，然而这个我的项目还是太过于晚期，遇到了一些不稳固的 bug，比方会 OOM，pathpolicy 不失效，有些个性在 merge gateway 模式下不失效等问题，在继续解决中，咱们也在一直帮忙上游社区提改良意见和奉献，心愿将来能够能达到生产可用的状态。</p><h2>逼格很高但不那么实用的 Gateway 规范</h2><p>Gateway 的处境很尬感，我的感觉是设计者并没有真的实际过多租户场景，当多租户共享一个集群时，就要明确辨别管理者和使用者的权限问题，Gateway 设计之初就没齐全思考分明，举个例子：</p><pre><code>apiVersion: gateway.networking.k8s.io/v1kind: Gatewaymetadata: name: egspec: gatewayClassName: eg listeners: - name: http port: 80 protocol: HTTP # hostname: “.example.com” - name: https port: 443 protocol: HTTPS # hostname: “.example.com” tls: mode: Terminate certificateRefs: - kind: Secret name: example-com</code></pre><p>这里监听端口这类的配置应该是给集群管理员而不是普通用户，而 TLS 证书的配置属于某个利用，管理员能够有权限配置，次要还是每个用户去配置本人的，所以这外面权限就没有离开。那就只能让用户也有权限配置 Gateway，所以这里就又须要在控制器里实现很多的权限管制的细节问题，如端口号白名单，冲突检测等。</p><p>集体感觉更优雅的设计是把其中租户级别的字段下沉到 HTTPRoute 中实现，或者一个独自的 CRD，这样用户态和超级管理员就能够离开的更分明。现有的形式也能做，就是有点混淆。</p><h2>最终 Higress 胜出</h2><p>除了以上重点的我的项目，咱们还测试了很多其余我的项目，我这里就不一一列举了。Sealos 最终选了 Higress。</p><p>咱们目前抉择网关的逻辑很简略，次要就是在满足性能的前提下足够稳固，最终抉择 Higress 简直是排除法得进去的。</p><p>稳定性是排在第一位的，在咱们的场景外面可能达到生产可用的目前只有 Higress。不过实际过程中也呈现过一些问题，好在 Higress 社区的反对力度很大，很疾速的解决了，次要有几个：</p><ol><li>Ingress 失效速度慢，路由条目多时， 2min 多新建路由能力失效，社区最初优化到了 3s 左右，这曾经到极致了，也没有再优化的必要了，因为曾经比容器 Ready 工夫还短了，Higress 应用了一种增量加载配置的机制，让海量路由条目时也能有夸大的性能。</li><li>控制器 OOM，在无动静加载时资源耗费比拟大，呈现过 OOM 的状况，目前三高问题都解决掉了。</li><li>超时问题，有一个进一步优化加载延时的参数配置 onDemandRDS 在咱们一个主集群会偶发申请超时，目前是把该配置敞开了，还在进一步查看起因，而在其它集群中未发现这个问题。</li></ol><p>安全性方面，咱们很多时候的故障问题都是性能问题造成的，流量过大，打爆网关比拟常见，所以网关的性能变得至关重要，实测下来 Envoy 要彪悍很多，控制器写的好不好也生死攸关，这个方面 Higress 体现出众：</p><p></p><p></p><p>在咱们曾经海量路由，超高并发的状况下，须要的资源少的可怜。</p><p>Higress 还兼容 Nginx Ingress 语法，次要是一些 annotations，咱们之前的代码都是用的 Ingress，所以简直没有任何迁徙老本，间接几分钟的降级就能够搞定。</p><p>同样为了促成社区更好的倒退咱们也给 Higress 一些意见：</p><p>1.能对 Gateway 的规范有更好的反对，目前尽管曾经反对了 v1 版本，但还没有齐全兼容 Ingress 上的能力。<br/>2.能凋谢出一些大杀器的性能，比方平安和熔断方面的能力。让开源和商业联合的更严密一些，咱们倒是不排挤付费，然而随着平台倒退，须要更强的一些性能。<br/>3.周边性能倡议更多通过插件机制扩大，让外围性能更内聚一些，简略可依赖。</p><h2>总结</h2><p>网关对于云和利用而言是个十分十分外围的组件，随着 Sealos 规模的不断扩大，也会呈现很多新的挑战，咱们心愿能和上下游社区建设严密的单干，让开源网关能失去更好的倒退，让更多开发者受害。</p><p>以上列举的很多网关都很优良，Sealos 没用不代表我的项目不厉害，只是咱们的场景刻薄且奇葩，真的在公网环境能反对多租户的网关并不多，所以各位看官还是要从本人的场景登程。咱们的选型仅作参考，同样 Sealos 自身也会以一个凋谢心态来持续跟进其余网关的倒退。</p><p>最初非常感谢 Higress 开源社区的大力支持，感激阿里云云原生团队开源了这么优良的我的项目，造福宽广社区用户。</p><p>作者：Sealos 创始人，环界云计算 CEO 方海涛</p><p><strong>原文链接</strong></p><p><strong>本文为阿里云原创内容，未经容许不得转载。</strong></p></article> ...

前言本篇文章次要介绍基于阿里云 EventBridge 的音讯集成能力，联合目前音讯产品的需要热点，从能力范畴到场景实战，对 EventBridge 的音讯集成解决方案进行了概要的介绍。 01 从音讯现状谈起音讯队列作为利用解耦，流量削峰填谷的无效工具，早已被开发者广泛应用于各类分布式服务中。随着业务的一直倒退迭代，越来越多的服务面临着稳定性和可保护方面的挑战，对音讯队列的需要也不再局限于一般的订阅-生产，这里列举 3 个场景的能力需要： 音讯路由能力这里次要的需要场景是数据同步和异地灾备。对于大多数音讯队列用户而言，音讯队列中的业务数据个别由一类服务来生产和解决，当用户有多个利用，且须要一个全局视线来汇总剖析这些不同利用的数据时，音讯路由就成了一个避不开的能力需要。同样，出于数据灾备的思考，云上大用户通常也有在不同 region 同步音讯数据的需要。 但在云上实现音讯路由可能并不是一件容易的事件。家喻户晓，云上个 region 之间网络是严格隔离的，用户想要实现数据的跨 region 传输，要么应用 CEN 等网络买通计划，要么应用公网进行数据传输。前者须要业务在设立之初就有齐备的网络布局，同时 CEN 的费用老本也是一笔不小的开销；后者则须要思考公网带宽老本，和将数据裸露在公网所面临的平安问题。 音讯加工能力构想这样一个场景，电商平台上，用户的订单信息是由 RocketMQ 来负责承载的，上游的领取、库存、营销部门都须要生产订单信息，因为历史和技术栈起因，这几个部门应用的音讯产品类型各不相同，别离是 RocketMQ、RabbitMQ 和 Kafka，而且这几个部门所须要的并不是全量的原始音讯，而是局部本人感兴趣的。同时，本身的接口也对数据 schema 做出了肯定的要求，并不冀望原始音讯投递过去。 此时，单纯的音讯路由仿佛也不能满足需要。如果这项工作交给一款产品来解决，那么这款产品须要满足 2 点能力，第一就是将音讯路由至其余品种音讯产品的能力，另外一点就是必须具备数据的过滤加工能力。 生态扩大能力传统音讯用户，其音讯的生命周期仅在本身业务的发送与生产阶段。但在万物上云的明天，如果能够利用品种繁多，功能强大的各类云产品来丰盛音讯的上下游，则将极大地挖掘音讯数据的潜在价值。例如用户可能须要将 SLS 的日志数据导入到音讯队列，以实现离线的数据加工能力；又或者可能须要将音讯队列中的数据用于触发函数计算，以实现整个利用的 Serverless 化。 但现状是，用户如果本身去实现各个生态产品的对接，则面临着开发工作量大，后续保护繁琐的问题。最现实的形式是有一款开箱即用的工具，可能对接足够多的生态，而且自身应用也尽量简略。 那么是否有一款云产品能够解决以上问题，帮忙音讯用户实现便捷、牢靠的音讯集成能力呢？这里就须要介绍本期的配角：阿里云事件总线 EventBridge。 02 事件总线与音讯集成事件总线 EventBridge 是阿里云提供的一款无服务器事件总线服务，反对阿里云服务、自定义利用、SaaS 利用以标准化、中心化的形式接入，并可能以标准化的 CloudEvents 1.0 协定在这些利用之间路由事件。 EventBridge 的外围能力能够演绎为 3 点：对立事件服务、数据管道与凋谢与集成。 对立事件服务在 EventBridge 呈现之前，各个云产品的事件互相独立，用户无奈在一个中央中央实现对全副云产品事件的收集和解决。EventBridge 的呈现突破了这一场面，其收纳了云上的绝大多数云产品事件，并在用户侧提供对立、体系的展现交互，让云上用户能够更加零碎的梳理、解决云产品事件。 数据管道EventBridge 并不简简单单仅笼罩云上事件，也提供数据管道的能力，实现数据的联通交互。例如用户能够应用 EventBridge 创立音讯路由工作，将音讯队列中的数据导入到其余音讯队列，也能够创立工作将 SLS 中的日志数据导入到音讯队列中来。目前 EventBridge 在源端和指标端均有丰盛的产品种类反对。 凋谢与集成EventBridge 凋谢了多种语言的 SDK，不便不同技术栈的开发者能够疾速不便的应用 EventBridge。同时 EventBridge 也兼容了云上规范 Cloudevents 的 sdk，即用户应用业界开源 sdk 也能够不便的将事件投递至 EventBridge。在事件 schema 定义上，EventBridge 采纳了目前云上事件的事实标准 cloudevents 1.0，保障了应用其余事件服务的客户能够无缝迁徙到阿里云 EventBridge，其在阿里云 EventBridge 上的事件也能够疾速接入到其余支流 EDA 引擎，防止了厂商锁定的状况。 ...

前文回顾： 本系列将介绍如何基于 ACK Fluid 反对和优化混合云的数据拜访场景，相干文章请参考： 《基于 ACK Fluid 的混合云优化数据拜访（一）：场景与架构》 《基于 ACK Fluid 的混合云优化数据拜访（二）：搭建弹性计算实例与第三方存储的桥梁》 《基于 ACK Fluid 的混合云优化数据拜访（三）：减速第三方存储的读拜访，降本增效并行》 《基于 ACK Fluid 的混合云优化数据拜访（四）：将第三方存储目录挂载到 Kubernetes，晋升效率和标准化》 在之前的文章中，咱们探讨了混合云场景下 Kubernetes 与数据相结合的 Day 1：解决数据接入的问题，实现云上计算和线下存储的连贯。在此基础上，ACK Fluid 进一步解决了数据拜访的老本和性能问题。而进入 Day 2，当用户真的在生产环境应用该计划时，最次要的挑战就是运维側如何解决多区域集群的数据同步。 概述许多企业出于性能、平安、稳定性和资源隔离的目标，会在不同区域建设多个计算集群。而这些计算集群须要近程拜访惟一中心化的数据存储。比方随着大语言模型的逐步成熟，基于其的多区域推理服务也逐步成为各个企业须要反对的能力，就是这个场景的具体实例，它有不小的挑战： 多计算集群跨数据中心手动操作数据同步，十分耗时以大语言模型为例，参数多文件大，数量多，治理简单：不同业务抉择不同的根底模型和业务数据，因而最终模型存在差别。模型数据会依据业务输出一直做更新迭代，模型数据更新频繁模型推理服务启动慢，拉取文件工夫长：大型语言模型的参数规模相当微小，体积通常很大甚至达到几百 GB，导致拉取到 GPU 显存的耗时微小，启动工夫十分慢。模型更新须要所有区域同步更新，而在过载的存储集群上进行复制作业重大影响现有负载的性能。ACK Fluid 除了提供通用存储客户端的减速能力，还提供了定时和触发式数据迁徙和预热能力，简化数据散发的复杂度。 节俭网络和计算成本：跨区流量老本大幅升高，计算工夫显著缩短，大量减少计算集群老本；并且能够通过弹性进一步优化。利用数据更新大幅减速：因为计算的数据拜访在同一个数据中心或者可用区内实现通信，延时升高，且缓存吞吐并发能力可线性扩大。缩小简单的数据同步操作：通过自定义策略控制数据同步操作，升高数据拜访争抢，同时通过自动化的形式升高运维复杂度。演示本演示介绍如何通过 ACK Fluid 的定时预热机制更新用户不同区域的计算集群能够拜访的数据。 前提条件已创立 ACK Pro 版集群，且集群版本为 1.18 及以上。具体操作，请参见创立 ACK Pro 版集群[1]。已装置云原生 AI 套件并部署 ack-fluid 组件。重要：若您已装置开源 Fluid，请卸载后再部署 ack-fluid 组件。未装置云原生 AI 套件：装置时开启 Fluid 数据减速。具体操作，请参见装置云原生 AI 套件[2]。已装置云原生 AI 套件：在容器服务治理控制台[3]的云原生 AI 套件页面部署 ack-fluid。已通过 kubectl 连贯 Kubernetes 集群。具体操作，请参见通过 kubectl 工具连贯集群[4]。背景信息筹备好 K8s 和 OSS 环境的条件，您只须要消耗 10 分钟左右即可实现 JindoRuntime 环境的部署。 ...

可观测性可观测性（Observability）是指零碎、应用程序或服务的运行状态、性能和行为可能被无效地监测、了解和调试的能力。 随着零碎架构从单体架构到集群架构再到微服务架构的演进，业务越来越宏大，也越来越简单。云原生时代背景下，随着微服务、Service Mesh、 Serverless 等新技术的呈现，业务的复杂度很快就超过了集体的极限，可观测性在古代分布式系统的设计和运维中变得越来越重要。传统的监控和告警办法往往只关注零碎的一些根本指标，而疏忽了更细粒度的信息和上下文。可观测性的指标是通过全面的数据收集和剖析，提供更深刻和全面的洞察力，使运维和开发人员可能更好地了解零碎的行为、排查问题、预测性能瓶颈和应答故障。 日志、指标和分布式追踪被称为可观测性的三大支柱： 日志（Logging）：日志是记录零碎运行过程中产生的事件和信息的记录。通过记录应用程序的日志，能够理解零碎的运行状态、谬误和异样信息，不便故障排查和系统分析。常见的日志零碎包含 ELK（Elasticsearch、Logstash、Kibana）和 Splunk 等。指标（Metrics）：指标是用于掂量零碎各个方面性能的度量规范。通过采集和记录指标数据，能够实时监控零碎的运行状况，包含 CPU 使用率、内存占用、申请响应工夫等。罕用的指标零碎有 Prometheus 和 InfluxDB 等。分布式追踪（Distributed Tracing）：分布式追踪是用于跟踪和监控分布式系统中申请的门路和性能的技术。通过将申请在零碎中的不同组件之间传递一个惟一标识符，能够追踪申请的流程和耗时，帮忙剖析和优化零碎性能。常见的分布式追踪零碎有 Zipkin 和 Apache Skywalking 等。通过提供全面且准确的可观测性，零碎的开发和运维人员能够更疾速地发现问题、了解零碎行为，并做出相应的优化和决策，从而进步零碎的性能、稳定性和可靠性。 云原生网关可观测体系MSE 云原生网关依靠阿里云现有的云产品（日志服务 SLS、利用实时监控服务 ARMS）以及对开源软件的良好反对构建了丰盛的可观测体系，为用户提供了弱小的日志、监控、链路追踪以及告警性能，性能大图如下所示： 网关的可观测性能力致力于帮忙客户构建产品的可靠性体验，为客户提供故障发现与故障定位的能力，缩小故障的产生以及升高故障的影响面。基于网关的监控与告警治理性能，实现故障的及时发现与告诉到客户；基于监控与日志，实现故障的疾速定位；基于链路追踪，实现申请调用的全链路故障根因排查。 云原生网关可观测实际过程概览本文将根据下图中标注的功能模块登程，帮忙读者体验网关可观测性在故障发现与故障定位中的能力。 整体流程如下图所示： 用户收到网关收回的告警用户查看 prometheus 监控找到出问题的路由、服务用户查看 SLS 日志获取更具体的报错信息用户通过链路追踪排故障的根因 测试环境架构概览 本文在 ACK 集群中部署了一系列 Springboot 的服务，调用关系如上图所示，其中 Spring SVC 4-2 产生了 crash。通过网关接入 ACK 集群，创立路由如下： 测试过程中会通过以下三种申请去拜访网关： 失常的申请，网关路由到 httpbin在网关处就返回谬误的申请，本文应用无奈命中路由的申请在上游服务返回谬误的申请，网关路由到 Spring SVC 1此时网关的错误率会呈现显著回升。 故障发现与定位过程通过告警策略及时发现故障首先配置网关的告警策略，从网关实例粒度设置告警规定与告诉策略，本文中采纳了邮件告诉的形式，除此之外还有电话、短信等形式。配置告警策略的示例如下图所示： 通过以下邮件信息能够得悉网关呈现了故障： 通过 Arms Prometheus 监控初步定位问题接下来，查看网关观测剖析->业务监控->全局看板的错误信息概览板块，以后监控信息如下： 依据图中内容，能够失去以下信息： “网关粒度失败率”看板中，网关整体失败率是大于上游服务失败率的，这意味着一部分申请在网关处返回了错误码，一部分申请在上游服务处返回了错误码“路由粒度失败率”看板中，可能看到只有路由名称为 “spring” 的路由失败率不是 0“上游服务粒度失败率”看板中，可能看到只有服务名称为 “springboot-svc-1.app-system.svc.cluster.local” 的服务失败率不是 0点击图中“路由失败申请数排行”或者“上游服务失败申请数排行”中的路由名或者服务名能够查看路由或者服务的详细信息。 ...

本文是 8 月 17 日直播的文字稿整顿，微信公众号「阿里云云原生」可观看直播回放。除去文章内容外，还包含针对实际网络问题的实战环节。 容器网络抖动问题产生频率低，工夫短，是网络问题中最难定位和解决的问题之一。不仅如此，对 Kubernetes 集群内的网络状态进行日常的持续性监测，也是集群运维中很重要的一环。 KubeSkoop 基于 eBPF 技术，提供了 Pod 粒度的、低开销的、可热插拔的实时网络监测能力，不仅能够满足日常网络监控的须要，也可能在呈现网络问题后，通过开启对应的探针，疾速定位及解决问题。KubeSkoop 提供了基于 Prometheus 的指标和 Grafana 大盘，同时也提供了基于命令行、基于 Loki 的异样事件透出能力，提供问题现场的详细信息。 本次分享将包含： 利用如何收到/收回数据包网络问题排查的难点，传统网络问题排查工具以及传统工具的问题对 KubeSkoop 和网络监测局部（即 KubeSkoop exporter）的简略介绍联合内核中的不同的模块具体介绍 KubeSkoop exporter 的探针、指标和事件在日常监测和异样排查中应用 KubeSkoop exporter 的个别流程KubeSkoop exporter 的将来布局。容器中的利用如何收到/收回数据包？ 在网络中，数据是以数据包为单位进行传输的。在 Linux 零碎上，数据包须要通过内核中各个模块层层解决，才可能失常地被利用接管，或是被利用发送。 咱们先来看接管过程： 网卡驱动收取网络报文后，发动中断内核 ksoftirqd 失去调度后，失去数据，进入到协定栈解决报文进入网络层，网络层通过 netfilter 等解决后，进入传输层传输层解决报文后，将报文的 payload 放入 socket 接管队列中，唤醒利用过程，让出 CPU利用过程被调度后，通过零碎调用将数据收取的用户态进行解决 再来看发送过程： 应用程序通过零碎调用向 socket 发送队列写入数据进入到内核态，socket 调用传输层进行报文发送传输层组装报文，调用网络层发送网络层通过 netfilter 等解决后，进入 tc egresstc qdisc 将报文依照顺序调用网卡驱动进行发送咱们在入方向并没有关注到 tc 的解决，但在出方向着重的提了一下，这也是链路中产生丢包异样的常见起因之一。 由下面的介绍能够看出，一个包在 Linux 内核中须要通过简单的解决步骤。内核网络子系统的模块泛滥，代码量宏大且简单，是造成网络问题排查的难点之一；包的接管和发送通过的链路长，给问题定位带来了相当的难度。同时网络相干零碎的参数繁多，配置简单，因为某些性能或者参数的限度导致了网络问题，也须要咱们花大量的工夫去定位；同时，零碎的磁盘、调度、业务代码缺点等，都可能体现为网络问题，须要对系统状态进行全面的观测。 罕用网络排查工具接下来，咱们再来介绍一下 Linux 环境下常见网络问题排查工具，以及其背地的实现技术。 ...

在国内领有 2500+ 中大型企业用户，用户社群汇集开发者超 3 万人，沉闷贡献者数间断数月稳居寰球大数据开源我的项目排行榜第一。毋庸置疑，Apache Doris 已成为全国数据库和大数据畛域最为沉闷的开源我的项目之一。Apache Doris 历经近十年的倒退，为何还能持续保持竞争力和生机？其背地的外围推动力又是什么？ 在 QCon 寰球软件开发大会·北京站的现场，基于 Apache Doris 的商业化公司飞轮科技的 CEO、Apache Doris 我的项目创始人 & PMC 马如悦承受了采访。马如悦曾在百度负责过分布式计算团队、大数据工程团队和 AI 产品工程团队的技术负责人，还主导设计和开发了实时数仓 Apache Doris。他对于 Apache Doris 的技术倒退路线以及实时数仓的将来倒退有着更加粗浅的认知。 Q1：作为一名深耕数据库畛域多年的从业者，您察看到企业对于数据仓库的需要点次要集中在哪方面？ 马如悦：纵观数据仓库的倒退历程，数据仓库的演进经验了三个阶段，第一阶段，即在 2010 年之前，传统数据仓库解决方案包含 Teradata、Greenplum、IBM Netezza 来解决大数据问题。第二阶段，约在 2010 年左右，随着谷歌三驾马车的问世，人们逐渐开始应用 Hadoop 大数据平台进行数据分析。现在曾经进入了第三阶段，现代化的数据仓库产品开始涌现，这些产品联合了传统数据仓库的可靠性和性能劣势，同时具备了对大数据的高效解决和实时剖析能力。 作为一个残缺经验了第二代大数据平台历史的从业者，在百度晚期我次要负责 Hadoop 和 Spark 相干的工作，起初主导设计了 Doris 并将 Doris 奉献至 Apache 基金会。咱们认为第三代数据平台的次要特点是实时化、架构的交融统一化以及云原生化。 随着业务需要的一直增长，企业对数据的实时性要求也越来越高，现代化数据仓库须要具备高速的数据处理和剖析能力，可能实时响应和解决大规模数据流。同时，企业越来越偏向于将数据存储和剖析工作迁徙到私有云 / 公有云 /K8s 上，因而现代化数据仓库须要反对云原生架构，具备弹性伸缩、自动化治理和云端部署的能力，以适应云计算环境的需要。除此之外，我认为交融对立是也是现代化数据仓库外围的特色。在大数据畛域，存在泛滥的零碎和组件，它们往往在架构中扮演着不同的角色。而随着时代的提高，架构“减负”已成为企业倒退的重要指标，因而像交融数据库、超交融数据库、湖仓一体、流批一体等具备“交融对立”特色的数据库开始涌现。结合实际倒退来看，过来几年，事务数据库已出现显著的交融趋势，像 OceanBase、TiDB 以及 PolarDB 等新一代 NewSQL 事务数据库曾经呈现。同样地，数据仓库走到明天，交融对立也是必经之路。 这些特点其实也就是企业对于实时数据仓库的实在需要，也是 Apache Doris 在过来几年来广受认可的重要起因。 Q2：近期，咱们关注到飞轮科技发表将企业产品 SelectDB Cloud 云原生存算拆散架构奉献到 Apache Doris 社区。在云原生存算拆散架构的研发过程中，团队遇到过最大的技术难题是什么？又是通过什么形式解决的？ ...

流动介绍KCD 杭州 杭州是中国西北沿海核心城市之一、浙江省省会。漂亮的西湖成就了“上有天堂，下有苏杭”的千古美誉。而明天，这张名片，仿佛曾经被“电商之都”所取代。杭州凭借着互联网电商经济成为了煊赫一时的新一线城市，同时也吸引了很多大型互联网公司，并且具备浓重的技术气氛。本次也是 Kubernetes Community Days 首次来到杭州，由 CNCF、蚂蚁开源、龙蜥社区、Dragonfly 社区、KubeEdge 社区联结发动。心愿可能在这座充满活力的城市进一步推广云原生相干技术。 议题征集中本次 KCD 杭州站 2023 演讲议题已凋谢投稿，届时咱们会筛选出优良议题在本次 KCD 杭州站流动中出现。 点击链接即可投递议题：https://www.wjx.top/wjx/join/activityFenMian.aspx?srt=eyRKT8y... 议题截止工夫2023 年 9 月 20 日 23:59 流动信息工夫：10 月 21 日（半天） 规模：150～200 人 模式：线下主题分享+圆桌 议题波及方向介绍本次流动由云原生供应链以及 AI 基础设施两个方向主题会场组成，议题内容可包含软件供应链、AI Infra、容器镜像、DevOps、可观测、平安等热点畛域。CNCF 生态中任何与主题相干的开源我的项目与云原生技术实际的内容均可参加，不局限于 Kubernetes 自身。 时长每个演讲时长 30～45 分钟，包含最初 5 分钟的 Q&A 发问环节。 注意事项此次流动不提供讲师差旅报销，请您合理安排出行在议题征集期间，可自在提交演讲议题若内容适合，但相应专题已无空档，可安顿其余演讲机会请确保您所提供的集体信息内容准确无误请确保您在演讲内容中应用的案例曾经取得第三方的认可和容许，咱们将不负责由此引起的任何纠纷和问题确认的演讲内容将公布在主办单位的无关媒介中，包含会议演讲 PPT、现场视频等。此非强制条款，如果不批准，请提前申明对于已提交演讲议题的审批后果，咱们将在议题征集截止后的一周内通过电子邮件或电话分割的形式告诉您最终分享议题以 KCD 杭州组委会最终发送的告诉为准如有流动相干问题，请增加微信：gaius_qi——完——

基础设施 SIG（OpenAnolis Infra SIG）指标：负责 OpenAnolis 社区基础设施工程平台的建设，包含官网、Bugzilla、Maillist、ABS、ANAS、CI 门禁以及社区 DevOps 相干的研发工程零碎。 01 SIG 整体停顿龙蜥大讲堂 - 基础设施系列专题分享完满收官，8 月邀请了多位 SIG 外围贡献者分享了包含 Ancert、龙蜥社区众测共创、Ance、KeenTune 智能调优、开发者服务平台 devFree 等在内的主题演讲。镜像平台上线镜像制品核心，反对多容器镜像同时构建、反对 AI 镜像构建。内核 CI 反对检测 KABI 性能上线，并且重置了所有合入到 devel-5.10 分支 PR 的测试状态。02 龙蜥大讲堂 8 月系列专题1. Ancert 硬件兼容性验证与守护8 月 1 日：硬件兼容性 SIG Maintainer 吴朝峰，介绍龙蜥社区硬件兼容性认证的步骤和流程和硬件兼容性认证工具 Ancert 的应用办法和步骤。帮忙社区开发者理解龙蜥社区硬件兼容性认证流程，Ancert 应用办法。 直播回放链接：https://openanolis.cn/video/888630644971945994。 2. 龙蜥社区众测共创8 月 3 日：QA SIG Maintainer 苏庆明，介绍龙蜥社区众测共创的理念和讲述了参加社区众测共创的门路。帮忙社区开发者理解龙蜥社区众测共创体系，理解如何应用社区的测试平台等基础设施保障开源我的项目的品质。 直播回放链接：https://openanolis.cn/video/888759693144047617。 3. Ance 兼容性评估8 月 8 日：QA SIG Contributor 谭伯龙，介绍 ANCE 操作系统兼容性评估工具诞生背景、外围个性、根本工作原理介绍以及以迁徙评估场景演示了工具性能。帮忙社区开发者理解龙蜥 ANCE 操作系统兼容性评估工具外围个性、根本工作原理和应用办法。 ...

2023 年 8 月 16 日～18 日，第 14 届中国数据库技术大会（DTCC 2023）于北京隆重召开，拓数派受邀参加本次大会，PieCloudDB 技术专家邱培峰在大会做了《云原生虚构数仓 PieCloudDB ETL 方案设计与实现》的主题演讲，具体介绍了 PieCloudDB 的 ETL 计划总体设计与实现，剖析了 ETL 工具 pdbconduct 及相干数据库内核扩大。 图为拓数派 PieCloudDB 技术专家邱培峰 对于数据库用户而言，ETL 的重要性显而易见。 ETL（ Extract, Transform, Load ），即数据的抽取、转换和加载，简略了解为数据库的数据导入过程。ETL 的实质是不同零碎（数据组织模式）之间的数据挪动。ETL 的过程有助于数据库用户实现数据的高效治理和优化。它确保数据库中的数据不仅仅是存储在其中，还通过了精心的解决，以满足用户的需要。 1 云原生环境下的 ETL随着云原生时代的到来，经济实惠且可轻松扩大的对象存储解决方案成为满足用户对高弹性、高性价比需要的首选。传统 ETL（Extract, Transform, Load）是一种将数据从源零碎抽取、荡涤、转换，最初加载到指标零碎中进行剖析的过程。传统 ETL 的特点是吞吐量大，批量加载性能十分好，毛病是对源端和指标零碎影响较大，通常是在非业务顶峰进行，因此会有较大的数据提早，通常为 T+1。 CDC（Change Data Capture）是指实时或者准实时捕捉数据库或文件系统中发生变化的数据，并将其同步到其余数据系统中，同时确保数据的一致性和准确性。CDC 通常通过解析源端日志的形式实现，对源零碎影响较小，且有较低的时延。但对指标零碎，尤其是剖析性数据库，相比于批量模式，会带来较大的数据更新开销。即使如此，CDC 形式在数据同步方面利用越来越宽泛；同样的，传统的 ETL 模式在很多场景仍有不可代替的劣势。 无论 ETL 还是 CDC 都是把数据复制作为指标的，因而不可避免的会造成肯定水平的数据冗余，也存在造成数据不统一的危险；而基于湖仓技术的一写多读，zero-ETL 等技术能够齐全打消数据复制造成潜在冗余和不统一危险。对立 ETL、CDC 和湖仓技术正是 PieCloudDB Database 的 ETL 计划的指标之一。 PieCloudDB 存算拆散的架构使得不同零碎能够间接共享同一份底层数据，防止了繁琐的数据抽取、转换和加载过程。目前，PieCloudDB 反对间接读取对象存储上的 Parquet 等格局的文件，实现了数据共享和拜访方面提供了便捷性。 某些理论场景下会产生 ETL 需要，例如同一份底层原始数据应用不同零碎查问时，或为不同类型的查问特化的零碎会有不同的存储形式等。因而，在进行 ETL 的方案设计时须要思考以下几个因素： ...

作者 | 百度APP云原生技术研发组 导读  随着云计算的技术的一直迭代演进，百度外部服务逐步搬迁到云环境中，部署老本和效率获得显著收益，但一些可观测能力的短板和缺失逐步露出，传统的形式往往通过植入代码进行批改来实现，但在业务状态和技术栈多样性的背景下，面临业务被侵入、沟通协调、性能、稳定性等方面的诸多问题。本文中咱们介绍百度基于eBPF实现的网络框架：DeeTune，蕴含构建服务拓扑、流量录制、无侵入指标监控等能力，进一步晋升了SRE和品质保障的工作效率。 全文3733字，预计浏览工夫10分钟。 云计算的提高以及基础设施、架构改良和其余相干技术的一直迭代倒退，促成了百度外部服务向云环境的迁徙。只管云服务在老本效益和经营效率方面获得了显著提高，但云环境基本功能的某些局限性和有余也日益显著。因而，某些正当的业务需要，如建设不同微服务之间的拓扑关系和进行测试会话，仍未失去满足。传统的施行办法通常是在业务零碎中嵌入代码，以便于性能集成。然而，因为业务构造和技术堆栈品种繁多，这种传统办法在业务入侵、通信、协调、性能、稳定性和其余相干方面面临诸多挑战。本文介绍了基于 eBPF 的百度网络框架 DeeTune。DeeTune 蕴含许多性能，如服务拓扑构建、流量录制、非侵入式指标监控等。这些性能有助于进步 SRE 的效率和质量保证。 01 问题和挑战百度的微服务规模宏大且持续增长，服务之间的依赖关系同样非常复杂。服务拓扑可能展现全局服务及服务间的调用关系，也可能携带监控信息展现服务链路间的黄金指标，因而服务链路对于零碎可观测性、稳定性保障、基础设施建设都有重要意义。 因为人工梳理老本大，基于SDK和框架的传统形式面临多技术栈、业务侵入等诸多问题，全局服务拓扑能力缺失会导致一些理论业务需要无奈失去满足： 稳定性保障：短少服务及流量拓扑来反对故障期间的疾速定位和准确止损。当呈现稳定性问题时，心愿根据服务拓扑可能疾速地定位问题服务及机房，可能高效获悉并告诉故障服务的依赖和被依赖方、评估故障影响面剖析； 基础设施建设：短少服务拓扑来领导机房搬迁和重建工作的发展。在以往的机房搬迁过程中，服务的梳理和确认是一项重要但繁冗工作，每次机房搬迁都须要较长的工夫梳理服务及其依赖，不仅须要投入人力，还须要预留机器资源，此外还容易引起稳定性危险； 零碎重构降级：短少服务上下游关系以评估零碎重构降级对上下游的影响。降级过程中如何精准告诉依赖方和被依赖方，重构过程中如何获取扇入、扇出等评估服务复杂程度的数据以判断服务是否须要拆分和合并等。 宏大的服务规模、简单的业务类型、繁多的技术栈使得品质工程师的工作面临微小的挑战，如集成测试环境搭建、测试用例编写、测试齐备度评估等。流量回放是目前较先进成熟的自动化测试解决方案之一，通过线上流量录制和线下流量回放，实现对代码的疾速回归能力。可能极大地晋升我的项目迭代效率、减速代码回归测试进度，保障业务研发品质。 没有对立的流量录制计划和工具，流量回放的能力和成果受到了很大制约，流量录制的难点在于： [1]业务技术栈简单，配套的根底库和框架也十分多，无奈通过框架或业务革新进行对立的流量录制； [2]即便是繁多技术栈和框架，也会面临业务侵入和有感的问题，稳定性也可能会受到肯定影响； [3]服务之间的拜访路径十分多，如通过网关拜访、虚构IP拜访、服务间间接连贯等，无奈通过对立的流量出入口录制流量。 服务间调用的指标（如流量、耗时等）和跟踪是业务上用于稳定性问题和服务性能优化的重要依据，但目前所有可观测性计划都是业务侵入的，须要框架或业务本身革新。另一方面，对于主机和容器的监控，除了操作系统提供的一些动态计数器，还须要可能从不同数据源收集和聚合数据，反对一些更深度的可观测性能力，帮忙剖析定位系统问题。但这类能力的开发难度和资源耗费都十分大。 02 eBPF介绍导致上述技术挑战的根本原因在于业务状态和所采纳的技术栈具备多样性，横向的跨业务、跨技术栈需要会导致规范性、业务侵入、沟通协调、性能、稳定性等多方面影响。 随着eBPF技术近几年的疾速倒退和利用，可能为咱们解决以上问题提供新的解决方案和思路： [1]eBPF是内核相干技术，它与用户态的技术栈、框架无关； [2]可能在业务无侵入的形式下拿到更多内核态和用户态信息，能够在很大水平上为咱们提供帮忙甚至是解决问题。 eBPF全称为：extended Berkeley Packet Filter，是linux内核态引入的一套通用执行引擎，它容许在Linux内核中基于事件触发运行用户自定义的代码逻辑： [1]eBPF提供了一种软件定义内核的办法，能够应用eBPF实现Linux的动静追踪以及Linux高速的网络数据包解决等逻辑； [2]eBPF能够在不扭转内核源码或加载内核模块状况下在内核中插入指定hook代码，能在内核或应用程序执行到一个特定的 hook点时执行（预约义的 hooks点位蕴含零碎调用、 函数出入口、内核追踪点、网络事件等）。 03 eBPF特点[1]平安、稳固：通过严格限度拜访函数集、内存地址、循环次数、代码门路触发，内核内置了稳固的API，保障只有被验证平安的 eBPF 指令才会被内核执行； [2]高效：eBPF 指令仍然运行在内核中，无需向用户态复制数据，并且借助即时编译器（JIT）将字节码转成机器码，运行效率等同于内核运行，执行更高效； [3]热加载(继续交付)：eBPF程序的加载和卸载无需重启linux零碎； [4]数据互通：maps实现用户和内核态数据互通； [5]兼容性：eBPF提供了稳固的 API，能在老内核上执行，那它肯定也能持续在新内核上执行。 应用ebpf技术，能够为平安、tracing&性能剖析、网络、观测&监控等方向提供新的思路和解决方案： [1]平安：能够从零碎调用层、packet层、socket层进行安全检查，如编写防火墙程序、开发DDOS防护系统等； [2]Tracing&性能剖析：内核提供多种类型探针(probe point)，如Kernel probes、perf events、Tracepoints、User-space probes、XDP等，能够编写eBPF程序收集这些探针点的信息，通过这种形式对程序进行跟踪，分析程序性能； [3]网络：能够开发内核层高性能包处理程序，比方Cilium提供内核层的负载平衡，把service mesh往更深层推动，解决sidecar的性能问题； [4]观测&监控：对这些探针点的继续观测和监控，能够丰盛指标数据的范畴和深度，更重要的是，这项工作能够在在不扭转既有程序的前提下实现。 04 最佳实际 [1]Facebook：Katran 开源负载均衡器， L4LB、DDoS、Tracing [2]Netflix：BPF 重度用户，例如生产环境 Tracing、profiling [3]Google：Android、服务器平安、可观测性以及其余很多方面，GKE 默认应用 Cilium 作为网络根底 ...

当用户充分利用原生云能力进行利用设计、部署和运维时，云原生也面临新的平安挑战，例如镜像破绽与投毒、编排软件破绽、不平安配置利用、容器逃逸等。 面对这样的危险，京东云重磅公布云原生平安平台，蕴含资产盘点、镜像平安、运行时平安、网络安全、集群平安、节点平安等平安服务，提供从镜像生成、存储到运行时的全生命周期云原生平安解决方案。 直击痛点打造一体化防护每年的京东6.18、11.11都会面临高并发、大流量的技术挑战。通过对大规模的利用开发和零碎的保障实际，京东云平安团队总结出了一套合乎DevSecOps场景的一体化全生命周期云原生平安防护理念，造成了保障全生命周期的CNAPP平台——京东云原生平安平台。 该平台由一个产品提供全面能力，对立管制端、对立权限散发、对立策略配置，实现资产盘点一体化、网络防护一体化、镜像容器节点利用防护一体化和基础设施平安一体化。与此同时，平台笼罩镜像构建、容器运行、利用平安、编排平安、计算资源平安、网络安全，贯通整个生命周期。 云原生实际积淀架构劣势目前，京东云经营着寰球最大规模的Docker集群、Kubernetes集群，以及最简单的 Vitess 集群之一，是目前寰球容器化最彻底的科技企业之一。 早在2014年，云原生技术暴发之前，京东就率先将Docker容器技术大规模利用至生产环境。2016年开始实际了Kubernetes技术，并成为Harbor最早的一批用户 。2018年，京东云正式退出CNCF基金会，成为其首位白金会员。京东云是CNCF开源我的项目最大的使用者与贡献者之一，并在当年取得CNCF终端用户奖。 基于多年的云原生实际，京东云原生平安平台积淀了云原生化部署、混合多云适配丰盛终端、国产化适配支流零碎等架构劣势。 云原生化部署采纳灵便的分层架构设计，可能基于用户场景、行业、规模属性灵便地进行私有化部署。轻量化探针面向云原生kubernetes场景采纳非侵入部署形式，还反对以Daemonset进行更加云原生化的主动一键部署、主动管理模式。管制面整体采纳计算数据拆散、接口计算拆散的架构，通过管控层进行探针治理、数据汇聚、工作治理，实现探针agent一键操作。 所有数据都由存储模块对立治理，包含离线计算、在线计算、长久化存储，反对多正本架构，确保数据的安全性。通过中间层对立提供接口实现接口对立入口、对立治理。 智能化利用网络架构感知通过主动采集、学习网络流量，多种形式智能剖析流量与利用关联关系，基于利用视角主动构建网络架构拓扑，真正实现每一个利用网络架构都清晰可见，不再是横七竖八的网络“毛线团”。 真正的业务无感利用平安保镖业务部署毋庸关注安全策略，通过自动化流程主动施行防护。业务方实现齐全无感接入，平安对立治理不再有脱漏。 弱小的未知威逼防护能力基于机器学习查杀引擎，将人工智能、算法和机器学习利用于恶意代码的预测、鉴定和阻止，在线和离线状况均能高效预测和预防已知和未知威逼，反对RASP能力，为每个利用都配置了“贴身保镖”。在fastJson、log4j零日破绽产生期间，精确辨认利用行为，无效分辨出未知威逼和零日破绽攻打。 当先的基础设施防护能力与新兴云原生平安厂商不同，京东云原生平安可能做到弱小的基础设施防护，笼罩节点破绽，病毒木马，网页木马，可疑操作，暴力破解，异样登录等平安检测与防护。自研云查杀引擎辨认已知病毒检测99%，未知病毒识别率高达97%，当先行业检测率。真正做到云原生平安底座与容器，网络与利用全方位笼罩。 混合多云适配丰盛终端以云原生架构体系为根底，反对跨平台部署京东云、混合云、公有云、其余云；适配多种终端服务器、虚拟机、IDC、容器、裸金属服务器等。 国产化适配支流零碎已胜利交付麒麟、海光、飞腾、统信等多个国产化零碎，撑持运营商、政府、金融、制作、交通、医疗、能源等畛域的数字化转型，在国产化破绽畛域始终保持当先的检测和防护能力。 京东云继续致力于以更低的老本、更高的效率、更好的体验为合作伙伴提供云原生平安服务，为产业数字化筑牢平安屏障。 作者：京东科技 王菁 转载请注明出处

云原生平安危险随着云原生架构的疾速倒退，外围能力逐步稳固，平安问题日趋紧急。在云原生平安畛域岂但有新技术带来的新危险，传统IT基础设施下的平安威逼也仍然存在。要想做好云原生平安，就要从这两个方面别离进行剖析和解决。 新技术带来新的平安危险云原生的概念定义自身就比拟形象，从诞生到当初也经验了屡次变动。2018年CNCF对云原生的概念进行了重定义：云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式API。尽管这是云原生概念最新的定义，然而不同的人对云原生的抽象概念了解相差很大，始终在一直地争执。广义的了解间接套用定义，认为定义之外的技术不属于云原生。狭义的了解则认为定义不够贴切，应该从字面含意进行了解，认为只有是能利用云的个性，在软件工程各阶段提高效率，降低成本的行为、技术，都能够认为是云原生。 从广泛认知来看，云原生次要包含kubernetes和容器、微服务、云基础设施，其中kubernetes和容器在某种程度上曾经是云原生的代名词。其中kubernetes和容器作为云原生时代的典型技术，也是带来危险最多的技术，包含：kubernetes组件破绽、认证鉴权不标准、公开镜像存在破绽、镜像被植入恶意程序、容器隔离被冲破造成逃逸等。微服务在云原生时代疾速倒退，在外部危险无奈防备的时候会扩充平安危险，造成横向攻打扩散。 传统IT基础设施的威逼仍然存在云原生不能脱离底层IT基础设施：计算、存储、网络而存在，因而这些IT基础设施面临的问题在云原生场景下仍然存在。DDoS攻打防护、cc攻打防护、破绽、木马、病毒、数据泄露等等平安危险，并没有因为云原生的倒退而升高。 云原生平安构建在云原生平安晚期，人们的惯性思维就是利用传统的平安防护伎俩去进行云原生平安防护。通过这么多年的攻防反抗，传统产品在各自的畛域都曾经南征北战，解决对应的平安问题也都不在话下，这些平安产品通过简略地革新，就能够与云原生架构配合运行。 积木式云原生平安这个阶段云原生平安并不存在一个残缺的架构，各平安产品就像搭积木一样跟云原生架构进行配合。随着这个平安体系的构建，工程师门很快就发现，平安并没有因为云原生的到来产生什么扭转，这种搭积木式的云原生平安计划，从远处看各方面的平安都能有，计划也很残缺。然而从近处看就能看到平安产品之间根本没有分割，应用起来并没有什么扭转，仿佛平安和云原生就是两个独立的畛域，无奈撑持云原生疾速倒退的平安防护需要。 装配式云原生平安随着在云原生平安方向上的深入研究，人们发现平安+云原生并不是简略组合一下就能变成云原生平安。要想做好云原生平安，就必须依照云原生的思维去思考平安问题怎么解决，云原生平安应该是一个整体，而不是各个割裂的平安产品。Gartner认为，全面爱护云原生利用须要应用来自多个供应商的多种工具，这些工具很少失去很好的集成，而且通常只为平安业余人员设计，而不是与开发人员单干。对于组织而言，这种孤立的平安工具在面对理论平安危险的并不太无效，而且会导致过多的警报、节约开发人员的工夫。在这种趋势下，Gartner提出了CNAPP云原生利用爱护平台，将多种平安工具严密地联合在一起，以爱护日益简单的攻击面。 云原生的一个底层核心理念就是拆解、组合和标准化，这其实也是软件开发畛域一个软件工程师长期谋求的指标，行将业务逻辑和通用逻辑一直拆分，通用逻辑逐步独立标准化，开发人员只须要关注本身业务逻辑。kubernetes从业务利用的角度将通用逻辑拆解，解决业务场景灵便多变的问题。不可变基础设施作为云原生定义的四大因素，是最容易被疏忽的，然而这个理念却是云原生可能继续倒退的外围，极大地升高了云原生的复杂度，将标准化施展到极致。这两个核心技术都是底层理念的体现。这个理念跟装配式修建非常相似，把传统建造形式中的大量工作转移到工厂进行，在工厂加工制作好修建配件（如楼板、墙板、楼梯、阳台等），运输到修建施工现场，通过牢靠的连贯形式在现场拆卸装置而成的修建。这种形式不仅修建速度快，工业化品质也有保障。 装配式云原生平安，就是依照云原生的核心理念，将各平安能力进行拆分、标准化革新、再组合。各平安能力不只是简略的重叠，通过云原生技术牢靠地连贯在一起，让每个业务利用从诞生开始，就具备适合的平安能力，实现公布即平安。相比积木式能力组合，这种形式能够让平安和业务实现深刻且自在地组合，造成灵便又牢靠的云原生平安。 利用依照工夫维度可分为开发、测试、部署、运行、响应，空间维度可分为主机、操作系统、kubernetes、容器、服务、网络，从这两个维度登程，将各种平安能力进行拆解和组合，通过对立的云原生平安平台进行治理，真正将平安和业务的各个阶段都能严密地连贯在一起，能力造成真正的云原生平安。 作者：京东科技 李卓嘉 起源：京东云开发者社区 转载请注明起源

在进行函数计算 Stable Diffusion 答疑的过程中，遇到很多同学在装一些插件的过程中遇到了难题，有一些须要装置一些依赖，有一些须要写一些代码，很多时候装置一个插件就能折腾几天，咱们收集了很多同学须要的插件，这一次把比拟难装的 Stable Diffusion 插件都装好了。 能够依据本人的须要自行勾选。 基于函数计算部署 Stable Diffusion 教程：https://developer.aliyun.com/adc/scenario/b2cc0e1c3a6244e0bd9fc0f37acd5a0e 应用时在列表中进行勾选，点击 Apply and quit，重启的 WebUI 就会自带插件。 这些插件能做什么？ADetailer 插件：修复崩坏脸应用 Stable Diffusion 生成人物的时候，常常会遇到脸部崩坏的问题，adetailer 插件无效改善脸崩问题。 关上 ADetailer。 找一张脸崩的图片，拖到【图片信息】选项卡内，获取图片信息，而后点击文生图，载入图片信息设置，After Detailer 里勾选 enable adetailer，如果是修复脸的话就抉择模型名字带 face 的，修复真人的话，感觉第三个和第四个成果更好。这个插件对修脸的确有奇效，能够看上面比照信息，多个脸也能修复。Adetailer 插件比单纯的勾选“面部修复”成果好很多。 Deforum 插件：瞬息宇宙制造者前一阵瞬息宇宙视频火了，通过画面一直变动，变成新场景的视频十分吸引眼球，这个插件就是制作这种视频的必备神器。 应用 Deforum 插件甚至能够本人定义关键帧和第一帧，留神格局与示例保持一致，制作爆款视频不是梦。 Prompt all in one 插件：翻译助手这个插件不愧名为 all in one，能够解决写提醒词过程中的翻译、增加逗号、多语言转换……问题，堪称神器。 能够抉择多种语言进行输出，能够抉择多种翻译接口，提醒词输出、翻译，还可能一键翻译所有的英文单词，这样从其余中央拿到提醒词后，就不必看哪个是生词，还要去软件翻译啦。能够间接在 webui 的输入框输出，点击一下空白处就能主动翻译。还能进行提醒词珍藏、历史提醒词。 roop 插件：一键换脸很多换脸技术，须要对人脸进行大量训练才可实现。而这个插件，只需提供一张照片即可，10 秒换脸。 Image Browser 插件：图像治理Image Browser 不仅是一个图像浏览器，也是一个弱小的图像管理器。准确的图像搜寻与多抉择操作相结合，大大提高了效率。该插件反对图像的搜寻和珍藏，反对图像预览和“发送到”。能够基于文件树结构预览和文件操作。 rembg 插件：一键抠图神器抠图是很多设计师的刚需，也是一个比拟费时费力的活，Stable Diffusion 插件stable-diffusion-webui-rembg 实现图片能够实现一键疾速抠图，省时省力成果还很不错。 ...

微服务已成为企业数字化首选的利用架构，并正在向缩短服务的构建周期和升高资源老本、晋升架构品质和架构效率两个方向演进。 明天，阿里云正式发表微服务引擎 MSE 重磅降级，全面 Serverless 化，带来两大新形态和两大新体验。 产业新形态，业内率先向 Serverless 状态演进MSE 的注册配置核心、云原生网关的 Serverless 化，体现在两方面。一是计费模式 Serverless 化，本来购买一套注册配置核心，3 节点起购，须要 498 元/月，应用 Serverless 模式计费后，1个月起购价将不到 100 元，随弹随用。二是运维层的 Serverless 化，能够帮忙 Nacos、Nginx 研发和运维轻松实现主动弹性、免去容量布局等操作，从而缩小运维累赘。新的计费模式将于 9 月开始公测，新老客户均实用。 开发新状态，注册配置开发版目录价预计降落超 20%MSE 的注册配置核心开发版已通过资源耗费的深度优化，将技术红利转化为老本红利，预计目录价价格将降落超 20%， 大幅升高 Nacos 和 Zookeeper 研发和运维工程师的微服务开发和测试老本。以往，开发者们须要自行购买服务器、搭建和保护开发测试环境，如果是在本地开发测试，还要进行端云联调，承当额定的公网流量费用。应用 MSE 的注册配置核心开发版，这些问题都会迎刃而解，从而使得开发者聚焦在业务开发上，另外，相比自建开发测试环境，开发版的价格将更有竞争力。价格变更将于 9 月失效，新老客户均实用。 产品上手新体验，控制台新增老手疏导MSE 提供注册配置核心、云原生网关、微服务治理的一站式上线老手疏导性能，并面向新用户提供一个月的收费试用资源，这意味着从工夫和资源两个纬度，升高了用户应用产品外围能力的老本，并且全面反对 Nacos、Zookeeper、Nginx 开源到商业的不停服迁徙，缩短迁徙前的评估工序。 服务自治新体验，面向服务的自治体系全面降级提供事件核心能力，事件核心对注册配置核心、微服务治理、云原生网关生成的事件数据提供了对立的治理能力、剖析与展现能力和告诉能力。对于一些异样事件，能够依据 MSE 提供的指引进行自主排查，以便疾速定位问题并提供解决方案，实现从低运维到真正免运维。 微服务引擎 MSE 继续投入技术革新，让客户在老本、性能、稳定性、平安方面一直的享受技术带来的红利： “咱们通过 MSE 云原生网关，将流量、平安、微服务网关三合一，大幅升高申请链路条数、升高架构复杂度、运维和故障排查老本，例如升高整个链路 RT 峰值从 500ms 降落至峰值 50 ms，服务公布期间 502 报错降为 0，499 报错均匀升高 10% 等。”  --- Soul ...

作者：邵丹 置信大家常常在短视频网站上刷到各种“高血压“小游戏吧。当你按捺不住点击，却发现手机上多了一大堆“流氓软件”的时候，血压就更高了。 然而！ 明天！ 咱们把“虚伪广告”做成了实在的游戏，并且能够轻松部署到阿里云 Serverless 利用引擎 （简称：SAE） 上，实现点击即玩！ （SAE 是一款极繁难用、自适应弹性的利用托管平台，用户能够在 SAE 上构建和部署任意语言的弹性利用。） 操作流程需 5 分钟 ， 实现更有 Airpods 等精美礼品奉送，详见文末流动链接。 资源筹备注册并登录阿里云账号开明 Serverless 利用引擎 SAE 并支付试用额度开明容器镜像服务 ACR开始部署登录 SAE 控制台，点击利用治理——利用列表，抉择华北 3（张家口） 地区 。 点击体验 SAE 2.0 公测版进入 SAE2.0 控制台。 点击利用治理—创立利用。 在创立利用页面，配置相干信息。抉择从源码仓库继续部署，点击设置继续部署。 4.1 在根底信息设置区域，输出自定义的利用名称与利用形容，利用部署形式抉择从源码仓库继续部署，而后单击设置继续部署，在设置继续部署面板，配置相干信息，而后单击确定。 4.2 在 HTTP 流量全托管区域，配置相干信息。 4.3 在容量设置区域，配置相干信息，而后单击跳过高级设置，创立利用。 4.4 利用创立实现后，会跳转至根底信息页面。在此页面，您能够查看计量数据、利用弹性监控、利用信息，以及编辑流量拜访设置等信息。 在根底信息页面的 HTTP 流量全托管区域，单击公网拜访地址，即可开始玩耍。首次拜访，SAE 会主动增加您的公网 IP 地址到白名单中。如果后续拜访失败，请更新 IP 白名单。 提交评测得大奖将您本次部署过程，以及对 SAE2.0 的应用感触反馈给咱们，即可取得流动奖品。 1. 参加奖：流动期间凡公布 100 字以上（含代码串）无效评测且通过审核的用户，可获 50 积分 争优奖：30 篇，流动期间评测文章被官网断定为“优”的前 30 篇，将取得 30 元猫超卡后劲奖：5 篇，官网评定优质评测文章，取得定制卫衣+小魔晴雨伞+SAE 根底版月包+优质评测证书最优奖：1 篇，官网评定最佳评测文章，取得 AirPods 2+SAE 专业版季包+最佳评测证书+社区首页展现 1 周 ...

如果说传统云计算期间的操作系统是 Linux，那云原生时代的操作系统就是 K8s ，其重要性显而易见。学好 K8s，可能帮忙开发者更好地把握云时代的重要趋势。然而，很多开发者一想到 K8s 较高的上手门槛和学习老本，往往望而却步，始终短少机会和能源真正上手。 如果你也始终想解决这个问题，从而疾速口头起来，理解、学习和应用 K8s 技术及产品，找个学习搭子吧！ 当初，约上你的“K8s 学习搭子”一起来加入“阿里云容器 Clouder 比拼”，把学习气氛烘起来！互相监督、摸鱼互喷、保持打卡、实现认证，只有你们通过了阿里云容器 Clouder 认证考试，就可能取得由阿里云总裁亲笔签名的证书，此外，还有云小宝留念公仔、定制水杯、晴雨伞得诸多实用礼品等你拿！ 约上 K8s 学习搭子 来场容器 Clouder 比拼！ 流动简介本次流动由阿里云培训中心与云原生利用平台联结举办，流动基于阿里云“云原生容器 Clouder”系列下的“容器利用与集群治理”课程与认证，通过学习与实操训练、考试，您将理解与容器集群相干的概念和技术，这些概念和技术能够帮忙您理解阿里云容器服务 ACK 的应用。 阿里云容器服务 ACK 是寰球首批通过 Kubernetes 一致性认证的产品，反对企业级容器化利用的全生命周期治理，是国内惟一间断三年入选 Gartner 公共云容器报告、惟一进入 Forrester 领导者象限的公共云容器计划。其整合了阿里云虚拟化、存储、网络和平安能力，可助力企业高效运行云端 Kubernetes 容器化利用。 同时，本认证也会向您介绍能够采取的工具、办法和可操作步骤，以帮忙您理解如何基于容器服务 ACK Serverless 版，更简略地构建和治理企业级利用。 流动工夫即日起至 2023 年 9 月 30 日 流动玩法和处分玩法 1: 「比」技能，实现阿里云容器 Clouder 认证 登录流动官网并报名加入，通过阿里云容器 Clouder 认证考试，即取得阿里云总裁亲笔签名认证证书。流动期间工作日每日 10 点开始，实现支付 ACK Serverless 试用资源、学习课程、趣味实操练手、考试认证 4 个工作，即可取得阿里云云小宝限量公仔，每天限额 10 个，先到先得，领完即止。 玩法 2：「拼」同学，携手上云领好礼 ...

开迈斯新能源科技有限公司于 2019 年 5 月 16 日成立，目前合资股东别离为大众汽车（中国）投资有限公司、中国第一汽车股份有限公司、一汽-大众汽车有限公司[增资扩股将在获得适当监督（包含反垄断）审批后实现]、万帮数字能源股份有限公司和安徽江淮汽车集团控股有限公司，总部位于江苏常州。开迈斯集车企与充电企业劣势于一体，提供从充电基础设施的研发制作到软件的智能互联，从私人充电用户到半公共、公共以及商务用户，从电力供应的行业源头到服务平台的终端体验，实现每一个业态的前后端无缝连贯。 开迈斯为中国新生代消费者而来，不仅重视私家电动车主的充电体验，还以高端的品质服务提供用户便捷无忧、智能高效的全新充电体验，开启乐享生存的旅程。同时，开迈斯致力于为电动出行提供全场景充电服务，依靠弱小的研发实力、先进的核心技术和高质量服务，还播种了国内新能源汽车充电畛域的诸多奖项：2021 年，开迈斯荣膺“中国充电桩行业最佳经营服务创新奖”；2023 年 3 月，开迈斯一举取得“高质量充电五星级场站奖“，成为首批取得五星级评估的优良充电运营商（五星级别是最高级别最高规范的场站）；同年 6 月，开迈斯荣获 2023 中国充换电行业十大影响力运营商品牌奖。开迈斯将继续推动充电网络建设速度和充电用户旅程的优化翻新，并将聚焦高功率充电设施研发和新能源服务畛域的摸索，从而推动新能源与新能源汽车深度交融的绿色倒退。 业务稳定性挑战大2023 年，开迈斯将持续致力于以用户为核心的整合翻新，致力打造智能电动出行。截止往年 5 月底，开迈斯充电网络覆盖国内 180 城，建设 1,198 座充电站和 10,490 个充电终端，积攒用户超 196 万。从建设滞后到“适度超前”，将来三年充电桩产业将迎来大倒退，市场规模达千亿级。当初全国各地很多城市在对充电桩的增设和利用上在一直降级加码，随着新能源汽车的倒退，充电用户群体的诉求飞速增长，开迈斯随同着业务的快速增长，对其架构的稳定性以及可用性也提出了前所未有的挑战。 开迈斯采纳传统的 SpringBoot 形式进行利用开发，利用间通过 Http 申请形式进行互通互联，也正是 SpringBoot 架构的简略性，无效帮忙到开迈斯的业务以及微服务数量进行疾速扩张。然而随着微服务规模的增大，逐步发现利用在公布、运行等各个阶段的都存在一些稳定性与效率上的问题。随着用户与的增多，相应的需要也越来越多，业务场景也越来越简单。在这个时候仅依附内部测试很难保障能够笼罩到所有的场景，每次利用的公布都须要进行充沛的测试与足够的灰度验证。为了满足疾速迭代的业务诉求，如何能够做到低成本地进行多个迭代在开发环境并行，并且保障每次业务发版的稳固，成了提效的要害。 在大规模之下，再小的问题都会牵一发而动全身。一方面，咱们面对的流量是随机的、无奈预测的，当激增流量超出服务承载下限时，可能会使服务变慢、负载飙高，导致服务解体。另一方面，散布式微服务架构是简单的网状架构，调用链路盘根错节，这时候任何一个服务（包含依赖的内部服务）呈现不稳固因素（如慢调用或异样）时，都有可能把上游调用方拖垮，进而造成级联影响。因而，在微服务治理中，咱们须要一些伎俩来预防这些不稳固的状况。 面对继续演进增长的微服务架构，开迈斯架构同学也意识到须要引入微服务治理能力对以后的微服务进行失当的治理，从而进一步晋升微服务的稳定性与效率。同样的，业务仍旧面临疾速倒退的诉求，如果将原先的 Spring Boot 框架升级成 Spring Cloud 并且引入各种高阶的服务治理能力，对于目前面对业务疾速倒退的开迈斯研发同学来说，须要投入老本过于太大。 无感实现微服务架构降级是否有一种不必改代码的形式实现咱们微服务的治理能力呢？比方通过施行全链路灰度公布来防止变更带来的稳定性危险；通过限流降级能力保障运行态的稳定性，解决不确定的流量带来的稳定性危险；通过鉴权能力解决微服务间调用的平安危险。这就好比，咱们如何能够在飞机高速运行的过程中，通过更换引擎来晋升飞机的性能？更要害的是，对于咱们飞机上的乘客来说，还要是无感的。 咱们将问题进一步形象，如何能够不改代码，实现任意 Java 利用的服务治理能力，并且在这个过程中咱们须要确保稳定性、问题诊断效率、架构的可持续性、性能等一系列事实的因素。 技术的摸索总是为业务服务的，咱们围绕着开迈斯的计划进行了一步探讨，是否能够通过对立南北和东西向流量治理的计划来解决用户无侵入服务治理的难题？ MSE 云原生网关是兼容 K8s Ingress 规范的下一代网关产品，将流量网关、微服务网关 和 WAF 平安网关三合一，具备高集成、易使用、易扩大、热更新的特点。它买通了 K8s/Nacos 等多种服务起源，通过无损高低线、全链路灰度、过载爱护、故障自愈、限流降级等伎俩，晋升整个链路的利用稳定性。MSE 云原生网关采纳了全托管的模式，用户在抉择云原生网关之后，只须要关怀网关的具体应用，无需关怀云原生网关自身的运维、稳定性、监控、报警 等性能， 开箱即用，应用门槛低。思考到云原生网关能够通过路由规定对立流量以及流控，那么是否可能通过 Higress 实现服务间调用流量的治理诉求？ 服务间的流量转发与治理既然思路敲定了，大家评估完了稳定性、平安与老本之后，那么就疾速开始计划的实际与摸索了。咱们首先面临的问题是原先通过域名调用 K8s Service 的形式，咱们如何将流量转发至 Higress 并且通过 Higress 再转发给实在对应的 Pod 呢？并且在这个过程中咱们须要思考计划的稳定性。 ...

PieCloudDB Database 最新动静云上云版「控制台」性能上线PieCloudDB 云上云版「控制台」性能全新上线，控制台集成了组织、数仓、用户、费用、权限等多方位治理性能，反对在一个组织下创立和治理多个数仓，并反对独立的一套权限管理体系。管理员可依据具体业务需要，凋谢不同的控制台零碎权限给不同的角色，以便被授予这些角色的用户进行操作（如用户治理、财务管理等）。 用户登录后可点击页面右上角头像处，进入控制台界面，初始注册用户主动成为组织管理员。 起源：PieCloudDB 云上云版 PieCloudDB 反对 LDAP 或 LDAPS 协定PieCloudDB 新增反对 LDAP（轻量级目录拜访协定）性能，反对用户抉择应用 LDAP 或 LDAPS 协定，用户可进入「控制台」，点击「组织治理」页面的「增加身份认证」，进行 LDAP 增加。通过 LDAP，企业能够实现身份验证和受权，进行对立的访问控制和用户治理，不便企业更加灵便的进行治理。 起源：PieCloudDB 全线产品 云上云版内部接入 PieProxy 反对 Transaction 和 Session 模式PieCloudDB 云上云版内部接入 PieProxy 现反对事务（Transaction） 和会话（Session）两种模式，并针对接入详情页面进行了优化。用户能够依据不同的利用场景抉择不同的连贯模式进行连贯。关注性能能够采纳事务模式，关注会话配置能够采纳会话模式。其中，会话模式为默认连贯模式。 起源：PieCloudDB 云上云版 云上云版虚构数仓日志性能凋谢PieCloudDB 云上云版凋谢虚构数仓日志性能，反对 ERROR 级别以上谬误日志收集，用户可点击虚构数仓列表 - 查看日志进行查看。 起源：PieCloudDB 云上云版 云上云版控制台数仓列表更新PieCloudDB 云上云版中，控制台的数仓列表减少跳转门路显示和复制性能，不便用户应用数仓门路间接在 region 下登录应用数据计算服务 。 起源：PieCloudDB 云上云版 云上云版反对聚合及线下对公汇款领取形式PieCloudDB 云上云版付款形式现反对聚合领取形式（微信、支付宝）及线下对公汇款形式，为企业用户创立专属汇款账号，解决企业领取的场景。 起源：PieCloudDB 云上云版 优化简墨（JANM）对超大字段存储的反对PieCloudDB JAMN 对超大字段存储的反对早已实现根本的读写操作。在全新版本中，PieCloudDB JAMN 已进一步优化，全面反对超大字段存储的 UPDATE/DELETE 和 VACUUM 性能。 起源：PieCloudDB 全线产品 OpenPie 近期新闻杭州企业高新技术钻研开发核心拓数派数据计算研发核心荣获“杭州市企业高新技术钻研开发核心”认定。这一荣誉的取得，进一步坚固了拓数派在杭州高新技术产业中的领先地位，体现了拓数派在数据计算畛域的技术实力和市场影响力。 起源：OpenPie 官网 ...

@TOC 一、Magma导航页介绍1.1 Magma导航页简介Magma导航页是一款可高度定制、轻量级和响应性强的集体仪表板 。1.2Magma导航页特点简略,轻量级,疾速多种语言多重主题可高度定制的二、本地环境介绍2.1 本地环境规划本次实际为集体测试环境，操作系统版本为centos7.6。hostnameIP地址操作系统版本Docker版本jeven192.168.3.166centos 7.620.10.172.2 本次实际介绍1.本次实际部署环境为集体测试环境，生产环境请审慎应用；2.在Docker环境下胜利部署部署Magma导航页。三、本地环境查看3.1 查看Docker服务状态查看Docker服务是否失常运行，确保Docker失常运行。[root@jeven ~]# systemctl status docker● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2023-07-11 20:05:39 CST; 2 weeks 0 days ago Docs: https://docs.docker.com Main PID: 9572 (dockerd) Tasks: 51 Memory: 2.8G CGroup: /system.slice/docker.service3.2 查看Docker版本查看Docker版本[root@jeven ~]# docker versionClient: Docker Engine - Community Version: 20.10.17 API version: 1.41 Go version: go1.17.11 Git commit: 100c701 Built: Mon Jun 6 23:05:12 2022 OS/Arch: linux/amd64 Context: default Experimental: trueServer: Docker Engine - Community Engine: Version: 20.10.17 API version: 1.41 (minimum version 1.12) Go version: go1.17.11 Git commit: a89b842 Built: Mon Jun 6 23:03:33 2022 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.6 GitCommit: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1 runc: Version: 1.1.2 GitCommit: v1.1.2-0-ga916309 docker-init: Version: 0.19.0 GitCommit: de40ad03.3 查看docker compose 版本查看Docker compose版本，确保2.0以上版本。[[root@jeven ~]# docker compose versionDocker Compose version v2.19.1四、下载Magma镜像在docker hub下载Magma镜像help14/magma:latestdocker pull help14/magma:latest ...

8 月 25 日“阿里云 Serverless 技术实际营（Serverless+AI 专场）”北京站圆满闭幕。流动受众以关注 Serverless+AI 技术的开发者、企业决策人、云原生畛域创业者为主，流动模式为演讲、入手实操，让开发者通过一个下午的工夫增进对 Serverless 和 AI 技术的了解，疾速上手 Serverless，拥抱云计算新范式带来的技术红利。 关注公众号，后盾回复：北京0825 收费下载北京站讲师 PPT 合集 8 月 30 日（周五）13:30，咱们将在【阿里云云原生】视频号对本场流动进行线上直播回放，欢送进行预约。 精彩回顾分享主题｜尽享红利，Serverless 构建企业 AI 利用计划与实际 阿里云云原生高级架构师洛浩为大家分享解说：本议题将介绍 AI 浪潮下，Serverless 构建企业 AI 利用的解决方案，最佳实际和技术支持，帮忙企业升高部署老本、进步开发效率和利用性能。 分享主题｜基于 Serverless 技术搭建 Stable Diffusion 创作平台 Serverless 基础架构负责人卢令为大家分享解说：本议题介绍如何利用 Serverless 技术构建 Stable Diffusion 平台，为集体/企业提供一个平安、高效的数字内容创作和治理平台。 分享主题｜Serverless 大语言模型利用构建 AI 知识库 阿里云智能技术专家寒斜为大家分享解说：本议题将介绍如何利用 Serverless 构建基于大语言模型的 AI 知识库，以提供更精确、高效的问答服务。通过应用 Serverless 技术，能够实现自动化部署、高可用性、低成本等劣势，从而更疾速、更无效地构建 AI 助手。 分享主题｜Serverless 架构下的 AI 利用开发新范式 阿里云 Serverless 产品经理江昱为大家分享解说：本文将探讨如何利用 Serverless 架构来开发人工智能利用，包含应用函数计算、Serverless 利用核心，modelscope 等实现 AI 模型的部署与调用，以及如何将 AI 利用与 API 网关、数据库等服务进行集成。 ...

8 月 25 日，“阿里云云原生技术实际营”在长沙圆满闭幕。流动现场，阿里云一线工程师、湖南昌盛优选云原生技术负责人与现场近百位关注云原生的开发者、企业决策者一起体验了云原生的产品和技术能力及高效稳固的企业级云原生上云计划，同时交换了 Serverless、容器、微服务、音讯队列、可观测等技术在具体落地不可漠视的要点。 在流动体验环节中，通过入手实操“基于函数计算部署 Stable Diffusion AI 绘画服务”、“基于 MSE 实现全链路灰度“、“基于容器服务搭建企业级利用”、“SAE 实现 XXL-JOB 零革新迁徙”以及“一件体验 RocketMQ 六大场景”。帮忙大家一起搭建了属于本人的云原生利用平台。现场氛围在互动中一直升温，也让咱们感触到了长沙站搭档的激情。 阿里云云原生技术实际营长沙站流动现场 关注公众号，后盾回复：0825 收费取得长沙站讲师 PPT 合辑 精彩回顾上面就让咱们一起回顾本次流动上都有哪些精彩霎时，扫描下方金句海报二维码即可退出本次流动群。 01 分享主题丨云原生技术计划概览 企业亟需充沛开掘云计算的技术红利，助力业务倒退，发明更多的商业价值。而云原生能够激活利用构建范式，以解决企业在新期间遇到的挑战。本次分享中，阿里云技术专家，姚翔为大家次要分享了利用的三大范式：全面容器化、核心技术互联网化以及利用 Serverless 化。 02 分享主题丨云原生降本增效 降本增效从云计算倒退至今始终都是企业上云最外围的关注点，在流动现场，昌盛优选云原生技术负责人，韩峰分享了企业线上批发业务高速倒退过程中， IT 架构全面容器化的演进历程中，借助优雅高低线、超卖治理、智能回收、弹性膨胀、分级管理，升高了云资源老本和研发运维效率。 03 分享主题丨函数计算和 Serverless 利用引擎的典型利用场景与案例解析 Serverless 是云原生的新一代技术，阿里云在利用 Serverless 化提供了三个范式，面向容器界面的 ACK Serverless、面向利用的 SAE 以及面向函数的函数计算。在流动现场云原生高级解决方案架构师，天暠为大家重点介绍函数计算以及 SAE 的利用场景及案例。 04 分享主题丨容器服务 ACK Serverless 的典型利用场景与案例解析 容器服务 ACK Serverless 版是一款基于阿里云弹性计算基础架构之上，同时齐全兼容 Kubernetes 生态，平安、牢靠的容器产品。通过 ACK Serverless，您无需治理和保护 Kubernetes 集群即可疾速创立 Kubernetes 容器利用，并且依据利用理论应用的资源量进行按需付费。本次分享中，云原生技术专家，元毅为大家介绍了 ACK Serverless，及其典型应用场景以及客户应用案例。 05 分享主题丨微服务治理和云原生网关最佳实际 微服务晋升了业务迭代及资源利用效率，但对开发和运维都提出诸多的挑战。微服务引擎MSE联合了阿里微服务开源我的项目、商业化计划以及双十一大规模生产验证。阿里云高 级产品专家，问思介绍了如果利用 MSE 产品，高效落地云原生时代下的微服务最佳实际。 06 分享主题丨云原生架构之音讯队列 RocketMQ 5.0 音讯队列是分布式互联网架构的刚需和基础设施，是零碎之间牢靠通信的桥梁。RocketMQ 个别用于在线业务零碎，在电商，银行，互联网架构中扮演着非常重要的角色，这些业务属性对 RocketMQ 的稳定性，性能便利性，可伸缩性，可集成性方面都提出了很高的要求。流动现场阿里云云原生架构师，尘辉从 RocketMQ 的技术背景登程 通过典型客户案例的剖析为大家具体解读了云原生架构之音讯队列 RocketMQ 5.0。 ...

作者：王夕宁、 刘强、 华相 公司介绍丽迅物流是百丽旗下专一于时尚产业、为企业提供业余物流及供应链解决方案的服务商。其产品服务次要包含城市落地配、仓配一体、支线运输及定制化解决方案。通过自研智能化物流治理平台，全面助力企业单干集约化倒退。目前，丽迅物流已在全国领有 70+ 全渠道实体云仓、6 大核心电商仓，总面积达 100 万+ 平方米，服务笼罩 300+ 城市、3000+ 商圈，为多家出名时尚品牌及其品牌门店提供全渠道配送服务。 为了升高业务各环节中的运维老本、进步物流服务效率，2021 年 8 月起，丽迅物流开始在阿里云上实现本身从 IDC 自建到全面云原生化的过程。其中应用了阿里云容器镜像仓库企业版 ACR EE 和阿里云容器服务 ACK 作为容器制品治理及调度平台，应用了阿里云服务网格 ASM 作为云原生应用服务的分布式治理平台，通过服务网格的服务治理和流量管制性能，实现了应用程序的高效部署和扩大。 通过本文，丽迅物流架构师刘强分享了对于基于阿里云服务网格 ASM 如何减速企业业务云原生化过程的实践经验。 业务痛点在技术架构转型及业务疾速倒退的背景下，丽迅物流须要和各供应链撑持平台、研发平台等多个业务单元和合作伙伴进行业务交互，其业务零碎多元化并且具备开放性。在市场环境和消费者需要疾速变动的现状下，咱们更心愿将精力专一于外围业务的研发。包含了以下须要解决的业务问题痛点： 利用版本迭代艰难 面对疾速变动的客户、业务要求，所依赖的利用性能越来越多。业务越简单，代码的耦合度也越来越高，新个性上线周期逐渐拉长，使得利用版本迭代愈发艰难。异构零碎无奈对立治理 企业级 IT 零碎多语言、多协定、多框架的现状，为对立进行服务整合、服务治理设下困局。同时，因为 IT 零碎部署基础设施简单，反对跨平台、跨多个 Kubernetes 集群的技术难点亟需解决。构建对立的云原生应用服务研发平台存在肯定艰难 以 Spring Cloud 为代表的开源微服务框架成为业界支流的微服务脚手架。这些框架已具备服务注册发现、健康检查等根底微服务能力，但面对企业级利用所波及的服务拜访安全控制、服务流控、路由管制、灰度公布等高阶服务治理问题，仍须利用自行整合大量的第三方开源框架。这使得云原生应用服务业务利用设计开发具备较高的技术门槛，对于企业构建对立的云原生应用服务研发平台带来肯定艰难。简单的运维体系 现有的运维体系存在肯定的复杂性，相比于服务网格提供围绕流量治理、安全性、可观测性的一系列性能，目前对于大规模治理应用服务的运维体系存在挑战。解决方案作为业内首个全托管 Istio 兼容的服务网格产品 ASM，一开始从架构上就放弃了业界当先性以及社区与业界倒退的一致性，管制立体的组件托管在阿里云侧，与数据面侧的用户集群独立，放弃高可用部署与稳定性。ASM 产品是基于社区开源的 Istio 定制实现的，在托管的管制面侧提供了用于撑持精细化的流量治理和平安治理的组件能力。通过托管模式，解耦了 Istio 组件与所治理的 K8s 集群的生命周期治理，使得架构更加灵便，晋升了零碎的可伸缩性。 阿里云服务网格 ASM 架构图 托管式服务网格 ASM 在成为多种类型计算服务对立治理的基础设施中，提供了对立的流量治理能力、对立的服务平安能力、对立的服务可观测性能力、以及基于 WebAssembly 实现对立的代理可扩大能力，以此构筑企业级能力。 除大数据的剖析体系外，丽迅物流的以后零碎曾经全面接入服务网格体系，包含应用以下能力： 丽迅科技业务利用部署架构图 认证鉴权体系客户端发动业务申请，后端须要验证用户申请的合法性。例如，判断用户申请是否有该资源拜访权限。认证通过后，返回后果中还须要减少一些原始申请中没有的信息，例如用户认证通过后在 header 中增加业务版本号、用户 ID 等。 ...

作者：刘军 不管您是一名开发者、架构师、CTO， 如果您曾深度参加在微服务开发中，那么置信您肯定有过开源微服务框架或体系选型的疑难：Apache Dubbo、Spring Cloud、gRPC 以及 Service Mesh 体系产品如 Istio，到底应该选型哪一个？这篇文章对这几个框架进行了具体的阐明，并在选型方面给了肯定的领导意见，置信能给微服务开发者带来肯定的帮忙。 须要留神的是，这篇文章的作者有深度 Apache Dubbo 社区参加教训，因而整篇文章是以 Dubbo 为根底开展的，通过将 Dubbo 与其余组件之间的分割与差别主观、通明的展示进去，来向读者出现几款开源产品的劣势和实用场景。整篇文章中有局部内容突出了 Apache Dubbo 我的项目的劣势，请大家在浏览过程中放弃对这点的意识，但它总体上并不影响咱们从总体上理解每个产品并取得具备价值的选型领导。 Dubbo 与 Spring Cloud 从上图咱们能够看出，Dubbo 和 Spring Cloud 有很多相似之处，它们都在整个架构图的雷同地位并提供一些类似的性能。 Dubbo 和 Spring Cloud 都偏重在对分布式系统中常见问题模式的形象（如服务发现、负载平衡、动静配置等）， 同时对每一个问题都提供了配套组件实现，造成了一套微服务整体解决方案，让应用 Dubbo 及 Spring Cloud 的用户在开发微服务利用时能够专一在业务逻辑开发上。Dubbo 和 Spring Cloud 都齐全兼容 Spring 体系的利用开发模式， Dubbo 对 Spring 利用开发框架、Spring Boot 微服务框架都做了很好的适配，因为 Spring Cloud 出自 Spring 体系，在这一点上天然更不用多说。尽管两者有很多相似之处，但因为它们在诞生背景与架构设计上的微小差别，两者在性能、实用的微服务集群规模、生产稳定性保障、服务治理等方面都有很大差别。 Spring Cloud 的劣势在于： 同样都反对 Spring 开发体系的状况下，Spring Cloud 失去更多的原生反对。对一些罕用的微服务模式做了形象如服务发现、动静配置、异步音讯等，同时包含一些批处理工作、定时工作、长久化数据拜访等畛域也有涉猎。基于 HTTP+JSON 的通信模式，对于开发、测试、上下游体系接入等更敌对，老本更低。Spring Cloud 官网具备绝对欠缺的入门文档和演示 demo 和 starters，包含书籍材料等，让开发者上更易于上手。Spring Cloud 的问题有： ...

作者：徐靖峰 关注了阿里云云原生公众号，常常能看到 MSE-Higress 相干的推文，恰逢这次阿里云产品举办了一个 MSE-Higress 云原生网关的测评流动，借此机会体验了一把云原生网关的性能。 购买流程体验 购买网关时，页面明确提醒费用没有蕴含公网和私网 SLB 的费用，这里须要留神，评测时会产生额定费用，同时也倡议 MSE-Higress 购买页给出具体的定价，参考 ACK 购买时的体验。 路由治理体验通过购买页购买后，等了不多久实例便创立实现了，速度还是很快的，这个体验不错。第一个测评内容先体验下网关最次要的性能路由转发的能力，给 MSE-Higress 配置路由 & 服务，拜访 httpbin.org 这个公网的服务，相熟 HTTP 接口测试的同学肯定也不会对 httpbin 感到生疏，它内置很多 endpoint，反对丰盛的 HTTP 测试场景。 MSE-Higress 的产品设计和畛域模型和我之前接触过的一些开源 API 网关差别不大，所以上手还是很快的，首先创立 httpbin 服务： 接着再创立路由，我筹备通过 ${网关ip}/httpbin/get 转发至 httpbin.org/get 的形式来进行路由测试。 匹配形式反对前缀匹配、准确匹配、正则匹配三种，根本笼罩了网关路由场景的常见诉求。另外还须要留神的一点是，路由门路肯定要配置成 /httpbin/ 而不能是 /httpbin，否则在待会配置门路重写时，会呈现问题，我一开始也是因为不理解 MSE-Higress 的设计，错配成了 /httpbin，导致路由不通。 参考文档：《配置重写策略》 [ 1] 下一步，关联好刚刚创立的服务。 最初在路由的策略配置中，配置重写策略，使得网关在申请 upstream service 时，去掉用于路由匹配的 /httpbin 前缀。 MSE-Higress 提供了一个调试的界面，能够很不便地对路由进行调试，就在我信念满满筹备实现第一个测试时，居然调试报错了： 步骤并不简单，略微花了点工夫搜寻了一下注意事项，定位到了问题，原来配置服务时是有提醒的："DNS 域名配置，如 www.aliyun.com，公网域名须要在 VPC 内配置公网 NAT 网关，内网域名暂不反对"，于是给 MSE-Higress 所在的 VPC 配置了 NAT 网关，最终调用胜利。 ...

作者：饶子昊（铖朴） Java 的局限性传统的一个 Java 利用从代码编写到启动运行大抵能够分为如下步骤： 首先，编写 .java 源代码程序。而后，借助 javac 工具将 .java 文件翻译为 .class 的字节码，字节码是 Java 中十分重要的内容之一，正是因为它的呈现，Java 才实现对底层环境的屏蔽，达到 Write once, run anywhere 的成果!基于步骤 2 的 .class 文件会被打包成 jar 包或者 war 包进行部署执行，部署过程中通过 Java 虚拟机加载应用程序而后解释字节码运行业务逻辑。整个过程如下图所示： 图 1：Java 程序运行过程 上述过程既给 Java 程序带来了其余编程语言不具备的劣势，比方跨平台，易上手等。但同时也给 Java 程序带来了一些性能问题，比方启动速度慢和运行时内存占用低等。 冷启动问题图 1 中 Java 程序启动运行具体过程如下图 2 所示： 图 2：Java 程序的启动过程剖析 [ 1] 一个 Java 利用启动过程首先须要加载该应用程序对应的 JVM 虚拟机软件程序到内存中，如上图红色局部形容所示。而后 JVM 虚拟机再加载对应的应用程序到内存中，该过程对应上图中的浅蓝色类加载（Class Load，CL）局部。在类加载过程中，应用程序就会开始被解释执行，对应上图中浅绿色局部。解释执行过程 JVM 对垃圾对象进行回收，对应上图中的黄色局部。随着程序的运行的深刻，JVM 会采纳及时编译（Just In Time，JIT）技术对执行频率较高的代码进行编译优化，以便晋升利用程序运行速度。JIT 过程对应上图中的红色局部。通过 JIT 编译优化后的代码对应图中深绿色局部。 ...

背景在分布式系统架构中，每个申请都会通过很多层解决，比方从入口网关再到 Web Server 再到服务之间的调用，再到服务拜访缓存或 DB 等存储。在下图流量防护体系中，咱们通常遵循流量漏斗准则进行流量防护。在流量链路的每一层，咱们都须要进行针对性的流量防护与容错伎俩，来保障服务的稳定性；同时，咱们要尽可能地将流量防护进行前置，比方将一部分 HTTP 申请的流量管制前置到网关层，提前将一部分流量进行管制，这样能够防止多余的流量打到后端，对后端造成压力同时也造成资源的节约，为此，在网关侧做流量防护是非常有必要的。 在传统的流量网关场景下，对流量进行访问控制是一个很常见的需要。比方在 nginx 中，limit_req 就是一个最为常见的限流配置，而在 Envoy 中，也反对本地以及全局两种模式的限流，然而二者均有其局限性。在性能的丰盛度上，二者不迭常见的限流组件开源我的项目，如 Sentinel 、Hystrix 等，在理论的应用场景中，实用性也很弱，比方不反对无性能损耗的集群限流等等。 云原生网关的流量防护性能，底层应用了 Sentinel 内核，并做了肯定的强化和革新。Sentinel 是以流量与容错为切入点，从流量管制、不稳固调用隔离、熔断降级、热点流量防护、零碎自适应爱护、集群流控等多个维度来帮忙保障服务和网关的稳定性，同时提供秒级的流量监控剖析性能。其商业化产品不仅在阿里外部淘宝、天猫等电商畛域有着宽泛的利用，在互联网金融、在线教育、游戏、直播行业和其余大型政央企行业也有着大量的实际。 云原生网关作为集平安、流量、微服务三位于一体的下一代云上网关，在诞生之初，就被赋予了全场景应用的一个定位，为此流量防护也是其必备的一个能力，在流量防护能力上，具备以下劣势： 具备与风行的流量防护我的项目如 Sentinel、Hystrix 等等同丰盛的流量防护性能，并且还在一直迭代更新中。人造反对均摊式的集群流控，使得用户无需关怀网关以及 Upstream 服务的节点数。提供配套的秒级监控，并反对 QPS、回绝 QPS 、异样 QPS 、RT 以及并发数等丰盛的流量指标，同时反对历史数据的查看，便捷地实现先观测，再配防护规定的应用门路。流量防护规定秒级失效，配置防护规定后，无需期待，秒级失效。Sentinel 流量模型介绍如下图所示，流量防护是指，针对不同的流量，设置一道适宜的屏障策略，在该屏障的观测下，一旦断定该流量不能被通过，应该及时拦挡，从而达到爱护网关、以及后端 Upstream 服务的作用。 云原生网关目前反对 QPS 限流、并发管制、熔断三种不同的流量防护能力，本文将从这三个性能别离去论述其具体的成果，以及实用的场景。 QPS 限流这是流量防护最通用的一个场景，顾名思义，就是限度某个路由的流量，使其只能在肯定的速率内拜访网关，避免某个路由流量激增，造成后端服务的解体。云原生网关不仅反对路由级别的限流，而且人造反对均摊式的集群流控，用户无需关怀网关节点的数量或者后端服务节点的数量，只须要配置一个总体的阈值，就能够轻松实现对某个路由的总体阈值限流。 并发管制并发管制的具体实现，是通过实时保护一个并发值（这个值指的是一秒内，该路由流量的最大并行值，即未实现的申请数量），一旦下一个申请超过了设定的阈值，就拦挡该申请。该性能不同于 QPS 限流，即便是在 QPS 较低的场景下，也能保障要害的资源，不被继续累积的慢调用所占用，而导致服务不可用，比方后端 Upstream 服务的线程池以及数据库资源等等，假如长期被占用，就会导致该 Upstream 服务出现异常。和 QPS 限流相似，云原生网关人造反对均摊式集群并发限流，只需配置一个总体的并发阈值，就能够实现对某个路由的总体并发管制。 熔断在 Sentinel 、Hystrix 等限流我的项目中，都能见到该性能，就如字面上的意义，熔断是指，在路由的流量呈现了某个异样状态，须要及时熔断该流量，从而保障与该路由相干 Upstream 服务可能高效稳固的运行，而不受某个异样路由流量的影响。 熔断机制背地对应熔断器模型 (Circuit Breaker)。当调用处于某种不稳态（通常是出现异常或慢调用）达到肯定水平（通常关注比例而不是绝对量），熔断开启 (OPEN)，所有的申请都会 fallback 掉；过一段时间后进入探测复原阶段 (HALF-OPEN)，放过肯定数量的申请，以这些申请的状况来 indicate 上游服务的复原状况，若这些申请达到稳态，则复原对应调用 (CLOSED)；否则重回熔断状态，具体原理如下图所示： ...

随着数字化过程的放慢，寰球数据量呈指数级增长，对数据库系统的性能提出了微小的挑战。优化器作为数据库管理系统中的关键技术，对数据库性能和效率具备重要影响，它通过对用户的查问申请进行解析和优化来生成高效的执行打算，进而疾速返回查问后果。然而，同一条 SQL 语句在不同的优化决策下可能会产生数量级的性能差别。随着数据规模和查问复杂性的减少，优化器的一直倒退和翻新将成为数据库系统继续晋升性能的重要方向，也是数据库系统的最强有力的竞争力之一。 针对云原生和分布式场景，云原生虚构数仓 PieCloudDB Database 设计与打造了新一代优化器：「达奇」。这个命名灵感来自于游戏《荒野大镖客》中的一个 NPC 角色，他的口头禅 “I have a plan” 与优化器的性能十分符合。 优化器「达奇」在 PieCloudDB 中实现了许多优化个性，通过生成高质量的查问打算，充当数据库系统的 “智囊团”，确保用户的查问性能和效率。「达奇」通过智能地剖析查问语句、优化查问打算以及利用分布式数据存储和计算能力，实现了更疾速、更高效的查询处理。 拓数派吉祥物「派派」 1 汇集操作与汇集下推明天，咱们将具体介绍「达奇」的全新性能：汇集下推。在古代的数据库系统中，汇集操作（Aggregate）是十分常见的一种操作类型。通过汇集操作，能够把多行数据合并成一行，并对其进行统计、求和、求均值等计算。 在传统的查问执行过程中，聚合操作通常在查问后果返回后进行，须要将所有数据传输至查问引擎进行聚合计算。然而，对于大规模数据集和简单查问，这种形式可能导致查问性能低下、计算负载过高和计算成本低廉等问题。 为了解决这些问题，PieCloudDB 优化器「达奇」打造了汇集下推（Aggregate Pushdown）这一性能，经测试，在很多场景下，汇集下推性能会获得百倍甚至千倍的性能晋升。 2 汇集下推原理汇集下推（Pushdown Aggregation）是一种数据库查问优化技术，通过将聚合操作下推至数据源，缩小数据传输和解决的开销，从而进步查问性能和效率。 汇集下推的实现原理是在查问执行过程中尽可能早地进行聚合操作，并将聚合操作下推至数据源进行解决。具体而言，当查问打算生成时，优化器会将聚合操作下推至数据源，以便在数据源处进行聚合计算。这样能够缩小数据传输量，加重查问引擎的累赘，并利用数据源的计算能力进行部分聚合。 上面咱们用一个简略的图示，来解说汇集下推的次要实现原理： 有无「汇集下推」比照 上图中，左图是没有汇集下推的执行流程，右图是有汇集下推时的执行流程。在左图没有汇集下推的状况下，表 T1 和 T2 会先做连贯操作，并在连贯之后的数据集上实现汇集操作。 而在右图有汇集下推的状况下，会在对表 T1 和 T2 进行连贯操作之前，先对表 T1 做一次汇集操作。这样能够在某些场景下使得连贯操作时表 T1 中参加的数据量极大的缩小，从而显著进步查问性能。为了能精确地进步查问效率，以上两种执行计划在「达奇」中都会生成，最初会依据代价模型的估算抉择代价较小的执行计划。 当有更多的表参加连贯时，「达奇」会尝试把汇集操作下推到不同的连贯层，通过代价的比拟来选定最优的下推地位。 3 汇集下推演示实例上面，咱们通过一个查问实例来看一下汇集下推的成果。首先，咱们通过上面语句来创立测试用表： CREATE TABLE t (x int, y int);INSERT INTO t SELECT i % 30, i % 30 FROM generate_series(1, 10240) i;ANALYZE t;测试所用的查问如下： ...

01 服务网格数据面的演进以 Istio 为代表的 Service Mesh 技术曾经存在四五年的工夫了，阿里云也是第一批反对 Service Mesh 云服务的厂商。在 Service Mesh 技术中，通过把服务治理的能力进行 Sidecar 化，实现与应用程序自身的解耦。这些若干个 Sidecar 代理就造成了一个网状的数据立体，通过该数据立体能够解决和察看所有应用服务间的流量。负责数据立体如何执行的治理组件称为管制立体。 能够看到，管制立体是服务网格的大脑，它为网格应用人员提供公开 API，以便更容易地操纵网络行为。总之，通过 Service Mesh 技术，Dev/Ops/SRE 将以对立的、申明的形式解决应用服务治理问题。 服务网格作为一种利用感知的云原生基础设施，提供了云原生利用感知的网络管理能力。 网络是 Kubernetes 的外围局部，波及了 Pod 间通信、Pod 和服务间通信以及服务与内部零碎间的通信等。Kubernetes 集群中应用 CNI 插件来治理其容器网络性能，应用 Kube-proxy 保护节点上的网络规定，譬如使发往 Service 的流量（通过ClusterIP 和端口）负载平衡到正确的后端 Pod。 容器网络成为用户应用 IaaS 网络的新界面，以阿里云 ACK Terway 网络为例，基于阿里云 VPC 网络直通弹性网卡，具备高性能特色；同时无缝地跟阿里云 IAAS 网络对接； 然而，kube-proxy 设置是全局的，无奈针对每个服务进行细粒度管制；而且 kube-proxy 只是专在网络数据包级别上运行。它无奈满足古代应用程序的需要，如应用层流量治理、跟踪、身份验证等。 咱们来看服务网格 Sidecar 代理模式下的云原生利用网络是如何解决这些问题的。服务网格通过 Sidecar 代理将流量管制从 Kubernetes 的服务层中解耦，将代理注入到每个 Pod；并通过管制立体操纵治理这些分布式代理，从而能够更加精密地管制这些服务之间的流量。 那么在 Sidecar 代理下的网络数据包的传输是怎么的过程？ 以后 Istio 实现中波及了 TCP/IP 堆栈的开销，它应用了 Linux 内核的 netfilter 通过配置 iptables 来拦挡流量，并依据配置的规定对进出 sidecar 代理的流量进行路由。客户端 pod 到服务器端 pod 之间的典型门路（即便在同一主机内）至多要遍历 TCP/IP 堆栈 3 次（出站、客户端 Sidecar Proxy 到服务器端 Sidecar Proxy、入站）。 ...

作者：微服务X音讯队列 各位报名参会的同学，大家好： 非常感谢大家对本期云原生开源开发者沙龙「微服务X音讯队列专场」的关注与反对。 因故原定于 8 月 12 日（周六）举办的沙龙延期举办。 具体工夫和举办地点如下： 阿里云云原生开源开发者沙龙微服务X音讯队列专场深圳站，推延于 8 月 27 日（周日）13 点在深圳市南山区科苑南路（深圳湾段）3331 号阿里核心 T1-3-1-E 青云涧举办。 流动详情如下： 1. 参会收费，点击链接填写报名信息。如您之前有过报名，烦请填写新的报名表单：https://survey.aliyun.com/apps/zhiliao/923j8sQJs 2. 交通指南： 自驾导航到深圳市南山区科苑南路（深圳湾段）3331 号阿里核心；地铁 2 号线到登良站 C 口出，步行 620 米达到阿里核心； 3. 舒适提醒： 如加入入手环节，请自带笔记本电脑，及提前注册阿里云帐号。 点击此处，即可收费报名参会

之前有一篇文章 “扯淡的DevOps，咱们开发者基本不想做运维！” 失去了许多开发者的共鸣，每一个开发人员，都心愿可能抛却运维工作，更专一于本人开发的代码，将创意转化为令人惊叹的利用。然而事不尽如人意，到了云原生时代，开发者的运维工作仿佛并没有缩小，而是变成了在 K8s 上的利用部署和治理。 对运维人员来说，只须要保护好底层的 K8s，便能够在弹性、便捷性上失去微小晋升。然而 K8s 对于咱们开发者而言还是太简单了，咱们还须要学习如何打包镜像以及 K8s 相干常识。许多工夫都节约在了利用部署上，咱们真的须要成为 K8s 专家吗？我只是想部署一个利用至于那么简单吗？你是否曾想过，是否有平台或办法，让咱们不用成为 K8s 专家，甚至都不须要懂 K8s 就能部署好你的利用，轻松治理利用？ 理论面临的问题对于咱们开发者而言，总会遇到以下不同的场景，兴许是公司层面的问题、又或是业务层面的问题，兴许当初用传统部署形式很简略，但随着业务增长，又不得不迁徙。而面对这些问题，咱们也要收回本人的声音。 身处小公司，没有专门的运维。须要程序员本人负责写 Dockerfile + YAML + Kustomize 而后部署到 k8s 下面。除了工作量以外，还面临 K8s 本身的复杂性，对于多套业务，Dockerfie、Yaml、CI、CD 脚本占据了绝大部分的工作量。不写这些行不行？公司内的微服务越来越简单，在写代码的根底上还得思考各个服务之间的通信、依赖和部署问题，毕竟除了咱们开发者以外，运维人员也不会比你更相熟微服务之间的简单依赖。兴许曾经开始尝试 Helm ，然而编写一个残缺的 Chart 包仍然是如此简单，还可能面临格局问题、配置解耦不齐全导致的换个环境无奈部署问题。工夫全写 Yaml 了。不额定编写 Helm Chart，间接复制利用行不行？在大型企业外部，正处于在传统利用迁徙到云环境的十字路口。面对多种集群的需要、现有利用的安稳迁徙、甚至一些公共的模块的复用如何做都将成为咱们须要解决的问题。不要每次都从新开发，把现有的利用或模块积攒下来行不行？在这些场景下，咱们大量的工夫都耗费在额定的 Dockerfile、Yaml、Helm Chart 这些编写上了。K8s 很好，但仿佛没解决咱们开发者的问题，咱们开发者用 K8s 反而变得更加简单。不说须要额定编写的这些文件或脚本，单单是把握 K8s 的常识就须要消耗大量工夫和精力。这些问题真的绕不过来吗？我感觉不是。来理解下 Rainbond 这个不须要懂 K8s 的云原生利用治理平台吧。谁说只有成为 K8s 专家后，能力治理好你的利用？ 为什么是 Rainbond？Rainbond 是一个不须要懂 K8s 的利用治理平台。不必在服务器上进行繁琐操作，也不必深刻理解 K8s 的相干常识。Rainbond 遵循“以利用为核心”的设计理念。在这里只有你的业务模块和利用。每一个业务模块都能够从你的代码仓库间接部署并运行，你不是 K8s 专家也能够治理利用的全生命周期。同时利用 Rainbond 的模块化拼装能力，你的业务能够灵便积淀为独立的利用模块，这些模块能够随便组合、有限拼装，最终构建出多样化的利用零碎。 1. 不懂 K8s 部署 K8s 行不行？行！ 对于很多初学者或者开发人员来说，如果公司外部曾经搭建好了可用的 K8s 平台，那么这一步不会是须要放心的问题。然而对于一些独立开发者而言，却很难有这样的环境，而 Rainbond 就提供了这样的解决方案，在 Linux 服务器上，只须要先运行一个 Docker 容器，拜访到 Rainbond 控制台后，再输出服务器的 IP 地址，即可疾速部署一套残缺的 K8s 集群。 ...

产品介绍云原生网关 MSE-Higress (以下简称 MSE-Higress )是遵循开源 Ingress/Gateway API 规范的下一代网关产品，将传统的流量网关、微服务网关、平安网关合三为一，升高 50% 的资源开销，具备高集成、易使用、易扩大、热更新的特点。MSE-Higress 提供了流量调度、服务治理、平安防护等能力，并深度集成 Dubbo、Nacos、Sentinel 等微服务技术栈，晋升网关链路的整体性能、升高部署和运维老本，同时反对 Nginx Ingress 的平滑迁徙，帮忙用户零老本疾速迁徙到 MSE-Higress。 评测要求流动工夫2023 年 8 月 10 日-2023 年 9 月 15 日（获奖名单 9 月底颁布） 评测内容通过体验 MSE-Higress，您能够围绕以下三大主题，进行测评创作： MSE-Higress 产品体验测评，能够包含但不限于以下内容：产品文档： 产品的操作文档是否丰盛、形容是否残缺和精确？如果没有，还欠缺什么局部、存在哪些有余？产品能力： 产品的性能是否满足您的业务场景，例如网关迁徙或接入、网关治理、域名/服务/路由治理、平安能力治理、插件市场等？产品控制台： 产品控制台是否满足您的操作需要，例如展现是否敌对，操作是否流出、提示信息是否残缺等？产品集成体验： 和 ACK、ECS 之间的产品集成体验是否晦涩，还有哪些集成体验须要晋升的中央？MSE-Higress 利用场景测评，能够包含但不限于以下内容：流量调度： MSE-Higress 作为流量入口网关，反对多种路由形式，包含单服务、多服务、标签路由、服务 Mock 和重定向，并且反对 gRPC、HTTP 和 WebSocket 等多种网络协议。服务治理： MSE-Higress 提供了丰盛的流量治理能力，反对多种服务发现形式，如容器服务、MSE Nacos、MSE ZooKeeper、ECS 和域名等，能够以对立的模型反对服务版本以及灰度公布能力。插件市场： 通过 MSE-Higress 的插件市场，实现了哪些业务逻辑，例如认证鉴权、平安防护、流量观测等。云原生网关的比照测评，能够包含但不限于以下内容：您应用过哪些网关，包含开源的计划或商业的计划，例如 Nginx、APISIX、Spring Cloud Gateway 等？您感觉相比其余网关，MSE-Higress 在性能、性能、架构、可扩展性、运维、价格等方面有哪些劣势，有哪些有余须要改良？ 流动奖品参加奖： 流动期间凡公布 100 字以上评测且通过审核的用户，可获 50 积分（每人最多得 150 积分） ...

作者：vivo 互联网容器团队 - Han Rucheng本文介绍了vivo容器团队基于 Prometheus等云原生监控生态来构建的容器集群监控体系，在业务接入容器监控的过程中遇到的挑战、艰难，并分享了相应的应答策略和优化计划。 一、背景介绍随着vivo业务迁徙到容器平台，vivo云原生监控体系面临着指标量疾速上涨带来的一系列挑战，本文将分享vivo 容器化我的项目中容器监控遇到的问题以及咱们的解决和优化办法。 二、监控架构首先对vivo容器监控架构进行一个简略的介绍。 【架构高可用】：集群维度的双正本 Prometheus 采集底层exporter数据，adapter多实例主动选主实现容灾。【数据长久化】：通过remoteWrite将数据存储到后端的VictoriaMetrics中进行长久化存储，Grafana应用VictoriaMetrics做为数据源展现和告警。【监控统一化】：通过remoteWrite将数据交由kafka-adapter转发到Kafka，由公司根底监控等服务通过生产Kafka中的数据来进行展现和告警。原生Prometheus没有提供高可用的规范计划，咱们通过自研 Adapter “分组选举”形式实现去重，即每个 Prometheus 正本对应一组 Adapter，两组 Adapter 之间会进行选主，只有Leader组的 Adapter才会转发数据。通过这种形式既实现了去重，也实现了Prometheus双正本高可用。 三、问题景象过来几年来，vivo容器化服务快速增长，监控流量上涨数倍，咱们次要遇到如下三个问题：监控组件负载疾速升高、容器监控数据断点和数据存储组件负载陡增。 3.1 监控组件负载疾速升高容器化每次部署IP都会变动的个性，导致容器监控指标量相比物理机和虚拟机要高出好几个数量级。同时因为集群规模的一直减少以及业务的快速增长，导致监控 Prometheus、VictoriaMetrics 负载疾速增高，给咱们容器监控带来极大的挑战。监控总工夫序列能够精简为以下的表达式，即与 Pod数量、Pod指标量、指标Label维度数量呈线性关系： TotalSeries = PodNum PerPodMetrics PerLabelCount 而随着集群规模的一直减少以及容器数量的一直增多，监控序列就会快速增长，同时监控组件负载疾速升高，会对容器监控零碎的稳定性产生影响。 3.2 监控丢点景象vivo容器层面（业务）的监控数据则通过自研Adapter转发给Kafka，进而存储到公司根底监控做业务监控展现和告警配置，同时也存储一份到Druid做更多维度的统计报表。咱们在推送监控数据的时候发现，Pod维度的指标难以保障发送频率，即配置指标采集频率为 10s，然而在推送的数据中频率无奈做到10s，且会有稳定。下图为 采集频率设置 10s，查问1分钟的指标数据。 一分钟内某一容器的 container\_cpu\_user\_seconds\_total 指标的值： 能够看到只取到了4个值，与冀望的 6个值不相符，即产生了“掉点”的状况，监控面板按指定频率展现数据会有频繁掉0景象。 3.3 数据存储组件负载陡增 vivo容器监控应用 VictoriaMetrics的v1.59.1-cluster版本做为后端时序数据库来长久化存储监控数据。在应用过程中发现 VictoriaMetrics的负载有不定期增高的状况，而后端数据库的提早会导致监控查问告警性能的异样影响用户体验。 四、解法4.1 监控组件负载疾速升高咱们应用 Prometheus-Operator 治理 Prometheus，因为优化计划中有 Prometheus-Operator 相干的名词，故为了上面的了解，先对 Prometheus-Operator 做一个介绍： （图片起源：官网架构图） 上图是Prometheus-Operator官网提供的架构图，上面来介绍下图中各组件： Operator：  Operator是最外围的局部，作为一个控制器，他会去创立Prometheus、ServiceMonitor资源对象，而后会始终监控并维持这些资源对象的状态。Prometheus：这种资源对象就是作为Prometheus Server存在， Operator 依据自定义资源 Prometheus 类型中定义的内容而部署的 Prometheus Server。Prometheus 也能够通过 labelSelector 去匹配多个ServiceMonitor。ServiceMonitor：ServiceMonitor就是exporter的各种形象，exporter是用来提供专门提供metrics数据接口的服务。Prometheus就是通过ServiceMonitor提供的metrics数据接口去 pull 数据的。该资源通过 Labels 来选取对应的 Service Endpoint，让 Prometheus Server 通过选取的 Service 来获取 Metrics 信息。一个 ServiceMonitor 能够通过 labelSelector 的形式去匹配一类 Service。Service：Service是Kubernetes内建资源用于把一组领有雷同性能的Pod封装起来，并提供一个对立的入口来裸露这组Pod的服务，从而为客户端拜访提供了一个稳固的拜访地址，屏蔽了底层Pod的变动和故障。Service能够联合Kubernetes中的其余组件实现负载平衡、服务发现、集群外部通信等性能。咱们重点关注 ServiceMonitor，因为ServiceMonitor为咱们提供了指定 target 采集的配置，例如采集频率，target内指标过滤，指标中label重命名等等操作。 ...

云原生网关：将平安、流量和微服务三合一作为面向南北向的公网网关，应用 Waf 防护异样流量是很惯例的需要，而且随着互联网环境变得越来越简单，用户对防护的诉求是继续加强的，惯例做法是将流量先接入 Waf 平安网关，过滤后再将流量转发给流量网关，最初达到微服务网关，一个典型的多层网关架构如下图所示： 在这个架构中，用 WAF 网关实现平安能力，Ingress 网关实现集群入口网关能力（非 K8s 场景或会部署一层 Nginx），SCG（Spring Cloud Gateway） 实现微服务网关能力。这样的架构下，须要对每一层网关都进行容量评估，每一层网关都是潜在的瓶颈点，都可能须要进行扩容。这样造成的资源老本和运维人力老本都是微小的。并且每多一层网关，就多一层可用性危险。一旦呈现可用性问题，多层网关会导致问题定位复杂度显著回升，对应的均匀故障复原工夫（MTTR）将大幅减少。 云原生网关提出了将平安、流量、微服务网关三合一的概念，架构如下图所示： 采纳云原生网关三合一的架构，能够显著降低成本，并进步零碎整体可用性。同时这也合乎 DevSecOps 的微服务演进趋势，微服务开发者能够更多地从业务接口视角关注安全性，而不是采纳所有路由一刀切的 WAF 防护模式。 云原生网关技术架构演进的过程如下图所示： 技术架构演进的背地是组织架构演进，这也是微服务 DevOps 始终在强调的，要围绕开发者为外围，从而晋升微服务开发效率。向 DevSecOps 演进并没有捷径，仍然须要开发角色和运维角色之间的双向奔赴，突破传统开发与运维之间的壁垒，造成从开发、部署、平安经营这样一个全功能化的麻利团队。 云原生网关平安防护实际云原生网关以 WAF 插件模式提供平安能力，实现了基于 ModSecurity 的规定防护引擎，能够依据用户配置的规定屏蔽可疑申请，并反对 OWASP CRS，为站点提供根底的防护性能。 插件配置阐明 插件应用简略，并且反对路由级/域名级细粒度防护，配置字段包含： 配置示例如下： 启用默认配置，进行拦挡useCRS: true启用默认配置，仅观测，不拦挡useCRS: truesecRules: - "SecRuleEngine DetectionOnly"自定义防护规定useCRS: truesecRules: - "SecRule REQUEST_URI \"@streq /admin\" \"id:101,phase:1,t:lowercase,deny\"" - "SecRule REQUEST_BODY \"@rx maliciouspayload\" \"id:102,phase:2,t:lowercase,deny\""依据该配置，以下申请将被禁止拜访： curl http://example.com/admincurl http://example.com -d "maliciouspayload"对特定路由或域名开启useCRS: truesecRules: - "SecRule REQUEST_URI \"@streq /admin\" \"id:101,phase:1,t:lowercase,deny\"" - "SecRule REQUEST_BODY \"@rx maliciouspayload\" \"id:102,phase:2,t:lowercase,deny\""_rules_:- _match_route_: - "route-1" secRules: - "SecAction \"id:102,phase:1,deny\""- _match_domain_: - "*.example.com" - test.com secRules: - "SecAction \"id:102,phase:1,pass\""此例 match_route 中指定的 route-1 即在创立网关路由时填写的路由名称，当匹配到这两个路由时，将应用此段配置；此例 match_domain 中指定的 *.http://example.com 和 http://test.com 用于匹配申请的域名，当发现域名匹配时，将应用此段配置；配置的匹配失效程序，将依照 rules 下规定的排列程序，匹配第一个规定后失效对应配置，后续规定将被疏忽。 ...

1. 前言在《疾速开始 PieCloudDB》中，咱们理解了如何在 PieCloudDB 创立账号，进行数据上传、查问和邀请用户。本文承接《疾速开始 PieCloudDB》，将对管控平台如权限治理、内部接入等进阶操作通过实例进行介绍和演示。 2. 账户实体PieCloudDB 以账户实体的模式是账户在数仓实例中具象体现，每一个 PieCloudDB 账户都领有四类账户实体，如下图所示。 其中： 用户实体代表该账户下所有从属用户。用户能够创立并成为数据库对象的所有人，并通过权限零碎和角色将数据库对象权限下放给特定角色下的其余用户。角色实体能够实现零碎和数据库权限的调配，PieCloudDB 零碎中共有四个预设角色，咱们会在后续进行介绍。虚构数仓实体代表计算资源。有相干权限的用户，可在账户下创立提供计算反对的虚构数仓。功能模块实体为 PieCloudDB 数据性能的汇合，包含数据洞察、数据集成等。这些性能通过虚构数仓的反对，实现查问、ETL 等与数据相干的操作。对 PieCloudDB 账户实体整体状况了一个大抵的意识后，接下来咱们深刻细节，进一步理解 PieCloudDB 权限零碎的外围：角色性能。 3. 角色PieCloudDB 权限管理系统是以角色为治理单位的权限管理工具。 角色是用户权限概念的具象化，代表了权限的汇合。权限以角色的形式下放给各个用户。一个角色可对应一个用户，也可对应一类用户。用户与角色并非一对一关系，一个用户可被授予多个角色，而一个角色可被授予给多个用户。每个用户都会被赋予至多一种角色，每一种角色都有其对应的权限。 PieCloudDB 角色权限分为数据库对象权限和零碎权限两局部。数据库对象权限对应账户内各角色的数据权限，且只有数据库对象所有者可治理相应权限。而零碎权限对应各角色管控平台的性能权限，其中包含计算资源的管理权限。 赋予与继承继承是权限以角色的模式传递给另一个角色的动作。继承的角色在层级上要高于被继承的角色，且继承角色的权限与被继承角色的权限保持一致，意味着即便发出继承角色所继承的权限，该权限状态会与被继承角色保持一致，并不会被发出。一个角色能够继承另一个角色的权限。继承的权限即便被改变，状态也会与被继承角色绝对应的权限保持一致。继承关系使得各角色间出现一个角色层次结构。 赋予是权限以角色的模式下放给用户的动作。领有角色管理权的角色，可将角色及其权限赋予给用户。 5. 零碎预设角色PieCloudDB 中，每个账户都预设了四个角色： 一般使用者是 PieCloudDB 预设角色中最根底的角色。每一位新用户在创立后都会主动被授予一般使用者角色，领有如拜访数据库、进行数据洞察等一些根底性能的权限。用户管理员继承一般使用者权限，次要负责用户及角色的权限治理，可邀请、增加、审核新用户、删除已有用户，有权创立、删除角色，治理各角色对应的零碎权限。数据管理员继承一般使用者，次要负责数据库对象权限、计算资源管理，有权应用数据集成性能。数据管理员能够创立、更改、删除和监控虚构数仓，除账户管理员外，其余预设角色只有权查问、应用虚构数仓。账户管理员是账户权限管理系统中等级最高的存在，继承数据库治理及用户管理员权限，也是账户的计费单位。账户管理员能够将权限以角色的形式下放给其余用户进行治理。预设角色零碎权限详情及继承关系如下图所示： 这些预设角色不可被删除。在通常状况下，倡议零碎角色由不同用户承当，管理员类角色尽量应用 PieCloudDB 零碎预设角色。 6. 赋权步骤在这一部分，咱们将从账户管理员起步，演示创建自定义角色的过程，具体步骤如下图所示。 假如账户管理员已将用户管理员及数据库管理员赋予了相应的用户，用户管理员可为新用户组建设自定义角色，并对该角色的零碎权限进行设置。 在自定义角色设立后，数据库管理员创立该角色所对应的数据库对象，并将相应的数据库权限赋予该角色，通过数据库权限这种形式来束缚相应数据的读写权。 零碎权限和数据库权限设置结束后，用户管理员再将该角色赋予用户组。角色权限管控下的用户组，可通过其对应的角色，在适当的权限条件下摸索数据。 7. 权限调配实例假如某公司须要对某几类线上产品的销售额进行存储和剖析，销售额数据结构如图所示，这里的示例数据与《疾速开始 PieCloudDB》中示例的数据平行。 该公司的数据管理团队决定由 David 、 Betty 和 Charlie 三位负责管理这部分数据及其从属的权限，并反对业务部门的 Adam 进行销售数据分析工作。 首先， David 作为账户管理员，须要将用户管理员角色赋予 Betty 。被赋予用户管理员权限后， Betty 再将数据库管理员的角色赋予给 Charlie 。 各管理员角色就位后， Betty 为 Adam 创立其对应的角色。依据 Adam 的需要， Charlie 再为其角色创立对应的数据库对象，将这些数据库对象的权限调配给 Adam 的角色。角色权限设置实现后， Betty 最初将该角色赋予给 Adam 。 ...

近期，由中国信息通信研究院（以下简称中国信通院）、中国通信标准化协会领导，中国通信标准化协会大数据技术标准推动委员会（CCSA TC601）、InfoQ 极客传媒联结主办的 2023 可信数据库倒退大会在北京圆满闭幕。中国信通院正式颁布了第 16 批可信数据库测评的后果，拓数派旗下数据计算零碎的首款计算引擎 PieCloudDB 虚构数仓，在 IO 密集型工作、CPU 密集型工作、报表工作、剖析型工作、交互式查问、混合负载、压力测试、稳定性等方面，凭借杰出的体现顺利通过评测，取得评审专家的统一认可，亦成为首家以虚构数仓通过信通院可信数据库评测的 OLAP 数据库。 图为：PieCloudDB 评测证书 “可信数据库” 产品能力评测是国内首个面向数据库产品的权威评测体系，旨在从根底能力、性能、可靠性、平安等维度全面掂量企业级数据库产品的能力。值得一提的是，拓数派参加了本年度《数据库倒退钻研报告（2023）》的编写工作，并凭借在云原生虚构数仓的突出成绩和优异体现，胜利入选《中国数据库产业图谱（2023）》。 作为拓数派首款数据计算引擎， PieCloudDB 以 SQL 语言实现结构化数据上的模型计算，突破企业数据孤岛，整合企业所有表格类数据资源，在云架构 eMPP 存算拆散技术加持下，可将物理数仓整合，依据数据受权动态创建虚构数仓，在云上，数据计算资源可按需扩缩容，关上有限数据计算空间，撑持更大模型所需的数据和计算。 图为：拓数派 CTO 郭罡 可信数据库倒退大会主题演讲 拓数派 CTO 郭罡在本次可信数据库倒退大会的分论坛发表了对于 “PieCloudDB 云原生数仓虚拟化的演进与倒退” 的主题演讲，对于 PieCloudDB 虚构数仓的技术冲破他示意，其技术创新不仅在于云原生存算拆散架构与 eMPP 分布式专利技术，更有自研「简墨」存储与全新的优化器「达奇」。PieCloudDB 针对底层分布式存储设计了高效的文件格式，可在节俭网络申请的同时进步计算效率，并升高用户存储老本。在计算层，各个计算节点针对元数据和用户数据都设计了多层缓存构造，防止网络提早和数据挪动，进步计算效率，保障用户的实时性需要。PieCloudDB 全新的优化器「达奇」，反对汇集下推，预计算，Block Skipping 等高级个性，全面满足各种简单的剖析查问需要。同时咱们正在开发新一代的高性能灵便计算引擎，不断完善或融入大数据各个生态。分享最初，郭罡提到作为一款高性能的国产数据库，PieCloudDB 全面适配国产化信创环境，通过技术创新引领行业改革，继续晋升国产数据库在国内科技界竞争力。      

在《云上商业智能最佳实际》中，咱们演示了如何应用 node-port 的内部连贯形式接入 PieCloudDB。本文联合传统内部连贯形式，聚焦全新的内部连贯工具 PieProxy，通过内部接入场景联合管控平台相干信息，对接入步骤进行举例和演示（演示视频链接）。 1. 前言目前， PieCloudDB 在各版本都提供了内部接入性能。同一账户下的用户可通过处于开启状态的虚构数仓，应用 JDBC 、ODBC 或 Postgres 驱动从内部连贯数据库来获取数据。 从 2.5.1113 版本起，PieCloudDB CoC 以及其余平行版本反对应用 PieProxy 进行内部连贯。PieProxy 是基于 PgBouncer、为 PieCloudDB 量身定制的内部连贯工具。与传统 node-port 连贯相比，PieProxy 更轻量，通过高并发、高可用性，无效加重数据库在解决内部连贯申请时的累赘。综上，咱们举荐应用 PieProxy 对 PieCloudDB 进行内部连贯。留神，2.5.1113 之前旧版本的 PieCloudDB 只提供传统 node-port 的连贯形式。 2. 汇总内部连贯信息PieCloudDB 内部连贯总共须要三类信息： 用户连贯信息用户名明码虚构数仓信息虚构数仓服务器地址端口号虚构数仓 ID数据库信息2.1 用户连贯信息这里咱们以《疾速开始 PieCloudDB》中的账户管理员 David 为例。登录管控平台后，各用户可通过管控平台右上角的用户信息栏点击内部接入，取得用户相干的内部接入信息。点击右上角菜单「内部接入」按钮，进入相干界面。 界面会对接入格局进行提醒，留神，目前只有通过 PieProxy 进行内部连贯的虚构数仓须要额定对连贯进行设置。 点击「重置接入 Token」取得接入用户名及明码。再次重置 Token 会将接入明码从新设置，先前的明码将不再无效。 2.2 虚构数仓信息 记录好用户名和 Token，咱们来到左侧菜单栏「虚构数仓」菜单。进入界面后，确认指标虚构数仓已开启内部接入。这里咱们进行内部连贯的虚构数仓为「VW1」。 依据须要内部接入的虚构数仓，点击右侧「查看详情」查看虚构数仓详细信息，界面大抵如下。 进入详情页面后，内部接入须要如上图所示该界面中的三条信息： 虚构数仓 ID接入地址服务端口号2.3 数据库信息本篇咱们以 PieCloudDB 中的初始数据库「openpie」为例，进行内部连贯。这里咱们只需数据库名称即可。2.4 总结通过 JDBC、ODBC、PostgreSQL 等驱动，咱们即可通过内部连贯接入 PieCloudDB 。综合在「内部接入」界面取得的信息，咱们通过以下信息进行内部连贯。 ...

2023 智能驾驶科技峰会在上海圆满闭幕，本次大会由世界人工智能大会（WAIC）组委会办公室领导，浦东新区人民政府反对，浦东新区科技和经济委员会、中国 （上海）自由贸易试验区治理委员会金桥管理局主办，海内外院士和业界重磅嘉宾齐聚一堂，共话产业新趋势。拓数派作为寰球数据计算零碎的引领者，被授予 “将来出行生态合作伙伴” 名称。 图为：WAIC 2023 智能驾驶科技大会 同时，由拓数派发动的 “汽车人工智能算法、软件及数据” 专场主题论坛引起了现场嘉宾的极大趣味。在论坛上，来自上汽帆一尚行、BlackBerry、WiTricity、东风商用车、元禾重元、尚颀资本及映驰科技等重磅嘉宾，独特出现了一场汽车行业人工智能的技术盛宴。拓数派创始人兼 CEO 冯雷对大会主办方的邀请深表感激，这也是其第二次携团队在 WAIC 大会上举办人工智能分论坛。 图为：2020 年冯雷携团队与上海经信委和 CMU 社区在 WAIC 创立 CMU AI 分会 在分享中冯雷示意，当下人工智能技术的倒退受到了宽泛的器重，为传统制造业带来了前所未有的倒退时机。汽车行业作为传统制造业的龙头之一，电动化、智能化、网联化、共享化 “新四化” 曾经成为汽车产业的转型趋势，新的科技反动或将颠覆产业价值链和生态构造，TaaS 在吆喝数据计算平台，一份数据多引擎计算，数据网络化汇集，反对更大模型。数据计算（Data Computing）势必会在这场行业技术革新的过程中施展重要作用。 图为：拓数派创始人兼 CEO 主题分享 在分享中，冯雷通过汽车行业的最佳利用实际，进一步论述了如何通过拓数派数据计算零碎为汽车智能化产业实现数据增值。他强调，将来随着智能汽车的高速增长，将会引发数据量指数级激增。依据行业公开数据预测，到 2025 年，我国智能网联车渗透率将大于 62%，智能网联汽车所产生的数据量将是智能手机的千倍，这将对数据的存储解决以及算力提出更高的要求。拓数派数据计算零碎涵盖多个先进的数据计算引擎与服务，其中首款数据计算引擎 PieCloudDB 虚构数仓，以云原生形式实现元数据、用户数据和计算拆散，数据计算资源按需扩缩容，实现数量级减少可计算数据空间的同时，数量级升高数仓老本，撑持更大模型所需的数据和计算，成为大模型数据计算的新范式。 图为：拓数派市场总经理 姜雪 图为：上汽帆一尚行 智能网联解决方案总监 谢忠开 图为：BlackBerry 大中华区首席代表 董渊文 图为：WiTricity 大中华区总经理 孙立 在圆桌论坛环节，拓数派搭档生态副总裁郭翔宇、东风商用车数字化部副部长杨牮、元禾重元合伙人李炜琦、 尚颀资本股权投资部副总裁姚力、映驰科技创始人兼 CEO 黄映，围绕 “人工智能赋能交通数字化转型” 的话题开展深刻交换探讨。 图为：圆桌论坛探讨 拓数派将以本次流动为契机，将来会加大对数据计算零碎的研发力度，继续引领数据计算的倒退并发明出更大的社会价值。     

介绍在云原生环境中，集群提供者经常将不同类型的工作负载部署在同一个集群中，利用不同业务的不同峰值成果，实现资源分时复用，防止资源节约。然而，不同类型负载之间混合部署经常会导致资源竞争和互相烦扰。最为典型的场景便是在线和离线负载的混合部署。当离线较多的占用计算资源时，在线负载的响应工夫就会受到影响；当在线长时间较多的占用计算资源时，离线负载的工作实现工夫不能失去保障。这种景象属于 Noisy Neighbor 问题。 依据混合部署的水平、资源类型的不同，解决该问题有许多不同的思路。Quota 治理可从整个集群维度限度负载的资源使用量，Koordinator 在这方面提供了多层次弹性 Quota 治理性能[1]。单机维度上看，CPU、内存、磁盘 IO，网络资源都有可能被不同负载共享。Koordinator 在 CPU、内存上曾经提供了一些资源隔离和保障的能力，磁盘 IO 和网络资源方面的相干能力正在建设中。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1245078?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

2023 年 5 月，由 Stackoverflow 发动的 2023 年度开发者考察数据显示，PostgreSQL 曾经超过 MySQL 位居第一，成为开发人员首选。PostgreSQL 在国内的热度也越来越高。6 月 17 日，PostgreSQL 数据库技术峰会在成都顺利召开。本次大会以 “新机遇、新态势、新倒退” 为主题，邀请泛滥行业大咖参加本次流动。PieCloudDB 产品总监陈金豹也受邀在大会中发表演讲《云原生虚构数仓 PieCloudDB 的架构和要害模块实现》。 随着云计算时代的到来，云平台提供了近似有限丰盛的计算资源，同时也使得计算成本极大的升高，开释出数据计算产生智能的更多机会。早在 2019 年，Gartner 便做出预测：数据库市场的将来在云上。随着云计算技术的倒退，企业也都在向这一趋势聚拢，越来越多的将本人的业务数据往云上迁徙。咱们置信数据库的将来在云上，这也是咱们打造 PieCloudDB 这款云原生数据仓库的起因。 PieCloudDB 于 2022 年 10 月正式问世。它是一款云原生分布式数据仓库，提供齐备的 SQL 语言反对，高效的分布式计算能力和齐备的事务反对。同时又实现了繁多数据集的多集群，秒级的弹性和只为必要的计算和存储付费的能力。 1. Why We Need PieCloudDB？1.1 NoSQL 和数据湖已不能满足用户的剖析需要在过来的很长一段时间里，NoSQL + 数据湖解决方案在数据分析畛域占据了支流市场，而 Hadoop、HDFS 等 NoSQL 数据库也是次要的数据分析平台。然而，随着 Cloudera 发表进行对 CDH 技术支持，对 Hadoop 等 NoSQL 平台的质疑声音也越来越大。 这一景象正是因为 NoSQL + 数据湖体系在简单查问反对、高并发隔离性和一致性等重要数据分析个性方面存在显著有余，现有基于规范 SQL 的 BI 工具难以集成，且 NoSQL 自身对高级剖析（如图形剖析、地理信息剖析等）的反对较弱。因而，NoSQL 开始被人们贴上 “过期” 的标签，不再占据数据分析畛域的次要市场份额。 ...

01 前言2015年云原生理念提出的时候，彼时寰球金融百年倒退造成的信息化到数字化的背地，金融级的技术服务水准通过长时间的打磨曾经造成行业共识的规范。8年前的云原生经典理念是聚焦在容器化、DevOps、继续开发继续集成、微服务架构这些软件开发层面的新范式。而金融级要求诸如高可用、高性能、业务连续性、系统安全稳固等等这些要求跟云原生架构的理念好像处在两个相距边远的领域。随着技术层面的一直演进，在新型的利用零碎的开发方面，金融机构开始逐渐引入容器化等云原生部署架构，然而始终发现聚焦在开发态层面的云原生能力是不能触达金融的零碎建设的各个层面。云计算技术突飞猛进的变动反过来推动了云原生的倒退从广义到狭义，明天的云曾经变成了更为普适性的规范基础设施，更是新技术新业务翻新的平台；因而诸如云原生大数据，和云原生存储以及云原生网络技术等技术让云的原生能力从软件开发走向数据平台进而延展到底层物理部署架构。明天的云计算无论是公共云还是专有云，其技术体系带来的先进性以及对开源的拥抱和反对的确在扭转着行业面向未来的布局。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1208533?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

2023年6月17日，中国开源软件推动联盟 PostgreSQL 分会在成都举办了数据库技术峰会。此次峰会以“新机遇、新态势、新倒退”为主题，联合当下信创热潮、人工智能等产业改革背景，探讨 PostgreSQL 数据库在这些新机遇下的发展前景。峰会邀请泛滥行业大咖、学术精英、技术专家、技术爱好者等加入本次盛会，分享 PostgreSQL 数据库将来的倒退时机、新技术和新方向，推动 PostgreSQL 在中国的倒退。 拓数派作为 PG 分会的生态搭档受邀参加本次峰会。拓数派 PieCloudDB 产品经理陈金豹在流动中发表主题演讲《云原生虚构数仓 PieCloudDB 的架构和要害模块实现》。 图为 拓数派 PieCloudDB 产品经理陈金豹 陈金豹认为私有云是将来数据库倒退的重要方向之一，而以关系型数据库为根底的数据仓库不足弹性，难以利用私有云的劣势；NoSQL 和数据湖的解决方案又不足对事务 ACID 的反对，且难以胜任简单的数据分析场景。用户冀望一个兼顾关系型数仓和私有云劣势的产品，这也是 PieCloudDB Database 的设计指标。 PieCloudDB 在计算引擎方面提供了齐备的 SQL 反对、ACID 事务反对以及高效的查问优化和执行器，齐全胜任各种简单的数据分析场景；而在私有云个性方面，PieCloudDB 实现存算拆散，提供弹性的计算集群，用户能够按需为计算和存储付费，实现降本增效。 PieCloudDB 的云原生架构中蕴含了两条重要个性：弹性伸缩的集群和 Multi-Cluster。PieCloudDB 应用齐全无状态的 Segment 节点提供极致的计算集群弹性；而多集群个性则是通过独立的零碎表以及分布式锁和事务独特实现。最初，陈金豹介绍了将来 PieCloudDB 行将公布的一些要害个性：Time Travel、Branch、Data Sharing 以及曾经公布的性能优化个性汇集下推和预汇集。 2023 PostgreSQL 数据库技术峰会成都站圆满结束。PostgreSQL 历经三十多年的倒退，越来越受到用户的欢送和认可，在 DB-Engines 稳固放弃在前列。依据 Stack Overflow 2023 年度调查报告，PostgreSQL 取代 MySQL 位居第一，成为年度最受欢迎的数据库。这些无一不表明了 PostgreSQL 的生态劣势，拓数派作为PostgreSQL 社区生态搭档，秉持拥抱凋谢的企业文化，始终以代码奉献、讲师布道、会议资助等多种形式参加到 PostgreSQL 的社区奉献中，在将来拓数派将持续为社区奉献一份力量。

2023 年 6 月 3 日，开源软件联盟 PostgreSQL 中文社区在武汉举办了技术沙龙流动。本次流动主题围绕将来数据库展开讨论和分享。通过探讨将来数据库的概念和特点，为智能化时代的倒退提供更多的反对和服务。同时，通过探讨数据库和 AI 技术的共生共荣，推动数字经济的倒退和翻新，创始将来数据库的新篇章。  拓数派作为 PostgreSQL 搭档社区，也受邀加入本次流动。拓数派（OpenPie）CTO 郭罡在流动中发表了主题演讲《云原生分布式虚构数仓 PieCloudDB 的诞生之旅》。  图：拓数派 CTO 郭罡在技术沙龙中发表主题演讲 郭罡从四个方面讲述了 PieCloudDB 内核的构建和成长之路：数据存储、数据拜访减速、元数据管理、分布式化。在演讲中，他首先介绍了 PieCloudDB 打造的全新数据存储引擎：JANM（简墨），该引擎实现了基于对象存储的行列混存构造。简墨在设计时充分考虑了 S3 拜访敌对、OLAP 敌对以及计算引擎减速敌对；对于数据拜访减速，为了降本增效，PieCloudDB 反对 S3 存储，并针对 S3 存储自身的瓶颈进行了大量优化；对于元数据的设计，PieCloudDB 将元数据存储到 FoundationDB 中，并通过借助元数据的缓存等技术来缓解 FoundationDB 的压力；最初则是从单机迈向分布式化，PieCloudDB 实现了分布式引擎并针对分布式场景进行了大量优化。  将来 OpenPie 团队将持续打磨 PieCloudDB 内核，在元数据存储、用户数据存储、优化器和计算引擎方面一直优化，为用户提供一款性能更加弱小，稳定性更高的产品。  2023 PostgreSQL 武汉站技术沙龙流动圆满结束，这次流动对于推动将来数据库和 AI 技术的交融，激发更多的翻新和单干都有重要的价值和意义。将来，拓数派将持续专一技术创新，为智能化时代的倒退注入更多的生机和创造力，为创始将来数据库新篇章奉献一份力量。   

随着平台工程理念的崛起，企业应用的独立的DevOps工具链逐步向更先进、更便捷的DevOps平台演进。Gartner公布了首份DevOps平台魔力象限报告（Gartner Magic Quadrant for DevOps Platforms）。在这个备受关注的报告中，中国云原生厂商灵雀云获“荣誉提及”（Honorable Mention），并成为惟一一家呈现在该报告中的中国厂商。DevOps平台提供了各类组织所需的残缺工具链能力。 Gartner倡议道：“软件工程领导者应该开始评估将DevOps平台作为减速交付客户价值的伎俩。” 另外，报告中也指出：“为了满足客户日益增长的需要，以及对DevOps市场进行更加深刻的评估，咱们首次公布了DevOps平台魔力象限报告，并取代了在2021和2022年公布的Market Guide for Value Stream Delivery Platforms报告。” 除了私有云厂商和传统DevOps厂商，寰球当先的云原生厂商也在报告中锋芒毕露，咱们认为这标记着云原生已成为构建下一代 DevOps 价值链平台的核心技术。 DevOps平台：DevOps落地的最佳门路依据Gartner的定义，“DevOps平台是指可能提供齐全集成能力，并通过麻利和DevOps实际实现软件继续交付的平台。平台能力涵盖了软件生命周期治理（SDLC）的各个方面，包含产品布局、版本控制、继续集成、测试自动化、继续部署、公布编排、平安和合规策略自动化、监控以及可观测性等。通过应用DevOps平台，能够增强团队合作，晋升软件开发的安全性，并且实现软件交付的可度量。 DevOps平台简化了创立、保护和治理现代化软件应用交付所需的组件。预构建的组件集成缩小了用户的认知负荷，进步了对软件开发价值流的可见性、可审计性和可追溯性。这种端对端的形式激励了零碎思维模式，减速了反馈循环。 通过应用DevOps平台，能够把整个软件生命周期中那些由简单的工具链、手动交接流程和不足统一可见性而产生的抵触最小化，产品团队可能在保证质量的前提下疾速交付利用。DevOps平台的广泛应用，使得开发、测试、基础设施运维和平安团队实现了技术整合，更快地交付客户价值。” DevOps平台在麻利开发、挪动利用开发、边缘计算、云原生利用开发、平台工程等场景下被广泛应用。Gartner预测， “到2027年，将有75%的企业从多点解决方案（Multiple Point Solutions）转向DevOps平台，以简化利用交付，而2023年这一数字只有25%。” 灵雀云缘何被荣誉提及？灵雀云ACP DevOps基于Kubernetes提供了一个凋谢的DevOps工具链集成和编排平台。它遵循平台工程（Platform Engineering）理念，能够集成开发人员喜爱并相熟的任何DevOps工具，并与ACP的多云容器治理平台相结合，把利用公布、运行在各种运行环境中。ACP DevOps能够充分利用ACP平台凋谢、灵便的特点和自动化运维能力，做到更高的服务质量、更低的开发运维老本、更快的交付速度。 咱们认为，灵雀云等云原生平台厂商的入选，预示着以利用为核心的云原生DevOps平台将成为越来越多企业晋升研发效率、优化交付品质的首要抉择。 ACP DevOps平台具备以下外围劣势： ● 开放式工具链集成与编排与很多平台不同，灵雀云并不从新开发任何DevOps工具，而是灵便集成各类优良的开源和商业版DevOps工具，兼容存量及将来工具选型，笼罩利用布局、需要、设计、开发、测试、交付、运维残缺生命周期，将 DevOps 各环节工具串联买通，造成残缺全面的开放式工具链。企业能够在平台上轻松地构建、部署和治理云原生利用。 ● 为用户量身定制DevOps最佳实际利用ACP DevOps平台的流水线能力，企业平台团队可将其本身的最佳实际和流程固化下来，为利用团队提供便捷且合乎企业标准的平台反对。ACP DevOps还内置了数十条流水线模板，以满足用户不同的应用场景。同时，灵雀云的DevOps征询和服务能力，能够帮忙企业梳理本身DevOps流程，打造全流程的DevOps最佳实际。 ● 多环境、多云反对，防止云厂商锁定灵雀云ACP DevOps平台，可与ACP容器治理平台一起，提供跨云、多集群治理的能力，可全面纳管各类公有环境、私有云上的K8s集群和基础设施，可能很好地解决客户在应用混合云和多云时面临的各种问题，为混合云和多云的环境提供对立的DevOps工具和流程。 ● 完满体现平台工程（Platform Engineering）设计理念ACP DevOps产品设计合乎平台工程的设计理念，可为利用团队提供自助式开发门户，辅助企业平台团队以平台化的模式将最佳实际固化下来，在保障合乎企业流程标准的同时升高利用团队对底层基础设施和工具的学习老本，聚焦于业务翻新。 截至目前，ACP平台已服务寰球500+头部企业客户，笼罩银行、证券、保险、运营商、工业、能源等多个行业畛域。 将来，灵雀云也将持续将ACP打造为更高可用、高性能、高牢靠的企业级云原生平台，助力企业客户胜利实现数字化转型。 起源 : Gartner®, Magic Quadrant™ for DevOps Platforms, Manjunath Bhat et al., 5 June 2023 GARTNER 和MAGIC QUADRANT是 Gartner, Inc. 和/或其关联公司在美国和国内上的商标，并在取得许可的状况下在此应用。保留所有权力。Gartner 并未在其钻研报告中反对任何供应商、产品或服务，也并未倡议科技用户只抉择该等获最高评分或其它名称的供应商。Gartner 的钻研报告含有 Gartner 钻研与参谋组织的意见，且该意见不应被视作事实陈述。就该钻研报告而言，Gartner 放弃做出所有明示或默示的保障，包含任何无关适销性或某一特定用处适用性的保障。 ...

本文作者：何文强——腾讯云 CODING 高级架构师。 负责 CODING DevOps产品解决方案架构设计和技术产品布道以及 CODING 云原生技术钻研与落地实际。在多个技术大会负责演讲嘉宾，腾讯云 CODING DevOps 课程认证出品人，腾讯云云原生训练营外围初创成员。精通麻利精益、DevOps 和云原生畛域，技术扎实，视线宽阔，格局前瞻；在泛互、教育、工业、政务、金融等多个行业领有数字化落地布局和实战经验；多年技术开发和团队治理教训，目前专一于一站式研发效力平台的建设和推广，聚焦于“以利用为核心“的云原生的落地与实际，致力于中国软件工程能力的晋升和改良。 Orbit 是腾讯云 CODING 推出的一个企业级云原生利用交付平台（图3-1）。Orbit 以利用为核心进行设计，次要包含利用建模、利用交付、利用运维和申明式基础设施设施交付 4 个方面进行平台设计，围绕着基于 OAM 利用建模、Application As Code、GitOps 版本化治理、对立可观测性 4 个维度进行具体价值主张申明。 图 3-1 基于OAM利用建模Orbit 基于凋谢利用模型 OAM（Open Application Model）进行利用建模（图3-2），采纳研发和运维视角拆散的准则，云原生专家或运维平台团队负责服务标准、服务模板和服务插件的制订，研发人员通过表单参数的形式援用平台团队定制模板和插件。通过这种职能视角拆散，研发人员在不须要学习和把握 Kubernetes 简单技术细节的状况下，轻松实现利用云原生化，极大升高利用云原生化的门槛；运维人员或平台团队通过对模板和标准的建设，可能无效晋升利用配置的一致性和可维护性，升高云原生规模化的老本和推广难度。 图3-2 Orbit 将利用代码（镜像）、数据库、配置和环境等利用因素进行了对立的定义和治理，通过对立的利用模型，屏蔽了利用底层的基础设施，不与具体云厂商绑定，兼容多云 Kubernetes 平台，反对企业基础设施的平滑降级和渐进式演进。 Application As CodeOrbit 将服务、配置、数据库、部署流水线、基础设施和环境的利用因素进行层级划分(图3-3)。服务、配置和数据库作为业务层，部署流水线作为交付层，基础设施和环境作为资源层。Orbit 将利用的所有因素都以代码的形式组织和存储到代码库中，以代码库作为利用因素的繁多事实起源，所有的变更都以代码提交的形式进行记录和存储，Orbit 通过代码库的版本控制系统能力，实现利用在任意时刻都可追溯、可审计、可回退能力。 图3-3 通过分层的设计模式实现利用配置在代码仓库中的正当有序组织，为不同的层级定义不同的目录层级，并给予相应的目录权限，实现细粒度的利用配置信息的权限管制，在加强通明、信赖与合作的同时也满足组织外部的平安合规和敏感数据治理规定。 GitOps 版本化治理Orbit 部署基于 GitOps 理念进行利用交付。GitOps 是以 Git 为外围进行利用配置信息的存储，通过有且只有惟一的存储库实现繁多事实起源，并利用 Git 的 Commit、Diff、Revert、Merge 等外围能力进行版本变更治理。开发人员将代码或配置的批改提交到代码仓库中，会触发继续集成流水线进行代码的编译构建，生成镜像推送到制品库，Orbit 会监听制品库和配置的变动，通过 Git Diff 能力主动拣配以后版本与上一版本的差别，按需抉择变更内容进行公布单创立。运维人员或公布人员通过对公布单内容的审查，进行版本的公布。在审计方面，通过 Git Commit 信息，能够查看每次变更的内容，实现变更内容的审计与追溯。在公布可靠性和回滚方面，通过 Git 版本化实现利用的原子化公布，也通过 Git 的 Revert 命令，让利用回滚变得简略牢靠。 ...

立刻体验基于函数计算部署【图生图】一键部署 3D 卡通格调模型：https://developer.aliyun.com/topic/aigc_fc 人工智能生成内容（Artificial Intelligence Generated Content，简称 AIGC）是当下最火的概念之一。AIGC 被认为是继业余生成内容（Professional Generated Content, PGC）和用户生成内容（User Generated Content, UGC）之后，利用人工智能技术主动生成内容的新型生产方式。 AI 生成内容的模式相当丰盛，除了文字外，还能够进行绘画、作曲、演唱、编剧、设计等。最近热度十分高的 Text to Image 就是 AI 加持下十分时尚的一种图片发明形式。看看上面这些图片，你肯定很难设想它们都是 AI 生成的吧。 明天咱们将应用阿里云函数计算 FC [ 1] 来部署 3D 卡通格调模型，给大家展现一下这项技术的魅力。 3D 卡通格调模型界面 部署胜利后，能够上传任何一张带人物照片进行生成 3D 卡通格调。 函数计算的劣势开箱即用，通过利用核心一键部署疾速体验，无需进行简单的环境配置按需付费，通过 Serverless 弹性策略在您启动服务的才开始计费反对 GPU 渲染，出图快，破费低筹备项开明阿里云函数计算 疾速开始抉择 3D 卡通格调模型利用在函数计算页面单击左侧“利用”搜寻“图生图-图像格调转换”单击“立刻创立 间接部署利用创立利用页面，抉择间接部署首次应用须要依据提醒进行角色名称受权利用可抉择北京、杭州、上海、深圳任一地区依据抉择的地区，抉择以下对应的镜像，复制到镜像地址框。上海地区镜像地址： registry.cn-shanghai.aliyuncs.com/aliyun-fc/3d-cartoonization:v1 杭州地区镜像地址： registry.cn-hangzhou.aliyuncs.com/aliyun-fc/3d-cartoonization:v1 北京地区镜像地址： registry.cn-beijing.aliyuncs.com/aliyun-fc/3d-cartoonization:v1 深圳地区镜像地址： registry.cn-shenzhen.aliyuncs.com/aliyun-fc/3d-cartoonization:v1 点击“创立并部署默认环境” 函数计算首次启动要花费 3-4 分钟，须要实现镜像拉取，冷启动等操作。最初画面如下 您能够点击 “Upload and Play” 在您的电脑上抉择一张图片，能够上传任何一张带人物照片进行生成 3D 卡通格调。 有奖体验阿里云将提供 Serverless 函数计算产品试用资源，邀请您体验：Serverless 一键部署通义千问预体验、文生图、图生图、图生文、文生文 5 大经典 AI 场景，让您取得通义千问 30 次对话预体验机会，同时简略、高效实现一键部署图像生成、文字生成服务，速成 AIGC 创作家。双重奖品设置，实现任意一个体验场景可得社区 400 积分兑换奖品，还可加入 AI 生成图像较量赢取 Airpods、阿里云定制蓝牙音箱及阿里云定制清雅杯！ ...

杭州拓数派科技倒退有限公司 （OpenPie）的旗舰产品 PieCloudDB Database 是一款云原生分布式虚构数仓。PieCloudDB 通过多种创新性技术将物理数仓整合到云原生数据计算平台。PieCloudDB 能够动态创建虚构数仓，按需灵便计算，从而突破数据孤岛，撑持更大模型所需的数据和计算。 PieCloudDB 于 2022 年 10 月 24 日公布 1.0 版本，实现计算和存储拆散，实现了弹性计算与弹性存储，做到了计算和存储均可按需付费，并实现了多租户隔离。2023 年 3 月 14 日，拓数派正式公布了 PieCloudDB 的云上云版本，云上云版本目前构建在阿里云上，并将很快扩大到其余云平台。云上云版将满足用户多样化的数据分析需要，打造公共云数仓服务最佳实际。 PieCloudDB 目前已有四个产品版本，别离是： 云上云（CoC）版本（收费试用）社区版（收费下载）企业版一体机版本PieCloudDB 云上云版为企业构建坚如磐石的虚构数仓，以云资源最优化配置实现有限数据计算可能。 PieCloudDB 企业版与社区版可为企业提供全新基于云数仓数字化解决方案，助力企业建设以数据资产为外围的竞争壁垒；PieCloudDB 国产软硬件一体机，采纳 eMPP 专利技术实现存算拆散，适配信创环境，为甲方企业升高运维老本，节俭开发工夫。 PieCloudDB 拓数派研发团队之所以会抉择云原生作为次要赛道，次要出于多方面的考量。首先，在传统的 MPP 数据库的客户环境中，往往存在一个独特的痛点，那就是：数据孤岛。客户的生产环境中 MPP 数据库集群数量过多，即便采纳数据联邦等解决形式，也可能会导致数据一致性性问题，还会对存储空间造成肯定的节约。第二，数据作为新的生产因素须要流通起来才会产生更大的价值。为了解决这些痛点问题，PieCloudDB 通过实现存算拆散的架构，将数据存储在共享存储（S3，HDFS，NAS）中，将元数据信息存储在共享 NoSQL 数据库 FoundationDB 中，实现了存储资源和计算资源的独立弹性伸缩，从而可能在维持高性能的同时，更加灵便的进行扩缩容，帮忙用户降本增效。 上面咱们来回顾一下 PieCloudDB 的诞生之路。PieCloudDB 从新打造 PostgreSQL 实现存算拆散。之所以没有从数据库底层进行从新设计研发，是因为所谓” 术业有专攻”，就像制作跑车的并不会亲自生产车轮一样，协调上面的轮子来跑的更快更稳才是咱们所专一的。而数据库底层组件就像车轮一样，PieCloudDB 在 PostgreSQL 的根底上做了大量革新与优化，实现分布式与存算拆散，充分利用 PostgreSQL 源源不断的创新能力和资源，联合拓数派研发团队的创新能力，针对分布式、OLAP 及云原生场景进行了大量极致优化，成就了这款云原生虚构数仓 PieCloudDB。 1. PieCloudDB 的诞生之路咱们次要是从四个方面来进行设计和打造 PieCloudDB 的：元数据管理、数据存储、数据拜访减速、分布式化。 1.1 元数据管理为了突破数据孤岛，PieCloudDB 设计了存储计算拆散的计划。在这种设计方案下，用户可能启动了多个虚构数仓来操纵同一份数据，因而可能会产生一个虚构数仓在更新数据而另一个虚构数仓在读取数据的状况。为了保障在多个虚构数仓（multi - coordinator）状况下数据的一致性，咱们设计了元数据服务，把元数据和用户数据以及虚构数仓解耦合。元数据服务使得同一组织下不同租户的元数据是共享的，用以实现分布式事务和分布式锁。 PieCloudDB 的元数据服务基于 FoundationDB 实现，PieCloudDB 通过借助 FoundationDB 的串行化事务模仿轻量级锁性能，并通过实现分布式锁来保证数据的一致性。 ...

2023年6月6日，由工业和信息化部主办，中国信息通信研究院（以下简称“中国信通院”）的“ICT中国·2023高层论坛-云原生产业倒退论坛”在北京召开。 本届论坛以“云智原生新底座，数实交融新征程”为主题，会上颁布了新一批利用现代化推动核心成员名单，灵雀云凭借利用现代化畛域的先进技术实力和丰盛实践经验胜利入选为成员单位。同时，灵雀云首席解决方案专家杜东明被聘为利用现代化推动核心专家委员会成员。 利用现代化推动核心（AMPC）是由中国信通院牵头、联结产学研用各方力量独特成立的业余组织，旨在探明利用现代化的实质，拉齐行业认知，凝聚产业力量，增强企业和行业用户之间的沟通，推动利用现代化理念的遍及与落地，疏导现代化利用的规范化建设。 利用现代化已成为企业数字化转型的必由之路数字经济大背景下，软件行业迎来历史性倒退时机，利用现代化作为软件倒退的必然趋势正在逐步成为寰球头部企业的共识，成为企业数字化转型的最佳实际门路。 ● Gartner预测到2025年，云原生平台将成为95%以上新数字倡导的根底，而在2021年这一比例只有不到 40%。● IDC预测，到2025年，数字经济将催生出超过5亿个新利用/服务，90% 的应用程序将是云原生应用程序。● Forrester钻研指出，实现利用现代化的企业可取得128%的ROI（投资回报率）晋升。● 调研机构Valuates Reports在报告中示意寰球利用现代化服务市场规模预计将从2022年的216.9亿美元增长到2028年的504.4亿美元，复合年均增长率达15.1%。 利用现代化是指通过应用现代化新一代的云原生技术栈，对遗留应用软件和零碎进行现代化革新的过程，使其降级到具备高弹性、高伸缩性的云原生环境。通过这个过程，应用程序能够跟上技术倒退步调，充沛享受云原生技术降本增效、麻利迭代的技术红利，更继续且更疾速地满足用户冀望与需要，发明更大潜在收益，解锁企业将来价值。 随着数字化转型过程放慢，云原生提供的弹性、可扩展性、降本等个性将进一步推动利用现代化一直倒退。 灵雀云ACP助力企业实现利用现代化利用现代化曾经成为企业博得竞争劣势、发明业务价值的必然趋势，然而企业革新时却不知从何动手。那么有没有开箱即用的利用现代化解决方案呢？ 作为国内云原生领军企业、利用现代化畛域实际先锋，灵雀云始终致力于帮忙企业实现利用现代化、减速数字化转型，提供蕴含技术、产品、解决方案、培训、征询等残缺的一站式服务。 灵雀云云原生全栈混合云平台ACP，笼罩企业业务利用全生命周期，反对灵便自定义各类基础设施，帮忙企业减速构建、运行及治理现代化利用，已为金融、能源、运营商、政企、制作、航空、汽车等畛域的数百家客户实现了利用的开发测试运维一体化，并为上百家ISV企业实现了利用的容器化转型。 作为利用现代化推动核心的成员单位，灵雀云将携手中国信通院及各方力量，独特摸索利用现代化转型胜利门路，促成利用现代化产业化倒退。

背景波司登开创于1976年，专一于羽绒服的研发、设计、制作，是寰球出名的羽绒服生产商。波司登用一系列世人注目的辉煌问题证实了本人的实力：间断26年全国销量当先，间断22年代表中国向世界公布防寒服风行趋势，产品滞销美国、法国、意大利等72个国家，寰球超过2亿用户。作为羽绒服反动的旗手，波司登引领了行业内的“三次反动”。 在产品力和销售成绩单背地，波司登在生产、仓储、物流、销售各环节已实现数字化转型和翻新革新。除生产端的智能生产工厂，波司登对仓储和物流环节也进行智能化革新，晋升小单快反、拉式补货的比重，最大限度缩小困扰服装企业多时的“库存”问题；为了精准散发销售端产品，波司登建设数据中台，买通全渠道数据，赋能消费者钻研、商品企划、渠道匹配等。当初，波司登每件羽绒服从生产到到达消费者，背地都是一段数字之旅。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1128357?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

导读：在万物云原生下的环境下，Java的市场份额也因耗资源、启动慢等毛病，导致在云原生环境里被放大而升高，通过这篇文章，读者能够更好地理解如何在云原生环境下通过降级相干版本和应用GraalVM打出原生镜像到形式，优化Java利用的性能和资源利用率，使Java利用更好地适应云原生环境。 1.引言（Introduction）1.1、目标：当初咱们的我的项目能失常运行，为什么要消耗大量人力重构？ 1.2、背景：云原生时代下和java的爱恨情仇： 在云原生时代，随着技术的突飞猛进变动，咱们寻找最佳技术解决方案的路线上总是充斥崎岖。作为分布式应用的支流技术，Kubernetes（简称k8s）和Java在这个时代交错出一段爱恨情仇般的佳话。那云原生下这两个技术到底是敌是友，须要咱们进行深入分析。首先，咱们站在云原生的角度来看，难以漠视的是k8s 确实被时代认可，尤其在微服务架构、容器化部署和资源管理等方面。其弱小的自动化、弹性伸缩和容错能力成为了很多软件系统的最佳实际。而Java作为一门领有28多年历史的编程语言，无论是在市场份额和生态圈都有无可撼动的位置。Java在分布式系统、中间件、业务逻辑解决等方面有着丰盛的实践经验，为开发人员提供了良好的编程体验和广大的生态反对。而在泛滥利用架构的背地的技术架构都离不开Kubernetes和Java。从这个角度看来，它们仿佛是一对黄金搭档，但关系到具体实际过程时，细节往往能决定成败。咱们来看看这两个技术在实际操作中产生的爱恨情仇。 1.2.1、 爱与恨：资源限度与治理在云原生架构中，k8s为利用提供了资源限度与治理的能力，使得利用可能按需分配资源。然而，Java在解决资源方面存在肯定的局限性。因为JVM在内存治理方面依赖于Xms和Xmx等参数进行配置，导致利用在Kubernetes中的资源管理绝对简单。在这期间咱们发现java也不甘示弱 在JVM层面对资源管理等方面也进行了改良 比方减少了Containters标记，使得Java利用在k8s环境中的资源配置更为简化。 1.2.2、恩怨难分：服务发现与负载平衡在微服务架构中，服务发现和负载平衡是要害。过来，Java生态中有很多解决方案，例如Eureka、Zookeeper等，这让java在服务发现和负载平衡方面有多种抉择， 但在k8s环境中，人造具备服务发现和负载平衡的能力，如果须要转到云原生就须要对微服务进行调整以适配k8s环境。 1.2.3、 重逢：继续集成与继续部署（CI/CD）k8s在继续集成与继续部署方面具备很强的能力，与GitLab、Jenkins等CI/CD工具的联合能够为Java利用提供极致的开发、构建和部署体验。通过将k8s和Java生态中优良的CI/CD工具整合在一起，架构师可能实现麻利的开发、疾速的迭代和高效的运维。 1.2.4、共生：爱恨交织在k8s的世界里，Java应用程序的部署和治理未然变得越来越高效。但随着微服务、Serverless 架构的衰亡，Java的致命缺点开始裸露进去。首先是启动工夫，Java应用程序在启动时须要加载泛滥类文件，带来了绝对较长的启动工夫。再者，Java应用程序的内存占用往往较高，这在云原生环境中意味着更高的运行老本。而后咱们开始寻找代替计划，以求解脱Java在云原生畛域的解放，进而拥抱更快、更轻量级的利用程序运行环境。 1.2.5、曙光：已经失去的通通要拿回来于是，GraalVM应运而生。GraalVM是一个高性能的Runtime，反对多种编程语言（这也是它通用的起因）。它提供了Java与云原生畛域的桥梁，能够将Java代码编译成本地可执行文件，这意味着更快的启动速度和更低的内存应用。与之同时，GraalVM还提供了对Java的残缺反对，便于将现有的Java应用程序迁徙到云原生畛域。此外，GraalVM还集成了许多弱小的个性，如 (AOT)编译、即时编译（JIT）以及弱小的GC回收机制。这些个性使得GraalVM成为了在云原生畛域的新宠。 2、技术选型：2.1、五因素： 2.1.1、充分利用现有代码库：如果曾经领有一个性能齐备且通过充沛测试的Java应用程序，那么将其转换为native-image能够最大水平地复用现有代码库，缩小从新编写应用程序所需的工作量和危险。此外咱们部门我的项目都是Java，应用native-image能无效升高迁徙老本。 2.1.2、开发者相熟度：如果队伍中曾经具备较为丰盛的Java开发教训，那么将Java利用转换为native-image会升高学习老本和培训老本，相较于应用全新的编程语言来重写利用，这会使得开发者更容易上手。 2.1.3、性能优化：尽管Java利用在某些性能方面可能不如其余编程语言，但通过应用native-image，能够将Java利用转换为与C或C++等编译型语言相似的二进制文件，从而放大性能差距。native-image为利用带来更快的启动速度和更低的内存占用，而这在k8s这种容器化的环境中尤为重要。 2.1.4、 跨平台能力：Java具备良好的跨平台兼容性，而借助GraalVM进行native-image编译，咱们仍然能够保留这一个性。这为利用部署提供较高的灵活性，升高了环境迁徙和保护的复杂度。 2.1.5、 开发和生态系统：Java领有宏大的开发社区和一个成熟、丰盛的生态系统，提供了大量的库和框架来反对各种利用的开发。应用native-image能够更好地利用这些资源，简化利用的开发和保护过程。 2.1.6、最终计划：采纳jdk17+springboot3+native-iamge=原生轻量化服务 对于低频流量的业务零碎，采纳试点我的项目的形式保障可行性的落地，依据业务性能进行我的项目合并，而对于合并后的全新我的项目，间接降级(jdk 和spring框架) version 实现我的项目合并后保障java版本的我的项目跑起来，之后采纳native-image的形式打包成原生镜像，让我的项目在 新个性/稳定性的版本根底上 晋升为真正的轻量化利用。 3、概念：3.1、为什么要降级jdk？3.1.1、新的语言个性：JDK 8 到 JDK 17 之间引入了许多新的语言个性和性能，如Lambda 表达式、Stream API、Optional 类、默认办法、接口公有办法等。这些个性能够使代码更简洁、可读性更好，并反对函数式编程格调，进步开发效率和代码品质。 3.1.2、性能优化和加强：JDK 17 中进行了多项性能优化和加强，包含垃圾回收器的改良、JIT 编译器的加强、并发类库的改良等。这些优化能够进步应用程序的性能和吞吐量，特地是在大规模和高并发的状况下。 3.1.3、模块化零碎：JDK 9 引入了模块化零碎（Java Platform Module System，JPMS），它提供了更好的代码组织和隔离，使得简单的应用程序能够更容易地保护和扩大。模块化零碎还能够帮忙辨认和解决潜在的依赖抵触问题，进步应用程序的稳定性和可靠性。 3.1.4、安全性加强：JDK 17 在安全性方面有多项改良，包含增强的加密算法（SHA-3、X25519、Ed25519 ）、更新的平安协定（TLS 1.3）、安全性加强的 API 等。这些改良能够晋升应用程序的安全性，防备潜在的安全漏洞和攻打。 3.1.5、工具和性能剖析：JDK 17 提供了许多工具和性能剖析的改良，例如 JShell（交互式编程工具）、Java Flight Recorder（JFR，低开销的性能剖析工具）、JDK Mission Control（JMC，性能监控和故障诊断工具）等。这些工具能够帮忙架构师和开发团队更好地剖析和优化应用程序的性能和行为。 3.1.6、继续改良和稳定性：从 JDK 8 到 JDK 17，Java 平台始终在继续改良和演进。JDK 17 是一个长期反对（LTS）版本，意味着它将取得长期的反对和保护，包含安全更新、谬误修复和性能改良。作为架构师，抉择降级到 JDK 17 能够取得更稳固和牢靠的平台，并确保应用程序可能失去长期的反对。 ...

企业在 Kubernetes 上运行 AI、大数据利用已成支流，资源弹性和开发运维效率失去显著晋升的同时，计算存储拆散架构也带来了挑战：网络提早高、网络费用贵、存储服务带宽有余等。 以 AI 训练、基因计算、工业仿真等高性能计算场景为例，须要在短时间内并发执行海量计算，多计算实例共享拜访文件系统的同一数据源。很多企业应用阿里云文件存储 NAS 或 CPFS 服务，挂载到阿里云容器服务 ACK 运行的计算工作上，实现数千台计算节点的高性能共享拜访。 然而，随着算力规模和性能晋升、以及模型规模和工作负载复杂度的减少，在云原生的机器学习和大数据场景下，高性能计算对并行文件系统的数据拜访性能和灵活性要求也越来越高。 如何能更好地为容器化计算引擎提供弹性和极速的体验，成为了存储的新挑战。 为此，咱们推出了弹性文件客户端 EFC（Elastic File Client），基于阿里云文件存储服务的高扩展性、原生 POSIX 接口和高性能目录树结构，打造云原生存储系统。并且，EFC 与云原生数据编排和减速零碎 Fluid 联合，实现数据集的可见性、弹性伸缩、数据迁徙、计算减速等，为云原生的 AI、大数据利用共享拜访文件存储提供了牢靠、高效、高性能的解决方案。 1 Fluid，云原生之数据新形象Fluid[1]是一个云原生分布式数据编排和减速零碎，次要面向数据密集型利用（如大数据、AI等利用）。 与传统的面向存储的PVC不同，Fluid 从利用角度登程，提出弹性数据集（Dataset）概念，对“在 Kubernetes 上应用数据的过程”进行形象。Fluid 是 Kubernetes 生态的开源我的项目，由南京大学、阿里云以及 Alluxio 开源社区联结发动，已于 2021 年募捐给 CNCF 社区。 Fluid 让数据像流体一样，在各种存储源（如 NAS、CPFS、OSS 和 Ceph 等）和 Kubernetes 下层利用之间来去自如，灵便高效地挪动、复制、驱赶、转换和治理。 Fluid 能够实现数据集的 CRUD 操作、权限管制和拜访减速等性能，用户能够像拜访 Kubernetes 原生数据卷一样间接拜访形象进去的数据。Fluid 以后次要关注数据集编排和利用编排这两个重要场景： 在数据集编排方面，Fluid 能够将指定数据集的数据缓存到指定个性的 Kubernetes 节点，以进步数据访问速度。在利用编排方面，Fluid 能够将指定利用调度到曾经存储了指定数据集的节点上，以缩小数据传输老本和进步计算效率。两者还能够组合协同编排，即协同思考数据集和利用需要进行节点资源调度。 Fluid 为云原生 AI 与大数据利用提供一层高效便捷的数据抽象，并围绕形象后的数据提供以下外围性能： 面向利用的数据集对立形象 数据集形象不仅汇总来自多个存储源的数据，还形容了数据的迁移性和特色，并提供可观测性，例如数据集总数据量、以后缓存空间大小以及缓存命中率。用户能够依据这些信息评估是否须要扩容或缩容缓存零碎。 可扩大的数据引擎插件 尽管 Dataset 是对立的抽象概念，但不同的存储有不同的 Runtime 接口，理论的数据操作须要由不同的 Runtime 实现。Fluid 的 Runtime 分为两类：CacheRuntime 实现缓存减速（包含开源分布式缓存AlluxioRuntime、JuiceFSRuntime，阿里云 EFCRuntime、JindoRuntime 和腾讯云 GooseFSRuntime）；ThinRuntime 提供对立拜访接口（如 s3fs、nfs-fuse 等分布式存储系统），不便接入第三方存储。 ...

前言新能源汽车曾经成为我国汽车市场再次崛起的要害支柱，随着新能源汽车市场的疾速倒退，不同类型的品牌造车厂商呈现出百花齐放的态势。极氪汽车是吉利控股集团旗下高端纯电汽车新品牌，2021 年 4 月极氪公布首款高端智能电动车型--极氪 001，大获市场好评，截至 2022 年 12 月，001 车型累计交付量冲破 7 万台。间断 3 个月问鼎自主品牌 30 万以上奢华纯电车型销量冠军。 极氪保持不止于车的服务体验，除了为客户提供卓越产品的同时，还通过极氪 APP 与用户建设连贯。极氪 APP 推出线上社区、订阅出行、好物商城、极氪生存等多元翻新动作，实现了极氪产品的全生命周期治理以及用户旅程的全场景笼罩。从用户想要理解相干车型，到有动向进行购买、提车应用、分享感触以及售后问题迅捷解决方案等各种环节的应用场景，都被集成到了这款 APP 之上。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1173573?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

大量的企业曾经将 Kuberentes 用于其生产环境, 但面对他们正在运行的多套不同阶段的 Kuberentes 集群，依然困惑于在保障业务团队敏捷性的同时，如何实现继续部署，高安全性、权限拆散以及可审计。咱们认为 GitOps 是目前比拟现实的一种办法来实现基于 Kuberentes 集群的继续部署，且同时满足安全性、权限拆散等企业级需要。 在这篇文章中，咱们将分享 GitOps 的核心思想和工作流程。后续的系列文章中，咱们会一起实际如何在 Amazon EKS 环境里构建 GitOps 格调的 CI/CD 流水线，欢送继续关注！ 亚马逊云科技开发者社区为开发者们提供寰球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、流动与比赛等。帮忙中国开发者对接世界最前沿技术，观点，和我的项目，并将中国优良开发者或技术举荐给寰球云社区。如果你还没有关注/珍藏，看到这里请肯定不要匆匆划过，点这里让它成为你的技术宝库！什么是 GitOpsGitOps 是一种为云原生利用程序实施继续部署的办法。它通过应用开发者曾经相熟的工具，包含 Git 和继续部署工具，专一于在操作基础架构时以开发者为核心的体验。 GitOps 的核心思想包含： 领有一个 Git 存储库，该存储库始终蕴含对生产环境中以后所需基础设施的申明性形容，以及一个使生产环境与存储库中形容的状态相匹配的自动化过程；冀望的状态以强制不变性和版本控制的形式存储，并保留残缺的版本历史；如果开发者想部署一个新的应用程序或更新一个现有的应用程序，开发者只须要更新存储库，软件代理主动从源中提取所需的状态申明，自动化过程会解决其余所有事件；软件代理继续察看理论零碎状态并尝试利用所需状态；为什么抉择 GitOps同传统的继续部署零碎相比，GitOps 有以下特点： 咱们为什么认为 GitOps 是实现基于 Kuberentes 集群的继续部署，且同时满足安全性、权限拆散等企业级需要的现实形式呢？其中一个起因是GitOps 在实践中能够抉择采纳推 (push) 或是拉 (pull) 的部署格调。 采纳拉 (Pull) 部署格调会有如下益处： 更加平安。因为 GitOps 代理运行在 Kubernetes 集群中，因而仅须要最小的权限用于部署。简化网络配置不须要该集群同 CD 程序建设网络连接，尤其在治理多集群时尤为简洁。一致性。治理多集群时，确保了每个集群的治理形式都是一样的。隔离性。每个集群的部署不依赖于集中的流水线 CD 程序。可伸缩性。该形式能够容易的扩大到同时治理成千盈百的集群。GitOps 部署形式咱们倡议首选拉 (Pull) 部署格调。因为采纳拉 (pull) 的部署格调从安全性、可伸缩性、隔离性、一致性都更优。 抉择 GitOps 的另一个起因，是能够通过 Kuberentes 上 GitOps 具体实际来理解细节。 GitOps 办法下，Git 成为零碎所需状态的惟一事实起源，反对可反复的自动化部署、集群治理和监控。开发者通过复用企业中曾经十分成熟的 Git 工作流程来实现编译、测试、扫描等继续集成步骤。当零碎最终状态的申明代码进入 Git 仓库主线分支后，依靠 GitOps 工具链来实现验证部署，到观测告警，到操作修复达到零碎最终状态的闭环。流程参见下图： ...

往年 4 月，阿里云对外发表产品提价和外围云产品收费试用以来，开发者反响强烈，已有超过 100 万人次拜访阿里云官网的收费试用。目前收费试用新增了云原生、AI、平安、开发工具、迁徙和运维治理等多个品类。同时，官网上还提供了各种教程，心愿帮忙大家疾速把握云产品应用形式，晋升云上开发能力。热门云原生产品收费试用支付 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1217895?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

第一局部 PieCloudDB 最新动静· PieCloudDB 实现多个产品兼容性认证PieCloudDB 与多家基础架构软件厂商实现产品兼容性认证，类别包含操作系统、服务器、CPU、云平台。新增 8 家生态搭档，包含龙蜥、麒麟、中科可控、海光、博云、杉岩、统信、兆兴等。 起源：OpenPie 官网 PieCloudDB 云上云版费用核心模块已上线通过 PieCloudDB 云上云版新增的费用核心模块，用户可实时理解账户余额、各我的项目生产状况、生产趋势等费用信息，帮忙用户随时掌控账户变动。 用户可点击管控平台左侧菜单栏的「费用核心」按钮即可拜访。 起源：PieCloudDB 云上云版 · PieCloudDB 云上云版新增老手指引模块云上云版全新 PieCloudDB 老手指引模块中涵盖「老手指引」，「上手手册」，「Sample 数据生成」等泛滥性能帮忙大家疾速理解与上手 PieCloudDB。 用户可在管控平台上点击菜单栏左下方的「老手指引」按钮拜访相干性能。 起源：PieCloudDB 云上云版 · PieCloudDB 云上云版新增虚构数仓主动启停性能PieCloudDB 云上云版新增虚构数仓主动启停性能，为用户提供「主动启动」和「主动敞开」两个性能。用户在停止使用虚构数仓后，通过设置的等待时间，虚构数仓将主动进行。当用户在应用须要虚构数仓的性能（数据洞察、数据导入、内部接入）时，虚构数仓会被主动拉起。从而无效帮忙用户降低成本。 用户可在新建虚构数仓时，在「高级配置」中开启 / 敞开，和设置期待时长。 起源：PieCloudDB 云上云版 · PieCloudDB 云上云版试用规定失去优化PieCloudDB 云上云版收费试用中，欢送返回： https://app.pieclouddb.com 注册试用。 在最新版本中，试用规定进行了优化，减少了试用额度，进步了计费折扣力度，配合主动启停性能，让用户得以在更长的试用工夫内，深度体验 PieCloudDB。现在，PieCloudDB 的试用时长可达 30 天。此外，新增的试用期限倒计时性能，也让用户得以更精准地理解残余试用期限。 起源：PieCloudDB 云上云版 PieCloudDB 新增预汇集优化性能PieCloudDB 新增预汇集性能，针对 sum、count、avg、min、max 等常见聚合操作，通过在数据被存储之前对其解决操作，以便在查问时能够间接应用预计算的后果，而无需从新计算，大大节俭了查问工夫，进步查问效率。 起源：PieCloudDB 全线产品 第二局部 OpenPie 近期新闻· PostgreSQL 16 beta 公布，拓数派再次引领中国奉献要害力量5 月 25 日，PostgreSQL 寰球开发团队官网发表，PostgreSQL 16 Beta 1 版本正式公布。本次新版本公布的个性中，多处均可看见拓数派工程师的身影，仅 Richard Guo 一人就奉献了 83 个 Commits。无论是在代码数量还是品质上，拓数派在中国代码奉献中起到了引领作用，成为国内推动 PostgreSQL 技术创新的要害力量。 ...

从传统数仓到湖仓一体，历经三十多年倒退，技术的浪潮疾速迭代，以云原生数仓为核心的古代数据栈时代未然到来。 背地的外围的起因在于，企业正在减速走向数字化、智能化，对数据的利用也提出了全新要求，特地是对数据的实时剖析、实时部署需要更加的强烈，而云数据仓库为用户实现云原生、智能运维、弹性资源等业务需要也带来了很好的撑持，成为明天企业数字化基础设施中的要害“底座”。 本期内容次要邀请来自火山引擎的专家，分享云数仓畛域关键技术、倒退方向以及最佳实际，为宽广数据畛域从业者带来思考。 流动工夫：6 月 20 日 14:00-15:30 流动内容：演讲议题一：揭秘新一代云数仓技术架构与最佳实际演讲人：Aurora 火山引擎 ByteHouse 资深产品专家内容概要：从传统数仓、到湖仓一体再到云数仓，技术疾速迭代，云数仓曾经成为数字化基础设施中的要害“底座”。云数仓先进性在哪里？源于字节跳动外部的 ByteHouse 云数仓版本具备哪些外围亮点？本次分享将具体介绍： 云数仓演进倒退之路ByteHouse云数仓的整体架构、产品能力、技术特点外围特点拆解：如何实现存算拆散、性能冲破、动静扩容缩容、弹性伸缩等云数仓典型案例和利用场景演讲议题二：从「三个落地案例」分析字节跳动云数仓最佳实际演讲人：火山引擎解决方案专家 师辰内容概要：不同行业、企业的用户规模、剖析需要不同，对云数仓的性能、稳定性、安全性要求也不同。在理论利用场景中，一款云数仓产品如何能力更丝滑落地，并解决业务问题，本次分享将围绕以下几个方面开展： 介绍 ByteHouse 云数仓在广告、气象等行业的客户单干案例围绕案例业务背景、技术架构、外围个性、性能指标与收益等开展分享总结云数仓我的项目落地的教训和办法演讲议题三：开箱即用，五步疾速上手 ByteHouse 云数仓演讲人：Aurora 火山引擎 ByteHouse 资深产品专家内容概要： 以 ByteHouse 为代表，介绍如何疾速上手云数仓立刻报名：https://live.byteoc.com/7002/9954838

2023/06/11，09:00-12:30，在DataFunSummit 2023：OLAP引擎架构峰会上，由阿里云资深技术专家，实时数仓 Hologres 研发负责人姜伟华老师出品的云原生OLAP论坛讲邀请来自阿里云、亚马逊云科技、三七互娱、聚水潭、诺亚财产的5位嘉宾，就相干主题进入深度分享与交换，会议将全程直播，欢送大家收费扫码报名收看～ 出品人：姜伟华 阿里云智能资深技术专家，实时数仓Hologres研发负责人 集体介绍：姜伟华，复旦大学博士，阿里云资深技术专家，花名果贝，阿里云产品实时数仓Hologres研发负责人，超过10年大数据研发教训，开源社区贡献者，曾创建国内最早的大数据发行版，领导出名公司大数据我的项目开源，他率领的团队创建了2个Apache开源我的项目，涌现出超过10名Apache Committer。 王奇 阿里云 高级技术专家 集体介绍：王奇，阿里云智能高级技术专家，花名慧青，阿里云产品实时数仓 Hologres 研发，超过8年大数据研发教训，目前次要聚焦于 Hologres 分布式、弹性计算等相干工作。演讲题目：弹性计算在阿里云大数据 OLAP 上的实际与思考演讲提纲：介绍目前大数据 OLAP 遇到的剖析性能、资源隔离、高可用、弹性扩缩容等外围问题2. 解析阿里云 Hologres 是如何解决极致性能、弹性、业务永续、性价比等外围刚需的最佳实际分享阿里云 Hologres 弹性计算组在弹性计算、资源隔离上的摸索和翻新听众收益：大数据分析的几个阶段是什么大数据分析遇到的问题是什么大数据分析的外围刚需是什么如何解决这些大数据分析遇到的问题和外围刚需如何解决大数据分析的弹性问题徐玉立 三七互娱 数据架构师 集体介绍：长期从事大数据和数据利用的研发工作。曾主导某互联网金融企业实时风控平台的产品研发，具备丰盛的数据中台建设实践经验。现任三七互娱旗下子公司37手游的数据架构师，次要负责数据仓库和数据中台的建设工作，以及广告归因和广告投放等零碎的架构设计。演讲题目：37手游量子智能广告零碎基于云原生 OLAP 的利用实际演讲提纲：次要介绍37手游的业务背景及特点，量子零碎的介绍及外围业务流程、业务价值，量子零碎的技术架构的演进等，还介绍了37手游 OLAP 的实际以及37手游量子零碎的一些将来布局。具体内容包含：37手游的业务背景37手游量子智能投放零碎的实际37手游 OLAP 实际将来布局听众收益：理解37手游广告投放零碎的外围业务流程理解37手游量子零碎的实际过程理解37手游在云原生 OLAP 的实际过程杨探 亚马逊云科技 解决方案架构师 集体介绍：亚马逊云科技解决方案架构师，负责互联网行业云端架构征询和设计。曾就任于 NTTDATA，服务国内、海内日企客户。演讲题目：专门构建的云原生数据仓库 Amazon Redshift演讲提纲：初识 Amazon RedshiftAmazon Redshift 之联邦查问Amazon Redshift 之 SpectrumAmazon Redshift 之机器学习听众收益：深刻理解 Amazon Redshift 架构深刻理解 Amazon Redshift 如何与其余亚马逊云科技服务集成，让客户轻松构建云上湖仓李月/鄢文斌 聚水潭 高级大数据开发专家/资深大数据开发工程师 集体介绍：李月，十年数据库、大数据开发和技术架构教训，14年-21年阿里云工作经验，参加了淘宝单元化、团体上云、国内业务全球化等要害业务倒退，21年退出聚水潭，主导数仓架构降级，商业化产品研发体系的搭建工作。 鄢文斌，19年硕士毕业始终从事数据开发，目前在聚水潭次要负责数据产品的开发工作。 演讲题目：聚水潭云原生 OLAP 架构的最佳实际演讲提纲：聚水潭数仓的构建之路数据智能产品介绍物流实时预警最佳实际云原生数仓的将来冀望听众收益：对于批发行业 Saas ERP 服务的有体系化意识对于批发电商场景商家工作流、业务痛点、数据智能产品价值有清晰的了解基于阿里云 OLAP 在线服务+实时剖析一体化云原生数仓的了解和思考李欣 诺亚财产 数据仓库总监 ...

5月27日至28日，寰球开源技术峰会GOTC 2023在上海张江迷信会堂胜利举办。作为面向寰球开发者的开源技术盛宴，大会以“Open Source, Into the Future”为主题，会集了诸多专家学者和产业代表，独特探讨开源将来，助力开源倒退。本次GOTC峰会也邀请了Linux基金会执行董事、LF AI & Data 基金会执行董事，CNCF中国区总监、来百度、华为、腾讯、火山引擎、红帽、Intel、VMWare、F5、微软、开源中国等企业的寰球开源重磅嘉宾缺席。 Sermant作为新锐开源我的项目，也在此次GOTC大会中亮相，并参加了流动展台、快闪演讲等流动，吸引泛滥开发者深刻理解Sermant的无代理微服务框架的非侵入、高性能、插件化的外围劣势，并对摸索实际和落地体现出极大趣味。 快闪演讲本次GOTC大会Sermant作为受邀请我的项目参加了快闪演讲流动，社区Committer李来在现场发表了题为《云原生微服务治理技术朝无代理架构的演进之路》的主题演讲，清晰的梳理微服务架构从SOA到SDK再到Service Mesh的演进历程，以及各阶段所遇到的问题，并且介绍了Sermant如何以非侵入、高性能、插件化的形式解决云原生时代的微服务治理问题。 （Sermant快闪演讲海报） Sermant快闪演讲视频已公布至Sermant哔哩哔哩官网账号，点击上面链接即可观看：https://www.bilibili.com/video/BV1Gh4y1Z7eN/ 流动展台Sermant在GOTC华为的展区中也安顿了互动展台，泛滥开发者在Sermant展台围观，对Sermant一键接入、零代码革新老本的应用形式体现出极大的趣味，并对Sermant推动架构演进的Demo示意高度的认可。很多政企畛域的开发者也和咱们一起探讨了Sermant在架构摸索、落地实际方面的可能性。 （给开发者深刻解说Sermant的架构和Demo演示）Sermant展台宣传视频也已公布至Sermant哔哩哔哩官网账号，点击上面链接即可观看：https://www.bilibili.com/video/BV1Uu411s7gf/ 云原生无代理服务网格SermantSermant是基于JavaAgent云原生无代理服务网格，利用字节码加强为宿主应用程序提供插件化的服务治理性能，解决了SOA架构治理能力难以扩大、微服务SDK架构的侵入性问题和跨部门降级推动难、Service Mesh架构的跨过程的性能问题。它的次要特点如下：l 非侵入：相比SDK，Sermant以JavaAgent形式挂载到指标微服务过程，业务代码0批改即可接入Sermant提供的服务治理能力。l 高性能：相比sidecar，Sermant无需占用独自过程，防止跨过程通信，绝对于Envoy资源损耗和时延升高80%l 插件化：Sermant在插件和插件之间、插件和业务代码之间做到类隔离，不仅使得服务治理能力失去解耦，也从本源上防止和业务利用产生类抵触。（Sermant整体架构模型） Sermant通过JavaAgent在微服务实例运行时进行加强，运行时可通过动静配置核心下发配置，进行服务治理规定的变更，实现标签路由、负载平衡等动静治理。配套的Backend服务能够将Sermant收集的服务治理事件和运行时异样事件进行上报，实现服务治理的可观测性。 以后Sermant曾经提供了限流降级、全链路灰度公布、优雅高低线等插件能力，基于类隔离机制，不仅使得各项治理能力失去解耦，也使得Sermant和业务利用不会产生类抵触。 （Sermant的插件化架构） 结束语Sermant作为专一于服务治理畛域的字节码加强框架，致力于提供高性能、可扩大、易接入的服务治理体验，并会在每个版本中做好性能、性能、体验的看护，宽泛欢送大家的退出。

随着人工智能、云计算、大数据等技术的倒退突飞猛进 ，各种数字技术曾经成为翻新的支柱。底层技术的倒退与行业之间的碰撞，正在成为颠覆性改革的巨大力量。一些数字先行者，正在通过云原生技术实现全面的翻新。数字化转型不是把技术武装到牙齿，而是把技术融入企业的基因。云原生是阿里云的 DNA，置信在阿里云云原生的助推下，越来越多的企业将实现业务“生于云，长于云”，全面迈向数字化新阶段。更多行业案例，点击《云原生架构：容器&微服务案例集》下载。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1203284?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

微服务和音讯队列都是以后比拟风行的架构模式，能够帮忙开发者在理论业务中解决大型简单分布式系统面临的各种挑战：微服务架构是一种云原生架构办法，目标是进步零碎的扩展性、可靠性和灵活性，它提倡将繁多的应用程序划分成一组小的服务，服务之间相互协调、互相配合，每个服务运行在其独立的过程中，服务与服务之间采纳轻量级的通信机制相互沟通，每个服务都领有本人的代码库、数据存储和运行环境，能够独立开发、测试、部署和运行。这种架构模式能够让团队更快地迭代、更快地部署新性能，同时还能更容易地扩大和保护零碎。然而，微服务架构也面临一些挑战，如服务之间的通信和数据一致性等问题，为了解决这些问题，通常应用音讯队列等工具来协调服务之间的通信和数据交换。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1199610?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

咱们非常高兴地发表，Dubbo 3.2 曾经正式公布了！这个版本带来了许多新性能和改良，这也是 Dubbo 在面对云原生化的当下的一次重要的尝试。 背景介绍Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官网提供了 Java、Golang 等多语言 SDK 实现。应用 Dubbo 开发的微服务原生具备相互之间的近程地址发现与通信能力， 利用 Dubbo 提供的丰盛服务治理个性，能够实现诸如服务发现、负载平衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩大，用户能够不便的实现流量拦挡、选址的各种定制逻辑。 01 Rest 协定反对1.1 Why Rest？随着挪动互联网的遍及，越来越多的应用程序须要与不同的零碎进行集成。而这些零碎可能应用不同的通信协议，这就须要应用程序可能灵便地适应各种协定。Rest 协定正是一种非常灵活的协定，它应用 HTTP 进行通信，能够与简直任何零碎进行集成。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1197822?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

是什么（What）Claude 是最近新凋谢的一款 AI 聊天机器人，是世界上最大的语言模型之一，比之前的一些模型如 GPT-3 要弱小得多，因而 Claude 被认为是 ChatGPT 最无力的竞争对手。Claude 的研发公司是专一人工智能平安和钻研的初创公司 Anthropic，由前 OpenAI 员工独特创建的。往年 3 月份 Anthropic 取得了谷歌 3 亿美元的投资，谷歌也因而取得其 10% 股份。两个小时（蕴含前后端）写进去的Demo：https://ud1wof-mj-web.oss.laf.dev/claude.html 为什么（Why）据官网介绍，Claude 的外围模型经由训练，指标是变得有用、诚恳和有害。此外 Claude 更能了解和承受自然语言，和它对话无需简单的技巧，能够轻松失去具体且易于了解的答案。 与 ChatGPT 等大型语言模型一样，Claude 的利用场景十分宽泛，信息搜寻、内容总结摘要、写作帮助、创意生成、问答、编程这些工作它都能轻松实现。目前 Claude 曾经被利用在多个出名产品中，比方常识笔记工具 Notio AI 就是用 Claude 帮助用户进行智能写作，国外问答社区 Quora 也在本人的 AI 聊天应用程序 Poe 中置入了 Claude。 重点：Claude是收费的，至多目前是这样 怎么做（How）目前Claude 曾经被置入一款团队合作沟通利用 Slack 中，目前能够收费应用。但咱们明天的重点是教大家如何在本人应用程序中接入Claude。 第一步：注册Slackslack官网地址：点我跳转注册时尽量抉择应用google的gmail邮箱，后续操作的成功率高。不要应用qq等国产邮箱。 第二步：创立工作区工作区是一个独立的合作环境,每个工作区有本人的渠道(Channels)、成员、权限设置等。不同工作区之间彼此隔离,成员和资源不共享。至此，工作区就创立好了 第三步：增加Claude利用到工作区（这一步须要魔法）点击Slack-Claude 官网网址（请自备梯子）这个链接还能够通过以下操作找到：受权增加Claude到Slack呈现以上界面，阐明以后ip被封闭了。请自行切换节点，尝试应用全局代理，切换无痕浏览等办法。换了个浏览器，果然好了。点击容许，呈现Success就胜利了 第四步：开明高级性能回到工作区页面，左侧会主动呈现Claude利用，此时聊天会发现Claude是不会回复任何音讯的。解决方案：点击左侧Slack Connect，没有这个选项的话，就点击浏览Slack，在下拉框里找到Slack Connect社区小伙伴的经验通知我，这个中央有的账户没有收费试用的机会，但我创立了几个工作区了，都能够收费试用，可能是因为试用的gmail邮箱吧。没有就从新注册新账号，或新建工作区走流程尝试，有钱就无所谓。所以后面注册时会让你尽量应用gmail邮箱。当初左侧会呈现方才新建的频道而后咱们为这个频道增加Claude利用进入刚建的频道，激活高级性能当初就能够欢快的和Claude聊天啦你认为到这里就完了？如果你仅仅想体验Claude和利用它为你提供一些帮忙，那的确到这里就完了。 第五步：接入Api那么怎么接入呢？都晓得 Claude 临时还没凋谢 API 的测试，不过还是有方法接入 Claude 的。0、开发咱们应用 Laf 提供的云函数接入api，开发速度更快。2023年了，如果你还不晓得Laf，那我只能再讲一遍了 Laf 是一个 Serverless 框架，提供开箱即用的云函数，云数据库，对象存储等能力，是一个十分洁净清新的开发平台，不仅入门简略，还能像写博客一样写代码！life is short, you need laf:)地址：中国区：https://laf.run海外版：https://laf.dev创立云函数 ...

PostgreSQL 始终被誉为寰球最先进的开源关系数据库之一，在 DB-engines 排行榜上长期稳居前五。5 月 25 日，PostgreSQL 寰球开发团队官网发表，PostgreSQL 16 Beta 1 版本正式公布。 本次 PostgreSQL 新版本性能亮点泛滥，波及多个模块，包含查问执行的性能改良、逻辑复制加强、平安个性加强、监控与治理个性等。随着这一里程碑式的公布， PostgreSQL 将为寰球用户带来更多卓越的性能和翻新式的改良。  作为一款开源数据库，PostgreSQL 的胜利得益于寰球开发者社区的开发奉献。本次新版本公布的个性中，多处均可看见 OpenPie 工程师的身影。无论是在代码数量还是品质上，OpenPie 在中国代码奉献中起到了引领作用，成为国内推动 PostgreSQL 技术创新的要害力量。  OpenPie 始终沉闷在 PostgreSQL 国内外社区，以代码奉献、讲师步道、技术内容等多种形式积极参与社区奉献。在代码奉献方面，多名研发共事参加了 PostgreSQL 11、 12、13、14、15 版本的奉献。特地值得自豪的是，在最新公布的 PostgreSQL 16 版本中，仅 OpenPie 内核工程师 Richard Guo 一人就奉献了 83 次 commit。  更令人自豪的是，在新版本公布的优化器模块的 6 个新个性中，Richard 作为主 author，主导了其中 2 个重要个性：  容许在 Union All 上应用 Memorize容许非空输出端作为内表来执行反连贯（anti-joins)  Release note: https://www.postgresql.org/docs/16/release-16.html 依据 2021 年 PostgreSQL 现状考察数据显示，85% 的受访者从未为 PostgreSQL 代码库、文档或提交做过奉献，只有 4% 的受访者曾奉献过几次。OpenPie 研发团队这一突出成绩充沛展现了 OpenPie 拥抱凋谢、追赶翻新的外围文化理念，也得益于研发团队的雄厚实力和对技术的深刻理解。  ...

中国头部游戏公司莉莉丝游戏（Lilith）和火山引擎 ByteHouse 达成单干，独特致力于减速莉莉丝游戏的实时数仓建设。此次单干将利用 ByteHouse 的翻新技术和性能，为广告经营剖析业务提效提供全面反对和帮忙。 莉莉丝游戏是中国中生代游戏公司代表，在中国游戏市场放弃领先地位。为了反对其日益增长的业务需要，莉莉丝游戏在国内宽泛应用 ClickHouse 进行广告投放和经营剖析业务，并在海内业务中搭建了开源 ClickHouse 集群来反对广告经营剖析。然而，这些应用过程中遇到了一些挑战，包含跨月跨季查问超时、OOM、不反对大表关联以及从 MySQL 数据实时同步稳定性差等问题。因而，莉莉丝游戏心愿通过调研 ByteHouse 的产品性能和性能，摸索单干机会以解决这些痛点。 ByteHouse 作为火山引擎的外围云数仓产品，具备多项弱小性能，为莉莉丝游戏的实时数仓建设提供了全面的反对。首先，ByteHouse 的 MaterializedMySQL 性能能够实时将莉莉丝游戏的 MySQL 或 PolarDB MySQL 中的业务数据整库实时同步到 ByteHouse 平台。该性能提供了可视化的管理工具，并减少了便捷的异样运维解决性能，实现了一键同步和稳固运行的指标。这大大降低了数据同步老本和运维工作量，为莉莉丝游戏提供了高效的数据同步链路。特地是 ByteHouse 特有的 HaUniqueMergeTree 表引擎反对实时的表级/分区级惟一键更新、局部列更新、实时删除等性能，让利用能简略地解决实时数据去重和更新问题。 其次，ByteHouse 自研的查问优化器解决了开源 ClickHouse 不反对简单查问能力的问题。该优化器反对 RBO、CBO、分布式打算优化，并实现了诸如 Dynamic Filter pushdown、物化视图改写和基于代价的 CTE 等高阶优化能力。通过这些能力优化，ByteHouse 可能胜利运行 TPC-DS 测试集的全副 99 个 SQL 用例，并在性能上大幅晋升。在理论环境中，ByteHouse 帮忙莉莉丝游戏广告业务简单查问剖析场景中性能晋升 3 倍以上，反对查问时间跨度从 1 个月晋升至 1 年以上，帮忙其笼罩更多剖析业务场景，放慢决策和优化业务经营。 此外，ByteHouse 还提供了可视化运维性能，针对 ClickHouse 运维复杂度高的问题，提供了集群治理、监控告警、衰弱度评估、权限治理、参数配置、数据管理、界面化扩容等一系列可视化性能。这大大降低了运维老本，为莉莉丝游戏提供了更便捷和高效的运维体验。 通过与 ByteHouse 的单干，莉莉丝游戏将基于该平台构建广告经营剖析平台外围 OLAP 引擎。这将使莉莉丝游戏可能实时处理海量投放数据和日志数据，并进行高性能计算。通过实时统计和归因剖析广告投放全链路数据，莉莉丝游戏可能实时调整广告投放策略，晋升买量成果。同时，通过细粒度的老本和成果剖析，莉莉丝游戏可能反对研发、经营、发行等团队进行精细化经营和治理，更好地理解市场需求，增强合作效率和透明度。此外，莉莉丝游戏还应用了 ByteHouse 来反对人群包的性能，在海量数据场景下能疾速筛选出合乎特定条件的用户，实现广告精准定向投放。 本次单干将为莉莉丝游戏提供弱小的数据能力反对，助力其在游戏行业中放弃竞争劣势。单方将共同努力，推动实时数仓建设的倒退，为广告经营剖析等业务畛域带来更高效和翻新的解决方案。 对于莉莉丝游戏（Lilith）莉莉丝游戏成立于 2013 年，总部位于中国上海，是一家集游戏研发和寰球发行于一体的出名游戏公司。莉莉丝游戏致力于打造优质游戏内容，一直推动游戏行业的翻新与倒退。目前，莉莉丝游戏在寰球范畴内领有泛滥滞销游戏产品，并踊跃拓展海内市场。 ...

“十四五”布局提出“放慢数字化倒退，建设数字中国”，在数字经济的大潮下，随同着金融供应侧结构性改革继续深入，银行业数字化转型步调逐渐减速。银行业的数字化转型，不仅是本身适应数字经济时代倒退的必由之路，更是服务实体经济高质量倒退、促成各行各业减速驶入数字化快车道的关键所在。神州云科致力于成为当先的国产数字化生态厂商，通过双轨超高可用架构、容翼系列和云科透明湖信创系列两大利用交付控制器产品，助力银行打造不凡的数字体验，促成银行业务高质量倒退。 自主翻新，超高可用 金融科技曾经成为金融行业倒退的外围驱动力。在银行数字化转型的过程中，利用交付成为了驱动银行业务稳固牢靠、平安可信、提速增效、麻利迭代的重要赋能工具。 （双轨超高可用架构及五大引擎） 为助力银行业务高质量倒退，更好地应答数字经济时代对可持续性的高要求，实现“信创”与“数字化”齐头并进，神州云科创新性的推出了双轨超高可用架构。该架构在双活数据中心的分区调度根底上，减少信创域和非信创域的分域调度，履行信创域与传统域利用全量部署，使双核心经营变为双核心四区域并行运行，互为多活，将“0到1”的单轨建设路线变为分辨别域协同的多活双轨超高可用架构。帮忙客户在新架构下，保障“信创”的同时解决性能瓶颈，晋升稳定性，保障利用可持续性，最终实现信创区域和非信创区域的平滑过渡，实现国产化代替指标。 两大产品系列助力银行数字化高质量倒退 为了更好的适配双轨超高可用架构，神州云科研发了容翼系列和云科透明湖信创系列两大利用交付控制器产品。 云科容翼和云科透明湖信创系列产品 神州云科利用交付控制器云科透明湖信创系列齐全自主研发，领有比肩世界一流产品的水准，凭借全国产、高性能、平安可控、高效能设计、扩展性设计等五大劣势，可满足银行信创需要。 神州云科利用交付控制器容翼系列采纳全新设计的 API 优先理念和容器底座，硬件架构采纳技术先进的 FPGA 芯片和最新英特尔 CPU 处理器交融的全新架构，能够提供200G超强性能，满足企业对超高性能和超高平安的利用交付需要。 神州云科多年来深耕利用交付畛域，在市场份额方面，据IDC《2022年Q4利用交付市场跟踪报告》显示，神州云科利用交付控制器产品营收增长率130%，排名第一，成为国内增长最快的利用交付厂商。同时，神州云科自主研发的云科负载平衡管理系统胜利通过人民银行金融信创生态实验室适配验证，成为国内首家在利用交付测试中通过测试的供应商，标记着神州云科在金融信创畛域的技术实力和业余程度再获权威认可。 历经多年的倒退与积淀，神州云科通过丰盛的产品矩阵，优质的服务体系，联结上下游合作伙伴构建数字化解决方案新生态。将来，神州云科将持续加大研发投入，继续打磨利用交付技术和产品，为银行数字化的高质量倒退保驾护航！

5 月 18 日，腾讯云举办了 Techo Day 腾讯技术开放日，以「开箱吧！腾讯云」为栏目，对外公布和降级了腾讯自研的一系列云原生产品和工具。其中，腾讯云开发者产品核心总经理刘毅围绕“开发麻利高效”这一话题，分享了对于“云原生利用开发与运维新范式”的主题演讲。本次演讲将为大家分享，腾讯云是如何通过云上开发运维合作能力，反对多职能团队晦涩合作，助力企业减速数字化麻利转型，晋升云原生架构的运维效率，受害云原生。 刘毅——腾讯云 CODING CEO、腾讯云开发者产品总经理。次要负责腾讯云开发者生态以及开发者工具和平台产品经营，率领团队把腾讯外部我的项目协同和研发效力晋升过程中，大规模利用到的工具和平台以及相干的优良实际输入和赋能给各行各业合作伙伴，帮忙实现数字化转型和降级。2011 年退出腾讯，打造过社交产品 QQ 空间，也打造过办公合作产品腾讯文档。云原生开发与运维畛域的新趋势现在，在 VUCA（Volatility易变性、Uncertainty 不确定性、Complexity 复杂性、Ambiguity模糊性）环境下，每个企业都在探讨如何晋升本人的外围竞争力，这也是近年来始终备受关注的话题。在寻找这个问题答案的过程中，腾讯云发现，**深入研发合作、研运一体的外围能力，打造高效、疾速的开发和运维新范式，可能为企业在数字化及云原生转型过程中继续赋能。**通过多年来对云原生开发与运维畛域的察看与思考，腾讯云得出 3 个要害，别离是： 开发云原生层面，出现“资源服务化”趋势；业务观测层面，需具备“数据和观测一体化”能力；利用观测与协同排障联合，“合作能力进一步晋升”。开发云原生呈「资源服务化」趋势随着云原生技术逐渐倒退为规模化实际，业界对于云原生的将来有了较为清晰的认知。除了具备初代的云原生 DevOps、容器、微服务这些必要元素外，进一步渗透到寻求资源配置和利用治理提效的最优解。 腾讯云对云原生具备残缺的布局，笼罩基础设施、平安、计算、架构、数据等多个方面，其中开发云原生是腾讯云原生布局的重要一环。 首先，将来利用将“ 生于云、长于云”，开发云原生也会出现“资源服务化” 特色。这意味着将来的资源管理和调度将变得更加高效，开发者能够从本地编码、离线交付、以及低效的资源管控中解放出来，在云端实现编码调试和利用部署，更大限度施展云原生技术红利。 业务对立可观测层面需具备“数据和观测一体化”能力其次，随着云原生的遍及，业务复杂度也逐步晋升，传统的监控模式，数据扩散不联通，不同业务层的监控也多是通过不同产品和工具实现。故监控到业务异样产生时，数据之间的下钻、联动剖析效率低。 通过以业务为外围，将多种数据源汇合在对立平台，笼罩指标、链路、日志、事件全数据类型，构建对立的数据采集、解决、观测平台，再配合一体化的故障预测、故障告警、故障定位工具，构建这样一个全链路、端到端的数据和观测的一体化平台，能够帮忙大幅晋升运维效率，从被动监控转为被动观测。 监管控一体化”持续演进系统可靠性和稳定性是企业竞争力的基石。一旦产生故障，须要迅速拉起多个职能角色参加其中，第一工夫多方协同定位问题、复原利用、解决问题。 在该过程中，排障人员会感触到观测工具和工程信息之间的割裂、上下文对齐异步、近程合作难同频的问题，排障效率仍有较大晋升空间。 通过买通代码数据、工程数据和观测数据，提供故障信息对齐能力，加强多人线上协同排障场景，进一步晋升运维合作能力，演进 DevOps 闭环，能力落到实处地帮忙业务侧及时高效应对排障，保证系统可用性。 客户面临的严厉挑战腾讯云成立以来多年，继续深耕云计算畛域并以卓越的技术能力服务数百万开发者，积攒了大量企业数字化治理教训，在实践中总结出客户在云原生利用开发和运维时广泛遇到的一些痛点，进一步映射了上述“趋势”观点: 开发调试到部署效率低，包含开发环境难以对立且反复配置、本地资源隔离弱且不稳固、继续构建与部署因环境管控简单、效率有待晋升。数据扩散问题定位低效，云原生架构简单，业务的指标、链路、日志等数据扩散，同时前后端存在孤岛问题，无奈对立观测业务架构，当异样产生时，须要多零碎、多数据调度以反对排障，影响运维效率。异步多人排障信息难对齐，故障时多可用区、多时段告警信息、监控日志、操作、反馈等无效诊断信息扩散在各个时段，且扩散在各个排障人手上。排障专家相互之间无奈疾速共享和对齐排障上下文。预先复盘时也难以回溯故障解决的过程信息。近程协同效率低，近程多职能协同排障存在资源权限、业务知识、工具和技术熟练度的差别。每个角色只把握链路中的局部信息或工具。因而排障时产生不同角色间信息无奈不便共享共识，导致排障效率升高。腾讯云观点观点一：“资源服务化”针对上述痛点，腾讯云首先思考的是开发调试与继续交付过程中实现“资源服务化”，为研发资源挑战提供解法。 于是咱们有了云原生开发的云端开发+环境托管的概念雏形，提供基于服务的云上开发环境 （Cloud Development Enviroment），使得通过云端进行开发、编译与调试，解决传统开发资源管理难题，进一步推动开发云原生落地。 在资源服务化机制中，开发同学们能够各自开发本人的模块，互不烦扰。必要时，他们之间又能够施行互相调用、甚至断点联调。 该流程在微服务场景能促使开发者左移联调，每个微服务能够疾速启动对应的云端开发环境，云端构建、云端部署，通过流量调度计划，疾速预览开发成果。开发集群还提供主动休眠等措施，进行老本管制。 观点二：“数据和观测一体化”针对传统监控体系中的若干问题，咱们举荐建设和应用“数据和观测一体化”可观测平台，并提供云上实际。 一体化的可观测平台将多起源、多类型的监控数据对立接入，依靠弱小的DSL、实时/关联剖析等能力进行数据处理，最终依靠通用能力组件对不同用户角色提供整合展现、多维分析、预警告诉及AIOPS能力。 从而解决因监控和告警数据扩散、短少全局视角所导致的监控规模扩大难、规范化治理难、关联剖析和排障定位慢等问题。 观点三：“监管控一体化”可观测能力联合 DevOps，咱们认为“利用治理”能够与“利用可观测”深度联合，建设以利用为核心、以业务为视角的对立观测平台。 在 DevOps 的上游环节，提供涵盖针对利用的日常问题发现/定位/解决的外围能力，接入利用可观测能力如监控告警、链路追踪以及日志追踪，从利用视角突破各APM类工具间的信息屏障，将本来零散的信息建设关联、抹平不同环境之间的工具差别，建设以利用为核心、服务研发视角的一体化观测能力。 同时，基于一体化可观测能力，对立各类观测数据规范，实现可观测工具的可插拔性以及可扩展性，用户也能够进行自定义扩大。在此之上，创新性联合腾讯会议的实时共识属性，降级运维排障协同伎俩，将 DevOps 深度演进闭环。 重磅新品发 一站式云上开发运维合作平台作为国内当先的云平台，腾讯云始终保持以客户为导向，不断创新和打磨贴近用户思考的产品和服务体验。现如今正式对外界推出一站式云上开发运维合作平台，反对多职能团队在同一平台上晦涩便捷地合作，“高效、疾速，打造新一代云原生利用开发与运维的新范式”。 一站式云上开发运维合作平台产品劣势能够概括为以下三点： 开发资源托管：可在线集群调试、一键拉取仓库并加载云端开发环境、动静资源调配、便捷灵便联调。利用观测：多协定监控、全产品笼罩、态势告警、无侵入式业务数据采集上报、全数据维度展现。近程协同排障：一键拉起干系人同屏会议，抹平信息割裂与组织异步，线上聚焦协同排障、定位、以及修复上线。 该范式旨在笼罩云上从利用开发到利用运维的全生命周期。简略来说，用户可通过云端开发环境 Cloud Studio 进行多人编码协同，在线调试与服务部署；也可将代码推送到一站式研发效力治理平台 CODING DevOps 以实现继续交付的一系列工作。 ...

本文转自公众号：OpenAnolis 龙蜥 近日，杭州拓数派科技倒退有限公司（以下简称 “拓数派”，又称 “OpenPie”）正式签订 CLA 贡献者许可协定，退出龙蜥社区（OpenAnolis）。 拓数派是立足于国内根底数据计算畛域的高科技翻新驱动企业。作为国内该畛域比比皆是的 Day-1 准独角兽，致力于在数字原生时代，使用突破性计算实践、独创的云原生数据库旗舰产品以及之上的算法和数学模型，建设下一代云原生数据平台的前沿规范，驱动企业实现从 “软件公司” 到 “数据公司” 再到 “数学公司” 的继续进阶，减速数字化转型降级。 拓数派旗下旗舰产品 PieCloudDB，采纳当先的数仓虚拟化技术，买通多云的数据管道，数据计算资源按需扩缩容，晋升数仓的敏捷性和弹性，助力企业升高数仓治理复杂度。PieCloudDB 在实现数量级减少可计算数据空间的同时，数量级升高数仓老本，关上有限数据计算空间，推动 AI/BI 到下一个精度；在 eMPP 分布式专利技术、服务器无感知（Serverless) 及 TDE（通明数据加密）等多项核心技术加持下，为企业构建高平安，高牢靠，高在线「坚如磐石」的云原生虚构数仓，助力企业实现数据价值最大化，更好地赋能业务倒退并走向绿色，成为新一代 AI 数据计算基础设施的一个榜样。目前，PieCloudDB 在金融、医疗、汽车及制作等行业积攒了一批种子用户，产品备受业界及用户的高度关注及认可。 拓数派 COO 陆公瑜示意：“拓数派始终持‘凋谢互信，单干共赢’的理念，踊跃打造丰盛的社区生态。将来，咱们将携手龙蜥社区，给用户带来数据库畛域最前沿的技术，满足用户多样化的数据分析需要，努力实现以‘数据计算’赋能百业，独特为客户发明价值！” 龙蜥社区理事韩磊示意：“拓数派从成立至今倒退十分迅速，其产品 PieCloudDB 可能帮忙用户进步数仓的敏捷性和弹性，实现数量级数量级升高数仓老本。置信拓数派与龙蜥社区携手可能在数字时代助力更多企业进步数据价值，减速企业数字化转型降级。 现在，拓数派已与麒麟软件、统信软件、龙蜥社区、中科可控、兆芯、海光、博云科技等根底软件厂商实现了兼容性互认证测试。拓数派致力于继续欠缺生态搭档网络，与各畛域的厂商进行交换和单干，独特推动数据库技术的倒退，构建凋谢、共享、可继续的数据库生态。    

公司介绍Soul 是基于趣味图谱和游戏化玩法的产品设计，属于新一代年轻人的虚构社交网络。成立于2016年，Soul 致力于打造一个“年轻人的社交元宇宙”，最终愿景是“让天下没有孤单的人”。在 Soul，用户能够无顾虑地表白本人，认知别人，摸索世界，交换趣味和观点，取得精力共鸣和认同感，在交换中获取信息，并取得有品质的新关系。 问题与挑战 2.1 多层网关链路长Soul在 2020 年开始逐步试探容器服务，在 ECS 转型容器阶段，呈现了容器入口网关(Ingress-Nginx)，微服务网关，加上对立接入层的 SLB+Tengine；造成了多重网关的架构；链路太长不仅带来老本和 RT 的问题，而且导致排查一个申请异样，须要拉十分多的人解决，定位问题代价十分大。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1170454?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

云原生下的服务治理在云原生技术的演进过程中，依靠云原生技术能力，造成一个能够向下治理基础设施，向上治理业务利用的技术中台，越来越成为企业冀望的云原生技术落地趋势。随着云原生技术中台 CNStack 公布具备变革意义的新一代 2.0 版本，其提供的云原生技术能力不仅能够撑持大规模业务零碎，也能够将外部不对立的体系集中管理起来，通过中台化的形式输入云原生技术能力。通过 CNStack 能够低成本实现业务利用的云原生革新，并且 CNStack 云原生平台能够为接入的利用提供业务监控、流量治理、服务凋谢等多种能力。 深刻到微服务体系中，CNStack 平台为简单的微服务架构零碎提供了多方面的服务治理与可视化监控能力，其中通过配合可视化数据监控与限流降级能力，运维人员能够确保业务零碎不论是在失常运行时、公布变更过程中、还是流量猛增的状态下，都能够安稳对外提供服务。诸如常见的线上突发流量导致服务流量超过承载能力、服务上游依赖呈现不可用导致影响本身服务稳定性等场景，CNStack 提供了全方位的流量防护能力，以流量与容错为切入点，从流量管制、不稳固调用隔离、熔断降级、热点流量防护、零碎过载爱护等多个维度来帮忙保障服务和网关的稳定性，同时提供秒级的流量监控剖析性能。 疾速玩转流量防护一键接入防护能力CNStack 平台提供了十分便捷敌对的利用接入形式，通过工作空间下的利用治理能力能够疾速创立利用，并且通过利用治理接入的利用均会默认主动接入流量防护能力，能够为利用疾速全方位配置流量防护。抉择 Java 类型创立的托管利用，会通过挂载探针的形式接入流量防护能力，不须要对业务代码进行任何埋点革新，对业务利用无侵入。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1182769?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

北京工夫 1 月 30 号公布的 OpenYurt v1.2.0 版本，社区呼声最高的几大个性终于落地，OpenYurt 的特点更加显明，次要特点包含：Kubernetes 无侵入，云边端全协同，可编程的资源访问控制，以及申明式云原生设施治理。 v1.2 版本聚焦在节点池治理，重点打造 OpenYurt 零碎的差异化技术竞争力，次要个性有升高云边通信的流量老本，边缘自治能力加强，更丝滑的跨地区通信能力等。 大幅升高云边通信流量老本在云边协同场景下，边缘通过公网和云端连贯，当集群中部署了大量的业务 Pod 和微服务零碎(引入大量 Service 和 Endpointslices)，边缘节点和云端之间须要耗费大量带宽，给用户带来极大的公网流量老本压力。 社区对升高云边通信流量始终有比拟强的诉求，如何在不侵入批改 Kubernetes 的根底上满足需要，首先大家比拟容易思考到的计划是在节点池内减少一个 sync 组件，实时同步云端的数据，而后再分发给节点池中的各个组件。然而这个计划落地将面临不小的挑战，首先数据拜访申请都是边缘被动向云端发动的，sync 如何拦挡这些申请并散发数据呢？同时如果 sync 组件故障，边缘的申请将面临中断，而保障 sync 组件的高可用会十分辣手。 OpenYurt 社区独创基于 pool-coordinator+YurtHub 的云边流量复用机制，既与原生 Kubernetes 的云边通信链路无缝交融，又优雅的保障了通信链路的高可用(YurtHub Leader 选举)，实现云边通信老本的消减。 在节点池内，节点从云端获取的数据，能够分为两种类型： pool scope data:  组件从云端获取的数据完全一致，如每个节点的 kube-proxy 获取到的 endpointslicesnode scope data: 组件从云端获取的数据和本身节点相干，如每个节点的 kubelet 获取到的 pods同时通过测试[1]发现，真正占用云边带宽的数据是 pool scope data。OpenYurt v1.2 中通过在节点池中复用 pool scope data，从而大幅升高云边的数据通信量。如下图： 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1162895?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

TCL 工程师团队基于阿里云企业云原生 IT 老本治理计划积淀了一套成熟的 IT 企业老本治理流程与零碎，通过阿里云容器服务提供的开箱即用的老本洞察、资源智能画像等性能，进行业务老本拆分、闲置资源可视化发现，并制订弹性伸缩与混部等优化策略，为团体优化了 10% 闲置的资源， 各类业务升高了 30% 的配额， 每年节俭近百万的 IT 老本投入。 客户简介TCL 创建于 1981 年，总部设于中国广东省惠州市，目前已造成 TCL 实业和 TCL 科技两大主体，布局智能终端、半导体显示、新能源光伏三大外围产业，成长为一家具备寰球竞争力的智能科技产业团体。TCL 目前领有 13 万名员工，在寰球布局 43 个研发核心和 32 个制作基地，业务遍布 160 多个国家和地区，寰球累计服务用户超 9.6 亿。 客户痛点整体资源利用率较低，老本洞察粒度有余，无奈驱动策略优化。在晚期上云的过程中，TCL 通过给不同的事业部调配独立云账号的形式，实现老本单元的布局与核算。然而当工程师团队心愿去洞察整体的资源应用、节约状况的时候，单纯从服务器等云资源的利用率状况来掂量业务的容量布局节约状况是不够正当的。因为从单个业务的视角，容量布局须要依据业务的峰值状况来布局。 业务高速倒退，传统容量布局的周期无奈满足， 影响业务应用。TCL 上云的过程经验了上云迁徙期、业务增长期、业务稳定期等多个阶段，在上云迁徙期和业务增长期中，发现传统依照月度、 季度甚至是年度的 IT 老本治理的周期，无奈跟上业务增长的速度，造成很多业务处于无资源可用 或者超预算应用的状况。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1170424?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

在云原生的环境下 守护容器平安，就好比守护一架飞机远航 除了对根底行李、乘客的查看 还须要确保飞行器、航线等的平安 程序不停，监测一直！ 在这些难题背后 很多传统平安厂商 要么防护伎俩旧调重弹，顾头不顾尾 要么是侵入式部署，“体型”太重，容器扛不动 威逼没防住，零碎先歇菜了 换句话说，游览淡季客流量大 靠自觉减少安保人员来进步安全性 那安保人员的冗余只能带来交通滞后 传统平安厂商在向云原生防护聚拢时 只思考到了在运行时进行容器防护 然而在左移开发阶段 开发人员便会引入 dockerfile、yaml等编排文件和镜像等资产对象 新引入的对象会产生新的威逼危险 这便是传统防护模式无奈笼罩的左移阶段 其实把♾️️拉平，无非蕴含四个阶段： Dev：平安开发阶段、平安测试阶段 Ops：平安治理阶段、平安经营阶段 下药肯定要对症 云原生的问题要用云原生的法子来解决 具备云原生基因的牧云（CloudWalker）在此时杀出重围 牧云（CloudWalker）云原生平安平台的 重要产品能力贯通DevOps始终 首推双模探针技术 实现云原生平安的全生命周期治理！ 上看：颗粒级的资产盘点看得更全 盘得更细不仅能够晓得以后业务应用了哪些镜像 还能够顺藤摸瓜 理清镜像-容器-Pod-集群关联链路 对于“哪些资产须要平安爱护” 客户可能通过牧云（CloudWalker） 做到“心里跟明镜儿似的” 左看：高效率的镜像扫描轻松扫描 稳准狠说白了就是一条研发测试流程 优良的人（是的，是我）会在这个流程上设置卡点 通过“准入+准出”机制来管制危险 辞别所有混水摸鱼的行为 对于安全部门来说 往往须要破费大量的工夫去推动业务部门进行配置 付出大量工夫心力不说，还难以保障成果 而长亭牧云（CloudWalker）镜像扫描的最大特点是： 1、扫得轻松：近程扫描，扫描过程零侵入旁路模式下的探针不须要部署在业务服务器上。真正意义上做到了零侵入和零烦扰，在保障及时捕获平安危险的同时保障业务稳定性。基于近程扫描模式，无需独自配置宿主机/node探针，即可笼罩90%前置平安危险。 2、扫得狠：分布式扫描，多种危险疾速扫云原生对象粒度丰盛，牧云（CloudWalker）在提供旁路平安扫描的同时，提供了高扩展性，分布式扫描高效灵便，保障各类业务场景覆盖率达到99%；此外牧云（CloudWalker）提供多种场景下的编排文件、制品扫描，笼罩镜像破绽检测、敏感信息检测、RBAC检测等多种危险。 3、扫得全：CI/CD扫描，自定义参数，全局策略主动监听流水线中的镜像构建并进行平安扫描，全局策略保障资产无脱漏，自定义参数策略可满足不同业务场景的需要。 右看：自适应的继续响应环境继续监测业务上线后，平安环境变得捉摸不透 该场景下，更强调对容器环境的 继续监测和应急响应解决的自适应能力 而这方面 得益于双模探针的运行模式天然不在话下 入侵检测：不仅能精确感知，还提供响应伎俩继续监控剖析容器运行状态，提供多锚点的检测能力，可能实时、精确地感知入侵事件并可视化攻打链路，发现失陷容器可立刻进行暂停、移除等响应操作。 容器逃逸：疾速发现、疾速剖析、疾速响应针对容器逃逸，这类会间接影响到承载容器的底层基础设施保密性、完整性、可用性的问题，长亭牧云（CloudWalker）反对检测各类可疑行为： privileged特权模式运行容器引起的逃逸危险挂载导致的容器逃逸内核破绽导致的容器逃逸 网络可视化：卡点拦挡、无处可逃的歹意流量在实在的业务场景中，网络的拜访是盘根错节的，长亭牧云（CloudWalker）反对网络流量可视化性能，通过 K8s api server+ ebpf 等组合拳实现服务发现等性能，主动发现过程、容器、POD、主机之间的网络连接并采纳雷达拓扑图展现。 ...

亚马逊云科技 Community Day 将于 5 月 28 日 在深圳南山区海德酒店 11 楼举办，Jina AI 软件工程师付杰将带来 《Jina AI 生态助力云原生场景下的 AIGC 利用开发》 的主题演讲。 Community Day 是亚马逊云科技寰球品牌和社区旗舰流动，由社区领导者发动，汇聚来自世界各地的亚马逊云科技专家、用户及行业首领针对云计算相干技术进行探讨。旨在通过沉漫式学习体验为开发者提供一个以本人喜爱的形式获取常识、互相学习的场合。 本次流动将有四大主题论坛，涵盖云原生、大数据、AI/ML、高校，演讲笼罩4大前沿畛域，以权威业余的技术干货，深度分析科技风向标；5大主题展区，最神秘好玩的奇趣游戏、最前沿一线的产品展现，寓教于乐，带观众近距离感触科技之美，以及现场 Build On 学习，更有高校科技成果转化国内成绩展现，等你来探寻！AI/ML论坛流动工夫：2023年05月28日下午13:00-18:00 主题： 《Community Day 深圳站—AI/ML论坛 解锁有限可能！》 地点：深圳市南山区海德酒店11楼（后海地铁站F口） 开发者官网报名链接：点击 亚马逊云科技 即可报名 生成式 AI 和大型语言模型（LLMs）热浪正在席卷寰球，并开始耳濡目染地扭转着人类的各个行业和工作和生存形式。每个须要人类创作原创作品的行业—从社交媒体到游戏、从广告到修建、从编码到平面设计、从产品设计到法律、从营销到销售都有待全新重塑。新世界正在到来。 本次峰会的人工智能论坛将邀请来自不同行业的经验丰富的专家和学者，从 AIGC 的概述和演进、 LLMs 的训练和部署、神经网络量化和压缩、多模态数据训练以及模型的服务封装等 AI 畛域的多个新锐话题，为您逐个解读在这个大时代中的时机挑战、常识底座和解决方案落地实际。 流动安顿 议题简介 付杰 | Jina AI 高级软件工程师** 本科毕业于北京交通大学，在加州大学圣地亚哥分校取得电子工程硕士学位，目前是 Jina AI Inference 团队的成员之一，负责大语言模型推理优化，部署落地的相干工作。 ️ 演讲主题： 《Jina AI 生态助力云原生场景下的 AIGC 利用开发》 * 主题简介：* 本次演讲的主题是介绍多模态场景下的向量搜寻技术，以及如何应用 CLIP-as-Service 的服务疾速搭建跨模态向量检索引擎。本演讲首先会论述目前多模态技术的倒退利用及其多模态表征模型（尤其是 CLIP）的原理及一些相干的上游利用，而后讲述如何应用预训练好的多模态模型取得输出数据的 embedding，以及一个满足工业界需要的 embedding service 须要蕴含哪些性能。最初展现咱们的 CLIP-as-Service 的一些现有性能以及一些简略的 demo。 ...

在进入千禧年后，随着计算机技术的倒退和业务翻新的不断涌现，许多大公司内的 IT 计算中心也在酝酿着改革。一方面，各部门绝对独立的 IT 治理平台曾经难以满足日益增长和一直变动的计算治理需要；另一方面，IT 计算中心也越来越多的成为业务翻新的发源地，从一个老本核心向营收起源倒退。相应的，一种围绕着资源和负载治理平台的技术畛域逐步称为学术界和产业界的热点。它在不同的倒退阶段和不同的利用场景有着不同的名字，从最早的集群（Cluster），网格（Grid），到起初的数据中心操作系统（DCOS），云计算（Cloud Computing）。同时，在资源管理和负载治理这两大方面也一直的拓展着本身的边界。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1154285?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

download：极客大学云原生训练营完结分布式事务实际：解决分布式系统的一致性问题在分布式系统中，因为数据扩散在不同的节点上，并且这些节点可能位于不同的物理地位，因而很容易呈现数据不统一的问题。为了解决这个问题，咱们须要应用分布式事务来保证数据的一致性。本文将介绍分布式事务的概念以及如何在实践中应用它来解决分布式系统的一致性问题。 分布式事务的概念在单机零碎中，咱们能够应用事务来保证数据的一致性。事务是一组原子性操作的汇合，这些操作要么全副执行胜利，要么全副回滚到初始状态。在分布式系统中，因为数据扩散在不同的节点上，因而须要应用分布式事务来保证数据的一致性。 分布式事务通常通过以下两种形式来实现： 二阶段提交（Two-Phase Commit，2PC）：在该协定中，由一个协调者来协调所有参与者的事务，并最终决定是否提交或回滚这些事务。 弥补事务（Compensating Transaction）：在该协定中，每个参与者都会进行本地事务，并记录下对全局事务的影响。如果某个参与者失败了，那么它会回滚本地事务，并执行一系列弥补操作来撤销本人对全局事务的影响。 分布式事务的实际在实践中，咱们通常应用分布式事务框架来简化开发过程。以下是一个应用Seata框架实现分布式事务的例子： @Servicepublic class OrderService { @Autowiredprivate OrderMapper orderMapper;@Autowiredprivate StorageClient storageClient;@GlobalTransactionalpublic void createOrder(OrderDTO orderDTO) { Order order = new Order(); order.setUserId(orderDTO.getUserId()); order.setProductId(orderDTO.getProductId()); order.setCount(orderDTO.getCount()); order.setAmount(orderDTO.getAmount()); order.setStatus(0); orderMapper.createOrder(order); // 扣减库存 storageClient.deductStock(orderDTO.getProductId(), orderDTO.getCount()); // 提交订单 orderMapper.updateOrderStatus(order.getId(), 1);}}在该例子中，咱们应用了Seata框架来实现分布式事务。@GlobalTransactional注解用于标识该办法须要参加分布式事务，当这个办法被调用时，Seata会协调所有参与者的事务并最终决定是否提交或回滚这些事务。 在createOrder办法中，咱们首先创立了一个订单并插入到数据库中。而后调用了storageClient.deductStock办法来扣减库存。最初，咱们更新了订单状态为已提交。如果在这个过程中呈现了任何异样，Seata会回滚所有的事务，并执行一系列弥补操作来撤销对全局事务的影响。 结语分布式系统的一致性问题始终是开发者们须要面对的一个难题。通过应用分布式事务，咱们能够保证数据的一致性，并且简化了开发过程。本文介绍了分布式事务的概念以及如何在实践中应用它来解决分布式系统的一致性问题。心愿这对您有所帮忙。

业务高速倒退，业务敏捷性和稳定性面临挑战波司登国内控股有限公司(简称波司登) 始于1976年，旗下品牌包含“波司登”、“雪中飞”等，波司登羽绒服滞销美国、法国、意大利等72个国家寰球超2亿人次在穿。 作为全国最大的品牌羽绒服生产商，波司登间断26年全国销量当先，在疫情黑天鹅的冲击下，线下销售渠道增长瓶颈，波司登减速推动数智策略。但因为波司登外围业务零碎别离由不同的软件开发商开发建设和保护，架构老旧、以传统单体利用为主，且版本迭代很慢，无奈满足波司登线上业务的高速增长带来的高并发、弹性扩大、敏捷性等更高的要求，为此波司登迫切需要进行外围业务零碎的云原生化革新降级，以撑持业务的高速倒退。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1156069?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

在《MoE 系列（三）｜应用 Istio 动静更新 Go 扩大配置》中咱们体验了用 Istio 做管制面，给 Go 扩大推送配置，这次咱们来体验一下，在 Go 扩大的异步模式下，对 Goroutine 等全副 Go 个性的反对。 异步模式 之前，咱们实现了一个简略的 Basic Auth[1]，然而，那个实现是同步的，也就是说，Go 扩大会阻塞，直到 Basic Auth 验证实现，才会返回给 Envoy。 因为 Basic Auth 是一个非常简单的场景，用户名明码曾经解析在 Go 内存中了，整个过程只是纯 CPU 计算，所以，这种同步的实现形式是没问题的。 然而，如果咱们要实现一个更简单的需要，比方，咱们要将用户名明码调用近程接口查问，波及网络操作，这个时候，同步的实现形式就不太适合了。因为同步模式下，如果咱们要期待近程接口返回，Go 扩大就会阻塞，Envoy 也就无奈解决其余申请了。 所以，咱们须要一种异步模式： 咱们在 Go 扩大中，启动一个 Goroutine，而后立刻返回给 Envoy，以后正在解决的申请会被挂起，Envoy 则能够持续解决其余申请。Goroutine 在后盾异步执行，当 Goroutine 中的工作实现之后，再回调告诉 Envoy，挂起的申请能够持续解决了。留神：尽管 Goroutine 是异步执行，然而 Goroutine 中的代码，与同步模式下的代码，简直是一样的，并不需要特地的解决。 为什么须要 为什么须要反对 Goroutine 等全副 Go 的个性呢？ 有两方面的起因： 有了 Full-feature supported Go，咱们能够实现十分弱小、简单的扩大。能够十分不便的集成现有 Go 世界的代码，享受 Go 生态的红利。如果不反对全副的 Go 个性，那么在集成现有 Go 代码的时候，会有诸多限度，导致须要重写大量的代码，这样，就享受不到 Go 生态的红利了。 ...

2022年12月28日，以“原生万物 云上翻新”为主题的第三届云原生实战峰会在线上举办。 会上，阿里云提出激活企业应用构建三大范式，并公布云原生可观测套件、企业级分布式应用服务EDAS 等产品焕新降级 ，以云原生技术继续推动企业数字翻新。 阿里云云原生利用平台总经理丁宇示意，从最开始布局容器，到外围零碎云原生化，再到往年提出外围云产品全面 Serverless 化，阿里云始终以先行者的视角布局技术，并一直带给业界新的设想空间。同时在开源生态上，2022年阿里云在开发者合作影响力上排名寰球第二。在搭档生态上，通过与搭档能力互补，让云原生产品和服务以最优的形式服务20多万企业，构建凋谢交融的生态体系。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1127549?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

数据库作为数字经济建设的重要根底，扮演着产业数字化和数据价值开释的基石角色。然而，数据库的倒退不能仅仅依赖于本身的技术和翻新，也须要建设一个良好的生态系统，与各方单干独特推动数据库技术的提高与翻新。拓数派（OpenPie）致力于继续欠缺生态搭档网络，与各畛域的厂商进行交换和单干，独特推动数据库技术的倒退，构建凋谢、共享、可继续的数据库生态。  近日，拓数派与麒麟软件、统信软件、龙蜥社区、中科可控、兆芯、海光、博云科技等厂商实现了兼容性互认证测试。认证结果表明，拓数派旗下旗舰产品 - 云原生虚构数仓产品 PieCloudDB Database 在国内出名的操作系统、服务器、处理器以及云平台上实现良好兼容，性能、可靠性体现优异，能够稳固运行。  拓数派旗下旗舰产品 PieCloudDB，在 eMPP 分布式专利技术、服务器无感知（Serverless）及 TDE 等多项核心技术加持下，为企业构建高平安，高牢靠，高在线「坚如磐石」的云原生虚构数仓，助力企业实现数据价值最大化，更好地赋能业务倒退并走向绿色，成为新一代 AI 数据计算基础设施的一个榜样。  本次兼容性互认证厂商涵盖操作系统、服务器、CPU 处理器等多个根底软件方向。充分证明了 PieCloudDB 作为一款性能优异、安全可靠的云原生虚构数仓，对业界支流根底软件的良好兼容性。  操作系统反对PieCloudDB 已与麒麟软件、统信软件以及龙蜥社区实现兼容性互认证测试，可能达到通用兼容性要求及性能、可靠性要求，满足用户的关键性利用需要。  麒麟软件旗下的河汉麒麟高级服务器操作系统是针对企业级要害业务，适应虚拟化、云计算、大数据、工业互联网时代对主机系统可靠性、安全性、性能、扩展性和实时性等需要，根据 CMMI 5 级规范研制的提供内生实质平安、云原生反对、自主平台深刻优化、高性能、易治理的新一代自主服务器操作系统。  统信软件旗下的统信服务器操作系统是统信操作系统（UOS）产品家族中面向服务器端运行环境的，是一款用于构建信息化基础设施环境的平台级软件。产品次要面向于我国党政军、企事业单位、教育机构，以及一般的企业型用户，着重解决客户在信息化根底建设过程中，服务端基础设施的装置部署、运行保护、利用撑持等需要。以其极高的可靠性、长久的可用性、低劣的可维护性，在用户理论经营和应用过程中深受好评，是一款体现当代支流 Linux 服务器操作系统倒退程度的商业化软件产品。  Anolis OS 8 是 OpenAnolis 社区推出的齐全开源、中立、凋谢的发行版，它反对多计算架构，也面向云端场景优化，兼容 CentOS 软件生态。Anolis OS 8 旨在为宽广开发者和运维人员提供稳固、高性能、平安、牢靠、开源的操作系统服务。目前 Anolis OS 8.6 正式版已公布，反对 X86_64 、RISC-V、Arm64、LoongArch 架构，欠缺适配 Intel、飞腾、海光、兆芯、鲲鹏、龙芯等芯片，并提供全栈国密反对。  此外，拓数派于本月正式成为龙蜥社区的合作伙伴，致力于满足用户多样化数据分析要求，努力实现以 “数据计算” 赋能百业，独特为客户发明价值。 服务器反对PieCloudDB 已与中科可控实现兼容性互认证测试，结果表明兼容性良好，能够顺利装置、配置，并稳固运行。  中科可控信息产业有限公司 (以下简称: “中科可控”) 基于海光处理器研发了多款高性能企业级机架式服务器，适宜为云计算、大规模计算集群部署、软件定义存储、大数据分析等利用高效减速，满足新一代数据中心多样性、高效能和绿色计算的需要。  CPU 处理器反对PieCloudDB 与海光、兆芯的多款 CPU 兼容性良好，能够牢靠、稳固、高性能地运行。  海光信息技术股份有限公司（以下简称: “海光公司” ）自主研发的海光全系列 CPU 产品是国内先进的 x86 架构的高性能通用处理器产品，专为工作要害型实时剖析、5G 利用、人工智能、机器学习、金融证券、高性能计算、大数据和云计算等畛域而打造，具备多外围、高性能、低功耗、安全可靠、生态好等特点，产品曾经大量利用在电信、金融、教育、科研、人工智能等重要畛域。  ...

腾小云导读 2022 年 10 月，腾讯自研业务产品全面完成云原生上云。自研业务产品云上规模已冲破 5000w CPU，借助云原生的技术劣势，全面晋升了腾讯自研业务产品的经营效率，在此过程中咱们也对腾讯云产品进行了打磨和验证。无论是在业务场景、稳定性要求、运维效率等多个方面，大规模容器化过程中都面临不少的技术挑战。本篇将进行分享，心愿能够给宽广开发爱好者带来灵感。 看目录，点珍藏 1 我的项目背景 1.1 腾讯自研业务产品云原生上云历程简介 1.2 腾讯有状态服务的共性 2 腾讯大规模业务容器化面临的几个挑战 2.1 容器疾速降级 2.2 容器原地热降级 2.3 面向业务产品的全局疾速扩缩容 2.4 对利用屏蔽多样的底层机型，晋升资源池利用率 2.5 从面向集群到面向利用的调度编排 3 总结 腾讯自研业务产品历经三年，包含 QQ、微信、王者光荣、腾讯会议等亿级用户规模的业务产品，都已全面上云。自研业务产品云上的资源规模已冲破 5000 万核，打造了国内最大规模的云原生实际榜样。各位读者点这里进入页面，左边扫码关注腾讯云开发者公众号，回复「云原生」可下载鹅厂7w字大规模云原生技术实际案例集、腾讯云技术实际精选文集。 在这个过程中，腾讯做了大量的技术优化和冲破，包含优化 K8s 集群、全局的资源管理调度，实现了 65%的 CPU 利用率、晋升容器利用链路上各层的稳定性等等。 3 年工夫，腾讯最终达成了全面云原生上云的指标。在容器利用治理上，有几个事件十分要害： 最晚期须要云原生理念的布道。让所有业务产品”意识“到云原生上云所带来的业务价值。几年前，腾讯外部的 K8s Oteam 联结腾讯学堂推出了第一个面向全公司的 K8s 系列课程。提供易用性和稳定性的容器治理平台。这解决不同的业务场景容器化上云的痛点并积淀了产品的能力，让所有腾讯业务产品都真实感受到云原生上云的价值。资源调度编排能力。底层海量的资源规模，须要打造极好的资源调度编排能力，晋升全局的资源利用率，从团体层面达成上云后的降本增效目标。度量机制。「各个业务产品云原生上云做的怎么样」须要有一套度量机制。例如腾讯的云原生成熟度模型，无效帮忙各个业务晋升了业务产品的云原生成熟度。上面将次要介绍开发过程中咱们遇到的局部技术挑战和解决方案，各位将能看到咱们在此过程中是如何一步步去夯实产品能力的。 01、我的项目背景1.1 腾讯自研业务产品云原生上云历程简介腾讯自研业务产品容器化上云始终以腾讯云产品为底座，整个过程分为两个阶段，云原生上云 1.0 和 2.0 阶段。2022 年前次要是 1.0 阶段，技术核心在「离线混部、在线混部」场景中，业务产品的容器化状态次要经验了富容器和微容器 2 个状态。 通过大规模自研业务产品的容器化，团队积淀了各种业务场景下容器化上云的最佳实际计划和产品所需的能力，例如容器调度（单集群和多集群）、弹性伸缩、有状态服务容器化、大规模资源管理、稳定性晋升、业务运维效率晋升等。 上云阶段不仅仅是把业务产品容器化上云，更重要的是要给业务产品带来理论的价值。这里有腾讯云原生的成熟度规定，来考核腾讯自研业务产品和其对应的容器平台。次要从四个维度考核： 最大的权重维度是资源利用率，指业务产品容器利用率、平台资源利用率。还有弹性伸缩能力、容器可调度能力以及申请的 Pod 资源是不是小外围的资源。通过这些外围指标来标准和评估业务产品云原生上云的过程和成果。 1.2 腾讯有状态服务的共性应用 IPC 共享内存时，可能有超 GB 的有状态本地数据，降级时不能失落，而且只容许 ms 级的用户无感知抖动。局部模块的开发框架须要反对热降级：在容器降级时反对热降级。海内外多地区部署，单个模块最多的实例数超过 1 万，整个产品的 Workload 十万级，散布在上百个集群中。底层应用的资源有各代的老旧机型，也有绝对较新的机型，但业务产品基本上不筛选机型。这些业务产品个性使其在 TKE 治理上面临微小挑战，既要尽量兼容这些业务产品个性，也要放弃其应用镜像公布和降级的云原生准则。TKEx 利用治理平台形象出了这些个性背地的需要，研发了多集群对立灰度公布、多地区多集群工作负载治理、面向利用的多集群协同扩缩容、容器疾速降级、容器热降级等通用的平台能力。 ...

作为新经济综合服务平台第一品牌，36氪自2019年落地四川站以来，一直通过新锐、深度的商业报道，陪跑、反对四川的新经济产业。通过开掘外乡优质我的项目，36氪四川帮忙企业链接更多资源，助力企业成长，促成行业倒退。本期报道的是成都元来云志科技有限公司的相干我的项目内容。 随着企业数字化转型步调放慢，中国企业进入全面上云的新阶段，而云原生作为新一代云计算的关键技术内核，将在产业数字化中施展要害一环。云原生可在基础设施层面为产业利用提供底层撑持能力,并进步对产业利用生命周期的治理能力,实现产业资源利用效率和交付效率的晋升、业务弹性扩大能力和灵活性的降级,以及运维难度的升高。据Gartner预测，到2025年，基于云原生平台的数字化业务比例将达到95%，云原生曾经成为云时代的新技术标准。 成都元来云志科技有限公司（以下简称“MIAOYUN”）于2019年成立，是国内首家专一于云原生智能运维的公司，总部位于成都，在西安、上海、北京、南京别离设有研发核心和营销中心。「MIAOYUN」致力于帮忙企业对立治理、智能运维、疾速构建扩散的云原生零碎环境，晋升多云原生零碎的对立管理性、易用性和可观测性，晋升生产效率、减速业务翻新。 「MIAOYUN」产品定位于一体化云原生系统管理和智能运维平台，具备多云原生零碎一体化治理和双态运维能力，同时接入基础设施数据与云原生环境数据，实现全链路的对立云原生治理调度、对立运维数据分析、对立监控告警的根底上，集成AI能力，帮忙企业实现智能运维，并基于丰盛的标准化组件和零代码开发能力，帮忙企业疾速构建多种场景化能力，最大化升高企业在云原生环境上的研发和运维投入，让企业更专一于本身利用的开发和交付。据介绍，「MIAOYUN」自成立以来，已胜利利用于电力、运营商、金融、政府、公安、工业制作、教育等多个行业的标杆企业。 「MIAOYUN」旗下主推两款产品，一款是秒云容器云平台（MYCP），基于Docker容器技术和以后最风行的Kubernetes容器编排引擎，依靠于容器人造的劣势和丰盛的容器调度和编排机制，重点解决企业生产环境中的基础设施云化，利用部署简化，运维治理自动化等难题；另一款是秒云运维智能剖析平台（MYLI），基于云原生容器化架构，内置多种搜寻剖析工具，提供全图形化操作界面，零代码定制开发个性化的日志剖析利用，帮忙客户疾速的从海量日志中定位问题，构建运维全景剖析视图，进步运维效率，升高运维老本。 MIAOYUN为国家电网四川省电力公司构建对立的治理运维平台，围绕用户的“电力交易平台”、“PMS2.0”、“应急指挥系统”等30+套要害信息系统构建业务全景视图，以业务的视角剖析、监控、观测故障，让用户直观的掌控云原生业务的衰弱状态。此外，「MIAOYUN」首席执行官张旸通知36氪，「MIAOYUN」能够轻松对接客户现有的软硬件工具，对立采集多起源、多厂商的告警事件，对立存储 、对立泛化、对立数据模型，以业务为全局视角，剖析展现业务下服务器、虚拟机、容器等全链路零碎状态，为客户构建更全面视角的云原生运维可观测体系。 张旸通知36氪，下一阶段对公司的倒退布局为首先持续迭代产品，保持研发最简略易用、最智能运维的云原生零碎；其次摸索全新的商业模式，实现客户的继续服务、业务的深度联合。守业以来，「MIAOYUN」已取得数千万元策略投资。

作者：罗健文 李来 云服务开发工程师在生产场景中部署的服务提供者常因业务降级或其余场景须要下线和上线的部署操作，本文总结了利用在高低线过程中会遇到的典型问题，并思考在虚机和容器场景该如何解决这些问题，躲避该过程中可能呈现的服务消费者的申请失败，实现利用的优雅高低线。 一、微服务利用上/下线公布过程中存在的问题在利用高低线公布过程中，如何做到流量的无损上/下线，是一个零碎能保障SLA的要害。如果利用高低线不平滑，就会呈现短时间的服务调用报错，比方连贯被回绝、申请超时、没有实例和申请异样等问题。 1.1上线过程中的问题 在利用上线公布过程中，因为过早裸露服务，实例可能仍处在JVM JIT编译或者应用的中间件还在加载，若此时大量流量进入，可能会霎时压垮新起的服务实例。咱们在理论场景中，已经遇到provider服务启动后，然而数据库连贯出现异常，未做好启动前的资源筹备，导致该provider服务在注册核心裸露后DB异样还未修复，无奈失常提供被consumer调用的能力，导致大量申请异样返回。如下图日志所示，利用初始化时，DB连贯失败（该服务对DB是弱依赖）。 1.2下线过程中的问题 在利用下线过程中，服务消费者感知服务提供者下线有提早，在一段时间内，被路由到已下线服务提供者实例的申请都抛连贯被回绝异样。其次服务实例在接管到SIGKILL信号时，会立刻敞开，然而这时候可能在申请队列中存在一部分申请还在解决，如果立刻敞开这些申请都会损失掉。理论利用中，咱们在环境上部署了provider的惟一一个实例，该服务被consumer调用，而后再执行kill -9 强杀利用provider的惟一实例后，服务过程实际上曾经被终止，然而服务的注册信息还会在注册核心（该场景应用的是ServiceComb）保留一段时间，未及时革除，如下图所示。若此时消费者服务consumer调到该实例会报连贯回绝谬误。因为消费者consumer服务还能发现该实例，获取其IP和端口尝试去调用，然而该provider服务实例其实曾经被销毁了。 二、如何解决利用上/下线问题那么有哪些优化措施，能够缩小利用上/下线中流量的损失？ 2.1 解决利用上线问题 利用上线公布次要问题是：其中一个起因是注册太早，过早的裸露了服务；另一个起因是一些利用初始化迟缓，若遇到大量流量，利用容易宕机。能够采取以下优化措施： 提早注册：微服务利用能够采纳提早注册的形式，即在利用启动之后肯定工夫再进行注册。这样能够确保利用齐全就绪后再注册，防止了服务未就绪就被内部拜访的状况。健康检查：微服务利用能够实现健康检查接口，通过该接口能够查看服务是否就绪。注册核心能够通过定期调用该接口来判断服务是否能够对外提供服务，从而防止了服务未就绪就被内部拜访的状况。预热：对新实例进行预热，而不是忽然将所有流量转移到新实例上，从而防止新实例遇到大量流量，利用容易宕机的状况。启动优化：对于整个服务启动的过程，能够进行一些优化措施，比方缩小不必要的依赖、调整启动程序等，从而放慢服务启动速度。2.2 利用正当的上线过程 正当的利用上线大抵分为这样一个过程：当利用启动后，通过设置提早注册工夫（服务对外裸露的工夫）确保利用多久后可提供服务，其次可依赖平台查看服务的就绪状态（比方K8S的就绪探针）确保服务对外提供服务为就绪状态，而后通过预热对刚启动利用进行爱护，确保流量缓缓进入刚启动的利用，最初流量逐步增到失常状况。 2.3 解决利用下线问题 利用下线过程最次要问题是：消费者利用无奈及时感知到注册核心列表的刷新，导致可能还有新流量拜访下线利用。能够采取以下优化措施： 缩小注册核心缓存工夫：将注册核心中服务列表的缓存工夫缩短，能够使消费者利用更快地获取到服务列表的最新信息。这样能够缩小因服务列表缓存而导致的拜访下线利用的流量。实时性优化：在服务消费者和注册核心之间应用长连贯、实时告诉等机制，从而可能实时获取注册核心中服务列表的变动。实现熔断机制：在消费者利用中实现熔断机制，当某个服务实例呈现故障或不可用时，能够疾速切换到其余可用的服务实例。这样能够防止将流量发送到已下线的应用程序上，并确保消费者利用的可用性。2.4 利用正当的下线过程 正当的利用下线大抵分为这样一个过程：当利用承受到内部的敞开（进行服务）申请后，不能在接管新的业务申请，然而会存在一些正在解决的业务申请，需等这些申请解决完后再销毁利用应用的资源，最初就能够告诉主过程退出。 三、利用下线留神点针对利用下线在虚机场景和容器场景须要关注一些留神点。 3.1 虚机场景 当咱们要敞开虚拟机利用时，咱们个别会应用ps -ef | grep xxx查找到过程ID，而后再执行kill -9 PID操作。 kill 命令应用科普： kill -9， 零碎会收回SIGKILL（9）信号，由操作系统内核实现杀过程操作，该信号不容许疏忽和阻塞，应用程序会立刻终止（强制杀死）。kill -15，默认应用信号，零碎向利用发送SIGTERM（15）信号，给指标过程一个清理善后工作的机会是一种优雅终止过程的形式，通知过程须要进行运行并开始清理资源。因为kill -9 PID会强制杀死利用，以正当的利用下线流程看，应需解决完相干旧业务申请，清理相干资源后再退出过程，所以当要敞开虚拟机利用时，请执行kill PID——以优雅的形式进行运行。 3.2 容器场景 Kubernetes目前是业界容器编排畛域的事实标准，业界个别默认都是用K8S来治理容器。K8S提供了Pod优雅退出机制，容许Pod在退出前实现一些清理工作。preStop会先执行完，而后K8S才会给Pod发送TERM信号。在容器场景利用K8S提供的preStop机制，配合提早下线API应用，这样就能保障流量的无损下线。 ...spec: containers: - name: lifecycle-demo-container image: nginx lifecycle: preStop: exec: command: ["/bin/sh","-c","to do xxx; do sleep 30; done"]...（1）为什么容器利用（K8S环境）要配置preStop？首先要介绍一下Pod的终止过程。 ...

背景ZooKeeper 作为分布式系统的元数据中心，对外服务的数据一致性须要失去很好的保障，然而一些老版本的 ZooKeeper 在一些状况下可能无奈保证数据的一致性，导致依赖 ZooKeeper 的零碎出现异常。 某用户应用 3.4.6 版本 ZooKeeper 做任务调度，ZooKeeper 实例的 tps 和 qps 都比拟高，事务日志产生的速率很快，即便此用户配置了主动清理的参数，然而主动清理的最小距离还是赶不上数据产生的速度，导致磁盘爆满。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1199618?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

放眼寰球数据库产品的世界，竞争十分强烈，拓数派作为国内数据库畛域的领导者，须要发明一个不同凡响的企业 IP 形象，以突显其品牌价值和产品劣势，这项要求对拓数派的设计师来说，挑战从未如此之高。 发明一个企业 IP 形象，不仅要吸引人的眼球，还要传播咱们的产品个性和价值观。在近一个月的设计过程中，拓数派的品牌设计师着重关注拓数派 PieCloudDB Database 的产品个性，将 PieCloudDB 业务上的个性与动物、物品、虚构角色等具像化的的形象联合，心愿通过一个可恶、富裕共性的形象来表白拓数派公司的产品理念，历经 2 轮票选，最终从 3 个设计角色中抉择了 “树懒” 这一动物原型，发明出了一个独特的企业 IP 形象 ——“小树懒派派”。这个角色凸显了咱们心愿传播的文化和品牌形象：可恶、淳朴、聪慧机智，Ta 尽管看起来动作迟缓，但只有动起脑来实力不可小觑，这种个性与拓数派 PieCloudDB 云虚构数仓产品十分类似。正如咱们的产品操作晦涩易上手，且领有弱小的性能与业余团队，能够为客户提供更高效的云原生虚构数仓解决方案。 小树懒派派是一个不常见的动物 IP 形象，代表着拓数派的独特、业余、智慧的战略眼光和企业文化特点。置信，不久的将来，派派将成为一个业内十分受欢迎的形象，为咱们的品牌带来更多的关注和认可，成为云上数据计算畛域的明星 IP。 彩蛋：借由美剧 Silicon Valley 第一季中的一处经典台词梗，咱们联合本身产品 PieCloudDB Database，为可恶的派派制作了有意思的表情包：We‘re making the world a better place… through scalable fault-tolerant distributed databases with ACID transactions.（咱们在让世界变成更美妙的中央… 通过一款可拓展的、容错的、分布式的、带事务 ACID 属性的数据库。） 点击获取拓数派官网表情包（第一期）   

Dragonfly 最新正式版本 v2.0.9 曾经公布！感激 Dragonfly 的贡献者们，同时也感激默默反对 Dragonfly 我的项目的各个私有云团队。欢送拜访 d7y.io[1]网站来理解详情，上面具体介绍 v2.0.9 版本带来了那些更新。 性能下载工作能够依据优先级(Priority)进行下载。优先级能够在下载工作时 cli 中作为参数传入，也能够在 Manager Console 设置对应利用关联的优先级。具体不同优先级的性能能够参考文档 priority protoc definition[2]。Scheduler 配置新增 PieceDownloadTimeout 字段，做用是当某个 Piece 下载超过 Timeout 时，设置对应的 Task 状态变更为失败。避免异样 Task 元信息残留在 Scheduler 中。残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1178855?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

微服务和音讯队列都是以后比拟风行的架构模式，能够帮忙开发者在理论业务中解决大型简单分布式系统面临的各种挑战： 微服务架构是一种云原生架构办法，目标是进步零碎的扩展性、可靠性和灵活性，它提倡将繁多的应用程序划分成一组小的服务，服务之间相互协调、互相配合，每个服务运行在其独立的过程中，服务与服务之间采纳轻量级的通信机制相互沟通，每个服务都领有本人的代码库、数据存储和运行环境，能够独立开发、测试、部署和运行。这种架构模式能够让团队更快地迭代、更快地部署新性能，同时还能更容易地扩大和保护零碎。 然而，微服务架构也面临一些挑战，如服务之间的通信和数据一致性等问题，为了解决这些问题，通常应用音讯队列等工具来协调服务之间的通信和数据交换。 音讯队列简略来讲就是一种将音讯从一个应用程序传递到另一个应用程序的通信机制。它将音讯保留在一个队列中，直到接收者筹备好接管音讯。这种通信机制能够让应用程序之间解耦，从而实现高可用性、可伸缩性和可靠性。 本次云原生技术实际营为大家带来微服务和音讯队列专场，为大家带来这两种支流架构的技术干货和最佳实际，流动详情如下： 参会收费：点击报名链接，填写报名信息，即可实现报名参会。交通指南：自驾导航到支付宝大厦公开停车场；地铁2号线东昌路地铁站3号口下。舒适提醒：如加入入手环节，请自带笔记本电脑，及提前注册阿里云帐号。留神️：点击链接，即可报名。 报名链接：https://survey.aliyun.com/apps/zhiliao/nN86taQg1?accounttrace... 参会采取报名审核制，咱们将在流动前 3 天下发审核通过的短信，若未收到视为未审核通过。 查看海报理解 本次流动详情

download：云原生利用架构设计与开发实战云原生：开启下一代企业应用 关键字：云原生、容器化、微服务、DevOps、Kubernetes 随着数字化时代的到来，企业对于IT零碎的需要也在一直地减少。而云原生作为下一代企业应用的核心技术之一，正在逐步成为了企业数字化转型中的重要组成部分。 一、什么是云原生？ 云原生是指将应用程序及其相干服务（如存储、网络等）以容器为根底进行构建、运行和治理的形式。它采纳了微服务架构，能够将每个功能模块拆解为独自的服务，并通过API进行通信。同时，云原生还波及到DevOps文化、自动化、可观测性等方面的实际。 二、云原生的劣势 相比传统的应用程序，云原生具备以下劣势： 可移植性：因为容器的个性，云原生利用能够很容易地在不同的环境中迁徙。 弹性伸缩：云原生利用能够依据负载状况主动进行程度伸缩，从而保障利用的可靠性和高可用性。 灰度公布：云原生利用能够通过灰度公布等形式，实现无缝降级，从而防止对用户造成影响。 安全性：通过对容器和镜像进行加密，云原生能够更好地保障应用程序的安全性。 三、Kubernetes与云原生 Kubernetes是一个开源容器编排平台，它能够自动化地部署、扩大和治理容器化应用程序。作为云原生技术的代表，Kubernetes曾经成为了企业数字化转型中不可或缺的一部分。Kubernetes能够进步应用程序的可移植性、弹性伸缩性以及灰度公布等能力，从而更好地反对云原生利用的构建和运行。 总之，云原生曾经成为了下一代企业应用的核心技术之一。采纳云原生技术，能够进步应用程序的可移植性、弹性伸缩性以及灰度公布等能力，从而更好地满足企业数字化转型的需要。同时，Kubernetes作为云原生技术的代表，也在企业中失去了宽泛的利用和推广。

前言根据Istioctl的思路(https://segmentfault.com/a/1190000043440836)，Dubboctl目前实现了manifest generate、manifest install、manifest uninstall和manifest diff这几个重要的根底命令，接下来会在补足测试用例的同时持续加强。为了让其他同学能疾速地了解Dubboctl，参加后续的开发工作，编写这个文档解释dubboctl的构造与要害流程。 构造Dubboctl目前构造如下所示： 概述cmd：负责解析命令，并利用operator与其余性能包实现命令。目前利用manifest包和 operator实现了manifest子命令。controller：负责响应DubboOperator CR的更新，利用operator与其余性能包实现相应的响应式性能。目前未实现该模块。operator：次要功能模块，提供RenderManifest、ApplyManifest、RemoveManifest等外围性能。cmd、controller等入口模块无需关注实现细节，只须要配置并调用性能即可。components：目前反对的组件有Admin、Grafana、Nacos、Prometheus、Skywalking、Zipkin、Zookeeper，各组件借助renderer实现RenderManifest，实现各自的渲染工作。kube：负责与k8s进行交互，次要应用controller-runtime库。 代码走读Dubboctl的总体入口在/cmd/dubboctl/main.go，/pkg/dubboctl/cmd处应用cobra组织命令行，实现命令的加载，如下图所示：其中manifest.go实现manifest子命令的加载： func addManifest(rootCmd *cobra.Command) { manifestCmd := &cobra.Command{ Use: "manifest", Short: "Commands related to manifest", Long: "Commands help user to generate manifest and install manifest", } // manifest generate cmd.ConfigManifestGenerateCmd(manifestCmd) // manifest install cmd.ConfigManifestInstallCmd(manifestCmd) // manifest uninstall cmd.ConfigManifestUninstallCmd(manifestCmd) // manifest diff cmd.ConfigManifestDiffCmd(manifestCmd) rootCmd.AddCommand(manifestCmd)}命令的具体实现处存在于/pkg/dubboctl/internal/cmd，每个文件对应一个子命令的实现。每个子命令文件可分为以下几局部： 该子命令承受的参数对应的构造体配置cobra入口子命令的实现逻辑接下来按这三局部对manifest generate进行代码走读。 manifest generateManifestGenerateArgstype ManifestGenerateArgs struct { // 用户的自定义配置，可配置多个，依照程序从右往左顺次笼罩 FileNames []string // 寄存Helm chart的目录，默认应用/deploy/charts ChartsPath string // 寄存profile的目录，默认应用/deploy/profiles ProfilesPath string // manifest输入门路，若不设置，将默认向控制台输入 OutputPath string // 多个SetFlag，--set key=val SetFlags []string}ConfigManifestGenerateCmd将manifest generate接入cobra，重点关注其中的RunE字段，其中定义了子命令的执行逻辑： ...

4 月 27 日，浙江省政协副主席朱从玖光临拓数派杭州总部调研领导工作，省政协经济委专职副主任吴建胜，省政协委员、经济界（一）界别组组长，中国建设银行浙江省分行行长、党委书记邵斌，省政协经济委办公室主任孙开颜，浙江金控投资治理公司董事长郑钧，杭州市创投协会会长、之江创投研究院执行院长周恺秉等陪同调研，拓数派创始人兼 CEO 冯雷，开创合伙人兼首席企业倒退官周妮娜，首席信息官李京博，市场部负责人姜雪，财务部负责人王姗姗等公司代表加入调研座谈。 冯雷汇报介绍了拓数派的核心技术冲破与价值，论述了公司使命 “数据计算，只为新发现” 背地的哲学逻辑在于数字智能时代不停冲破新边界，拓数派的数据计算利用横向扩大的形式赋能百业，将来将天然延长并反对大模型人工智能等状况。 图为：拓数派创始人兼 CEO 冯雷座谈会发言照片 图为：拓数派创始人兼 CEO 冯雷座谈会发言照片 朱从玖副主席对公司在云原生和数据库等方面获得的翻新成绩、良好的发展势头示意充分肯定，心愿公司紧紧抓住全省鼎力推动数字经济翻新提质 “一号倒退工程” 的时机，进一步施展研发翻新方面的劣势，放慢科技成果转化，加大市场开辟力度，推动企业一直发展壮大。也心愿无关部门加大反对服务力度，助力公司倒退。 图为：拓数派创始人兼 CEO 冯雷座谈会发言照片 最初，冯雷示意拓数派愿在政府引领和领导下，在激活数据因素，打造具备国内竞争力的数字产业集群，晋升产业链条数字化程度，造就中国数据计算畛域产业人才等方面，为中国数字经济的倒退奉献一份力量！    

随着云计算和容器技术的一直倒退，容器引擎和容器运行时曾经成为了云原生时代的基石，它们负责了容器生命周期的治理以及容器运行过程中环境的创立和资源的配置。openEuler 社区基于容器引擎我的项目 iSulad[1]在解决容器运行效率、安全性以及隔离性等问题上进行着一直地尝试与摸索。 华为云在 2023 年 4 月 21 日阿姆斯特丹的 Kubecon+CloudNativeCon Europe 2023 云原生峰会上公布了多沙箱运行时Kuasar[2]，将 Kubernetes CRI(https://github.com/kubernetes/cri-api) 规范中的 Pod 语义精确地映射到了 Kuasar 的 Sandbox 语义。与此同时，iSulad 容器团队与华为云 Kuasar 严密单干，率先反对了 Kuasar 的 Sandbox 语义，实现了从 Kubernetes 到 iSulad 容器引擎到 Kuasar 对立容器运行时的全栈买通。通过 iSulad 和 Kuasar 我的项目，对立了容器运行时应答不同容器隔离技术的 Kubernetes 生态场景，简化了单节点上多种容器（或沙箱）状态的对立部署。相比于 Containerd + Kata-Containers 的运行时组合，iSulad + Kuasar 「不仅能够反对多种容器隔离技术，而且使容器运行时治理组件的内存耗费缩小了 99%，并行启动工夫缩短了 40%以上！」 背景与现状 从容器编排组件 Kubernetes 的视角来看，可能解决 CRI(Container Runtime Interface)申请的服务端都是容器运行时(Container Runtime)。事实上，容器运行时还能够再细分为两个档次，即容器引擎和底层容器运行时。 容器引擎(Container Engine)次要负责容器运行环境的创立、容器资源的配置和容器生命周期的治理，北向接管来自于 Kubernetes 或前端命令行的输出，南向则调用底层容器运行时(Low Level Container Runtime)来实现最终容器环境的生成和容器生命周期的操作。 在业界，容器引擎和容器运行时的术语常常被交替应用。「在本文的语义中，容器运行时特指底层容器运行时」。除了 iSulad 以外，以后的容器引擎还包含 Containerd，Docker 等，底层容器运行时包含 runc，Kata-Containers 等。 ...

随着数字化浪潮的降临，云原生技术正在扭转着各行各业，通过IT改革驱动业务翻新倒退，促成企业本身以及产业生态的转型降级。 因而，灵雀云联结云原生技术实际联盟（CNBPA）和行业内头部厂商F5，独特发动了《第五期（2022-2023）传统行业云原生技术落地调研——金融篇》，将持续以聚焦行业的模式，深入探讨云原生技术对金融行业带来的冲击与改革。 本期调研将连续2018年以来此系列调研的钻研办法，从云原生技术全栈视角，对金融企业目前高度关注的容器、微服务、DevOps、平台工程、FinOps等热门畛域和行业趋势动手，全面摸底云原生技术的利用状况和落地成熟度，心愿能为2023年度金融行业IT建设提供借鉴，减速数字金融倒退。 调研期间，共计收到了 294 份无效问卷，统计分析了来自银行、保险、证券和其余金融机构等不同细分畛域、不同规模企业的云原生利用状况。本次调研与去年相比，更具体地评估了云原生在金融行业的利用现状，同时深入分析了金融行业在容器、微服务、DevOps、平台工程、FinOps等畛域的具体利用实际。您能够从本报告中，更加深刻地理解云原生技术在金融行业的落地成熟度和将来发展趋势。 调研后果01 云原生在金融行业进一步遍及，越来越多的中小型金融机构开始步入云原生化过程从往年受访企业的IT服务器规模和研发团队规模来看，采纳云原生技术的企业，从今年规模较大的金融机构（500台服务器以上），逐步向中小型金融机构（500台服务器以下）偏移，云原生技术在中小IT规模金融机构的使用率和普及率有所增加，整体出现从头部向腰部下沉的趋势，越来越多的区域性股份制商业银行、城市商业银行（含城市信用社和农村信用社），以及保险、证券、资管公司也开始全面拥抱云原生技术。 02 混合多云部署模式已成为支流从云服务采纳状况来看，92%左右的受访企业示意曾经应用云服务，较去年有所晋升。同时，往年的调研数据显示，金融企业在构建云原生基础设施时，多云/混合云部署比例大幅攀升，较去年上涨近15%，混合多云部署模式曾经成为金融行业的支流趋势。 03 FinOps是老本治理新方向，云原生技术在升高运维老本、节俭硬件资源等方面具备显著劣势近年来，随着云计算、大数据、人工智能等技术的疾速倒退，金融企业面临着越来越大的IT老本压力。为此，越来越多的金融企业开始采纳FinOps理念，行将财务、经营和开发部门整合在一起，以升高IT老本并进步业务效率。调研数据显示，90%以上的金融企业通过云原生技术实现了IT老本的升高。在2022 CNBPA云原生最佳实际评比的获奖案例中能够看到，有很多金融企业通过采纳云原生技术在多个方面带来了可观收益。 04 平台工程成DevOps落地新趋势DevOps相干的调研数据显示，超四成的企业抉择引入商业化DevOps平台撑持DevOps落地，抉择采纳商业化DevOps平台曾经成为趋势。同时，在金融机构关注的云原生新兴方向中，平台工程占比最高。这也从侧面反映了平台工程在DevOps落地中的重要性。通过平台工程的构建，金融机构能够实现对基础设施和应用程序的对立治理和监控，实现疾速迭代和自动化部署，进步开发运维效率和协同性。 05 其余● 数字化转型下的金融企业偏向于采纳麻利的利用更新策略针对金融企业的敏态需要，利用更新的频率和效率显得更加重要。超64%的受访企业放弃着每周级或更快的更新频率。这表明金融企业在数字化转型的过程中，对利用更新的速度和效率有着较高的要求。 ● 内部负载平衡技术依然是实现云原生架构高可用的首选在云原生架构高可用及多集群流量治理方面，超过半数的受访者更加偏向采纳成熟稳固与简洁的计划，例如在云原生架构内部采纳负载平衡或DNS技术。大概23%的受访者会思考采纳联邦、服务网格等更加原生且更为简单的技术来实现集群架构自身的高可用与集群间流量治理。能够看出在金融畛域，成熟稳固且牢靠的技术仍然是用户的第一考量与抉择。 ● 裸金属服务器成为金融企业云原生基础设施新宠调研数据显示，相较于在虚拟机或传统物理机上部署容器，金融行业越来越偏向于将容器间接部署在裸金属服务器上，这个数字是去年的1.5倍。随着云原生技术的一直倒退和遍及，将有越来越多的金融机构开始摸索裸金属服务器上部署容器的形式，以冀望实现更高效、更灵便的云原生基础设施架构。 ● 微服务因其轻量、灵便的技术劣势，成为最受金融企业欢送的架构之一调研显示，超过60%的受访金融企业曾经开始应用微服务。对于金融行业而言，微服务架构有着独特的劣势。首先，金融业务的复杂性和安全性要求高，微服务架构的模块化和解耦个性使得零碎更加灵便和平安。其次，金融行业的业务规模宏大，微服务能够实现服务的程度伸缩，进步零碎的可用性和稳定性。此外，微服务能够更好地反对麻利开发和DevOps实际，进步团队的合作效率和软件交付速度。 ● 云原生转型架构革新难度大，超83%企业抉择与第三方技术厂商单干调研结果显示，零碎架构革新难度大成为了金融机构云原生转型面临的最大挑战。在此背景下，近97%的企业曾经或打算落地云原生平台，其中，与第三方技术厂商单干的企业占比高达83%以上，阐明企业更偏向于抉择引入第三方商业化厂商单干，以防止反复造轮子，缩短数字化转型周期、进步转型效率和降低成本。 论断从2023年的调研数据来看，云原生化曾经成为金融行业IT团队的必然选择，不同细分畛域、不同规模的金融机构都在踊跃拥抱云原生技术，摸索数字化转型新门路。其中，混合多云部署模式、FinOps和平台工程将是最受关注的畛域，这些趋势将进一步推动金融机构在数字化转型中的过程，并带来更高的效率和更好的客户体验。 咱们心愿本次调研能够为金融企业的云原生转型提供新思路，帮忙您开启云原生赋能金融数字化的新篇章。 理解更多扫描下方二维码，立刻获取完整版调研报告。 对于云原生技术实际联盟“云原生技术实际联盟”是由各行业云原生建设最佳实际企业以及行业顶尖的云原生平台提供商、行业解决方案与服务提供商联结发动的，汇聚国内外云原生畛域翻新利用与实际案例的技术生态联盟。 联盟聚焦Kubernetes、DevOps、微服务等前沿开源技术和理念，同时关注各行业企业建设云原生平台的胜利案例。为企业在不同行业场景下建设基于容器技术的云原生平台，实现自动化开发、测试、运维一体化过程并全面拥抱微服务提供门路参考和全方位反对。 作为全国首个以云原生技术利用实际为外围的组织，联盟将恪守“凋谢、交融、翻新、共赢”的理念，致力于推动云原生技术产业化落地；构建技术带动实际、实际反哺技术的良性生态；晋升云原生技术在市场的影响力。 立刻退出联盟

4 月 23 日，朋湖网重磅公布《2023 年度中国数据智能行业优良厂商图谱》，涵盖感知智能、认知智能和决策智能三大畛域。在朋湖网公布的《2023 年度中国数据智能行业优良厂商图谱》中，将拓数派选为认知智能畛域优良厂商。 图为：《2023 年度中国数据智能行业优良厂商图谱》 这份图谱是朋湖网历时数月，通过企业的融资状况、技术专利、市场拓展、成长生命周期等维度进行剖析，并联合投资人等市场和资本反馈，通过资料申报、间接交换、外界评估、匿名拜访等穿插验证的筛选举荐机制，公布的优良厂商案例图谱。在这份图谱中，朋湖网依照数据智能倒退阶段，筛选涵盖数据智能产业中的感知智能、认知智能和决策智能的优良代表企业制成。 朋湖网创始人周元生示意：“近年来，随着大数据、人工智能、云计算等技术的一直倒退，数据智能产业迎来了疾速倒退的时代。数据智能产业是以后高速倒退的产业之一，也是将来最具后劲的产业之一。随着数据技术的一直倒退，数据智能产业的利用范畴也在不断扩大，将来会有近千亿规模的市场空间。朋湖网继续关注着这个行业优良企业的亮眼体现，咱们关注到拓数派作为一支立足国内的，寰球云上数据和数据计算畛域的重要翻新力量，有着寰球稀缺的守业团队，其创始人冯雷（Ray Von）领有北京大学双学位，研究生毕业于美国人工智能诞生地、计算机学科排名寰球第一的卡内基梅隆大学 (CMU)，目前出任 CMU 上海校友会主席。冯雷时任 Pivotal（中国）创始人期间，曾追随 Windows 操作系统之父 Paul Maritz 学生实现 Pivotal 中国的组建并协同 Pivotal 公司在美国纽交所上市，被业内誉为 PaaS 云（云原生）第一股，并将其主导研发的 Greenplum 开源数据库打造成为寰球标杆，在剖析型数据库行业中产生了不可漠视的影响力。咱们置信，在模型、数据和计算三个畛域穿插下，拓数派能为世界性的冲破带来来自中国的多维度翻新，旗下云原生虚构数仓 PieCloudDB 将为行业高质量倒退注入加速度。”  对于朋湖网朋湖网致力于服务中国新经济科技产业，推动新经济与产业交融，连贯企业、产业资本、政府、用户。对科技、企业服务等畛域进行深度报道和产业钻研，一直地为行业出现优质的内容和研究成果。 2020 年 12 月朋湖网作为发动单位之一成立 “上海市产业互联网专委会”、2021 年 10 月发动成立 “中国农村振兴数字产业联盟”。“第八届中国（杭州）国内电子商务博览会（杭州市人民政府主办）” 开幕式承办单位。2021、2022 为世界人工智能大会（WAIC）单干媒体。 成立至今，朋湖网公布多份行业钻研及行业剖析报告如《2021 中国农村振兴下的产业梯度转移钻研》、《2022 建设对立大市场下，隐衷计算的利用市场钻研》等研究成果。    

随着业务飞速发展，当贝的传统 IT 资产也渐显臃肿，为了防止制约倒退的瓶颈，痛定思痛，技术团队果决改革：外围业务云原生化之后，运维效率、整体稳定性和研发效率均失去了全面晋升。本文次要简述当贝技术团队云原生之路的背景诉求、落地办法和播种成绩。 前言当贝成立于 2013 年 8 月，中国出名的智能大屏增值服务提供商之一，中国大屏应用软件分会会长单位，是一家横跨软件、硬件和操作系统全生态的大屏端互联网平台型公司，致力于成为亿万家庭 AIoT 的外围入口和生存娱乐中心，间断多年入选将来独角兽榜单，国家级专精特新“小伟人”企业。 当贝云原生架构实际历程传统运维体系的三大痛点随着当贝的业务规模飞速发展，背地的 IT 技术也在不断更新迭代，IT 资产规模也在高速回升，不可避免地迎来一些挑战。其中，以运维体系的挑战最为显明，经团队总结，有以下三个较为突出的痛点。 人工运维效率低，危险大，老本高，资产治理艰难传统运维体系下，有大量人工参加。从各环境代码公布，到顶峰低谷的扩容缩容，再到各类证书、云服务器等云资产治理，这些环节，人工参与度越高，危险越大，即使运维人员有着超高程度，也很难保障短暂状况下不呈现任何失误或忽略。 同时，人工参与度越高，效率也就越低，合作老本越高。为保障稳定性，每一次线上零碎变更，都须要协调大量跨部门配合，常常须要研发、运维、测试等多个岗位的同学深夜参加。 随着当贝 OS、当贝音乐、当贝市场等业务倒退多点开花，IT 规模也急剧扩张，云资产治理也成为了较为突出的痛点。 稳定性挑战大，异样排查及复原老本过高当贝对系统稳定性、业务连续性有着极高要求。随着流量疾速减少，特地是在一些如春节联欢晚会这种状况下，流量往往以十倍乃至数十倍激增，对稳定性和容量布局造成极大压力。 同时，当生产环境产生异样，在传统的运维体系下，有着依赖链路简单、排查难度大、定位工夫久、牵扯人员广等外围痛点。 对此，整个服务端部门定下了 1-5-10 快恢及 99.95%可用性两大要求，精准洞察问题外围，同时领导了解决思路。 在当贝各项业务高速倒退的状况下，落实这两大要求，是整个服务端团队火烧眉毛且必须打赢的攻坚战。 自建可观测体系落地简单，易用性和稳定性差，运维老本高任何成规模的 IT 零碎，可观测体系都是极其重要的底层基石，它使 IT 架构的整体设计如依赖拓扑、调用链路追踪、技术标准、运行状况、稳定性等诸多信息清晰出现，除了定位排查以外，更有助于提前发现历史的架构设计缺点、零碎瓶颈并及时解决，在保障业务间断的同时，高效撑持业务倒退与迭代。 在晚期阶段，为保障各项零碎疾速上线、业务高速迭代，存在一些技术架构考虑不周、设计有余的状况，具体表现为选型不一、业务高度耦合、调用链路过长、云资源抉择不合理、治理不清晰等。这些因素组合在一起，造成宏大的历史包袱，在过来传统的运维体系下，曾自建一些可观测组件或框架，但却面临着稳定性差、运维老本高难度大、易用性差、体系不对立等各方面问题，以至于未能齐全施展其应有的价值。 现在，在当贝业务规模继续减速成长的背景下，亟需落地一套全面易用、平安稳固、性价比高的可观测体系，以反对公司行稳致远。 云原生架构的建设面对传统运维体系非常突出的三大外围痛点，为防止其在将来对当贝可继续倒退的策略造成制约，当贝技术团队进行了宽泛钻研、深入分析、踊跃调研，最终将眼光瞄准在了云原生架构上。 正如阿里云在《云原生架构白皮书》中所言：云计算的下一站，是云原生；IT 架构的下一站，是云原生架构。 当贝技术团队极为认同这个观点，云原生是一个确定的技术发展趋势，越来越多的公司拥抱云原生，利用云原生实现更高效率的倒退及翻新。 经全局视角下的充沛评估，当贝技术团队在研发总监张子枭的领导下，提出云原生化、中台化、微服务化、数字化四大技术战略目标，决定全面转型云原生架构。 只有利用云原生架构，齐全解决传统运维体系危险高、效率低下的痛点，能力具备对局部积弊已久、陈疾顽疴的老零碎进行中台化和微服务化革新。 而在云厂商的抉择上，思考到阿里云是国内云计算的布道师与发挥者，实力寰球当先，对云原生技术倒退的奉献引人注目，同时其汇聚了业内最顶尖的人才、最丰盛的教训案例、最牢靠的成熟度，以及其“客户第一”的价值观，当贝技术团队最终抉择借力阿里云落地云原生架构转型。 容器化上云在云原生架构基础设施畛域，Kubernetes 是当之无愧的领头羊。 相比于依赖虚机自建集群而言，由阿里云提供的 ACK 服务，有着更优弹性、更优韧性、免运维、更高效的资源管理等长处，同时无缝集成了大量阿里云产品。 依赖 ACK 及其集成的大量产品，当贝技术团队极快地实现了外围服务的容器化革新，并顺利完成灰度公布、全面切流等工作。值得一提的是，在新架构落地过程中，当贝技术团队不可避免地会遇到疑难杂症困扰，但正因为有阿里云大量的教训案例撑持、最佳实际领导，包含容量布局、可观测、平安防护、稳定性等诸多方面，使整个上云过程始终处于牢靠状态。 实现上云后，这些外围服务从开发态测试态，变更与运行态，贯通服务整个生命周期，效率都失去了极大晋升。 利用云原生 Devops，我的项目公布与协同效率晋升 300%，完全避免人工运维干涉的高风险性；利用 ACK 服务与服务器资源人造解耦的个性，齐全解脱了基础设施运维的低效困扰；利用 HPA+CronHPA，从容应对流量顶峰低谷…… 不仅如此，这些外围服务整体资源利用率晋升了 20%，运维效率更是晋升了 500% 以上，使更大规模的 IT 资源管理成为可能。 在深度参加上云革新的过程中，当贝技术团队积淀了大量的常识与教训，为公司技术储备添砖加瓦，同时仍在积极探索云原生技术。 云原生网关在引入 ACK 作为云原生的基础设施的同时，当贝技术团队也引入了 MSE 云原生网关作为流量治理组件。 ...

“云数据库曾经成为数据库行业的事实标准。”3月24日，在北京召开的阿里云瑶池数据库峰会上，阿里云数据库产品事业部负责人李飞飞示意，云数据库是一个全新的赛道，在这条赛道上云厂商具备先发劣势。以PolarDB为代表的瑶池数据库打造“云原生+一站式”的数据管理与服务，正在率领国产数据库实现换道超车。 过来40多年，数据库技术始终在迭代，而进入到数字化和云计算时代后，云数据库就以高牢靠、高可用、高性能，高弹性、自动化智能部署与运维等压倒性劣势，对传统数据库市场发动了冲击。云数据库不仅能安稳撑持数字时代的业务峰值，在弹性场景下，老本仅为传统商业数据库的十分之一。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1180934 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

Kubectl patch 命令容许用户对运行在 Kubernetes 集群中的资源进行部分更新。相较于咱们常常应用的 kubectl apply 命令，kubectl patch 命令在更新时无需提供残缺的资源文件，只须要提供要更新的内容即可。 Kubectl patch 反对以下 3 种 patch 类型： strategic patch（默认）：依据不同字段 patchStrategy 决定具体的合并 patch 策略。 Strategic merge patch 并非通用的 RFC 规范，而是 Kubernetes 特有的一种更新 Kubernetes 资源对象的形式。与 JSON merge patch 和 JSON patch 相比，strategic merge patch 更为弱小。JSON merge patch：遵循 [JSON Merge Patch, RFC 7386[1]](https://tools.ietf.org/html/rfc7386) 标准，依据 patch 中提供的冀望更改的字段及其对应的值，更新到指标中。JSON patch：遵循 [JSON Patch, RFC 6902[2]](https://tools.ietf.org/html/rfc6902) 标准，通过明确的指令示意具体的操作。接下来对 Kubectl patch 的 3 种类型进行介绍。 1 应用 strategic merge patch 更新资源上面是具备 2 个正本的 Deployment 的配置文件。 ...