阿里云

<article class=“article fmt article-content”><p> 随着大模型能力越来越弱小，利用大语言模型进行智能答疑曾经成为了一个十分广泛和常见的场景。然而，各个产品或业务方要可能精确无效地进行答疑，仅依附大模型的通用能力是远远不够的，这时候利用公有畛域FAQ文档进行大模型的检索加强生成往往能够无效解决上述问题。<br/>通义百炼平台提供了十分简便地畛域常识问答大模型利用创立办法，而计算巢AppFlow能够通过简略配置将通义百炼模型利用与钉钉机器人串联起来，从而实现精准无效的畛域常识答疑机器人性能。<br/> 上面，将具体介绍配置和应用办法，如果您也有相似需要就一起来试试吧～</p><h2>配置步骤</h2><h3>创立百炼利用</h3><ol><li>筹备好您的FAQ文档等内容，登陆通义百炼控制台，点击左侧利用核心-企业知识库。抉择上传企业常识，并在下方“抉择常识检索范畴”中抉择或新建常识标签。</li></ol><p><br/></p><ol start=“2”><li>点击左侧利用广场，抉择“企业常识检索加强”-“创立利用”，输出利用名称后点击确定。</li></ol><p></p><ol start=“3”><li>抉择“根据标签筛选”，抉择您须要用作答疑的文档的标签值，点击创立实现。</li></ol><p></p><ol start=“4”><li>找到刚刚创立的利用并点击“调用”按钮。在弹出框中找到agentKey和appId并复制保留。</li></ol><p></p><h3>配置连贯流</h3><ol><li>拜访AppFlow控制台，点击左侧菜单栏“连贯流”，抉择“创立连贯流”，填写以后连贯流的根本信息。</li></ol><p></p><ol start=“2”><li>“抉择触发事件”，找到并点击抉择“钉钉机器人”，触发事件抉择“收到文本音讯时”，点击“保留，进入下一步”</li></ol><p></p><ol start=“3”><li>找到“阿里云百炼”连接器，抉择执行动作“在线推理”。</li></ol><p><br/></p><ol start=“4”><li>点击“抉择链接凭证”，抉择“增加新凭证”，抉择您领有“AliyunSFMFullAccess”或相应权限的RAM角色名称。</li></ol><p></p><ol start=“5”><li>点击“入参配置”，业务空间标识和利用Id别离填写在百炼平台获取的AgentKey和appId字段。</li><li>在“Prompt提醒词”右侧抉择插入变量，能够利用钉钉机器人收到的音讯作为参数。例如下图：</li></ol><p></p><ol start=“7”><li>填写实现后点击“”配置模型推理后的音讯发送回钉钉的执行动作。抉择“钉钉机器人”，执行动作抉择发送文本音讯，点击“保留，进入下一步”进行参数配置。</li></ol><p></p><ol start=“8”><li>Webhook地址点击右侧“插入变量”，抉择节点1的“会话回调地址”</li></ol><p><br/>“加签”在稍后创立完机器人后获取并填写，这里临时跳过。<br/>“本文内容”配置您的执行动作中理论代表您模型推理后果的字段。<br/></p><ol start=“9”><li>点击保留即可实现配置。回到页面再次点击编辑，进入流编辑页面，点击第一个节点的编辑按钮，能够获取调用webhook地址，请保留改地址后续在钉钉机器人配置中应用。</li></ol><p></p><h3>创立钉钉机器人（应用Outgoing性能，更简略）</h3><ol><li>间接在须要退出机器人的群聊中进入机器人治理页面增加自定义机器人，</li></ol><p><br/></p><ol start=“2”><li>填写机器人根本信息。平安设置抉择“加签”，复制签名密钥，回到Appflow,点击左侧菜单栏“连贯流”，找到刚创立的连贯流并点击详情。进入连贯流详情页点击“编辑”。</li></ol><p><br/><br/></p><ol start=“3”><li>进入流根本信息填写页面，间接点击下一步，进入流配置页面。点击“步骤3：发送文本信息”的编辑按钮，点击“入参配置”，在加签Tab填写钉钉机器人生成的签名，点击保留即可。</li></ol><p><br/><br/></p><ol start=“4”><li>回到钉钉机器人页面，勾选“开启Outgoing机制”，在POST地址栏填写第一步中的Webhook地址，点击实现即可。</li></ol><p></p><ol start=“5”><li>在群里中@机器人即可实现对话</li></ol><p></p><h3>三、创立钉钉机器人（应用钉钉开放平台）</h3><ol><li>拜访钉钉开放平台，分割您的组织管理员获取开发权限。而后点击创立利用。成为钉钉开发者的步骤能够参考文档https://open.dingtalk.com/document/orgapp/become-a-dingtalk-developer</li></ol><p></p><ol start=“2”><li>抉择左侧“机器人”Tab，而后点击右侧“创立利用”按钮。填写您的“利用名称”和“利用形容”，上传利用图标并点击保留。</li></ol><p><br/></p><ol start=“3”><li>点击保留后跳转到利用开发页面，下来以后页面到最下方抉择“机器人”并点击增加。点击“机器人配置”按钮开展机器人配置信息。</li></ol><p><br/></p><ol start=“4”><li>填写相干必填信息。音讯接管模式请抉择“HTTP”模型，页面会呈现“音讯接管地址”输入框。在这里填写刚刚在AppFlow获取的地址。</li></ol><p></p><ol start=“5”><li>点击调试按钮。能够钉钉扫码进群调试机器人。确认无误后点击公布。</li><li>回到利用开发页面，点击刚刚创立的利用名称进入利用详情页面。点击左侧菜单栏最下方的“版本治理与公布”，进入到版本公布与治理，点击右上角“创立新版本”按钮，输出版本相干信息，并抉择适合的“利用可见范畴”。</li></ol><p><br/><br/></p><ol start=“7”><li>点击保留将进入权限审批环节，审批完结后利用将主动公布。如果您曾经有权限了能够点击间接公布。</li></ol><p></p><ol start=“8”><li>去您想要增加对话机器人的群里增加机器人。@机器人即可与通义千问机器人进行对话啦！</li></ol><p></p><h2>写在最初</h2><p>Appflow是阿里云计算巢团队自主研发的一款利用与数据集成平台，目前开发团队曾经反对了泛滥公共连接器，您能够纵情施展您的设想，应用AppFlow为您免去繁琐的反复接入和开发工作，为你的工作提速提效！<br/>点击页面左侧"连贯流"Tab，去创立你本人的Flow吧~<br/></p><h2>分割咱们</h2><p>有任何疑难或者需要或者合作意向都能够退出咱们的官网反对钉钉群（群号 69295006877）～欢送大家一起退出群聊交换，为工作和Coding提效～<br/></p></article>

<article class=“article fmt article-content”><p>在云原生时代，微服务、容器化等技术从根本上扭转了利用研发/运维形式。在晋升效率的同时，也带来了更简单的故障剖析流程，这使得可观测成为云原生架构下十分重要的课题。本次流动将由阿里云技术专家为咱们带来可观测性实践经验和技术计划分享。</p><p><strong>流动工夫：</strong> </p><p>3 月 8 日 14:00-18:00</p><p><strong>流动地点：</strong></p><p>北京朝阳区融科望京核心 B 座 18 层二月半茶文化空间</p><p><strong>分享主题：</strong></p><p>1）阿里云可观测构建全栈可观测能力丨阿里云解决方案架构师 李晨</p><p>2）以利用为核心的端到端可观测最佳实际丨阿里云产品专家 汪宁</p><p>3）面向智算服务，搭建指标监控体系丨阿里云技术专家 曾庆国</p><p>4）智能洞察加持下，如何助力根因剖析与告警收敛丨阿里云技术专家 董善东</p><p> 干货满满，名额有限，点击下方立刻报名： <br/><em>https://survey.aliyun.com/apps/zhiliao/g-pTPmngW</em></p><p></p></article>

<article class=“article fmt article-content”><p>作者：元毅、庄宇</p><p>如何打造云上（公共云）、云下（IDC 数据中心）对立的云原生 Serverless 利用平台，首先咱们来看一下 ChatGPT 4 会给出什么样的答案：</p><p>如何打造云上、云下对立的云原生 Serverless 利用平台？</p><pre><code>打造云上、云下对立的云原生 Serverless 利用平台须要思考几个要害因素，包含技术架构设计、开发生态系统的构建、以及运维治理等多个方面的协同工作。以下是一些步骤和倡议：1. 对立的 API 和服务界面：为了实现云上云下的一体化，须要定义对立的 API 和服务界面，确保不同环境中的利用能够无缝迁徙和互操作。2. 容器化：利用容器技术（如 Docker）将利用打包，使得它们能够在任意环境中以雷同的形式运行。3. Kubernetes：采纳 Kubernetes 作为容器编排工具，以便在云上云下实现统一的利用部署、治理和扩缩能力。4. 服务网格：利用服务网格技术（如 Istio）来治理服务间通信，实现简单微服务架构中的服务发现、负载平衡、故障解决和安全性。5. Serverless 框架：抉择或开发适宜的 Serverless 框架（如 Knative 或 OpenFaaS），以提供无服务架构的能力，如事件驱动、主动扩缩容等。6. 开发者平台和 CI/CD：构建一个集成了开发、测试、部署工具的平台，并采纳 CI/CD 流程自动化代码的集成和部署。7. 分布式云和混合云策略：确保平台反对分布式云和混合云策略，这样利用既能够在私有云上运行，也能够在公有云或者边缘计算环境中运行。8. 数据一致性和存储解决方案：设计高效的数据存储和同步机制，确保云上云下数据的一致性和可靠性。9. 监控和日志：集成监控和日志零碎，以便实时跟踪利用状态并在必要时进行调试或故障排除。10. 安全性：确保零碎满足平安要求，包含网络安全、数据加密、访问控制以及合规性。11. 用户和开发者文档：提供具体的用户和开发者文档，帮忙用户了解平台的应用办法和最佳实际。12. 社区和生态系统：构建一个弱小的社区和生态系统，激励开发者参加，奉献代码，独特改良平台。通过上述步骤，你能够创立一个可能平滑地在云上云下运行的 Serverless 利用平台，缩小运维压力，放慢利用的交付速度，并晋升利用的可扩展性和弹性。</code></pre><p>是不是感觉 AI 答复的很全面，没错，不过总结来说下面的答复其实要害就 2 点：分布式云/混合云策略以及标准化的技术计划。</p><h2>分布式云趋势</h2><p>依据 Gartner 报告中，到 2025 年，50% 的大型企业将在他们抉择的地区通过『分布式云』服务实现业务模式转型。另外依据 IDC 报告中，2021 年 86% 企业采纳分布式云混合云架构，仅有 14% 客户抉择独自公共云。Gartner 报告指出，平安、运维复杂性、财务复杂性是分布式云架构的次要挑战。</p><p></p><h2>客户的诉求</h2><ul><li>技术选型的诉求：如何抉择标准化的 Serverless 技术计划，做到云上、云下技术栈对立</li><li>老本的诉求：如何升高资源以及运维老本</li><li>稳定性的诉求：如何保障服务运行的稳定性</li><li>弹性诉求：云下 IDC 集群也能够弹性扩大资源，有限扩容 Serverless 利用</li></ul><h2>为什么是 Knative</h2><p>Knative 是一款基于 Kubernetes 的开源 Serverless 利用编排框架, 以其云原生、跨平台的 Serverless 利用编排劣势，成为广受欢迎的开源 Serverless 框架。</p><p>作为一个通用的 Serverless 框架，Knative 由 3 个外围组件组成：</p><ul><li><strong>Serving：</strong> 治理 Serverless 工作负载，能够和事件很好地联合，并提供基于申请驱动的主动扩缩容的能力。在没有服务须要解决时，可缩容至零个实例。Serving 组件的职责是管理工作负载以对外提供服务。主动伸缩是 Knative Serving 组件最为重要的个性之一，目前伸缩边界无限度。同时，Knative Serving 还反对灰度公布。</li><li><strong>Eventing：</strong> 提供了事件的接入、触发等一整套事件治理的能力。Eventing 组件针对 Serverless 事件驱动模式具备一套残缺的设计，包含内部事件源的接入、事件注册和订阅、以及对事件的过滤等性能。事件模型能够无效地解耦生产者和消费者的依赖关系。生产者能够在消费者启动之前产生事件，消费者也能够在生产者启动之前监听事件。</li><li><strong>Function：</strong> Knative Functions 为您提供了一个简略的形式来创立、构建和部署Knative服务。您无需深刻理解底层技术栈（如 Kubernetes、容器和 Knative），通过应用 Knative Functions，即可将无状态、事件驱动的函数作为 Knative 服务部署到 Kubernetes 集群中。</li></ul><p></p><h2>分布式云容器平台 ACK One</h2><p>分布式云容器平台 ACK One（Distributed Cloud Container Platform for Kubernetes）是阿里云面向混合云、多集群、分布式计算、容灾等场景推出的企业级云原生平台。</p><p></p><h2>打造云上、云下对立云原生 Serverless 利用平台</h2><p>容器服务 ACK One 以后已反对托管 Knative 能力，用户能够借助 ACK One + Knative 打造云上、云下对立云原生 Serverless 利用平台，并通过 Knative 轻松应用云资源，云下 IDC 集群也能够弹性扩大资源，有限扩容 Serverless 利用。</p><p></p><p><strong>劣势：</strong></p><ul><li>ACK One 注册集群接入 IDC 自建集群，提供与 ACK 统一的运维体验</li><li>Knative 应用体验统一，组件免运维</li><li>ACK One 注册集群为 IDC 自建集群提供云上弹性能力，联合弹性容器实例 ECI，随时按需应用云上资源</li><li>公共云 ACK 集群+ 云下 IDC 机房自建集群，提供更高稳定性保障</li></ul><h2>基于 ACK One+Knative 部署 LangChain-Chatchat</h2><p>LangChain-Chatchat 是一个开源的利用 langchain 思维实现的基于本地知识库的问答利用。咱们看一下如何基于 ACK One + Knative 部署 LangChain-Chatchat 利用。</p><h3>前提条件</h3><ul><li>已通过容器服务 Kubernetes 版接入一个注册的 Kubernetes 集群。具体操作，请查看创立注册集群 <strong>[</strong> <strong>1]</strong> 。</li><li>只反对线下集群是 Calico 路由反射模式或者 Cilium BGP 路由模式。</li></ul><h3>部署 Knative 服务</h3><ol><li>登录容器服务治理控制台 <strong>[</strong> <strong>2]</strong> ，在左侧导航栏抉择<strong>集群</strong>。</li><li>在<strong>集群列表</strong>页面，单击指标注册集群名称，而后在左侧导航栏，抉择<strong>利用 > Knative。</strong></li><li>在 <strong>Knative</strong> 页面的<strong>服务治理</strong>页签下，抉择<strong>命名空间</strong>为 <strong>default</strong>，而后单击<strong>应用模板创立</strong>，将以下 YAML 示例粘贴至模板，最初单击<strong>创立</strong>，创立一个名为 <strong>knative-llc-demo</strong> 的服务。</li></ol><pre><code>apiVersion: serving.knative.dev/v1kind: Servicemetadata: name: knative-llc-demospec: template: metadata: annotations: autoscaling.knative.dev/maxScale: ‘100’ autoscaling.knative.dev/minScale: ‘1’ k8s.aliyun.com/eci-extra-ephemeral-storage: 80Gi k8s.aliyun.com/eci-use-specs: ’ecs.gn5-c4g1.xlarge,ecs.gn5i-c8g1.2xlarge,ecs.gn5-c8g1.2xlarge’ spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/chatchat:0.2.7 imagePullPolicy: IfNotPresent ports: - containerPort: 8501 name: http1 protocol: TCP name: lcc</code></pre><p>在<strong>服务治理</strong>页签，获取服务的<strong>拜访网关</strong>和<strong>默认域名</strong>。</p><p></p><ol><li>将 <strong>knative-llc-demo</strong> 服务的网关地址与须要拜访的域名进行 Host 绑定，在 Hosts 文件中增加绑定信息。绑定示例如下：</li></ol><pre><code>39.104.58.99 knative-llc-demo.default.example.com # 网关IP和域名请以您的理论数据为准。</code></pre><ol start=“2”><li>实现 Host 绑定后，在<strong>服务治理</strong>页签，单击 <strong>knative-llc-demo</strong> 服务的<strong>默认域名</strong>，拜访 LangChain-Chatchat。如图所示，可通过域名间接对 LangChain-Chatchat 进行拜访。</li></ol><p></p><h2>小结</h2><p>以后阿里云容器服务 ACK One 已反对托管 Knative 能力，为云上、云下提供标准化的 Serverless 利用能力。通过 ACK One 注册集群接入 IDC 自建集群，提供与 ACK 统一的运维体验，并取得云上弹性能力，联合弹性容器实例 ECI，随时按需应用云上资源，有限扩大 Serverless 利用。想取得具体介绍，可浏览阿里云 ACK One 注册集群 <strong>[</strong> <strong>3]</strong> 和 ACK One Knative <strong>[</strong> <strong>4]</strong> 。</p><p>欢送应用钉钉搜寻 ACK One 客户交换群的群号：<em>35688562</em> 或 Knative 交换群：<em>23302777</em> 退出咱们。</p><p><strong>参考链接：</strong></p><p>[1] 创立 ACK One 注册集群</p><p><em>https://help.aliyun.com/zh/ack/distributed-cloud-container-pl…</em></p><p>[2] 容器服务治理控制台</p><p><em>https://cs.console.aliyun.com</em></p><p>[3] 阿里云 ACK One 注册集群</p><p><em>https://help.aliyun.com/zh/ack/distributed-cloud-container-pl…</em></p><p>[4] ACK One 注册集群 Knative*</p><p>https://help.aliyun.com/zh/ack/distributed-cloud-container-pl…*</p></article> ...

作者：拂衣 PTS 简介性能测试 PTS（Performance Testing Service）是阿里云上一款简略易用，具备弱小的分布式压测能力的 SaaS 压测平台。PTS 能够模仿简单的业务场景，并疾速精准地调度不同规模的流量，同时提供压测过程中多维度的监控指标和日志记录。用户无需筹备资源，即可按需发动压测工作，监控压测指标，获取压测报告，进而可能高效率、全方位地验证业务站点的性能、容量和稳定性。 阿里云压测平台演进之路阿里云压测平台 PTS，由阿里云可观测团队倾心打造，应双十一稳定性和容量布局的需要背景而诞生，随高可用、中间件上云而对外输入产品能力。整体演进分以下 5 个阶段： 2010 年-阿里巴巴容量布局平台在此之前，阿里巴巴大促流动的容量布局次要通过人工估算的形式来实现的。各个系统的负责同学聚在一起开个会，将信息汇总到一起，按专家教训就把容量布局的机器估算给定下来了。而且，各个系统通常都留了比拟大的机器冗余，即便估算的不准也不会造成大的业务影响。 此时，容量计算的公式被第一次提了进去，通过指标容量/单机容量下限，失去各利用须要的机器资源数，再加上肯定比例的冗余量，就是大促时须要的总资源数。 在阿里容量布局平台的 1.0 版本当中，通过对各业务零碎线下环境单机压测，来获取各服务的单机容量下限，实现了从人工容量布局到系统化容量布局的适度。 2013 年-阿里巴巴全链路压测-流量平台随着双十一业务规模疾速拉升，分布式系统架构的技术组件越来越多，利用的上下游依赖关系也越来越简单。双十一当天 0 点到来的时候，从 CDN 到接入层、前端利用、后端服务、缓存、存储、中间件整个链路上都面临着微小流量，这个时候利用的服务状态除了受本身影响，还会受到依赖环境影响，并且影响面会持续传递到上游，哪怕一个环节呈现一点误差，误差在上下游通过几层累积后会造成什么影响谁都无奈确定。因为各层依赖的不确定性，无奈再基于单业务容量下限布局全局容量。 所以咱们建设了全链路压测机制，通过全面仿真双十一业务流量，咱们的零碎可能提前经验几次“双十一”，让容量的不确定性问题提前裸露并解决。 流量平台是全链路压测的 CPU，可能模拟出双十一上亿用户的仿真流量，制作每秒数十万次用户行为的超大规模流量。次要由两大部件形成：1）全链路压测操控核心，进行压测的配置和操控、数据的监控以及对压测引擎集群的管控；2）压测引擎，由控制台对立管控，部署在外网 cdn 集群，进行登陆、session 同步，发送各种协定的压测申请、状态统计。 2013 年之后，全链路压测成为双十一、双十二等大促备战最重要的稳定性验证工具，随着业务的倒退一直进化，继续施展着不可代替的作用。 2018 年-阿里云 PTS 1.0：阿里云压测产品公布在云计算的浪潮下，越来越多的用户开始基于阿里云上的根底产品设计本人的架构。在 2018 年，咱们正式公布了阿里云压测产品：PTS，将阿里巴巴团体压测平台的技术架构迁徙至阿里云，对外部用户提供 SaaS 化的压测产品。PTS 1.0 外围能力包含： 有限靠近实在的流量：业务场景中无论是高并发要求还是发动端的分散度，笼罩三四线城市次要运营商的节点广度都能做到真正模仿用户行为，客户端到服务端间简单的网络瓶颈也能暴露无遗，压测后果更加全面和真实可信。操作简略易上手：不须要专门的性能测试团队或者测试背景的积攒，齐全面向开发的交互设计，开发自测试，投入产出比高。多维度施压：反对并发和 RPS 双维度。压力动静调整：反对压测能力动静批改。2020 年-阿里云 PTS 2.0：施压能力、产品体验再降级随着 PTS 1.0 用户规模的不断扩大，越来越多的用户在不同的业务场景对 PTS 提出了反对超高并发的压测需要，甚至超过了团体双十一的并发量级，典型场景如：春晚红包压测、保险开门红压测、考试报名压测等。PTS 2.0 通过优化资源调度和施压引擎性能，提供了百万并发、千万 QPS 的压测能力，间断撑持了屡次春晚红包流动等顶级流量压测。 同时，PTS 2.0 降级了流量录制和多协定场景化性能，晋升了产品体验： 流量录制性能：容许录制理论用户操作，以便创立实在的用户行为模仿。多协定反对：对流媒体、MQTT、RocketMQ、Kafka、JDBC、Redis、Dubbo  等协定反对白屏化压测配置，扩宽测试场景。2024 年-阿里云 PTS 3.0：可观测、智能化、开源加持的下一代压测平台在 PTS 1.0 和 2.0 的继续演进中，PTS 在产品体验、施压能力都失去了大幅晋升。要做一轮残缺的容量布局，用户还须要解决以下问题： ...

作者：潘伟龙（豁朗） 背景日志服务 SLS 是云原生观测与剖析平台，为 Log、Metric、Trace 等数据提供大规模、低成本、实时的平台化服务，基于日志服务的便捷的数据接入能力，能够将系统日志、业务日志等接入 SLS 进行存储、剖析；阿里云 Flink 是阿里云基于 Apache Flink 构建的大数据分析平台，在实时数据分析、风控检测等场景利用宽泛。阿里云 Flink 原生反对阿里云日志服务 SLS 的 Connector，用户能够在阿里云 Flink 平台将 SLS 作为源表或者后果表应用。 阿里云 Flink SLS Connector 对于结构化的日志十分间接，通过配置，SLS 的日志字段能够与 Flink SQL 的 Table 字段列一一映射；而后仍有大量的业务日志并非齐全的结构化，例如会将所有日志内容写入一个字段中，须要正则提前、分隔符拆分等伎俩才能够提取出结构化的字段，基于这个场景，本文介绍一种应用 SLS SPL 配置 SLS Connector 实现数据结构化的计划，笼罩日志荡涤与格局规整场景。 弱结构化日志解决的痛点弱结构化日志现状与结构化解决需要的矛盾日志数据往往是多种起源，多种格局，往往没有固定的 Schema，所以在数据处理前，须要先对数据进行荡涤、格局规整，而后在进行数据分析；这类数据内容格局是不固定的，可能是 JSON 字符串、CSV 格局，甚至是不规则的 Java 堆栈日志。 Flink SQL 是一种兼容 SQL 语法的实时计算模型，能够基于 SQL 对结构化数据进行剖析，但同时也要求源数据模式固定：字段名称、类型、数量是固定；这也是 SQL 计算模型的根底。 日志数据的弱结构化特点与 Flink SQL 结构化分析之间有着一道鸿沟，逾越这道鸿沟须要一个中间层来进行数据荡涤、规整；这个中间层的计划有多种抉择能够应用，上面会对不同的计划做简略比照，并提出一种新的基于 SLS SPL 的计划来轻量化实现解决数据荡涤规整的工作。 弱结构化日志数据上面是一条日志示例，日志格局较为简单，既有 JSON 字符串，又有字符串与 JSON 混合的场景。其中： Payload 为 JSON 字符串，其中 schedule 字段的内容也是一段 JSON 构造。requestURL 为一段规范的 URL Path 门路。error 字段是前半部分蕴含 CouldNotExecuteQuery：字符串，后半局部是一段 JSON 构造。tag__:__path 蕴含日志文件的门路，其中 service_a 可能是业务名称。caller 中蕴含文件名与文件行数。{ "Payload": "{\"lastNotified\": 1705030483, \"serverUri\": \"http://test.alert.com/alert-api/tasks\", \"jobID\": \"44d6ce47bb4995ef0c8052a9a30ed6d8\", \"alertName\": \"alert-12345678-123456\", \"project\": \"test-sls-project\", \"projectId\": 123, \"aliuid\": \"1234567890\", \"alertDisplayName\": \"\\u6d4b\\u8bd5\\u963f\\u91cc\\u4e91\\u544a\\u8b66\", \"checkJobUri\": \"http://test.alert.com/alert-api/task_check\", \"schedule\": {\"timeZone\": \"\", \"delay\": 0, \"runImmediately\": false, \"type\": \"FixedRate\", \"interval\": \"1m\"}, \"jobRunID\": \"bf86aa5e67a6891d-61016da98c79b-5071a6b\", \"firedNotNotified\": 25161}", "TaskID": "bf86aa5e67a6891d-61016da98c79b-5071a6b-334f81a-5c38aaa1-9354-43ec-8369-4f41a7c23887", "TaskType": "ALERT", "__source__": "11.199.97.112", "__tag__:__hostname__": "iabcde12345.cloud.abc121", "__tag__:__path__": "/var/log/service_a.LOG", "caller": "executor/pool.go:64", "error": "CouldNotExecuteQuery : {\n \"httpCode\": 404,\n \"errorCode\": \"LogStoreNotExist\",\n \"errorMessage\": \"logstore k8s-event does not exist\",\n \"requestID\": \"65B7C10AB43D9895A8C3DB6A\"\n}", "requestURL": "/apis/autoscaling/v2beta1/namespaces/python-etl/horizontalpodautoscalers/cn-shenzhen-56492-1234567890123?timeout=30s", "ts": "2024-01-29 22:57:13"}结构化数据处理需要对于这样的日志提取出更有价值的信息须要进行数据荡涤，首先须要提取重要的字段，而后对这些字段进行数据分析；本篇关注重要字段的提取，剖析依然能够在 Flink 中进行。 ...

Sora 的初现，曾经震惊了整个行业，正在缓缓的颠覆一些垂直行业。在惊叹之余，预计大部分人都在思考如何顺应潮流，驾驭趋势。 InfoQ 正在筹备 2024 年 6 月 14-15 日深圳 ArchSummit 架构师峰会，阿里云云原生利用平台负责人丁宇受邀在会议上演讲，他的演讲会围绕 AI 颠覆程序员 / 开发者生产力开展，随着大模型、AI 的疾速倒退， AI 编程助手的引入为软件开发带来了质的飞跃。 进入大模型时代，AI 编程的倒退实现了哪些冲破，并从寰球视角来看，开发者对于 AI 编程的需要差别、AI 编程工具能力。AI 编程工具基于大模型的设计要点、难点、改良思路，这些都是基于丁宇多年的工作教训而来的。 当然，他也会介绍阿里的大模型技术是如何借助 AI 编程能力来晋升程序员的生产力的，也会介绍将来在 AI 编程畛域有哪些趋势等前瞻性思考。帮忙听众理解 AI 编程带来的革命性巨变，全面理解 AI 编程的设计要点、落地实现和将来趋势。 嘉宾介绍 丁宇（叔同）2010 年退出阿里巴巴，目前是阿里云研究员，云原生利用平台负责人，十次参加阿里双 11，构建了互联网分布式高可用技术体系，并负责阿里容器基础设施，推动对立调度、混合部署、云原生上云、Serverless 架构、大模型时代 AI 工程化等。此前在信通院云原生产业大会上，丁宇被授予年度云原生产业领军人物的名称。 参加体验赢惊喜大会门票 通义灵码， 是阿里云出品的一款基于通义大模型的智能编码辅助工具，提供行级/函数级实时续写、自然语言生成代码、单元测试生成、代码优化、正文生成、代码解释、研发智能问答、异样报错排查等能力，并针对阿里云的云服务应用场景调优，助力开发者高效、晦涩的编码。 官网链接：https://tongyi.aliyun.com/lingma 本次ArchSummit 架构师峰会期间，通义灵码联结InfoQ 策动发动 AI编程体验流动，点击进入小程序，参加通义灵码体验抽奖流动，有机会赢寰球架构师峰会专属收费门票（票价5440元） 点击此处，进入通义灵码官网疾速体验。

作者：杨磊 青团社是国内当先的一站式灵便用工招聘服务企业，灵便用工行业的 Top1。青团社于 2013 年在杭州成立，业务曾经覆盖全国，在行业深耕 10 年。我的分享将分为以下三局部： 青团社架构演进的历程青团社如何实现云原生总结与瞻望云原生架构的演进历程2020 年，咱们的技术架构比拟单薄，存在较多问题。面对这些问题，团队开始了架构演进，存在的问题次要是以下多个方面。 第一，运维能力和可观测性比拟差，因为公司大部分都是业务研发人员，业余的 DBA 和运维都没有。 第二，在业务刚刚开始起步时，业务迭代速度十分快，每天都会有很频繁的公布，线上常常因为公布导致一些稳定性的问题，作为平台型公司连贯 B 端和 C 端两端，对线上可用性要求十分高，但晚期的架构设计也不太正当，所以很多时候利用是无奈反对高可用的。 第三，因为线上的资源部署不太正当，比拟浪费资源，资源老本较高。 第四，部署模式比拟粗放，日志、告警都没有，所以出了问题之后排查十分艰难，研发人员通常须要很长时间能力把这些问题弄清楚，响应工夫比拟长，置信大部分初创型公司在业务晚期倒退的阶段都存在这种问题。 那咱们如何去应答这些挑战呢？答案就是应用云原生架构来重塑架构体系， 一直地对架构进行演进，抉择适合的技术栈，配合应用云的基础设施，来构建业务平台，让零碎达到好的水准。 从下图中能够看到，青团社的业务架构演变遵循从单体架构到 SOA 架构再到微服务。基础架构物理机是没有的，团队从 2014 年开始就间接应用阿里云 ECS，在 2021 年开始容器化，最终达到冀望的云原生架构状态。 云原生基金会官网对云原生的定义是 5 局部，第一是容器化，第二是不可变基础设施，第三个是申明式 API，而后是服务网格和微服务，其中微服务作为承载业务利用的外围，围绕这个，会有像调度编排、流量治理、可观测、DevOps 这些畛域的一些能力，这是技术架构要做的事件。 从技术角度看，云原生架构是基于云原生技术的一组架构准则和一些设计模式的组合，将利用中的非核心的业务逻辑剥离进来，而后下沉到云原生基础设施这一层来对立解决，这样业务开发人员只须要关怀本人的业务开发，让咱们的业务利用变得更加轻量，高效。 因为公司是 2013 年成立的，晚期的业务非常简单，运维能力也比拟差，所以单体架构是优选。通过四五年的倒退，业务有了长足的提高，平台的性能和模块都曾经比拟多了，因而，就降级到 Spring Cloud 微服务架构。过后用的是一套规范的用法，比方服务注册核心、配置核心用的是 Eureka，网关用的是 Spring Cloud Gateway。 此时，尽管实现了微服务架构，但也存在诸多问题，例如服务不稳固、排查效率低下、资源利用率低等。基于这些问题，开始做业务容器化革新。 首先，选用成熟的 K8s 平台去做业务容器平台，先解决部署与排查问题。 一开始咱们选型的是阿里云容器服务 ACK Serverless 版，次要是看中了它开箱即用，不须要额定去保护，比较简单的长处。在应用的过程中，次要是先在开发侧去验证它，用了一段时间到 2021 年的时候，就实现了线上的迁徙。 之后选用阿里云 ACK 的技术底座去实现线上容器化革新的起因是，过后在用 Serverless 过程中呈现一些问题，比方调度比较慢等，在过后咱们是没有这些能力去解决的。革新之后，大略是 300 多个微服务。此外，还波及到一些基础架构的革新，比方服务注册核心，咱们原先用的是 Eureka，起初迁徙到 MSE 的 Nacos 里，配置核心应用了 MSE Nacos，来晋升性能和稳定性。 ...

为什么须要做软硬件协同？在后摩尔时代，整个算力的晋升逐步放缓，那怎么晋升计算机性能？龙蜥社区 Java 语言和虚拟机 SIG 成员、阿里云智能程序语言与编译器技术总监李三红在 2023 龙蜥操作系统大会上分享了如何通过 Alibaba Cloud Linux 做南向和北向的协同，基于阿里云自研芯片倚天做全栈协同设计和优化，解锁阿里云的底层算力。最初，他也做了 C/C++ 编译器套件 Alibaba Cloud Compiler(ACC)以及 Alibaba Dragonwell 解读。以下为本次分享全文： （图/龙蜥社区 Java 语言和虚拟机 SIG 成员、阿里云智能程序语言与编译器技术总监李三红） 在这个分享里，咱们具体讲讲怎么样通过 Alibaba Cloud Linux 做南向和北向的协同，解锁阿里云的底层算力。开始之前，介绍一下 Alibaba Cloud Linux 和龙蜥社区的关系。 整体上看，龙蜥社区分三层：最上层更多的是龙蜥社区和国内开源社区的单干，包含 Linux Foundation，这是整个龙蜥社区的根底，因为龙蜥自身就是操作系统。除了 Linux Foundation 外，也投入与云原生 CNCF 基金会的单干，以及和 Java 畛域的两大顶级基金会 Eclipse 和 Apache 的单干。中游是原生发行版社区，通过产业协同去促成整个产品演进迭代。当咱们有了十分好的开源社区，如何撑持上游可继续的商业模式？龙蜥社区依据场景的不同，提供了三个版本类别：第一个是 Anolis OS 商业版，比方统信、麒麟商业版。第二个是企业定制版，而 Alibaba Cloud Linux 就是龙蜥社区定制版。最初一个就是开源社区的收费版本，如 Anolis OS 23、Anolis OS 8 等等。 介绍软硬件协同之前，我先分享下咱们的思考，就是为什么须要做软硬件协同？咱们看下整个产业的计算机算力的大趋势，上图参考自两位图灵奖的获得者 David A. Patterson 和 John L. Hennessy 在 2019 年 ACM 的通信杂志上发表的论文《A New Golden Age for Computer Architecture》。论文回溯了整个计算机体系结构的倒退周期，基本上是三个阶段： ...

作者：王涛(扬礼)、陈裘凯(求索)、徐之浩(东伝) 背景工夫步入了 2024 年，新的技术趋势，如大模型/AIGC/多模态等技术，曾经开始与理论业务相结合，并开始生产落地。这些新的技术趋势不仅进步了算力的需要，也给底层基础设施带来了更大的挑战。 在计算方面，以 GPU 和 FPGA 等异构硬件为例，他们通过短周期的迭代和演进来适应一直变动的需要。阿里团体通过对立调度、对立资源池以及全面弹性等调度伎俩满足了简单的计算需要。 在存储方面，经典的微服务利用通过云原生化的形式，兼顾了性能和效率。但对于计算量增量最大的分布式 AI 训练、大数据等计算密集型利用，data locality 间接影响了计算作业的运行效率与吞吐，网络 I/O 的耗费还间接拉高了带宽老本，且在可预感的场景中，数据集规模还会以较高的速率放弃增长，如何通过正当的数据缓存亲和性技术减速数据拜访，将是晋升计算工作运行效率的同时降老本的要害。 大模型训练/多媒体等场景的数据集以图片和音频文件为主，人造适宜将数据托管在 OSS 对象存储上，也是目前线上大多数计算作业的存储选型，以训练场景为例，具备以下读数据的特色：1）数据集程序的随机化解决造成传统的单机缓存策略生效；2) 多个 epoch 会对数据集进行多轮读取；3) 作业间可能复用同个数据集； 综上，阿里巴巴团体外部多个 AI 平台业务面临的现状中，人造适宜用分布式缓存/文件系统的模式进行 I/O 层面的减速。 面临的挑战计算存储拆散架构晋升了数据拜访与计算程度扩大的灵便度，但导致了数据拜访高延时，对于训练等对数据缓存亲和性有显著诉求的场景提早不敌对：业务团队应用的机器学习工作在训练过程中要实时频繁拜访 OSS 上的数据（以样本数据集与 checkpoint 为主），在 OSS 带宽受限或者压力较大时，拜访 OSS 上数据速度比拜访本地文件速度要慢 1~2 个数量级，且占据了用户大量的带宽老本；Kubernetes 调度器数据缓存无感知，同一数据源屡次运行拜访仍旧慢：在事实利用中深度学习工作运行会一直反复拜访同一数据，包含雷同模型不同超参的工作、微调模型雷同输出的工作、以及 AutoML 工作等。这种深度学习工作的反复数据拜访就产生了能够复用的数据缓存。然而，因为原生 Kubernetes 调度器无奈感知缓存，导致利用调度的后果不佳，缓存无奈重用，性能难以晋升；OSS 成为数据并发拜访的瓶颈点，稳定性挑战大：大量机器学习工作在同时训练时都会并发拜访后端 OSS 存储。这种并发机器学习训练造成的 IO 压力比拟大，OSS 服务成为了性能单点，一旦 OSS 带宽呈现瓶颈则会影响所有机器学习工作；训练文件扩散，元数据压力：机器学习工作的训练数据文件通常会扩散在不同门路下，读取文件须要消耗大量的工夫在 list 操作上。对象存储的 list 操作性能较差，在进行大规模 list 时对 OSS 元数据压力很大，经常出现超时或者 list 失败的状况。IO 稳定性对业务运行有间接影响：导致业务体现不稳固，甚至造成工作失败。基于 FUSE 的存储客户端更容易产生这样的问题，一旦这些问题无奈主动修复，则可能中断集群训练任务。时刻放弃 IO 的稳定性是保障业务顺利运行的要害路径之一。在事实利用中，通过对于以上典型数据拜访 pattern 的剖析，咱们发现 IO 性能问题会导致 GPU 等低廉计算资源不能被充分利用。机器学习本身训练的特点导致了数据文件拜访较扩散，元数据压力较大。如果可能精细化地缓存元数据和文件数据，那么一方面能够进步缓存效率和磁盘利用率，另一方面也能够解决文件查找操作带来的元数据损耗。 ...

作者：张浩翔（笃敏） 概述随着可观测数据采集需要的一直新陈代谢，多样化的数据输入输出选项、个性化的数据处理能力组合、以及高性能的数据处理吞吐能力曾经成为顶流可观测数据采集器的必备条件。然而，因为历史起因，现有的 iLogtail 架构和采集配置构造曾经无奈持续满足上述需要，逐步成为制约 iLogtail 持续向前疾速演进的瓶颈： ▶︎ iLogtail 设计之初齐全面向文件日志采集至日志服务的场景： 1）简略地将日志分为多种格局，每种格局的日志仅反对一种解决形式（如正则解析、Json 解析等）； 2）性能实现与日志服务相干概念（如 Logstore 等）强绑定； 基于此设计思维，现有的 iLogtail 架构偏差于单体架构，导致模块间耦合重大，可扩展性和普适性较差，难以提供多个解决流程级联的能力。 ▶︎ Golang 插件零碎的引入极大地扩大了 iLogtail 的输入输出通道，且肯定水平晋升了 iLogtail 的解决能力。然而，囿于 C++ 局部的实现，输入输出与解决模块间的组合能力依然重大受限： 1）C++ 局部原生的高性能解决能力依然仅限于采集日志文件并投递至日志服务的场景应用； 2）C++ 局部的解决能力无奈与插件零碎的解决能力相结合，二者只能选其一，从而升高了简单日志解决场景的性能。 ▶︎ 与 iLogtail 整体架构相似，现有的 iLogtail 采集配置构造也采纳平铺构造，不足解决流水线的概念，无奈表白解决流程级联的语义。 基于上述起因，在 iLogtail 诞生 10 周年之际，日志服务启动对 iLogtail 的降级革新，寄希望于让 iLogtail 的易用性更佳，性能更优，可扩展性更强，从而更好地服务宽广用户。 目前，通过半年多的重构与优化，iLogtail 2.0 曾经跃然纸上。接下来，就让咱们来领先理解一下 iLogtail 2.0 的新个性吧！ 新个性（一）【商业版】采集配置全面降级流水线结构为了解决旧版采集配置平铺构造无奈表白简单采集行为的问题，iLogtail 2.0 全面拥抱新版流水线配置，即每一个配置对应一条解决流水线，包含输出模块、解决模块和输出模块，每个模块由若干个插件组成，各模块的插件性能如下： 输出插件： 用于从指定输出源获取数据（各插件具体性能详见输出插件 [ 1] ）解决插件： 用于对日志进行解析和解决（各插件具体性能详见解决插件 [ 2] ），可进一步分为原生解决插件和扩大解决插件<!----> 原生解决插件：性能较优，实用于大部分业务场景，举荐优先应用扩大解决插件：性能笼罩更广，但性能劣于原生解决插件，倡议仅在原生解决插件无奈实现全副解决需要时应用<!----> 输入插件： 用于将解决后的数据发送至指定的存储咱们能够用一个 JSON 对象来示意一个流水线配置： ...

微服务架构下，每个应用服务独立开发、独立公布，小步快跑，继续疾速交付业务需要。多人协同开发同一个利用时，分支开发模式是一个适宜的协同计划。该模式下一个需要或工作通常对应一个 feature 分支，多个需要一起合并到 release 分支进行集成测试验证并公布。期间可能遇到以下问题： 痛点 1：当开发同学领到一个需要时，怎么为这个需要疾速地拉一个 feature 分支？痛点 2：当多个相干需要一起公布时，多个 feature 分支怎么高效自动化地合并到 release 分支？痛点 3：当其中一个 feature 分支没有通过测试验证时，怎么“阻止”它公布到生产环境防止漏测引起故障？痛点 4：当其中一个 feature 分支做了测试验证，然而发现有重大问题，怎么能够“退出”本次公布而不影响其余需要失常公布？痛点 5：当一个需要 feature 分支提交测试了、公布上线了，怎么主动、及时的更改相应需要状态，便于相干业务、产品、测试同学跟踪进度？ 云效解决方案云效应用交付平台 AppStack 提供的变更继续交付解决方案能够比拟轻松地解决以上问题。在理解具体的应用前，咱们先理解下 AppStack 中波及的一些外围概念： 利用： 一个软件的最小公布单元，聚合代码、环境、版本等软件资产，以及研发流程定义。最小公布单元意味着无奈解耦的一个或者多个服务的组合，这个服务组合会通过一个流程进行对立交付。变更： 变更是对利用的一次个性扭转（引入新的个性或扭转已有个性），源于需要，终于交付。通常一个需要或工作对应一个变更，对应一个 feature 分支。研发流程： 利用实现一次变更的过程和束缚，包含开发、测试、公布上线的残缺流程，由多个阶段的多条流水线承载，顺次在不同环境进行测试、构建、部署，最终审批通过后公布生产环境。 上面，咱们以一个 spring-boot 利用的“图书馆管理系统”为例，演示如何在云效应用交付平台 AppStack 中开发“图书借阅性能”、“图书偿还性能”、“图书到期续借性能”三个需要，并一起公布上线。**过程中，前述的 5 个痛点都将失去解决。 作为利用负责人作为利用负责人，须要编排利用构建、部署流程，通过流水线工具自动化起来；须要定义利用生产公布准则，来标准利用研发流程升高公布危险。 新建利用新建利用，输出利用名称，利用模板抉择「变更继续交付模式」。 代码源配置利用设置，配置利用代码源，设置默认分支。 配置研发流程本利用的研发流程能够分为测试阶段、预发阶段、生产阶段： 测试阶段：由 Java 单元测试、Java 代码扫描、构建、部署测试环境等步骤组成。用于日常测试验证。预发阶段：由构建、部署预发环境等步骤组成。用于预公布验证。生产阶段：由构建、生产公布审批（人工卡点）、部署生产环境、合并骨干、敞开变更等步骤组成。生产公布审批通过后，部署生产环境。生产环境部署验证通过后，表明本次公布胜利，能够将公布 release 分支合并回骨干 master，并主动敞开相干变更。 设置变更集成形式和准入规定本示例各阶段都抉择「增加变更集成」形式，在运行阶段流水线时能够抉择多个变更分支集成到 release 分支进行构建部署验证。 测试阶段：无准入规定。预发阶段：配置准入规定为：「测试阶段-执行后果」等于「胜利」，防止没有通过测试验证的分支间接进入预发。生产阶段：配置准入规定为：「测试阶段-执行后果」等于「胜利」，「预发阶段-执行后果」等于「胜利」，防止没有通过预发验证的分支间接进入生产阶段。 作为一线开发“需要 1：图书借阅性能”、“需要 2：图书偿还性能”、“需要 3：图书到期续借性能”三个需要别离调配给开发小张、小明、小强开发。 第 1 步，为一个需要新建一个变，更拉一个 feature 分支小张创立一个变更「变更 1-实现图书借阅性能」，抉择新建分支输出 feature001，则可主动为该需要拉取一个分支（解决上述痛点 1）。顺次类推，小明创立一个变更「变更 2-实现图书偿还性能」，主动新建分支 feature002。小强创立一个变更「变更 3-实现到期续借性能」，主动新建分支 feature003。 ...

微服务架构下，每个应用服务独立开发、独立公布，小步快跑，继续疾速交付业务需要。多人协同开发同一个利用时，分支开发模式是一个适宜的协同计划。该模式下一个需要或工作通常对应一个 feature 分支，多个需要一起合并到 release 分支进行集成测试验证并公布。期间可能遇到以下问题： 痛点 1：当开发同学领到一个需要时，怎么为这个需要疾速地拉一个 feature 分支？痛点 2：当多个相干需要一起公布时，多个 feature 分支怎么高效自动化地合并到 release 分支？痛点 3：当其中一个 feature 分支没有通过测试验证时，怎么“阻止”它公布到生产环境防止漏测引起故障？痛点 4：当其中一个 feature 分支做了测试验证，然而发现有重大问题，怎么能够“退出”本次公布而不影响其余需要失常公布？痛点 5：当一个需要 feature 分支提交测试了、公布上线了，怎么主动、及时的更改相应需要状态，便于相干业务、产品、测试同学跟踪进度？ 云效解决方案云效应用交付平台 AppStack 提供的变更继续交付解决方案能够比拟轻松地解决以上问题。在理解具体的应用前，咱们先理解下 AppStack 中波及的一些外围概念： 利用： 一个软件的最小公布单元，聚合代码、环境、版本等软件资产，以及研发流程定义。最小公布单元意味着无奈解耦的一个或者多个服务的组合，这个服务组合会通过一个流程进行对立交付。变更： 变更是对利用的一次个性扭转（引入新的个性或扭转已有个性），源于需要，终于交付。通常一个需要或工作对应一个变更，对应一个 feature 分支。研发流程： 利用实现一次变更的过程和束缚，包含开发、测试、公布上线的残缺流程，由多个阶段的多条流水线承载，顺次在不同环境进行测试、构建、部署，最终审批通过后公布生产环境。 上面，咱们以一个 spring-boot 利用的“图书馆管理系统”为例，演示如何在云效应用交付平台 AppStack 中开发“图书借阅性能”、“图书偿还性能”、“图书到期续借性能”三个需要，并一起公布上线。**过程中，前述的 5 个痛点都将失去解决。 作为利用负责人作为利用负责人，须要编排利用构建、部署流程，通过流水线工具自动化起来；须要定义利用生产公布准则，来标准利用研发流程升高公布危险。 新建利用新建利用，输出利用名称，利用模板抉择「变更继续交付模式」。 代码源配置利用设置，配置利用代码源，设置默认分支。 配置研发流程本利用的研发流程能够分为测试阶段、预发阶段、生产阶段： 测试阶段：由 Java 单元测试、Java 代码扫描、构建、部署测试环境等步骤组成。用于日常测试验证。预发阶段：由构建、部署预发环境等步骤组成。用于预公布验证。生产阶段：由构建、生产公布审批（人工卡点）、部署生产环境、合并骨干、敞开变更等步骤组成。生产公布审批通过后，部署生产环境。生产环境部署验证通过后，表明本次公布胜利，能够将公布 release 分支合并回骨干 master，并主动敞开相干变更。 设置变更集成形式和准入规定本示例各阶段都抉择「增加变更集成」形式，在运行阶段流水线时能够抉择多个变更分支集成到 release 分支进行构建部署验证。 测试阶段：无准入规定。预发阶段：配置准入规定为：「测试阶段-执行后果」等于「胜利」，防止没有通过测试验证的分支间接进入预发。生产阶段：配置准入规定为：「测试阶段-执行后果」等于「胜利」，「预发阶段-执行后果」等于「胜利」，防止没有通过预发验证的分支间接进入生产阶段。 作为一线开发“需要 1：图书借阅性能”、“需要 2：图书偿还性能”、“需要 3：图书到期续借性能”三个需要别离调配给开发小张、小明、小强开发。 第 1 步，为一个需要新建一个变，更拉一个 feature 分支小张创立一个变更「变更 1-实现图书借阅性能」，抉择新建分支输出 feature001，则可主动为该需要拉取一个分支（解决上述痛点 1）。顺次类推，小明创立一个变更「变更 2-实现图书偿还性能」，主动新建分支 feature002。小强创立一个变更「变更 3-实现到期续借性能」，主动新建分支 feature003。 ...

作者：蔡靖 对于以后业务运行在 IDC 内的 Kubernetes 集群中，心愿通过云计算为云下业务提供同城灾备的高可用冗余能力，可利用阿里云分布式云容器平台 ACK One [ 1] 来提供对立得流量、利用和集群治理，实现业务流量的多集群路由和劫难状况下的流量的主动平滑容灾。本文次要介绍通过 ACK One 疾速构建混合云同城容灾零碎。 搭建混合云容灾零碎个别须要五个步骤： 应用 ACK One 注册集群治理 IDC / 第三方公共云 K8s 集群实现云下网络与云上 VPC 的互联互通创立 ACK One 舰队并关联集群应用 ACK One GitOps 公布利用到多个集群（可选）应用 ACK One 多集群网关治理多集群流量分布式云容器平台 ACK One分布式云容器平台 ACK One（Distributed Cloud Container Platform for Kubernetes）是阿里云面向混合云、多集群、分布式计算、容灾等场景推出的企业级云原生平台。ACK One 能够连贯并治理您任何地区、任何基础设施上的 Kubernetes 集群，并提供统一的治理和社区兼容的 API，反对对计算、网络、存储、平安、监控、日志、作业、利用、流量等进行对立运维管控。 ACK One 注册集群 [ 2] 能够帮忙您将云下 Kubernetes 集群接入云端，疾速搭建混合星散群，能够将本地数据中心 Kubernetes 集群或其余云厂商 Kubernetes 集群接入阿里云容器服务治理平台，进行对立治理。在混合云场景下，承当了至关重要的作用。 ACK One 舰队 [ 3] （Fleet）是 ACK One 治理多集群提供的对立入口，为开发者提供多集群 GitOps 利用散发、流量治理、对立运维等能力。其基于成熟的开源社区我的项目 Argo CD [ 4] 和 Open Cluster Management [ 5] 构建，保障了产品的开放性。每个舰队实例则由 ACK 托管，您能够省去大量的运维工作，专一利用开发。 ...

AIGC 生成姓氏头像火爆全网，阿里云开发者社区X函数计算推出新流动！2 步基于函数计算搭建 AI 艺术字利用，晒姓氏头像赢 Cherry 机械键盘 MX8.0（价值 800+）、小米挪动电源等新春好礼！该场景基于 Stable Diffusion API Serverless 版解决方案打造，上手简略、帮忙 AI 开发者轻松实现 AI 绘画平台开发、变现！ 流动工夫：1 月 25 日-2 月 29 日流动地址：https://developer.aliyun.com/topic/fcnewyear 扫描二维码进入流动页面（倡议 PC 端体验） 最佳实际为了不便大家直观体验一下该解决方案功效，基于函数计算团队开发者的基于 Stable Diffusion Serverless API 解决方案搭建的 AI 文字生成利用，作为一个试验 demo 凋谢体验，期待为宽广开发者 AI 绘画守业及变现提供一些无益思考。间接加入体验流动，送好礼！ 部署胜利的 AI 绘画利用： 眯着眼睛看看是什么字？ 开源代码 github：https://github.com/devsapp/serverless-stable-diffusion-api 能够本人基于开源代码加工开发。

有人说，程序员工作赚钱真简略，电脑上按按键盘就行了，一点也不辛苦。 有人说，程序员不懂生存，就晓得天天对着电脑。 “在前辈眼里，程序员是坐办公室的神秘职业、高级白领；在敌人街坊眼里，程序员是修电脑高手；在同性眼里，程序员是蓬头垢面的宅男，然而程序员的幻想大部分都是扭转世界。” 如果咱们突破刻板印象，程序员到底是怎么一个群体呢，他们眼中的本人是什么样子？ 9月26-28日，由 Linux 基金会、云原生计算基金会（CNCF）主办的 KubeCon+CloudNativeCon+Open Source Summit China 2023 将在上海举办，在这个开发者共赴技术盛宴的流动过程中，阿里云策动发动面向开发者的 AIGC 体验流动：「AIGC 一张开发者自画像」。只需实现 4 步操作工作，提交「自画像」，就有机会 Get 惊喜礼品。 如果你也到现场参会，欢送来到阿里云展区线下参加体验流动。 流动信息流动工夫 2023 年 9 月 25 日-2023 年 10 月 15 日 流动对象 阿里云官网实名认证用户首次领用试用产品用户根底操作 STEP 1： 支付函数计算收费试用资源；STEP 2： 支付容器 ACK Serverless 收费试用资源（个人版或企业版二选一）；STEP 3： 抉择适合的形式（基于函数计算或者基于容器服务 Serverless 版），实现创作提交参赛作品；STEP 4： 依照点赞排名，角逐最终奖项。惊喜礼品、激励创作 点击浏览原文，进入流动页面 查看海报 理解详细信息

BladeLLM是阿里云PAI平台提供的大模型推理引擎，致力于让用户轻松部署高性能、低成本的大语言模型服务。BladeLLM对LLM推理和服务的全链路进行了深度的性能优化和工程优化，确保不同模型在不同设施上都达到最优性价比。 除了在惯例上下文长度下的极致性能优化之外，BladeLLM还冲破了现有LLM推理零碎上下文长度的极限，可能反对更长的输出长度以及文本生成长度等，使得LLM可能解锁更多的利用场景，并且BladeLLM在超长上下文下仍然放弃极致的性能，相比于其余LLM推理服务零碎有显著的性能劣势。 本文次要介绍BladeLLM在超长上下文方面具备的劣势，包含反对的最大上下文长度以及超长上下文的推理性能。 背景超长上下文是LLM倒退的必然趋势超长上下文推理能力是LLM涌现的重要能力之一，该能力促生了一系列具备微小潜在价值的利用场景，包含个性化的聊天机器人（Character.AI）、文学创作工具（Jasper）、文章摘要工具（ChatPaper）等。个性化的聊天机器人会和用户进行持续性的交互，给予用户工作、情感、学习等多方面的帮忙。LLM会在交换过程中记忆残缺的聊天内容，模型输出长度逐次递增，在屡次交互后造成超长输出文本序列；文学创作工具借助LLM的能力批量生成长篇文本，如小说、故事和剧本等。相比传统的手工创作过程，LLM文学创作工具能够在短时间内生成大量的背景、情节和对话，在大幅度晋升作家和编剧的创作效率的同时为读者提供更加丰盛且多样的浏览资料。LLM涌现的超长上下文推理能力被认为是通往AGI的必经之路，该能力的意义次要体现在以下几个方面： 摸索更多利用场景：超长文本生成的反对使得LLM能够利用于更多的利用场景，如个性化聊天机器人、生成长篇小说、技术文档、学术论文等。这些利用场景通常须要生成较长的文本内容。生成更具上下文连贯性的文本：LLM的指标是生成与给定上下文相干的自然语言文本。当生成序列限度较短时，可能会导致生成的文本与上下文的连贯性有余，影响生成文本的品质。而LLM反对超长文本生成，能够更好地放弃上下文的完整性，生成的文本更加连贯，从而晋升生成文本的品质。晋升生成多样性：较长的生成序列能提供更多的空间来摸索不同的文本可能性，从而进步生成文本的多样性。LLM反对超长文本生成，能够更好地捕获上下文的轻微变动，生成更多样化、丰盛的文本内容。随着相干利用场景的铺开，反对超长上下文的模型层出不穷，其中包含反对84K上下文的MPT StoryWriter、200K上下文的Claude 2以及256K上下文的LongLLaMA等等（见下图）。零碎层面尽管曾经有局部框架（如DeepSpeed）针对超长上下文进行反对和优化，然而仍然集中于训练阶段。而在推理阶段，风行的框架无不面临超长输入输出无奈运行或运行效率低下的问题，能够说超长文本的输出和输入对大模型推理引擎带来新的挑战。 超长上下文的挑战首先，现有的LLM推理引擎难以满足大模型解决超长上下文信息的需要，这些零碎对于存储资源的配置计划以及计算算子的设计会极大地限度模型的最大输入输出长度。因而，大规模的上下文反对须要更高效的存储和计算策略；此外，更长的上下文信息使得推理工夫急剧增长，引起成本上升和用户体验的降落，这个问题在现有的LLM推理引擎中尤为显著。推理工夫增长的次要起因是LLM的Attention机制，它须要计算每个Token与其余Token之间的绝对重要性，随着上下文长度的减少，Attention计算须要解决更多的Token从而导致更长的计算工夫，因而更疾速高效的Attention计算方法是减速LLM超长文本生成的要害。 以HuggingFace Llama2-13B模型为例，随着上下文长度的减少，生成一个token的工夫显著减少，具体增长趋势如下图所示。上下文长度34K时HuggingFace开源模型生成一个token的工夫是上下文长度1K时的3.5倍. 技术计划以下是BladeLLM推理引擎的技术架构图，蕴含了很多外围组件，本文次要介绍其中的RaggedAttention和DNN-based AutoTuner. RaggedAttention近期，对于Transformer Multi Head Attention计算有两个颇具影响力的工作即FlashAttention和PagedAttention,  它们对LLM训练和推理零碎的设计范式产生了深远的影响。 PagedAttention受到操作系统中虚拟内存和分页思维的启发，在不间断的显存空间中存储间断的keys和values. PagedAttention将每个sequense的kv cache划分为块，每个块蕴含固定数量的tokens的keys和values。因为这些块在显存中不用间断，从而极大地缩小了显存碎片，并且无需为每个sequense提前预留大量的显存，使得贵重的显存资源失去了最充沛的利用。极致的显存利用率配合上Contiguous Batching，极大地晋升了LLM推理服务的吞吐。相应地也带来一个毛病，不间断的显存块在肯定水平上影响了kernel访存效率，从而影响了性能。 同期BladeLLM自研的RaggedAttention尽管要解决的问题与PagedAttention相似，然而在实现办法上存在肯定差别，具体来说就是在kernel性能与显存利用率之间有着不同的tradeoff。 RaggedAttention的名字是受Tensorflow框架中RaggedTensor的启发。Ragged是不规则的意思，这意味着RaggedAttention的kv cache不是规定的Tensor，而是容许其中每个sequence的长度各不相同，从而可能和Contiguous Batching高效配合，晋升零碎吞吐。然而和PagedAttention不同的是，RaggedAttention保障同一个sequence的key和value cache是间断存储的，因而可能晋升kernel的访存效率和进而晋升性能。同样地，间断存储会造成肯定的显存碎片和显存预留问题，从而影响了显存利用率。这是一个典型的工程上的tradeoff，没有标准答案，因为不同的算力显存配比、不同的输入输出长度、甚至不同业务对于延时的不同要求都会导致系统瓶颈的差别。作为AI平台，BladeLLM致力于为不同模型、不同设施、不同workload、不同业务场景以自动化的形式寻求最适宜的配置。 例如对于变动范畴极大的上下文长度，借助于下一大节将要介绍的AutoTuner，RaggedAttention在不同上下文长度下都能放弃高效的计算和访存，咱们实测上下文长度从1变动到512000，RaggedAttention都能取得极致的性能。  DNN-based AutoTunerLLM推理属于典型的强Dynamic Shape场景，不仅Batch Size维度会动态变化，Sequence Length维度变动幅度更为微小。Dynamic Shape场景下谋求Kernel极致性能的次要办法之一是基于理论运行尺寸进行Tuning调优，即针对每一组特定的输出尺寸都通过理论运行和测量选取Best Schedule，采纳这种办法的工作包含AutoTVM, Ansor等。 这种办法尽管能够达到很极致的性能，然而存在Tuning开销大的问题，特地是Tuning后果只能对特定Shape实用，对于Dynamic Shape场景十分不敌对：如果离线事后针对所有可能的shape都tune一遍，须要破费的tuning工夫以及计算资源十分微小；如果在线对每组新shape实时进行tuning，会对线上性能产生重大的性能扰动。 针对以上痛点，BladeLLM采纳了DNN-based AutoTuner，齐全依赖DNN模型预测的后果而无需理论运行测量来选取Best Schedule. 咱们在训练数据收集、模型构造、特征提取、Loss函数设计等方面进行了大量的摸索和尝试，一直晋升DNN模型的预测准确率，目前基于DNN-based AutoTuner的GPU计算密集算子的均匀性能达到基于理论运行测量的Tuning调优性能的99.39%. 在解决了预测准确率之后，升高DNN预测模型的运行工夫和占用的计算资源成为该技术利用于高实时性在线推理场景的要害挑战。间接应用已有框架和引擎（如PyTorch, TorchScript, OnnxRuntime等）搭建预测模型无奈满足服务的高实时性需要，咱们通过模型零碎联结优化，使得AutoTuner DNN模型预测延时升高至2us. 极致的系统优化使得预测模型性能相比于用PyTorch, TorchScript, OnnxRuntime搭建的模型别离晋升36倍，19.5倍和4.3倍（见下图），并且推理过程占用的系统资源极低，预测模型只应用一个CPU Core而非GPU资源以确保不对服务的GPU模型本身性能造成任何烦扰。因为微秒级的低预测时延和99%以上的预测准确率，AutoTuner不仅被利用于LLM在线推理服务，还胜利服务于包含搜推广、语音辨认、Stable Diffusion等Dynamic Shape业务场景。 后果比照咱们以最大文本生成长度以及相应的生成工夫为例来比照不同LLM推理零碎最大能反对的上下文长度以及相应的性能，后果如下： lmDeploy(基于FasterTransformer)在生成长度超过10K之后会Hang住vLLM在生成长度超过12K之后呈现illegal address谬误Huggingface原始的Llama模型在生成长度超过34K后OOMLightLLM最大生成长度(67K)和BladeLLM(70K)靠近，然而所须要的工夫是BladeLLM的3倍注：为了比照的公平性，以上后果均基于fp16权重和fp16 kv cache测量，BladeLLM现已反对kv cache量化，可进一步将单卡最大反对的上下文长度晋升至280K；以上所有的测量均未采纳投机采样；以上测量在8月份实现，目前业界LLM推理引擎都还在疾速倒退中，咱们期待更新的后果比照，同时BladeLLM反对更长上下文、更高性能的新版本开发也靠近序幕，有了新的后果咱们会持续和大家分享。 总结超长上下文是LLM倒退的必然趋势，而以后支流的LLM推理和服务引擎所反对的上下文长度以及超长上下文的推理性能都远远不够，以上分享了一些对于BladeLLM对超长上下文的反对以及超长上下文推理性能，欢送大家交换探讨。此外，除了关注超长上下文场景，BladeLLM也会继续关注推理的多个技术方向，包含低比特量化压缩、多轮对话、极致内核优化、编译优化等，后续咱们也会有更多的技术分享对外公开，欢送大家继续关注！

时隔近半个世纪，新中国第一次参加亚运会的影像材料将首次对外披露。只是年代久远，老照片老视频都有了岁月痕迹，画面不再清晰，这些宝贵史料急需你的帮忙！ 一、流动介绍2023年，正值亚运110周年，也是第19届杭州亚运会行将举办之际，阿里云与亚奥理事会单干，发动“历久弥新——用 AI 修复亚运会宝贵史料”流动，开发者应用阿里云的 AI 技术对亚运会历史老照片进行修复，重燃亚运经典，为亚运助威，并有机会入选“亚运史上第一个 AI 修复特展“。 亚奥资料馆首次披露1974年中国队参加的首届亚运会宝贵原片，邀请寰球开发者应用AI技术修复，参加即可取得礼品。 新用户可收费支付价值万元的机器学习平台PAI 及对象存储 OSS 试用资源。 优秀作品还有机会在亚运史上第一个 AI 修复特展中展出！ 邀请好友实现老照片修复工作，PK赢取iPad，苹果音响等多款好礼！ 二、流动工夫流动工夫： 2023年8月30日0点——2023年10月8日24 点（以流动页面理论展现为准）。展览入选提交工夫： 2023年9月14日前提交的作品有机会入选“亚运史上第一个 AI 修复特展— 1974 年德黑兰亚运会特展”。后果颁布工夫： 2023年10月20日在流动页面颁布流动后果，流动礼品将在流动后果颁布后的10个工作日内邮寄。三、流动玩法参与者需基于流动页面指定的“1974 年德黑兰亚运会老照片”进行修复，修复其余照片不予审核通过；修复前和修复后的老照片版权归均属于亚奥理事会，仅可在本次流动中应用，不可用作他用。参与者须要应用机器学习交互式建模平台PAI-DSW 对老照片进行修复PAI-DSW 中预置了丰盛的开源 state of the art 的修复模型，以及 sdwebui 的服务供参与者应用。除已提供的模型外，开发者也能够应用其余开源模型，但不可应用除了 AI 模型外的其余工具对于PAI-DSW 的新用户，阿里云提供了5000CU*H 的收费试用资源，能够在流动页面中间接支付；或能够购买 PAI-DSW 资源包参或按量应用进行计费，计费规范详见阿里云产品定价。邀请挑战——邀好友实现老照片修复挑战，赢PK好礼。理解更多流动规定：https://developer.aliyun.com/article/1318140 四、流动奖品奖品流动一：老照片修复奖品亚运老照片修复流动地址： https://developer.aliyun.com/topic/aiforgames 参加奖（人数不限）：按流动要求上传修复作品并通过审核的参与者可取得开发者社区 200 积分及电子证书一张修复人气奖（100 人）：按流动要求上传修复作品，作品点赞数 ≥3个，且排名Top100的参与者可取得罗马仕充电宝 1 个；修复心得奖（10 人）：按流动要求上传修复作品，且额定公布修复心得。心得公布后需将地址粘贴至作品形容处，随修复作品一起上传，主办方将依据心得品质评奖，奖品为Cherry键盘鼠标套装；修复大奖（10 人）：每张照片均有 1 张作品取得修复大奖，奖项由评委参考评奖规范选出。修复大奖作品有机会在“1974 德黑兰亚运会特展”中展出，获奖者将被授予阿里云及亚奥理事会颁发的荣誉证书，且将取得小米手环 8 及亚运特许纪念品 1 个 。奖品流动二：邀好友，参加PK赢取奖品邀请好友参加亚运老照片修复即有机会赢取奖品 流动期间，用户参加流动点击“邀请好友”后“复制链接”生成您的专属链接给好友，好友关上链接后在流动页内实现工作一和二，即算助力胜利实现1人邀请。 举荐官地址： https://developer.aliyun.com/topic/referralforgames?taskCode=9304 ...

作者：微服务X音讯队列 8 月 27 日，“云原生开源开发者沙龙-微服务 X 音讯队列专场”在深圳圆满闭幕。流动受众以关注 微服务 + 音讯队列技术的开发者、企业决策人、云原生畛域创业者为主，流动模式为演讲、入手实操，让开发者通过一个下午的工夫增进对微服务和音讯队列技术的了解，疾速上手，拥抱云原生带来的技术红利。 在流动体验环节中，率领大家入手实操了“如何通过 WAF 插件加码网关的平安防护能力”、“基于 MSE 实现微服务的全链路灰度“、“一键体验 RocketMQ 六大生产环境”三个体验。现场互动频频，氛围热烈，充分体现了深圳站搭档的激情。 阿里云云原生开源开发者沙龙深圳流动现场 关注公众号，后盾回复：0827收费取得深圳站讲师 PPT 合辑 精彩回顾上面就让咱们一起回顾本次流动上都有哪些精彩霎时。 01 分享主题丨Dubbo Triple 协定重磅降级 - 反对基于 HTTP 协定买通前端 Web 与后端微服务 在流动现场，Apache Dubbo PMC、阿里云研发工程师江河清为大家分享： 传统微服务调用只能在后端过程之间调用，而全新降级的 Triple 协定将全面买通包含 Web、挪动端等平台，仅需简略申请结构即可实现调用，将大大减低工程上开发、调试的难度。 02 分享主题丨Higress：下一代网关 在流动现场，Higress Maintainer、阿里云技术专家张添翼为大家分享： 分享和互助是开源长期衰弱倒退的依靠，Higress 是站在 Nginx 和 Envoy 的肩膀上走得更远，咱们会尽力帮忙集体开发者和企业用户站在 Higress 的肩膀上走得更远。 03 分享主题丨Apache RocketMQ 分级存储设计详解 在流动现场，Apache RocketMQ Committer、阿里云音讯研发工程师李智敏为大家分享： RocketMQ 拓宽了存储系统的边界，分级存储是其重要的个性之一，这是一个须要全链路调优的简单工程。它能在云原生和 Serverless 的技术趋势下，无效解决块存储容量下限的问题，同时带来更灵便的弹性与老本的降落，做到 “鱼与熊掌兼得”。 04 分享主题丨Apache RocketMQ 在应答高可用挑战中的“设计范式” ...

作者：潘梦源 前言Kruise Rollout [ 1] 是 OpenKruise 社区开源的渐进式交付框架。Kruise Rollout 反对配合流量和实例灰度的金丝雀公布、蓝绿公布、A/B Testing 公布，以及公布过程可能基于 Prometheus Metrics 指标自动化分批与暂停，并提供旁路的无感对接、兼容已有的多种工作负载（Deployment、CloneSet、DaemonSet）。 目前 Kruise Rollout 新增了流量调度反对自定义资源的能力 ，从而更好的反对渐进式公布中的流量调度。 本文将对 Kruise Rollout 所提出的计划进行介绍。 什么是渐进式公布？**渐进式公布（Progressive Delivery）是一种软件部署和公布策略，旨在逐渐将新版本或性能引入生产环境，以升高危险并确保零碎的稳定性。一些常见的渐进式公布模式如下： 金丝雀公布： 在公布时会创立一个金丝雀版本的 Deployment 进行验证，当验证通过后，再进行全量的工作负载降级，并删除金丝雀版本的 Deployment。 A/B 测试： 依照肯定的规定将用户流量切分成 A、B 两个不相交通路，并将导入不同版本的 Pod 实例进行解决，以此来更好地察看、比照或者灰度新版本能力。 金丝雀公布、A/B 测试和蓝绿公布都是逐渐测试和评估新性能或变更的策略，它们能够依据具体的需要和场景抉择适宜的部署和测试策略，并联合流量灰度等技术实现逐渐公布和测试新版本或性能。 为什么须要对网关资源提供反对？Kruise Rollout 目前曾经对 Gateway API 提供了反对，那么为什么还须要对不同供应商的网关资源提供反对呢？在解释这个问题之前，咱们先来简略介绍一下 Gateway API。 以后社区中不同的供应商都有本人的网关资源，并提出了本人的规范，而 Kubernetes 为了提供一个对立的网关资源规范，构建标准化的，独立于供应商的 API，提出了 Gateway API。目前，只管 Gateway API 还处于开发阶段，但曾经有很多我的项目示意反对或打算反对 Gateway API。包含: Istio 是最风行的服务网格我的项目之一，Istio 1.9 版本打算引入实验性的 Gateway API 反对。用户能够通过 Gateway 和 HTTPRoute 资源来配置 Istio 的 Envoy 代理。Apache APISIX 是一个动静、实时、高性能的 API 网关，APISIX 目前反对Gateway API 标准的 v1beta1 版本，用于其 Apache APISIX Ingress Controller。Kong 是一个为混合云和多云环境构建的开源 API 网关，Kong 在 Kong Kubernetes Ingress Controller (KIC) 以及 Kong Gateway Operator 中反对 Gateway API。然而因为目前 Gateway API 并不能笼罩供应商所提出网关资源的所有性能，并且依然有大量用户应用供应商提供的网关资源，尽管用户能够通过开发 Gateway API 对网关资源进行适配，但这样的工作量较大，所以仅仅为 Gateway API 提供反对是远远不够的，只管随着 Gateway API 个性的不断丰富，在将来，应用 Gateway API 将成为一种更加举荐的形式。因而，尽管 Kruise Rollout 目前曾经提供了对 Gateway API 的反对，如何对现有供应商多种多样的网关资源提供反对依然是一个重要的问题。 ...

基于函数计算 FC 快捷部署 Stable Diffusion，本人设计 T 恤本人穿！赢 Airpods 三代，森马周边！ https://developer.aliyun.com/adc/series/activity/aigc_design 用 Stable Diffusion 制作艺术二维码，本文将具体解说基于函数计算部署 Stable Diffusion 做一个艺术二维码，艺术化的二维码不是单纯的艺术作品，具备可辨认的功能性十分重要，因而在生成过程中，须要对参数和二维码进行屡次调整以达到最佳状态，心愿这篇文章可能帮忙您提供一些生成办法，观看文章须要 5 分钟，看完即会连忙尝试！ 资源筹备注册并登录阿里云账号 [ 1]开明函数计算并支付试用额度 [ 2]开明文件存储 NAS 服务并支付试用额度 [ 3]部署云端 Stable Diffusion抉择“AI 数字绘画 stable-diffusion 自定义模版“，点击立刻创立，开始创立 Stable Diffusionhttps://fcnext.console.aliyun.com/applications/create 创立 Stable Diffusion 须要开明函数计算 FC 和文件存储 NAS，新用户肯定支付试用额度 创立 Stable Diffusion WebUI 抉择地区 —》抉择“绘图类型”（后续可本人换）—》首次部署须要 RAM 角色 APN 受权 其余中央如无特殊要求能够间接默认 确认通晓应用 SD 过程中产生的函数计算费用及重要揭示，期待 Stable Diffusion WebUI 部署胜利 更换及治理模型须要进行“初始化模型治理”，留神存储模型开始用到文件存储  NAS 产品 确认理解应用 NAS 的费用和注意事项，确认开始创立模型管理工具——抉择“主动配置”——确认 ...

作者：赵伟基（兆维） 在传统的利用开发中，通常须要治理底层的基础设施、服务器与网络配置等方面的工作。然而在云原生 Serverless 化的浪潮下，这些基础设施的细节被形象和自动化，开发者无需关注服务器等配置、扩大、监控和保护等工作，能够更专一于应用程序的业务逻辑和性能开发。Serverless 架构的价值在于提供高效、弹性、无服务器治理、服务按需付费、疾速部署与迭代、以及高可扩展性等劣势，升高开发和运维的复杂性，进步开发效率和应用程序的品质。 Knative Serving 是一款基于 K8s 的 Serverless 开源平台，用于构建和治理现代化、可拓展、流量驱动、无服务器的应用程序。Knative Serving 提供了诸多个性来反对用户部署 Serverless 服务，如基于 HTTP 流量触发 pod 的主动扩缩容、服务版本订正、主动流量治理、故障复原等。 起源：https://knative.dev/docs/serving/architecture/ Knative 整体架构如下层所示，Controller 和 DomainMapping 等组件等负责管理 KnativeCRD 资源的生命周期，其弹性能力由外围的 Activator、Autoscaler 和 Queue-Proxy 等组件提供。网络和路由能力依赖各类 Ingress Gateway 提供。 本文重点关注 Knative 网络层能力的实现。Knative 网络层能力须要依赖 Knative Ingress CRD 与其余网络层组件实现。目前，Knative 官网提供了基于 Contour、Istio 和 Kourier 等作为其网络层组件，提供无限的网络能力，如根本的路由、认证鉴权和 TLS 等，能够满足根本的路由和平安要求。Higress 是平安、流量和微服务三合一的云原生网关，应用 Higress 作为 Knative 服务的流量入口可能取得更强的流量治理、平安防护、可观测和可扩大能力。 Knative 网络层工作原理接下来咱们以 Net-Istio 为例，介绍 Knative Serving 通过网络层实现服务对外公布的过程。Net-istio 网络层将数据面与管制面进行拆散。数据面采纳 Envoy，负责解决网络流量。管制面负责管理与配置数据面，反对对网关的动静配置和治理。 当有 KService 被部署的时候，Knative Serving Controller 将解析 Kservice 中的路由项并生成对应的 KIngress 资源。KIngress 是 Knative 的 CRD，其资源中蕴含了服务对外披露所需的所有信息，示例如下： ...

作者：隆基 一致性首先来看 RocketMQ 的第一个个性-事务音讯，事务音讯是 RocketMQ 与一致性相干的个性，也是 RocketMQ 有别于其余音讯队列的最具区分度的个性。 以大规模电商零碎为例，付款胜利后会在交易系统中订单数据库将订单状态更新为已付款。而后交易系统再发送一条音讯给 RocketMQ，RocketMQ 将订单已付款的事件告诉给所有上游利用，保障后续的履约环节。 但上述流程存在一个问题，交易系统写数据库与发消息相互离开，它不是一个事务，会呈现多种异常情况，比方数据库写胜利但音讯发失败，这个订单的状态上游利用接管不到，对于电商业务来说，可能造成大量用户付款但卖家不发货的状况；而如果先发消息胜利再写数据库失败，会造成上游利用认为订单已付款，推动卖家发货，然而理论用户未付款胜利。这些异样都会对电商业务造成大量脏数据，产生灾难性业务结果。 而 RocketMQ 事务音讯的能力能够保障生产者的本地事务（如写数据库）、发消息事务的一致性，最初通过 Broker at least once 的生产语义，保障消费者的本地事务也能执行胜利，最终实现生产者、消费者对同一业务的事务状态达到最终统一。 一致性：事务音讯-原理如下图所示，事务音讯次要通过两阶段提交+事务弥补机制联合实现。 首先生产者会发送 half 音讯，也就是 prepare 音讯，broker 会把 half 存到队列中。接下来生产者执行本地事务，个别是写数据库，本地事务实现后，会往 RocketMQ 发送 commit 操作，RocketMQ 会把 commit 操作写入 OP 队列，并进行 compact，把已提交的音讯写到 ConsumeQueue 对消费者可见。反过来如果是 rollback 操作，则会跳过对应的 half 音讯。 面对异样的状况，比方生产者在发送 commit 或者 rollback 之前宕机了，RocketMQ broker 还会有弥补查看机制，定期回查 Producer 的事务状态，持续推动事务。 无论是 Prepare 音讯、还是 Commit/Rollback 音讯、或者是 compact 环节，在存储层面都是恪守 RocketMQ 以程序读写为主的设计理念，达到最优吞吐量。 一致性：事务音讯 demo接下来来看一个事务音讯的简略示例。应用事务音讯须要实现一个事务状态的查询器，这也是和一般音讯一个最大的区别。如果咱们是一个交易系统，这个事务回查器的实现可能就是依据订单 ID 去查询数据库来确定这个订单的状态到底是否是提交，比如说创立胜利、已付款、已退款等。主体的音讯生产流程也有很多不同，须要开启分布式事务，进行两阶段提交，先发一个 prepare 的音讯，而后再去执行本地事务。这里的本地事务个别就是执行数据库操作。而后如果本地事务执行胜利的话，就整体 commit，把之前的 prepare 的音讯提交掉。这样一来消费者就能够生产这条音讯的。如果本地事务出现异常的话，那么就把整个事务 rollback 掉，之前的那条 prepare 的音讯也会被勾销掉，整个过程就回滚了。事务音讯的用法变动次要体现在生产者代码，消费者应用形式和一般音讯统一，demo 外面就不展现了。 ...

作者：比扬 01 客户介绍与我的项目背景浙江极氪智能科技有限公司于 2021 年 3 月成立，2021 年 4 月公布极氪品牌及旗下首款产品——极氪 001。极氪是一家以智能化、数字化、数据驱动的智能出行科技公司，秉承用户型企业理念，聚焦智能电动出行前瞻技术的研发，构建科技生态圈与用户生态圈，以“共创极致体验的出行生存”为使命，从产品翻新、用户体验翻新到商业模式翻新，致力于为用户带来极致的出行体验。 截止 2023 年 4 月，极氪量产车交付曾经冲破 10 万辆，从 0 到 10 万辆，极氪用时仅两年，快于其余新权势品牌至多四年以上的工夫，继续刷新新权势品牌交付记录，这不仅是对“极氪速度”的展示，也是对“中国速度”最好的诠释。 为了保障好极氪汽车业务的疾速倒退和用户体验，技术团队除了放弃高效的性能迭代的同时，也在一直的夯实其零碎稳定性和应急响应能力。自 2023 年开始，大数据团队正试点推广面向极数BI业务的数字化稳定性治理建设。 极数 BI 是一款面向极氪经营治理全体系的可视化数据分析系统，已笼罩多个外围业务场景。极数 BI 不仅仅是一个报表工具，还提供了全域数据互联互通、智能化数据分析和全景数据可视化的性能，能够为其余业务“产生了什么、为什么产生、将要产生什么、如何应答”提供欠缺的数据撑持和辅助决策能力。突破数字鸿沟，发明数据价值，逐渐实现全业务域的经营过程观测与经营后果出现是极数 BI 的倒退指标。 为保障极数 BI 的数字化稳定性治理建设落地，极氪通过建设端到端的全链路可观测体系、企业级应急响应机制和跨部门团队的人员协同机制，以业务连续性保障为指标，实现了极数 BI 业务的“X分钟的故障发现与通报”、“X分钟的应急响应与故障定位”、“X分钟的故障复原”外围稳定性指标的达成。 02 我的项目落地时面临的挑战和需要云原生浪潮下，Serverless 因其全托管免运维、老本升高和弹性伸缩等个性正逐渐在引领下一代的利用架构。极数 BI 业务从立项之初就确定了 Serverless 化的方向，并基于阿里云 Serverless 利用引擎（SAE）胜利落地。利用 Serverless 化最大化限度加重了运维工作，然而在本身业务的数字化稳定性治理方面仍然面临较大挑战： 如何笼罩和收敛从基础设施到业务利用监控的全链路告警事件 从前台业务数据、用户体验，到后盾应用服务性能，再到云服务及根底资源，即系统资源层、云服务应用层、业务监控层，尽管针对不同的服务模块都有对应监控，构建了绝对欠缺的指标监控体系，但因为微服务化后的服务模块泛滥、依赖简单，很有可能因为某个组件的异样或不可用导致整条链路产生大量冗余告警，造成告警风暴，从而造成运维团队疲于应酬海量告警信息，并且非常容易脱漏真正用于故障排查的重要音讯。因而，针对海量继续告警信息，如何进行告警合并，在保障不错过外围告警音讯的前提下克制告警音讯数量，成为了面临的重要运维难题。 如何构建对立的报警体系、通报机制和跨团队应急协同机制 系统资源层、云服务应用层、业务监控层，为了监控这些简单的IT环境，因为各层资源分属不同的团队进行治理，导致采纳了多种监控零碎，例如 Prometheus、Grafana、Skywalking、阿里云云监控、阿里云 ARMS 等，以获取更全面的监控数据和更好的理解运行状态和性能体现。然而多种监控零碎的并存带来的其中一个显著问题是告警信息的扩散，不同的监控零碎产生不同的告警信息，通过不统一的形式通报给告警解决人，而告警的排查通常须要多个团队独特单干进行解决，犬牙交错的告警解决减少了人员响应的复杂性和工作量，疲于应酬的水平往往远超出了告警解决人员的日常负荷。 如何标准故障等级定义、应急处理流程和故障管理体系 业务可用率是一套业务系统可靠性、维修性和培修保障性的综合反映。Availability = MTBF / (MTBF + MTTR)，通常业界习惯用 N 个 9 来表征零碎可用性，比方99.9%（3-9 availability），99.999%（5-9 availability），零碎呈现故障的停机工夫间接反映了业务可用率。如何定义一套实用于极氪本身业务的故障等级定义、应急处理流程和故障管理体系将是保障极氪对外承诺的业务可用率的重要撑持伎俩。通过建设一个可遵循的标准、全流程闭环的故障管理体系，配合技术手段的晋升，能够无效升高故障产生的几率，缩短故障的 MTTR，最终使故障造成的破坏性趋近于 0。 ...

“对于宇宙，我所晓得的最富诗意的事实之一就是， 咱们身材中的每一个原子都已经存在于某一颗暴发的恒星里。 组成你左手的原子和组成你右手的原子 很有可能来自不同的恒星， 而咱们都是恒星的孩子， 咱们的身材是由星尘组成的。 ” —— 物理学家 劳伦斯·克劳斯 出自：《无中生有的宇宙》 AIGC 热潮席卷寰球，能驾驭好 AI 工具的人，行将成为各行业最为热门的人才。 跃跃欲试钻研 AI 的你，是否想用本人的新技术和创造力一试身手呢？ 阿里云携手国民服装品牌森马推出 AIGC T 恤设计翻新赛，无论您是开发者、设计师、还是 AI 绘画爱好者，都能够使用阿里云函数计算疾速部署 Stable Diffusion， 以T恤为画布， “宇宙漫游” 为主题，进行AI 创作并投递作品，即有机会取得 Airpods、作品定制的阿里云X森马联名 T 恤、森马定制旅行箱、森马无门槛代金券等丰富处分，所有作品均有机会被森马选中并购买版权成为下一季服装图案主题。 超实用！函数计算部署 Stable Diffusion内置罕用插件， 包含 Deforum\roop\adetailer\tragger\detaset tag editor 等内置罕用 ControlNet， 包含 scribble\openpose\depth\linerart 等内置罕用模型库， 包含真人、动漫、修建及空间设计等格调模型反对 SDXL1.0， 疾速体验最新开源我的项目的魅力立刻加入中转流动页面查看，倡议 PC 端体验： https://developer.aliyun.com/adc/series/activity/aigc_design 参加流程： 奖项设置本次大赛设置了两个奖别：“作品优良能拿奖”、“提交作品就拿奖”。 作品优良能拿奖 ◆一等奖（1 名） 可取得 AirPods（3 代）、作品定制 T 恤、优质 AIGC 创作者证书 ◆二等奖（3 名） 可取得阿里云定制背包、作品定制 T 恤、优质 AIGC 创作者证书 ...

作者：极氪汽车吴超 前言2021 年，极氪 001 迅速锋芒毕露，仅用 110 天便创下了首款车型交付量“最快破万”的纪录。2022 年 11 月，极氪 009 在短短 76 天内便率先实现了首批交付，刷新了中国奢华纯电品牌交付速度的纪录。2023 年 6 月，极氪汽车再次交付 10620 辆，成为放弃五个月间断同比增长的惟一奢华纯电品牌。至此，极氪 001 已成为寰球最快冲破 10 万辆销售的豪华车，再次稳居 30 万元以上纯电车型销冠。 在过来的两年里，极氪汽车业务减速倒退，数字化倒退部门面临微小挑战。作为反对公司履约交付、整车交付、领取结算等诸多外围零碎的技术部门，团队简直每天都须要应答不同规模的利用公布，且利用零碎所需的云资源耗费日益减少。之前，为确保业务疾速倒退失去无效反对，基础设施的整体架构不足顶层统筹规划，局势犹如横蛮成长。公司尽管在行业赛道中一直突破交付纪录，但疯狂增长背地，则是濒临失控的基础设施框架及老本收入，这种情况正对将来业务的可继续倒退，带来了极大的危险和隐患。 因而，从去年开始，技术中台团队制订了明确的技术指标，力求尽快成立专项小组，深度整治现有基础设施的问题。团队期待通过改良基础架构，为极氪汽车将来基础架构的可继续倒退保驾护航。 治理挑战摆在面前的第一个问题，就是云原生场景下的资源管理。 事实上，自 2021 年起，咱们便开始了微服务和容器化革新打算，90% 以上的服务以容器的模式构建和部署。晚期在探讨如何优化计算资源的配置时，惯例的做法是对服务器进行资源利用率检测，对利用率不超过肯定阈值的资源，依照 CPU /内存峰值用量调整即可。但在云原生环境下，因为 Kubernetes 为容器资源管理提供了资源申请（Request）与资源限度（Limit）的语义形容，使得利用能够超额分配在对应的服务器资源上，若只是简略的剖析计算资源利用率，而疏忽了资源的分配率，可能导致在下一次利用公布时，因资源有余而无奈调度容器到对应节点。 公司以后应用到阿里云及多个公有云平台，运行了数十个 K8s 集群，同时这些集群上承载了数千个 Pod 节点，在理论运行利用零碎时，许多服务的利用率并不高，造成了极大的资源节约。然而当咱们着手制订打算，心愿优化这部分资源时，发现诸多挑战： 资源管理复杂度高： 相比于利用间接部署在服务器上，云原生架构的劣势在于对底层计算资源的治理更为精细化，以集群为单位的资源调度形式，对于晋升集群利用率有显著的作用。但与之带来的问题便是治理复杂度的问题。通过一个集群对立治理利用，尽管升高了总体资源老本，但使得分账、拆账变得更为简单，晚期为了可能解决各业务的分账以及权限管控等场景，职能团队别离创立了不同的 K8s 集群，给到对应的项目组，用于部署利用零碎，但集群的资源利用率并没有失去无效晋升。同时，随着业务的一直扩大，这些集群波及到不同部门、不同环境，版本已存在越来越大的差别。在利用部署时，因为管理人员的程度参差不齐，导致在日常运维及问题诊断时，非常耗时。资源分配不够智能： 业务类别千差万别，有 B 端经营治理，也有 C 端的高并发利用，尽管 K8s 提供了资源分配的形式，然而对于运维公布人员来说，难以预判将来利用的实在流量状况，以至于难以正当调配 CPU /内存资源大小，仅依照教训参数对立给出默认规格配置。如何实现长期主义： 在制订策略时，咱们放心此类静止式的架构优化流动，即使投入了大量的人力老本，也只能在短期内使得资源管理“看上去很美”，而随着业务架构的一直调整，又或者因优化资源产生稳定性影响之后，对将来继续经营治理资源的信念将会消减，从而使得本来的老本投入的边际收益趋向于零。业务指标为应答云资源治理方面的有余，以及不同云平台的能力差异，咱们曾思考过是否须要建设一套 CMP 多云治理平台，对所波及到的云平台及账号对立治理。然而在评估是否要立项时，咱们认为云原生时代下“以资源为核心”的多云治理理念，难以满足咱们对于利用架构设计的期待。这种治理形式，不仅开发成本极高，还须要适配多个云厂商的不同接口，并且对于资源管理的意义并没有设想中的大，只是解决了一部分资源开明创立的工作，但这并非是云原生环境下利用治理的外围场景及工作。 极氪以后的基础设施架构次要是以 K8s 集群为底座，这意味着只有可能治理好这些集群，便可能治理好资源，从而为下层的业务零碎提供更大的价值。于是，咱们在设计资源管理计划时，彻底摈弃了 CMP 的以资源为核心的多云资源管理理念，投向了聚焦于云原生基础设施的治理这一方向。 平台技术团队将此次在资源管理域的我的项目指标定义为：老本可见、用量可控、配置可管， 而以后须要解决的问题包含： 1. 老本洞察与剖析： 设计更为精细化的老本均摊模型，看清各业务的老本收入状况，同时为不同业务提供 Pod 资源利用率的智能剖析，辅助运维部署工程师在利用公布时，正当设置资源规格； ...

开迈斯新能源科技有限公司于 2019 年 5 月 16 日成立，目前合资股东别离为大众汽车（中国）投资有限公司、中国第一汽车股份有限公司、一汽-大众汽车有限公司[增资扩股将在获得适当监督（包含反垄断）审批后实现]、万帮数字能源股份有限公司和安徽江淮汽车集团控股有限公司，总部位于江苏常州。开迈斯集车企与充电企业劣势于一体，提供从充电基础设施的研发制作到软件的智能互联，从私人充电用户到半公共、公共以及商务用户，从电力供应的行业源头到服务平台的终端体验，实现每一个业态的前后端无缝连贯。 开迈斯为中国新生代消费者而来，不仅重视私家电动车主的充电体验，还以高端的品质服务提供用户便捷无忧、智能高效的全新充电体验，开启乐享生存的旅程。同时，开迈斯致力于为电动出行提供全场景充电服务，依靠弱小的研发实力、先进的核心技术和高质量服务，还播种了国内新能源汽车充电畛域的诸多奖项：2021 年，开迈斯荣膺“中国充电桩行业最佳经营服务创新奖”；2023 年 3 月，开迈斯一举取得“高质量充电五星级场站奖“，成为首批取得五星级评估的优良充电运营商（五星级别是最高级别最高规范的场站）；同年 6 月，开迈斯荣获 2023 中国充换电行业十大影响力运营商品牌奖。开迈斯将继续推动充电网络建设速度和充电用户旅程的优化翻新，并将聚焦高功率充电设施研发和新能源服务畛域的摸索，从而推动新能源与新能源汽车深度交融的绿色倒退。 业务稳定性挑战大2023 年，开迈斯将持续致力于以用户为核心的整合翻新，助力智能电动化出行。截止往年7月底，开迈斯充电网络覆盖国内 192 城，建设 1,274 座充电站和 11,113 个充电终端，积攒用户超 241 万。从建设滞后到“适度超前”，将来三年充电桩产业将迎来大倒退，市场规模达千亿级。当初全国各地很多城市在对充电桩的增设和利用上在一直降级加码，随着新能源汽车的倒退，充电用户群体的诉求飞速增长，开迈斯随同着业务的快速增长，对其架构的稳定性以及可用性也提出了前所未有的挑战。 开迈斯采纳传统的 SpringBoot 形式进行利用开发，利用间通过 Http 申请形式进行互通互联，也正是 SpringBoot 架构的简略性，无效帮忙到开迈斯的业务以及微服务数量进行疾速扩张。然而随着微服务规模的增大，逐步发现利用在公布、运行等各个阶段的都存在一些稳定性与效率上的问题。开迈斯架构同学也意识到须要引入微服务治理能力对以后的微服务进行失当的治理，从而进一步晋升业务的稳定性。 同样的，业务仍旧面临疾速倒退的诉求，如果将原先的 SpringBoot 框架升级成 Spring Cloud 并且引入各种高阶的服务治理能力，对于开迈斯研发同学来说，老本过于太大。 降级架构不改代码是否有一种不必改代码的形式实现咱们微服务的治理能力呢？比方通过施行全链路灰度公布来防止变更带来的稳定性危险；通过限流降级能力保障运行态的稳定性，解决不确定的流量带来的稳定性危险；通过鉴权能力解决微服务间调用的平安危险。这就好比，咱们如何能够在飞机高速运行的过程中，通过更换引擎来晋升飞机的性能？更要害的是，对于咱们飞机上的乘客来说，还要是无感的。 咱们将问题进一步形象，如何能够不改代码，实现任意 Java 利用的服务治理能力，并且在这个过程中咱们须要确保稳定性、问题诊断效率、架构的可持续性、性能等一系列事实的因素。 技术的摸索总是为业务服务的，咱们围绕着开迈斯的计划进行了一步探讨，是否能够通过 ServiceMesh 的计划解决用户无侵入服务治理的难题。 支流的分布式 Sidecar 模式在近几年受到了大家的青眼，然而在应用过程中也有问题逐步裸露了进去，Sidecar 模式在内存耗费上比拟可控，最多也是在 MB 这个量级，然而在 CPU 利用率上，随着业务吞吐量的增长，Sidecar 的 CPU 耗费根本达到了与业务耗费持平的量级，相当于在应用 Sidecar 之后，雷同业务规模须要两倍的集群数来承载。总的来看，业内也逐步意识到了这个问题，逐步演进出了其余计划，通过集中化的形式实现无侵入的流量路由。另一方面，引入 Envoy Sidecar 对于开迈斯来说则减少了不必要的运维老本、问题诊断的效率也大幅度回升，同时引入 ServiceMesh 的技术复杂度对业务的研发同学来说也是十分高的门槛。既然 ServiceMesh 计划对用户来说门槛比拟高，那么是否能够通过 Higress 实现服务间调用的治理诉求？ 只需透出网关的操作界面即可，基于托管的 Higress 给无侵入的服务治理提供了一种新的思路，在满足用户服务治理治理需要的同时，相比Sidecar 在资源利用率、运维复杂度、性能和时延等方面具备劣势。 ...

阿里云 Serverless 利用引擎 SAE2.0 正式公测上线！全面降级后的 SAE2.0 具备极简体验、规范凋谢、极致弹性三大劣势，利用冷启动全面提效，秒级实现创立公布利用，利用老本降落 40% 以上。 此外，阿里云还带来容器服务 Serverless 版、函数计算、第八代高主频计算实例、办公平安平台 SASE 等多款产品的全新降级，进一步升高企业上云、用云门槛，让利用开发更简略。 阿里云云原生利用平台负责人丁宇示意，老本是企业上云的外围关注点之一，阿里云进一步开释技术红利，继续推动全栈产品 Serverless 化，用技术和翻新惠及更多中小企业和开发者，升高翻新老本。  Serverless 利用引擎（Serverless App Engine，简称 SAE）是一款利用零代码革新、极繁难用、自适应弹性的利用托管平台。 在 SAE 上，用户不用再关怀简单的基础设施，只须要上传代码包或者容器镜像即可实现在线业务全托管，SAE 会主动运行利用和伸缩实例，并提供网络、负载平衡、监控等配套能力。 SAE2.0 本次降级带来三大全新能力： 产品应用更简略， 利用零革新上线，零学习老本，秒级实现创立公布利用，同时依照理论使用量付费，利用老本降落 40% 以上；其次，规范更加凋谢， 基于容器规范构建并且外围能力开源，提供了丰盛的平台工程能力，助力研发运维提效 50%；在弹性能力上继续加强， SAE2.0 实现了百毫秒级弹性伸缩，依据流量自适应调整资源应用，利用冷启动提效，反对缩容到 0，没有业务流量就不须要付费，这对于新兴的业务以及一些翻新守业的公司更加敌对。与此同时，阿里云还带来了全新的容器服务 Serverless 版，针对 K8s 做了大量优化，晋升弹性能力，反对动静容量布局，K8s 外围零碎组件全托管。 同时，降级了智能弹性预测 AHPA，相比手动配置，准确率晋升 80%；基于库存感知调度和可用区打散调度， 进步了弹性的确定性以及利用的高可用性，让万千企业与开发者更便捷、更弹性地应用云。 针对以后十分火爆的 AIGC 畛域，阿里云也降级了高度集成大模型框架的函数计算FC，开发者能够在函数计算上轻松部署来自 ModelScope、HuggingFace 等开源生态和社区的模型，目前函数计算的利用中心里已退出 Stable Diffusion、通义千问、通义万相等 10 多款热门 AI 利用模版，大幅升高大模型的利用开发门槛。 除了 Serverless 产品全新降级之外，阿里云还带来了全新的第八代高主频计算实例hfg8i。 基于阿里云「飞天+CIPU」计算体系架构，采纳国内首款第四代至强 SPR 处理器，全核睿频可达 3.9Ghz，单核性能相比上一代晋升 60%，全面反对 eRDMA 能力，网络延时最低 8 微秒，带来全方位的算力晋升，帮忙企业轻松应答多人在线游戏、工业仿真、视频直播等算力密集型场景。 ...

评测前请点击文末链接，支付 MSE-Nacos 收费试用，再启动评测。 注册配置核心 MSE-Nacos (以下简称 MSE-Nacos)，即 Nacos 的企业版，开箱即用的 Nacos 云服务，对 Nacos 内核进行企业级稳定性加固，故障自动检测及复原、多可用区容灾、推空爱护等个性，具备风险管理能力，全局继续剖析并治理集群危险；企业级平安基于 RAM 鉴权体系，可构建细粒度的安全控制能力，集成阿里云 KMS 提供配置加密能力，帮企业更平安地应用 Nacos 服务；基于 Alibaba Dragonwell 进行深度调优，比 Nacos 开源版性能晋升 50% 以上；企业级易用性，提供推送轨迹、丰盛欠缺的监控报警能力和便当的控制台操作，总的来看，企业版相比开源在稳固、平安、性能和效率方面更具备劣势。评测内容 通过体验 MSE-Nacos 进行体验，您能够围绕以下三大主题，进行测评创作： 1、Nacos 开源版的的应用测评，能够包含但不限于以下内容： （1）开源选型：多个开源注册配置核心在性能、性能、控制台体验、上下游生态、社区体验等方面的比对。 （2）最佳实际：应用过程中遇到过哪些报错或异样，是如何解决的。 （3）开源需要：在性能、控制台体验、上下游集成等方面有哪些需要。 2、MSE-Nacos 产品体验测评，能够包含但不限于以下内容： （1）产品文档：产品的操作文档是否丰盛、形容是否残缺和精确？如果没有，还欠缺什么局部、存在哪些有余？ （2）产品能力：产品性能是否满足您的业务场景，如迁徙工具、风险管理、推空爱护、推送轨迹、端云互联等？ （3）产品控制台：产品控制台是否满足您的操作需要，例如展现是否敌对，操作是否晦涩、提示信息是否残缺等？ （4）产品集成体验：和 Spring Cloud/Dubbo/K8s 之间的开源集成体验、和 ACK/SAE/EDAS 之间云产品集成体验是否晦涩，还有哪些集成体验须要晋升的中央？ 3、MSE-Nacos 利用场景测评，能够包含但不限于以下内容： （1）服务发现：MSE-Nacos 作为注册核心，实现利用的服务注册与发现，以及消费者对提供者的调用，配合服务治理实现全链路灰度。 （2）服务配置：MSE-Nacos 作为配置核心，实现将利用中的变量、参数等从代码中提取进去，并存入一个配置文件，在须要更改配置时，只需更改此配置文件即可。 （3）可观测：通过 Grafana 监控大盘，查看引擎的节点数、配置数、服务提供者数、每秒查问数、每秒操作数和连接数等信息。 流动奖品 1、参加奖：流动期间凡公布100字以上评测且通过审核的用户，可获50积分（每人最多得150积分） 2、争优奖：30篇，流动期间评测文章被官网断定为“优”，将取得30元猫超卡 3、后劲奖：5篇，官网评定优质评测文章，取得小米无线充电器 + 开源定制咖啡杯 + 优质评测证书 4、最优奖：1篇，官网评定最佳评测文章，获Redmi显示器A27 + Nacos 定制大礼包（ 雨伞、T恤、茶杯、咖啡杯、Polo衫、书包）+ 最佳评测证书 + 阿里云社区首页达人展现一周 * 特地权利：阿里云官网将从后劲奖和最优奖中，选取若干文章，署名公布至“阿里开发者”公众号解锁产品的有限后劲，你就是让扭转产生的力量！ ...

作者：褚杏娟 上图来源于基于函数计算部署 SD实现光影成果 前言： Serverless 在中国倒退这些年，经验了低潮、低谷、当初从新回到公众视线。很多企业都十分感兴趣，局部企业开始大规模利用；也有一些企业对在生产环境真正落地蠢蠢欲动。 同时，在当下 AIGC 技术浪潮中，Serverless 如何与 AIGC 更好联合施展更大的价值？ 带着这些问题，InfoQ 记者对话阿里云智能 Serverless 研发负责人杨皓然、高德服务端负责人孙蔚，一起探讨 Serverless 和 AIGC 联合能够激发哪些想象力？ Serverless 新进展问题1：从去年强调 Serverless 化至今，在这半年的工夫里，阿里云在 Serverless 技术方面获得了哪些停顿？ 杨皓然： 2022 年，阿里云在 Serverless 方面提出了十分明确的观点，认为 Serverless 是云计算的下一个阶段，阿里云致力于让整个产品体系 Serverless 化。次要在以下几个方向上继续倒退： 第一个方向是产品体系的 Serverless 化。 2022 年，数据库曾经全面采纳了 Serverless 的模式，而往年更多的中间件服务也逐渐 Serverless 化，包含传统的微服务注册核心和网关等，同时消息中间件也会提供 Serverless 的产品状态。 第二个方向是通过 Serverless 让云服务可能更细腻地集成，最终目标是让这些服务成为开发者构建利用的原子化、可组合组件，使开发者可能应用即开即用的组件来疾速构建利用。 第三个方向是持续深耕 Serverless 计算平台自身的技术能力。 这包含进一步晋升函数计算、Serverless 利用引擎 SAE 的弹性速度，以及 GPU 的 Serverless 化停顿等。在容器的 Serverless 状态方面，阿里云推出了全新降级的容器服务 Serverless 版，为开发者提供更丰盛的抉择，从容器到利用将失去全栈反对。 孙蔚： 从具体利用 Serverless 的角度，我来补充下关注到的三个停顿。 ...

作者：涂鸦 背景在分布式系统架构中，每个申请都会通过很多层解决，比方从入口网关再到 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)；否则重回熔断状态，具体原理如下图所示： ...

Forrester 于近期公布了《Navigate The Cloud-Native Ecosystem In China, 2023》，报告概述了中国云原生畛域的开源我的项目对构建云原生生态的促进作用，这些开源我的项目正深刻影响着企业的技术决策者以何种策略拥抱云原生这一古代 IT 基础设施的外围。 报告表明，中国超过 80% 的云决策者示意，他们的公司正在采纳云原生技术， 例如容器、分布式数据库、微服务、服务网格、FaaS 和分布式中间件，这一比例显著高于寰球同行，以推动智能自动化、集成、数据库、大数据、剖析、AI 2.0、物联网、5G和区块链等次要畛域的翻新。 Forrester 首次面向中国公布该报告2022 年，Forrester 公布了寰球范畴的《Navigate The Cloud-Native Ecosystem in 2022》，往年的报告是 Forrester 首次针对中国的云原生开源我的项目和背地反对的企业进行的调研。Forrester 认为阿里云在云原生开源畛域布局最为全面。 此次报告将云原生畛域开源我的项目分为 5 个方向，别离是：基础设施推动者（Infrastructure enablers）、开发推动者（Development enablers）、运维推动者（Operations enablers）、畛域创新者（Domain Innovators）、标准制定者（Specifications），阿里云共计奉献了 24 个开源我的项目，他们别离是： 基础设施推动者有 3 个开源我的项目， 别离是 Inclavare Containers、Dragonfly 和 OpenYurt。开发推动者有 9 个开源我的项目， 别离是 Sentinel、Apache Dubbo、Spring Cloud Alibaba、Nacos、Higress、Tengine、OpenKruise、KubeVela、 OpenSumi 和 Serverless Devs。运维推动者有 2 个开源我的项目， 别离是 ChaosBlade 和 Koordinator。此外，阿里云容器服务团队近期还开源了 Kubernetes 容器网络诊断工具 KubeSkoop，以升高网络问题排查难度，让没有网络常识的人也能够自动化地定位网络问题。畛域创新者有 6 个开源我的项目， 别离是 Apache Dubbo、GraphScope、Fluid、KubeDL、GraphScope 和 AliOS Things。标准制定者有 4 个开源我的项目， 别离是 Container runtime interfaces、Container storage interfaces、CloudEvents（参加制订）和 OpenSergo。此前，CNCF 统计了基金会中的 148 个寰球开源我的项目，由中国互联网公司发动的有 37 个，占比 25%；其中阿里云主导及参加开源我的项目共计 13 个。木兰开源社区也统计过 CNCF Landscape 中的 580 个开源我的项目以及他们所对应的发动企业，察看到近八年来云原生畛域中企业的投入与其发动我的项目的影响力。得出结论，2022 年阿里云在 CNCF 开发者合作影响力排名中 ，位列寰球第二。 ...

往年，CommunityOverCode Asia 2023 将是阿帕奇亚洲大会的首次线下会议，北京，8 月 18 日至 20 日。会议将继续 3 天，设有 17 个论坛方向，共收集到 150 余个议题投稿，其中中文议题约 110 个，英文议题近 40 个。Apache Dubbo 和 Apache RocketMQ 邀请您来参会，点击浏览原文或扫描下方海报的二维码、填写问卷，有机会收费取得 3 天通票。 对于 Apache Dubbo Apache Dubbo 是一款易用、高性能的 WEB 和 RPC 框架，同时为构建企业级微服务提供服务发现、流量治理、可观测、认证鉴权等能力、工具与最佳实际，已被中国工商银行、小米、携程网、恒生电子、海尔、新东方、顺丰科技等企业采纳，并荣获 2022 InfoQ 中国开源开源倒退报告我的项目排名第 6、2022 CSDN 中国开发者影响力年度开源影响力我的项目、2022 开源我的项目成熟度评估优良壹级等荣誉。 对于 Apache RocketMQ Apache RocketMQ 自诞生以来，因其架构简略、业务功能丰富、具备极强可扩展性等特点被泛滥企业开发者以及云厂商宽泛采纳。历经十余年的大规模场景打磨，RocketMQ 曾经成为业内共识的金融级牢靠业务音讯首选计划，被广泛应用于互联网、大数据、挪动互联网、物联网等畛域的业务场景。 延长浏览： 阿里云中间件开源往事

作者：草谷 前言微服务引擎 MSE 全新公布！新版本带来了一系列令人振奋的个性和改良，让您更轻松、高效地构建和治理微服务应用程序。从疾速入门到迁徙优化，MSE 为开发人员提供了全方位的反对和解决方案。无论您是刚刚接触微服务还是曾经深耕其中，MSE 都将为您带来独特的体验和冲破。让咱们一起摸索 MSE 的全新个性，开启微服务开发的新篇章！ 疾速入门，带你 15 分钟体验 MSEMSE 重视用户体验，咱们为您提供了全新的疾速入门指南。只需 15 分钟，您就能够轻松理解 MSE 的基本概念和外围性能，体系化意识 MSE，企业能够更加迷信、系统地进行微服务架构的评估和选型，进步决策的准确性和成功率，为企业的数字化转型提供强有力的反对。 部署微服务利用观看《部署微服务利用》视频演示：https://help.aliyun.com/zh/mse/getting-started/mse-quick-start#f814392035lp6 将疏导您部署 Demo 利用 A（consumer）和利用 B（provider）。 Demo 中利用 A 调用利用 B，您可返回 Github 查看 Demo 代码Demo 同时交融 SpringCloud 和 Dubbo 框架，引擎类型为 Nacos微服务查问与配置观看《微服务查问与配置》视频演示：https://help.aliyun.com/zh/mse/getting-started/mse-quick-start#18c3af7035n4n 服务将主动注册至您抉择的 MSE Nacos 实例，因而咱们将疏导您查问第一步部署胜利的服务提供了对立配置管理的能力，因而咱们将疏导您体验公布配置的过程，利用 A（consumer） 会一直得监听您公布的配置 对外裸露服务观看《对外裸露服务》视频演示：https://help.aliyun.com/zh/mse/getting-started/mse-quick-start#31c97a4035tpd MSE 云原生网关是兼容 K8s Ingress 规范的下一代网关产品，将传统的流量网关和微服务网关性能合并，更稳固、更平安、更高性能咱们将疏导您通过「云原生网关」将服务裸露到公网，并进行路由调试 体验全链路灰度观看《体验全链路灰度》视频演示：https://help.aliyun.com/zh/mse/getting-started/mse-quick-start#4435f82035lx5 MSE 服务治理提供无损高低线、全链路灰度、流量治理等全生态能力，帮忙您更低成本开发、打消变更危险、加强运行稳定性咱们将疏导您通过「服务治理」实现全链路灰度公布，实现基线利用和灰度利用的全链路流量隔离 提供收费试用（Freetier）在疾速入门的体验中，波及到注册配置核心，云原生网关，微服务治理，ACK 4 款体验产品，阿里云将提供收费试用流动，让您能够收费体验咱们产品！无需领取费用即可尝试咱们的外围性能和个性。无论您是个人用户、学生、开发者还是初创企业，都能满足您的需要： 点击链接申请：https://free.aliyun.com/?product=9564559 全新上云迁徙体验 微服务迁徙工具微服务架构的应用程序曾经成为许多企业的首选，然而，随着业务的疾速倒退和技术的一直演进，微服务架构的迁徙却成为一个严厉的挑战。当初，咱们为您带来 MSE（Microservices Engine） Sync，这是一款专为微服务迁徙而设计的弱小工具，让微服务迁徙变得轻松自如。 反对多种引擎数据模型转换MSE Sync 提供了弱小的模型转换性能。它能够主动将 Eureka，Nacos，ZooKeeper 相互转换，您能够大大减少手动重构的工作量，进步迁徙效率。 ...

往期回顾： 流动回顾｜阿里云 Serverless 技术实战与翻新成都站回放 & PPT 下载 流动简介阿里云 Serverless 技术实际营（AI 专场）是一场以聚焦企业级 AIGC 利用开发与落地开展的主题流动，流动受众以关注 Serverless 和 AI 技术的开发者、企业决策人、云原生畛域创业者为主，流动模式为演讲、入手场景实操，让开发者通过一个下午的工夫增进对 Serverless 技术的了解，疾速应用 Serverless技术，纵情拥抱 AI 利用开发和云计算新范式带来的技术红利。 流动报名信息：流动工夫： 2023 年 8 月 25 日（周五） 13:30 流动地址： 阿里核心.望京 A 座 收费名额有限，限度 60 人，采取报名审核制！ 立刻报名！还有超多周边礼品！ 报名链接： 参会体验聚焦企业级 AIGC 利用的开发与落地Stable Diffusion 搭建与利用基于大语言模型疾速构建 AI 知识库/AI 助手间接领用云产品收费试用额度手把手实际万人打磨场景颁发技术实际营结业证书现场抽大奖流动议题及分享嘉宾一、13:30-14:05 分享主题：尽享红利，Serverless 构建企业 AI 利用计划与实际 分享嘉宾：洛浩｜阿里云云原生高级架构师 议题简介： 本议题将介绍 AI 浪潮下，Serverless 构建企业 AI 利用的解决方案，最佳实际和技术支持，帮忙企业升高部署老本、进步开发效率和利用性能。 二、14:05-14:40 分享主题：基于 Serverless 技术搭建 Stable Diffusion 创作平台 分享嘉宾：卢令｜阿里云智能高级技术专家 ...

作者：王夕宁 阿里云服务网格负责人，以下内容基于 2023 寰球软件工程翻新技术峰会的演讲内容整编而成 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 代理下的网络数据包的传输是怎么的过程？ ...

作者：图杨 背景某位资深运维工程师A：“一天不收个几十条告警，我都感觉心里不虚浮” 。运维工程师B：“我那几个告警天天告，我的利用一点问题都没有，然而我又不敢关”。运维工程师C：“我每天都要花大量的工夫，整顿曾经产生的告警：查它们是什么起因导致的，是故障还是误报，要不要解决，要不要屏蔽。”运维工程师D：“要不咱们给告警数配置一个告警吧，一天收100条告警是失常的，哪天告进去200条预计就是有问题了”。会呈现这样的对话不是因为这几位运维工程师不业余，实际上，误告警泛滥，真告警被吞没，就是大多数团队，甚至顶尖的互联网企业的运维团队的现状。想要配置出“零碎无异样时不误告，有异样时及时告”的“高质量”的告警规定是十分具备挑战性的。 所以这些告警都是些什么？为了保证系统和利用的稳定性，工程师们会搭建监控零碎以实时地采集比方RT(响应工夫)、QPS(调用次数)、Error Rate(错误率)、HTTP状态码、Full GC次数等要害指标，并对外围利用的要害指标进行实时地巡检，当检测到指标以后值超出“失常水位”时，相干的工程师就会收到对应的告警。 那这些误告警又是怎么产生的呢？传统的告警规定次要是动态阈值告警，当某指标的理论值超出用户设定的阈值，就认为是零碎呈现了异样。然而，想要疾速选定适合的阈值，配出“高质量”告警，是很难的。阿里云利用实时监控服务ARMS通过对近百位用户的访谈与调研，发现均匀每个用户每天收到1275条告警。而且，咱们对 6 万条对于响应工夫和错误率突增的告警进行了剖析，发现其中只有 3.05%的告警是“真”告警，剩下的96.95%都是因为阈值设置不当引发的误告警。 为什么配出”高质量“告警很难？传统的告警规定是动态阈值告警，工程师们会对每个指标设定一个固定的阈值来定义指标的“失常水位”，当指标的理论值超出阈值时，对应的工程师就会收到告警。比方当利用的RT超出1s，就算是异样。然而适合的动态阈值，是很难定义的。因为： 1. 同一指标，不同利用，不同接口的“失常水位”不同。现实生活中，SRE(运维工程师)须要对很多利用、很多接口配置告警。即便是同一个指标，不同利用，不同接口的“失常水位”都是是不一样的。下图是同一家公司，不同利用的错误率指标。 下图是同一利用，不同接口的均匀响应工夫指标： SRE须要为每一个利用、每一个接口的每一个指标来设定“失常水位”。 这对于有几百个利用、几十条要害指标的公司来说，仅靠人力来一直地设定和保护指标的“失常水位”须要破费大量的工夫。 更可怕的是，随着业务的倒退，代码一直变更，各项指标的“失常水位”会一直地变动。这意味着SRE要一直地调整告警阈值。 v2. 有的指标，不同时段的“失常水位”不一样比方某工作网站的访问量，在10：00-18：00时段内，访问量低于1000是异样的；然而在夜间，比方22：00-6：00，访问量超过1000可能是收到了攻打。在这种场景下，指标的“失常水位”会随着工夫变动而一直变动。如果咱们硬配置一个阈值，比方低于1000就告警，那整个早晨都会受到告警的打搅。 有的SRE可能会示意，那我早晨主动吧告警关掉就好了，然而现实生活中，这种起伏不定的指标，很难有像“1000”这么规整的阈值，现实生活中的调用量指标是上面的样子，就是会有一些令人意想不到的“大毛刺”。 3. 告警阈值的合理性难以及时验证SRE们配好一个告警阈值之后，也很难验证这个阈值是不是正当的。运维工程师们往往会一直地被打搅，他们要一直地调整阈值，能力失去一个较高质量的告警。当指标的失常水位随着业务变动而变动之后，周而复始，从新调整阈值。 业界是怎么帮助用户配置出”高质量“告警的？如何无效地帮忙客户配制出“高质量”的告警规定，是每一个APM(利用性能监控)厂商关注的问题。为了解决这个问题，支流的APM厂商都提供了智能告警服务。次要思路就是用统计学算法或者机器学习算法，提取指标的特色，上面介绍业界如何解决下面提到的问题： 问题 1：同一指标，不同利用，不同接口的“失常水位”不同为了解决阈值难配的问题，一些APM厂商给出了动态阈值举荐的性能。个别地，他们用算法为各个接口、各个利用，依据对于指标的历史数据学习指标特色，联合指标历史均匀水位以及稳定状况给出一个倡议阈值。 然而，厂商给的是通用算法，SRE很难评估算法举荐的阈值是不是合乎他的业务，是不是真的“高质量”的阈值。 问题 2：有的指标，不同时段的“失常水位”不一样对于稳定型指标，一些厂商推出了动静阈值(也称区间检测)性能。在这个场景下，指标的理论值不再和繁多的动态阈值比拟，而是和一个工夫序列做比照。具体地，算法会依据指标历史数据学习其稳定特色，并对将来一段时间指标失常变动范畴进行预测。比方每天00：00对将来一天的指标“失常水位”的高低边界进行预测，等采集到理论值时，比方10：00时，将理论值与之前的预测值进行比拟，理论值超过了边界就被断定为异样。上面是一个动静阈值性能的示意图，绿线是指标的理论值，蓝色暗影是算法计算出来的，指标在失常状况下的高低边界。 这里的毛病在于：算法对用户来说是黑盒，SRE们不敢把要害的业务指标释怀地交给算法。另外，这些算法是通用的，不肯定合乎SRE的理论业务需要。而且，很多APM厂商没有关注到这一点，没有给用户调节动静阈值的性能。 问题 3：告警阈值的合理性难以及时验证一些APM厂商给出了阈值和指标过来一段时间理论值的比照图。然而，SRE们往往没有工夫对每个利用、每条指标、每个接口都浏览一遍来设置正当的阈值。 另外，对于动静阈值的性能，很少有厂商给出比照图。SRE没有足够的信息来对告警阈值进行调整，只能一直地受到告警打搅再调节阈值。这样，有了几次误告警之后，SRE们就会把这些“金玉其外;败絮其中”的AI性能关掉。 ARMS 是怎么帮用户实现半分钟配出”高质量“告警的？为了解决这些问题，为了给用户提供“通明的”、“易用的”、“所见即所得”的智能化告警体验，ARMS对利用性能监控告警性能进行了全面降级。 上面咱们介绍ARMS如何解决“高质量”告警难配的问题。 问题 1：同一指标，不同利用，不同接口的“失常水位”不同实际上，对每一条指标配置一个适合的阈值其实都不算难，难的中央在于每个利用、每个接口、每种指标类型适宜的阈值都不一样。SRE要遍历所有的指标，为他们设置适合的阈值，这是须要消耗大量工夫的中央。 对于配动态阈值这种反复的工作，ARMS决定交给代码来做。用户只须要抉择要配告警的利用、接口和指标类型。 而后点击“填入P4倡议阈值”，ARMS就会主动拉取每个利用、每个接口对应指标的历史3天数据，而后用N-sigma算法，计算每个指标历史3天的均值和方差。当业务没有发生变化，咱们默认指标遵从一个正态分布，它偏离它的冀望N倍标准差的概率很小。依据这个原理，咱们给出一个举荐阈值。这里的"P4"是示意的是最不重大的告警，这个倡议阈值仅仅示意指标有些许异样。 当用户的业务产生了变动，利用失常水位也产生了变动，那么用户也只须要编辑一下告警规定，再点一次“填入P4倡议阈值”即可。真正做到了一次配置，随处失效。 问题 2：有的指标，不同时段的“失常水位”不一样因为动态阈值告警难以满足如RT、QPS等稳定型指标的监控性能，咱们举荐动静阈值，也叫区间检测性能。这里咱们会主动依据指标7天历史数据，预测指标将来高低边界。用户能够依据高低边界配置告警，当指标理论值超出上边界或下边界，触发告警。 ARMS次要应用了Meta(Facebook)公司2018年颁布的Prophet算法 [ 1] 。算法会先依据指标历史7天数据，用工夫序列合成算法，将指标分解成节令项、趋势项和残差项。举个例子 [ 2] ，对于上面图 1 中的工夫序列，Prophet算法会将它分解成有法则的趋势项(图2)节令项(图3)和没有法则的残差项。 图 1 图 2 图 3 既然趋势项和节令项是有法则的，咱们就能够对将来一段时间指标的值进行预测。然而还有残差项的存在，所以如果咱们对指标的变化趋势预测失去的是一个区间，能够看图 1 中蓝色暗影局部。Prophet是一个无畛域的，时序预测通用算法。咱们对该算法做了一些试验之后，发现把它利用到APM畛域，还须要大量的革新。 当用户配置区间检测工作之后，ARMS会在后盾以每24h一次的频率，学习指标历史7天数据的特色，提取指标趋势性、季节性等特色，失去指标将来24h的预测曲线。再依据指标本身的稳定状况，也就是误差方差的大小，为将来一天指标的数据做出一个预计区间。用户在配置区间检测告警中，能够对算法计算出来的高低边界进行预览。下图中，蓝线是指标的理论值，绿色的暗影是高低边界。 ...

作者：熊峰 云原生时代的 Serverless 利用托管架构回顾过去十年，数字化转型将科技翻新与商业元素一直交融、重构，从新定义了新业态下的增长极。商业正在从大工业时代的固化范式进化成面向创新型商业组织与新商业物种的簇新模式。随着数字化转型在中国各行业宽泛深刻，不论是行业巨头，还是中小微企业都不得不面对数字化改革带来的未知时机与挑战。 ——《阿里云云原生架构白皮书》 近年来，传统企业的上云步调正在提速，能够说，上云已逐步成为企业倒退的必然选择。在这个过程过程中，云原生通过凋谢、规范的技术体系、麻利的构建和运行高弹性、容错性高、易于治理的零碎，帮忙企业最大化利用云的能力，施展云的价值，也正是因而，越来越多的企业、行业开始拥抱云原生。能够说，云原生岂但重构了整个软件技术栈和生命周期，同时也重构了企业上云的形式。 云原生这个概念从提出、到壮大、再到明天的遍及，始终处于一个一直演进和变革的过程中。云原生体系下利用的托管状态随着企业应用架构在一直演进。 最早的利用大多是集中式、单体式的，利用通过优雅的分层来实现畛域模型的共享和更粗疏的模块拆分。随着互联网的爆炸式倒退，分布式的架构逐步取代集中式架构。 容器的呈现和极大遍及，通过集装箱式的封装，标准化开发和运维使得大规模、跨语言的分布式应用大规模落地成为事实。云原生利用托管架构迎来了第一次飞跃：容器化。 在此之后，微服务架构得以更大规模的风行开来，随之而来的是企业须要运维的基础设施日益简单、须要治理的容器数量出现几何式增长。Kubernetes 一方面屏蔽了IaaS 层基础架构的差别，并凭借低劣的可移植性，帮忙利用统一地运行在包含数据中心、云、边缘计算在内的不同环境； 另一方面，凭借优良的开放性、可扩展性以及沉闷开发者社区，Kubernetes 在大规模容器编排之战中怀才不遇，成为分布式资源调度和自动化运维的事实标准。云原生利用托管架构迎来了第二次进化：全面拥抱 Kubernetes。 只管 Kubernetes 带来了泛滥益处，然而在生产环境中落地 Kubernetes，继续保障系统的稳定性、安全性和规模化成长，对于绝大部分企业来说，仍然充斥挑战。在这样的背景下，Nodeless Kubernetes 进入大家眼帘：在保留残缺 Kubernetes 能力的根底上，将简单的运维和容量管理工作下沉到云基础设施底座。至此，云原生利用托管架构迎来了第三个阶段：Serverless Kubernetes。 只管 Serverless Kubernetes 极大加重了企业运维 Kubernetes 的累赘，但 Kubernetes 本身的复杂性和平缓的学习曲线仍然让人望而却步，如何让用户的利用跑在 Kubernetes上，既能享受到 Kubernetes 带来的诸多技术红利，又能尽可能 0 革新，成为又一个亟待解决的问题。基于此，云原生利用托管架构迎来了第四个阶段：Serverless利用托管。 前面的这两种模式，就是咱们明天着重探讨的的 Serverless 架构与状态。那到底什么是 Serverless 呢？不同的组织，从不同的视角，给出了不同的表述和定义，这里咱们选取最有影响力的两个定义： Berkeley Serverless 论文认为：Serverless Computing = FaaS + BaaS。一个利用必须可能实现主动缩扩容和按使用量计费能力被认为是 Serverless 利用。 CNCF 则认为：Serverless 计算指的是构建和运行应用程序不须要进行服务器的运维治理。它形容了一种细粒度的部署模型，在该模型中，一个利用被打包成多个功能模块并上传到平台，而后依据以后的确切需要执行、扩缩容和计费。 只管视角和表述不同，然而仔细的读者能够很快从中提炼出共性的关键词：按需应用、按量付费（老本）、免运维（效率）、主动伸缩（弹性）。 实质在于，将企业无限的资源和精力从繁冗的基础设施运维中解放出来，投入并聚焦到本人的外围业务逻辑中。 这里咱们能够类比买车、租车、网约车来了解什么是 Serverless。 企业自主保护服务器就好比买私家车，只管付出了极大的资源老本(买车)和运维老本（车险、培修）、然而承载容量固定(座位无限)，并且平时大量闲置（不开的时候还是有老本）。 企业购买云主机搭建本人的业务零碎好比汽车租赁，只管能够灵便租赁应用时长，然而扩容缩容都绝对麻烦，闲置老本有所缩小，然而仍然存在。 Serverless 时代好比打网约车，齐全按需应用按量付费、依据负载主动弹性伸缩、也根本没有闲置老本。 了解了什么是 Serverless 后，咱们看看 Serverless 利用托管如何做到让利用运维更简略，如何晋升资源利用率，帮忙企业降本增效？咱们从三个视角来看这个问题： ...

作者：十眠、立衡 OpenKruise 是一个基于 Kubernetes 的扩大套件，次要聚焦于云原生利用的自动化，比方部署、公布、运维以及可用性防护。本文介绍通过 OpenKruise 构建自动化运维的形式实现全链路灰度性能。 灰度公布进步利用交付的稳定性和效率在公布利用的过程中，咱们通常心愿用大量特定流量来验证新版本的公布是否失常，以保障整体稳定性。这个过程被称为灰度公布。对于灰度公布，咱们通过逐渐减少公布的范畴，来验证新版本的稳定性。如果新版本呈现问题，咱们也能及时发现，管制影响范畴，保障整体的稳定性。 渐进式公布个别具备以下特点： 逐渐减少公布的影响范畴，回绝一次性全副公布；阶段性的公布过程，能够通过金丝雀公布形式小心验证，以验证新版本的稳定性；可暂停、可回滚、可持续、可自动化状态流转，以便灵便地管制公布过程并确保稳定性。据调研数据 70% 的线上问题都是因为变更导致，咱们常说平安生产三板斧，可灰度、可观测、可回滚，也是为了管制变更带来的危险与影响面。通过采纳灰度公布的形式，咱们可能更加持重地公布新版本，防止因公布过程中呈现的问题而带来的损失。 微服务架构对灰度公布提出了更高的要求 在微服务架构的场景下，传统的灰度公布模式往往不能满足微服务交付的简单、多样化的需要。这是因为： 微服务调用链路比拟长，比较复杂。在微服务架构中，服务之间的调用链路比较复杂，一个服务的改变可能会影响到整个调用链路，从而影响整个利用的稳定性。一次灰度可能波及多个模块，整个链路都要调用新版本。因为微服务架构中服务之间相互依赖，一个服务的批改可能须要其余服务的相应调整。这就导致了在进行灰度公布时，须要同时调用多个服务的新版本，减少了公布的复杂度和不确定性。多个我的项目并行，须要部署多套环境，环境构建不灵便、老本高。在微服务架构中，往往会有多个我的项目并行开发，须要部署多套环境来反对不同的我的项目。这就减少了环境构建的难度和老本，从而导致公布效率低下。为了解决这些问题，咱们须要采纳更加灵便、可控并且实用于微服务场景的公布形式，全链路灰度公布的场景也就应运而生。通常每个微服务都会有灰度环境或分组来承受灰度流量。咱们心愿进入上游灰度环境的流量也能进入上游灰度的环境中，确保1个申请始终在灰度环境中传递，从而造成流量“泳道”。在“泳道”内的流量链路中，即便这个调用链路上有一些微服务利用不存在灰度环境，那么这些微服务利用在申请上游利用的时候仍然可能回到上游利用的灰度环境中。 全链路灰度为微服务公布保驾护航 这种形式能够依据服务的理论状况，能够对单个服务能够进行独立的公布和流量管制，也能够管制多个服务同时进行公布变更，从而保障整个零碎的稳定性。同时，还能够采纳自动化的部署形式，实现疾速、牢靠的公布过程，进步公布效率和稳定性。 实际全链路灰度的挑战在 K8s 中实现微服务全链路灰度公布是一个非常复杂的过程，须要波及多个组件和配置的批改与协调。以下是具体的一些步骤和问题： 在微服务架构中，网关是服务的入口，须要依据灰度公布的要求，调整网关配置，实现路由匹配和流量特色（比方 Header 批改）。为了实现全链路灰度公布，须要新部署一套灰度应用环境，并为其打上灰度标记（新部署一套 Gray 利用以及 Gray 灰度标）。这样能够将流量流向灰度环境，从而实现灰度公布。验证流量失常，将基线环境降级，销毁灰度环境，复原网关配置。在灰度公布过程中，须要对流量进行验证，确保流量的失常流向和服务的失常运行。如果验证通过，能够将基线环境降级到灰度版本，并销毁灰度环境。最初，须要复原网关的配置，以确保流量失常流向。如果产生异样，须要疾速回滚。因为微服务架构简单，可能会呈现各种异常情况，比方服务解体、流量异样等。在这种状况下，须要疾速回滚，以防止产生更大的损失。因而，须要事后设计好回滚计划，并在产生异样时疾速执行回滚操作。另外一方面，生产的流量是端到端的，那么意味着咱们须要管制流量在前端、网关、后端各个微服务等组件中闭环。不仅仅是 RPC/Http 的流量，对于异步调用比方 MQ 流量咱们也须要合乎全链路“泳道”调用的规定，这整个过程中波及到的流量管制的复杂度也是十分高的。 为了简化微服务全链路灰度公布的过程，能够应用一些自动化工具和产品，如 MSE、Kruise Rollout 等。这些工具和产品能够帮忙咱们更加便捷地实现微服务全链路灰度公布，并进步公布的效率和稳定性。 Kruise Rollout+MSE 端到端的全链路灰度公布实际为什么要 Kruise Rollout？Kruise Rollout [ 1] 是 OpenKruise 社区开源提出的一个渐进式交付框架。其设计理念是提供一组可能将流量公布与实例灰度相结合，反对金丝雀、蓝绿、A/B Testing 等多样化公布模式，以及反对基于 Prometheus Metrics 等自定义 Metrics 实现公布过程自动化，无感对接、易扩大的旁路式规范 Kubernetes 公布组件。次要个性如下： 非侵入性： 不对用户的利用交付配置做任何的侵入，应用旁路的形式来扩大渐进式交付的能力，并且可能做到即插即用的成果。可扩展性： 充分考虑了对多种相似的工作负载的反对（Deployment、StatefulSet、CloneSet 以及自定义 CRD 工作负载）；在流量调度方面，通过 lua 脚本的计划可能反对 Nginx、Alb、Mse、Gateway API 等多种流量调度计划。 Kruise Rollout 自身就反对各种灰度公布的能力（金丝雀、A/B Testing、蓝绿公布），深刻理解后发现它的公布模型十分符合 MSE 全链路灰度，因而与 Kruise Rollout 联合后能够十分不便的让用户实现 MSE 全链路灰度公布能力。 ...

作者：隆基 本文将从技术角度理解 RocketMQ 的云原生架构，理解 RocketMQ 如何基于一套对立的架构撑持多元化的场景。 文章次要蕴含三局部内容。首先介绍 RocketMQ 5.0 的外围概念和架构概览；而后从集群角度登程，从宏观视角学习 RocketMQ 的管控链路、数据链路、客户端和服务端如何交互；最初介绍音讯队列最重要的模块存储系统，理解 RocketMQ 如何实现数据的存储和数据的高可用，以及如何利用云原生存储进一步晋升竞争力。 01 概览在介绍 RocketMQ 的架构之前，先从用户视角来看下 RocketMQ 的要害概念以及畛域模型。如下图，这里依照音讯的流转程序来介绍。 在 RocketMQ 中，音讯生产者个别对应业务零碎的上游利用，在某个业务动作触发后发送音讯到 Broker。Broker 是音讯零碎数据链路的外围，负责接管音讯、存储音讯、保护音讯状态、消费者状态。多个 broker 组成一个音讯服务集群，独特服务一个或多个 Topic。 生产者生产音讯并发送到 Broker，音讯是业务通信的载体，每个音讯蕴含音讯 ID、音讯 Topic、音讯体内容、音讯属性、音讯业务 key 等。每条音讯都属于某个 Topic，示意同一个业务的语义。 在阿里外部，交易音讯的 Topic 被称为 Trade，购物车音讯称为 Cart，生产者利用会将音讯发送到对应的 Topic 上。Topic 里还有 MessageQueue，用于音讯服务的负载平衡与数据存储分片，每个 Topic 蕴含一个或多个 MessageQueue，散布在不同的音讯 Broker。 生产者发送音讯，Broker 存储音讯，消费者负责生产音讯。消费者个别对应业务零碎的上游利用，同一个消费者利用集群共用一个 Consumer Group。消费者会与某个 Topic 产生订阅关系，订阅关系是 Consumer Group+Topic +过滤表达式的三元组，合乎订阅关系的音讯会被对应的消费者集群生产。 接下来就从技术实现角度进一步深刻理解 RocketMQ。 02 架构概览下图是一张 RocketMQ 5.0 的架构图，RocketMQ 5.0 的架构从上往下可分为 SDK、NameServer、Proxy 与 Store 层。 ...

作者：孙彩荣 很遗憾，这不是一篇对于中间件实践或原理解说的文章，没有浅近艰涩的工作原理剖析，文后也没有令人惊叹的工程数字统计。本文以理论我的项目和代码为示例，一步一步演示如何以最低老本实现 Apache Dubbo 体系与 Spring Cloud 体系的互通，进而实现不同微服务体系的混合部署、迁徙等，帮忙您解决理论架构及业务问题。 背景与指标如果你在微服务开发过程中正面临以下一些业务场景须要解决，那么这篇文章能够帮到您： 您曾经有一套基于 Dubbo 构建的微服务利用，这时你须要将局部服务通过 REST HTTP 的模式（非接口、办法模式）公布进来，供一些规范的 HTTP 端调用（如 Spring Cloud 客户端），整个过程最好是不必改代码，间接为写好的 Dubbo 服务加一些配置、注解就能实现。您曾经有一套基于 Spring Cloud 构建的微服务体系，而后又构建了一套 Dubbo 体系的微服务，你想两套体系共存，因而当初两边都须要调用到对方公布的服务。也就是 Dubbo 利用作为生产方要调用到 Spring Cloud 公布的 HTTP 接口，Dubbo 利用作为提供方还能公布 HTTP 接口给 Spring Cloud 调用。出于一些历史起因，你正布局从一个微服务体系迁徙到另外一个微服务体系，前提条件是要保障两头过程的平滑迁徙。 对于以上几个场景，咱们都能够借助 Dubbo3 内置的 REST 编程范式反对实现，这让 Dubbo 既能够作为生产方调用 HTTP 接口的服务，又能够作为提供方对外公布 REST 格调的 HTTP 服务，同时整个编码过程反对业界罕用的 REST 编程范式（如 JAX-RS、Spring MVC 等），因而能够做到根本不改变任何代码的状况下实现 Dubbo 与 Spring Cloud 体系的相互调用。 对于这一部分更多的设计与实践论述请参见这里的博客文章 [ 1]对于 Dubbo REST 的更多配置形式请参见 rest 应用参考手册 [ 2]示例一：Dubbo 调用 Spring Cloud在曾经有一套 Spring Cloud 微服务体系的状况下，演示如何应用 Dubbo 调用 Spring Cloud 服务（蕴含主动的地址发现与协定传输）。在注册核心方面，本示例应用 Nacos 作为注册核心，对于 Zookeeper、Consul 等两种体系都反对的注册核心同样实用。 ...

作者：Jessie 大家对于最近 Stable Diffusion 一直出新的视觉“整活”印象都很粗浅，很多人对最近比拟风行的制作光影文字很感兴趣，制作光影文字能够作为进阶 Stable Diffusion 的必备一课，本文将具体解说基于函数计算部署 Stable Diffusion 实现光影文字效果，观看文章须要 5 分钟，看完即会连忙尝试！ 资源筹备注册并登录阿里云账号 [ 1]开明函数计算并支付试用额度 [ 2]开明文件存储 NAS 服务并支付试用额度 [ 3]部署云端 Stable Diffusion抉择“AI 数字绘画 stable-diffusion 自定义模版“，点击立刻创立，开始创立 Stable Diffusionhttps://fcnext.console.aliyun.com/applications/create 进行根底配置间接部署 —》首次开明函数计算配置提醒的“角色名称”—》确认 FC 和 NAS 曾经开明 进行高级配置抉择地区—》绘图类型任选 1 个—》首次部署须要 RAM 角色 APN 受权 其余中央如无特殊要求能够间接默认 创立并部署默认环境确认通晓应用 SD 过程中产生的函数计算和 NAS 费用（计费项超出试用额度后间接转为按量付费） 部署胜利两个地址解释如下： 第一个以 sd 结尾的是 Stable Diffusion webui 拜访域名，您能够间接关上应用内置的 SD1.5\动漫格调 \真人格调模型第二个以 admin 结尾的链接则是您的模型文件以及插件文件的治理后盾，咱们须要先拜访这个后盾进行模型的上传。 拜访 admin 结尾的域名，进入模型治理平台 ...

作者： 郑明泉、余凯 为啥争吵，吵什么？"你到底在说什么啊，我K8s的ecs节点要拜访clb的地址不通和本地网卡有什么关系..." 愤慨语气都从电话那头传了过去，这时电话两端都缄默了。过了好一会传来地铁小姐姐甘甜的播报声打断了刚刚的寂静「乘坐地铁必须全程佩戴口罩，下一站西湖文化广场...」。 pod须要拜访clb的443的监听， 然而如果是集群内（集群内前面都指的K8s的节点或者POD）拜访就会呈现如下报错Connection refused： 所以就捋了一下客户链路如下: 具体景象是什么无论是节点node还是pod里拜访192.168.1.200:443都是不通的，然而拜访192.168.1.200:80却是失常的。同时集群外的ECS192.168.3.100拜访192.168.1.200:443和192.168.1.200:80都是失常的。 进一步剖析看看CLB1的IP192.168.1.200被绑定到了K8s的node节点的kube-ipvs0网卡上，这个是一张dummy 网卡，参考dummy interface。因为 SVC1 是LoadBalancer类型的，同时复用了这个CLB1，关联endpoint是POD1192.168.1.101:80，那么就能够解释为何拜访192.168.1.200:80是失常，是因为kube-proxy依据SVC1的配置创立ipvs规定同时挂载了可被拜访的后端服务。而集群里拜访192.168.1.200:443都是不通的，因为IP被绑定到dummy网卡后，就不会再出节点去拜访到CLB1，同时没有443对应ipvs规定，所以间接是回绝的。 这个时候如果节点里没有ipvs规定（ipvs优先于监听）然而又能拜访通的话， 能够检查一下是否本地有监听0.0.0.0:443的服务，那么这个时候所有网卡IP+443都能通，然而拜访的是本地服务，而不是真正的CLB后端的服务。 是否有方法解决呢最倡议的形式最好的形式拆分， 集群内和集群外的服务离开两个CLB应用。 阿里云svc注解的形式SVC1应用这个注解service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname，进行占位，这样就不会绑定CLB的IP到kube-ipvs0的网卡上，集群内拜访CLB的IP就会出集群拜访CLB，然而须要留神如果监听协定为TCP或UDP，集群内拜访CLB IP时将会存在回环拜访问题。详细信息，请参见客户端无法访问负载平衡CLB [ 1] 。 须要CCM版本在 v2.3.0及以上版本才反对这个注解， 具体参考：通过Annotation配置传统型负载平衡CLB [ 2] demo： apiVersion: v1kind: Servicemetadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname: "${your_service_hostname}" name: nginx-svc namespace: defaultspec: ports: - name: http port: 80 protocol: TCP targetPort: 80 selector: app: nginx type: LoadBalancer集群内拜访 ExternalTrafficPolicy 策略有影响吗？咱们都晓得K8s的nodeport和loadbalancer模式是能够调整内部流量策略的，那么图中的「内部策略为Local/Cluster，所有集群节点创立IPVS规定是有区别的」该如何解释呢， 以及集群内拜访nodePort/CLBIP的时候会产生什么。 以下都是针对svc的internalTrafficPolicy都是Cluster或者缺省的状况，这个ServiceInternalTrafficPolicy个性在1.22的K8s中默认开启，具体参考service-traffic-policy [ 3]具体到阿里云容器在不同网络CNI状况下的数据链路，能够参考上面的文章： 全景分析阿里云容器网络数据链路（一）—— Flannel全景分析阿里云容器网络数据链路（二）—— Terway ENI全景分析阿里云容器网络数据链路（三）—— Terway ENIIP全景分析阿里云容器网络数据链路（四）—— Terway IPVLAN+EBPF全景分析阿里云容器网络数据链路（五）—— Terway ENI-Trunking全景分析阿里云容器网络数据链路（六）—— ASM Istio此处咱们只探讨ipvs TrafficPolicy Local在Kubernetes 从1.22降级到1.24的行为变动。 ...

本文依据作者在「TakinTalks 稳定性社区 」公开分享整顿而成 #一分钟精髓速览# 全栈可观测是一种更全面、更综合和更深刻的观测能力，能帮助全面理解和监测零碎的各个层面和组件，它不仅仅是一个技术上的概念，更多地是技术与业务的联合。在“以业务为导向”的大前提下，全栈可观测正在成为趋势。 本文分享了阿里云可观测平台服务作为寰球散布的超大业务零碎，同时也作为服务寰球企业用户的可观测平台提供方，在故障洞察提效中遇到的业务挑战，以及 6 个关键技术点和 2 个利用案例。 背景全栈可观测是一个技术和业务相结合的畛域，单从技术维度了解，可观测蕴含了基础设施、应用服务、客户端等等，而是更狭义的维度则关注这项技术如何撑持企业的业务， 提供逾越各个层面的数据收集、剖析和可视化，帮忙企业更好地了解和治理其零碎和利用。从技术开源到各类头部厂商的产品，再到国内外多个业务组织的落地，都能够看出全栈可观测曾经成为一种技术趋势。 Gartner 报告显示，落地可观测性具备相当高的策略价值 这一观点也在 Gartner 的报告中失去印证，依据 Gartner 的预测，到 2026 年，胜利利用可观测性的 70% 组织将可能实现更短的决策响应工夫，从而为指标业务或 IT 流程带来竞争劣势，这阐明可观测技术曾经冲破了技术层面，进入业务层面。 所以从业务视角来看，业务的变动（规模，复杂性，稳定性要求）必然驱动企业对可观测技术提出更高的要求。 阿里云可观测平台服务作为一个寰球散布的超大业务零碎，同时也作为服务寰球企业用户的可观测平台提供方，因为其撑持的业务架构的一直变动，驱动了可观测技术栈的一直演进。 明天我将联合阿里云的可观测业务挑战，重点从几项关键性技术和场景，与大家交换我对可观测技术的思考。 01 业务如何推动阿里云观测技术演进？ 阿里云可观测性技术倒退工夫线 2012 年鹰眼零碎买通利用和中间件： 阿里云可观测性技术终点能够追溯到 11 年前，过后淘宝开始逐渐施行微服务架构，这导致了大量服务之间互相调用非常复杂。因而，在这个期间咱们构建了鹰眼监控零碎（EagleEye），来解决不同业务之间的调用问题。能够说，正是淘宝业务的疾速倒退和微服务架构的演进，才促成了这一技术的产生，也为前期的可观测体系打下了根底。 2013-2015 年引入指标和日志： 这个阶段，从社区的角度来看，容器技术和开源我的项目开始呈现。同时，相似于 Service Mesh 这样的我的项目也应运而生。因为底层基础设施的扭转，即容器化的遍及，监控畛域呈现了新的需要和要求。咱们的监控技术方向也逐渐从买通利用和中间件之间的调用链，演进到引入观测指标和日志等。 2017 年 ARMS 云服务： “可观测性”这个词正式呈现并明确了其定义，即关注的数据维度，如指标等。阿里云随即基于原有的鹰眼监控零碎，推出了产品化的服务 ARMS。 2022 年全栈可观测套件： 在上云容器化、平台化的前提下，开源社区的倒退带来了绝对标准的可观测技术栈，所以阿里云在 2022 年公布了全栈的可观测相干技术，基于开源的标准实现相干的云服务。 从阿里近 10 年的监控技术倒退能够看出，技术并不是自发演进的，更多是因为业务架构和基础设施架构的变动推动了可观测性技术的架构扭转。 02 阿里云的可观测遇到了哪些挑战？2.1 作为平台方：服务寰球企业用户 2.2 作为业务零碎：寰球散布2.2.1 确保较高的业务能见度咱们常常面临用户无奈找到其观测数据的问题。这是一个常见的挑战，须要咱们思考，从数据采集到存储和生产如何确保高度的业务可见性。 2.2.2 如何确保SLA达标上述的问题只是一个表面现象，咱们须要深刻理解问题的根本原因。可观测性数据链路十分长，涵盖了从数据采集、端侧解决、服务端解决、存储到查问等全链路的业务零碎。因而，咱们须要疾速诊断故障，确定是哪个环节呈现了问题，或者是否是因为用户配置问题导致的等等。咱们须要在最短的工夫内诊断用户数据链路故障并可视化故障，将均匀定位工夫从 10 分钟升高到 5 分钟或更低。我将在前面分享具体的实际形式。 ...

云原生月度动静 ✦ 云原生是企业数字翻新的最短门路。 《阿里云云原生每月动静》，从趋势热点、产品新性能、服务客户、开源与开发者动静等方面，为企业提供数字化的门路与指南。 本栏目每月更新。 01 趋势热点 阿里云蝉联 FaaS 领导者，产品能力获最高分 日前，权威咨询机构 Forrester 公布 The Forrester Wave™: Functions-As-A-Service Platforms, Q2 2023。阿里云凭借函数计算的产品能力在 40 个评分我的项目中拿下 24 个最高分，再度入选领导者象限，这也是国内惟一两次进入 Forrester FaaS 领导者象限的科技公司。 相干文章： 阿里云蝉联 FaaS 领导者，产品能力获最高分  Serverless 系列直播上线 阿里云联结 InfoQ 发动 Serverless 系列直播，以实践经验和企业落地思考分享为主，推动更多企业应用 Serverless，真正让 Serverless 落地。目前圆桌派上线三期，围绕 Serverless与 AIGC 联合的新玩法、欢聚团体教育场景 Serverless 最佳实际、用 Serverless 技术实现古籍活化等开展。 相干文章： 直播预报丨如何用最新的 Serverless 技术让文化古籍“活过来”？  容器服务和利用实时监控服务 ARMS 荣获信通院两大稳定性先进级认证 7 月 25 日，由中国信通院发动的“2023 稳保体系”评估后果在可信云大会现场颁布，阿里云容器服务 ACK、利用实时监控服务 ARMS 别离成为首批通过云服务稳固运行能力、根因剖析技术能力评估的产品，且均获“先进级”认证，使阿里云成为信通院云服务“稳定性守护者”企业代表。 相干文章： 阿里云率先荣获容器集群稳定性先进级认证  ASK 正式更名为容器服务 Serverless 版（ACK Serverless） ...

作者：拂衣、丛霄 2019 年 Berkeley 预测 Serverless 将取代 Serverful 计算成为云计算新范式。Serverless 为利用开发提供了一种全新零碎架构。借助 2023 年由 OpenAI 所带来的 AIGC 风潮，以阿里云函数计算 FC、AWS Lambda 为代表的 Serverless 以其更高老本效益、更简化的后端代码 & 扩展性及更极致的弹性等泛滥个性，将开发者从沉重的手动资源管理与性能老本优化中解放，再次激发开发者蓬勃的想象力与创造力。国内越来越多开发者及企业开始尝试如何将 Serverless 利用于理论业务或者场景。 但在优雅应用 Serverless 之前，仍旧有不少小问题须要提前解决。因为 Serverless 平台的扩缩容是基于申请解决/事件驱动的并发度进行扩缩容的，对于习惯基于 CPU 指标进行 Pod 程度扩缩的的开发者而言，就会遇到以下难题，比方并发度、最小实例数、最大实例数这几个参数之间的关系是什么样的？又比方单个实例最大并发度怎么设置，才可能合乎本人的业务需要？ 01 Serverless 参数配置的考量维度Serverless 能提供肯定通用能力，但针对不同业务逻辑须要采取适合的配置能力更好的施展 Serverless 价值。但如何评估函数的最佳配置波及到多变量协同优化的问题，尽管函数计算 FC 提供了基于利用“每日申请总数”和“均匀申请响应工夫”的申请预估、基于利用目前应用的服务器“规格”和“利用率”的现有服务器用量预估等形式辅助进行参数配置。但想要更好进行配置，咱们倡议从以下三个维度去评估配置 Serverless 服务参数。 （1）在老本与性能之间进行取舍如何依据业务偏好抉择性能优先或老本优先是参数配置须要思考的第一大难点。在单实例多并发数绝对固定的状况下，能够进步单实例并行处理申请数量，缩小实例数，从而降低成本。当并发数过高时会减少资源竞争，导致性能提早减少，从而减少老本；如果对于延时敏感度绝对较低，能够选取较低实例规格，单价老本更低，与之相同，想要更短延时，能够抉择较高的实例规格，但单价成更高。 （2）联合不同函数业务逻辑的复杂度除了老本和性能取舍，针对不同类型函数逻辑，不同配置参数成果也有着微小差别。很多函数业务逻辑简单，只针对繁多逻辑分支进行特定配置并不代表整体性能最优；不失当的配置可能产生大量预期之外的运维老本。对此，咱们针对 CPU 密集型、 IO 密集型不同类型函数进行测试，以便更好的开掘不同规格与不同类型函数TPS之间的关系。 在不同规格下，对 CPU 密集型函数进行压测 能够看到 CPU 密集型规格越高， maxTPS 越大，规格与 maxTPS 出现显著线性关系。规格越大，maxRT 越低 ，阐明 CPU 密集型的函数，增大资源规格能够显著升高 RT。但规格增大到 4G、8G 后，对 RT 的升高成果边际效应递加。 ...

作者：颜廷帅（瀚廷） 01 背景OpenAI 在 3 月 15 日公布了备受瞩目的 GPT4，它在司法考试和程序编程畛域的惊人体现让大家对大语言模型的激情达到了顶点。人们纷纷议论咱们是否曾经跨入通用人工智能的时代。与此同时，基于大语言模型的利用也如雨后春笋般呈现，为咱们带来了协同办公、客服对话、语言翻译、内容生成等方面前所未有的畅快体验。 然而，当咱们享受着大语言模型带来的普惠 AI 能力时，它也给开发者们带来了前所未有的挑战。随着模型一直增大，计算量也达到了空前的高度，间接导致推理工夫变长。为了解决大语言模型推理的提早问题，业界曾经提供了一些解决方案，比方 Tensorrt、FasterTransformer 和 vllm。为了帮忙用户解决云原生零碎中的大语言模型推理减速问题，云原生 AI 套件引入了 FasterTransformer 推理减速计划。 本文将在 ACK 容器服务上，以 Bloom7B1 模型为例展现如何应用 FasterTransformer 进行推理减速。本例中会应用以下组件： ArenaArena 是基于 Kubernetes 的机器学习轻量级解决方案，反对数据筹备、模型开发，模型训练、模型预测的残缺生命周期，晋升数据科学家工作效率。同时和阿里云的根底云服务深度集成，反对 GPU 共享、CPFS 等服务，能够运行阿里云优化的深度学习框架，最大化应用阿里云异构设施的性能和老本的效益。更多 arena 信息，能够参考云原生 AI 套件开发者使用指南 [ 1] 。 Triton ServerTriton Server为Nvidia 提供了机器学习推理引擎，能够反对 Tensorflow、Pytorch、Tensorrt 和 Fastertransformer 多种 backend。云原生 AI 套件曾经将 Triton Server 退出到 Arena 中，用户能够通过简略的命令行或 SDK 来在云原生零碎中实现 Triton Server 服务的拉起、运维和监控。更多 AI 套件中应用 Triton Server 信息，能够参考部署 PyTorch 模型推理服务 [ 2] 。 ...

RocketMQ 背景Apache RocketMQ 诞生至今，始终服务于 100% 阿里团体外部业务、阿里云以及开源社区数以万计的企业客户。 历经十多年双十一严苛流量验证的 RocketMQ，承载了超过万亿级音讯规模的洪峰压力。2021 年 Apache RocketMQ 更是进入全新 5.0 时代。 立足于企业业务集成的外围场景，RocketMQ 在高牢靠低提早方面重点优化，构建了全新的低提早存储引擎和多场景容灾解决方案；面向业务集成过程中链路逻辑的多样性，RocketMQ 提供了丰盛的业务音讯类型，这些个性的积攒使得 RocketMQ 成为金融级业务音讯的首选计划。 Apache RocketMQ 联结创始人、阿里云资深技术专家、阿里云音讯产品线负责人——隆基带你玩转 RocketMQ。手把手视频教学，一键部署六大场景。 流动简介现在 RocketMQ 已蓬勃发展了 10 多年，最次要的驱动力便是和开发者一起成长，一直的有开发者分享实践经验，对产品继续反馈，提出新需要；也一直的有开发者退出社区，一起研发 RocketMQ 的新个性，如高可用架构、物联网音讯个性等。 做好 RocketMQ 的规范应该由千万开发者来给出答案。 产品的改良非一日之功，须要坚持不懈。为了更好地长期失去开发者理论应用中的反馈和倡议，联结阿里云开发者社区推出了 “寻找 RocketMQ 首席评测官”流动，寻找在音讯畛域有技术实践经验、违心深度评测产品并提出贵重倡议的开发者。期待您的退出，帮忙 Apache RocketMQ 以及阿里云音讯产品继续晋升竞争力。 流动截止 8 月 31 日，参加流动有机会取得阿里云社区定制周边，更有千元好礼等你拿！ 流动入口点击此处立刻参加流动：（或返回文末浏览原文进入） https://developer.aliyun.com/topic/rocketmq?utm_content=g_100... 也能够间接进行产品评测： https://developer.aliyun.com/mission/review/rocketmqtest?spm=... 流动玩法介绍玩转云产品：支付资源，开启你的评测之旅实现【收费支付 RocketMQ】-【理解评测流动】即可赢取社区 100 积分。前 100 名实现工作用户将取得 10 元猫超卡，流动完结后短信发放。 邀请挑战：邀好友实现工作，参加 PK 赢大奖！流动期间，用户参加流动点击“邀请好友”后“复制链接”生成您的专属链接给好友，好友关上链接后在流动页内实现工作一和二，即算助力胜利实现 1 人邀请，最高赢取科沃斯 T10 扫地机器人、CHERRY 机械键盘 mx2.0s 等好礼。 ...

作者：宋小生 - 安全壹钱包中间件资深工程师 Dubbo3 可观测能力速览Apache Dubbo3 在云原生可观测性方面实现重磅降级，应用 Dubbo3 最新版本，你只须要引入 dubbo-spring-boot-observability-starter 依赖，微服务集群即原生具备以下能力： 能力一：可视化查看集群、单机流量指标与衰弱状态Dubbo 3.2 最新版本反对以利用、单机、单条服务等多种不同粒度观测运行状态，包含 qps、rt、线程池、谬误分类统计等。 能力二：全链路追踪Dubbo 3.2 最新版本通过内置链路过滤器在 RPC 申请中对链路数据进行采集，采集之后通过导出器将链路数据导出到各大厂商。 https://cn.dubbo.apache.org/zh-cn/overview/tasks/observability/ 云原生可观测性的摸索云原生降级的挑战高质量交付的前一部分有 DevOps 保障开发与测试的品质与效率，后有云原生保障运维部署效率与品质，然而大规模疾速迭代意味着频繁变更，变更与零碎运行带来的稳定性问题不能被忽视，比方宕机，网络与零碎异样等，很多未知的问题难以避免，借助可观测零碎来及时感知问题、高效剖析异样、疾速复原零碎，提前躲避已知问题，深度开掘未知问题，高效晋升运维品质，能够看到建设一个欠缺的可观测平台对于发现已知和未知异样，晋升零碎的稳定性是十分必要的。 Dubbo 可观测建设指标Dubbo 作为微服务 RPC 根底框架间接建设大而全的可观测零碎与定位不合乎也不是很事实，然而能够从本身登程提供更多的根底监控数据来为企业建设可观测零碎提供助力，可观测性与传统单维度监控不同，更关注的是数据的关联性，通过单维度和多维度角度整体观测和剖析问题，首先从风行的三大支柱指标登程，在此基础之上，Dubbo 提供多维度聚合与非聚合指标帮忙用户疾速发现问题与诊断问题，多维指标中进而能够通过利用、主机等标签信息关联到链路零碎，链路零碎提供了服务申请级别的链路性能与异样问题剖析性能，Dubbo 通过提供链路门面对接各大全链路厂商，链路剖析之后能够通过链路数据例如：TraceId,SpanId 自定义数据等来追踪到具体日志，详情日志中 Dubbo 侧提供了丰盛的专家建议与错误码供开发与运维同学疾速诊断与定位问题。 Dubbo 多维度指标体系Dubbo 多维度指标体系建设中从纵向和横向两个角度来看，纵向 Dubbo 侧提供繁难接入的门面外观，而后将零碎中采集到的指标存储在内存指标容器中，接着依据指标类型决定是否进行聚合计算，最初将指标导出到不同的指标零碎。从横向角度来看采集维度也笼罩到容易出问题的 RPC 申请链路，三大核心交互与线程资源应用状况等场景。 Dubbo 多维度指标体系采集哪些指标？后面介绍了大面上的指标采集，然而 Dubbo 应该采集哪些具体的指标呢？接下来能够看到 Dubob 采集指标时参考的一些方法论。 依据谷歌 SRE 书：Google 针对大量分布式监控的经验总结提出 4 个黄金指标（提早、流量、谬误以及饱和度）能够在服务级别帮忙掂量终端用户体验、服务中断、业务影响等层面的问题。 RED 办法(来自 Tom Wilkie)，RED 办法则关注申请、理论工作以及内部视角（即来自服务生产方的视角）蕴含：速率、谬误与持续时间。 USE 办法(来自 Brendan Gregg)：USE 办法次要着眼于资源外部，蕴含：利用率、饱和度与谬误。 Dubbo 多维度指标体系接入-导出到 QOS多维度指标体系在 3.2 之后的版本曾经公布与继续迭代中，对用户来说只须要引入一个依赖即可： ...

作者： 倪海峰（海迩） 前言随着企业规模的不断扩大，传统单体利用已很难进一步反对业务的倒退，业务的迭代速度曾经难以满足业务的增长，此时企业会对利用零碎做微服务化的革新，升高业务的耦合度，晋升开发迭代的效率，让开发更加麻利。 零碎架构微服务化的，本来的愿景是心愿通过将零碎的颗粒度变小，晋升业务的迭代效率。然而在实际微服务架构的过程中，尤其是在服务数量越来越多之后，那么引发的效率问题可能会大于微服务架构自身所带来的架构红利。 微服务架构下的公布挑战零碎拆分为微服务之后，其中一项业务指标便是心愿通过将服务粒度变小，实现业务的高频交付。然而在实际微服务架构的过程中，将上下游服务齐全解耦简直可能存在于现实状态下。常见的状况是，频繁地对微服务做变更公布，通常都会导致业务流量呈现大量损失，于是研发人员不得不在早晨业务低峰期做变更。并且在公布过程中，波及到的上下游团队必须全程待命，以便于在公布阶段发现问题之后，立即修复，极大地升高了研发人员的幸福感。 如何落地可灰度、可观测、可回滚的平安生产能力，满足业务高速倒退状况下疾速迭代和小新验证的诉求，是企业在微服务化深刻过程中必须面对的问题。 本文将重点讲述在阿里云 EDAS ACK 环境下，对 Spring Cloud 微服务利用进行全链路流量管制的整体计划。通过全链路流量管制性能，能够疾速创立流量管制环境，将具备肯定特色的流量路由到指标版本利用。 灰度公布实际准则在微服务架构下，灰度公布实际的关键在于：分层、隔离、兼容这三大因素，在此基础之上，具备业务可观测的能力。分层是在设计灰度公布计划前的后期筹备，而隔离和兼容则是实现灰度的次要伎俩。 在实现全链路灰度场景的流量隔离有两种实现思路：基于物理环境隔离和基于逻辑环境隔离两种。 基于物理环境的隔离，须要为要灰度的服务搭建一套网络隔离、资源独立的环境，在其中部署服务的灰度版本。因为正式环境与灰度环境绝对隔离，正式环境无法访问到灰度环境的服务，因而即使是未做版本更新的服务以及各组件，同样也须要在灰度环境中部署。从实现原理上来讲，常见的蓝绿部署便是其中一种技术实现。然而在线上服务足够多的场景下，基于物理环境隔离的计划灵便度绝对有余，同时会造成大量的冗余节点以及额定的资源开销。 逻辑环境隔离计划的外围在于对流量染色，当流量在调用链上转发申请时，通过网关以及各个中间件及微服务来辨认到被染色的灰度流量，并将申请动静转发至对应的灰度版本。再依据规定作出动静决策。因而当版本发生变化时，调用链路的转发规定同样也会实时作出扭转。相比于通过搭建一套物理上隔离的灰度环境，基于逻辑动静调整策略的形式可能节俭大量的资源及运维老本，并能够帮忙开发者实现更为简单的全链路管制场景。 标签路由通过标签将一个或多个服务的提供者划分到同一个分组，从而束缚流量只在指定分组中流转，实现流量隔离的目标。标签路由能够作为多版本开发测试、同利用的多版本流量隔离以及 A/B Testing 等场景的能力根底。实际上，标签路由的应用场景还有许多，例如实现全链路流控、同 AZ 优先、全链路压测、容灾多活等等。 最初，在具体的工程实际中，并非所有组件通过隔离便可能无效地实现流量的精细化管制，例如数据库等有状态组件，无论是从施行老本还是从技术视角，都不会在每次上线时都从新搭建一套全新的表库，对数据同步之后再刷新对应版本后的 SQL 脚本。因而，在特定场景下的新老版本兼容就成为了必要的前置条件。 架构剖析该我的项目中后端架构技术栈为 Spring Cloud Alibaba，应用了一整套的阿里云云原生的最佳实际，其中也包含 EDAS、MSE 云原生网关。前端利用应用 VUE 开发，其资源均为动态资源。从利用架构中能够得悉，动态资源以 Nginx 为 HTTP 服务对外提供。 在此次架构设计中，业务需要如下： 前端到后端可能依照依照不同的简单规定（如 header 中的城市、UserID 等）做精细化路由管制，同时当上游服务灰度版本存在异样或不存在时，可能降级至基线服务解决申请。依照肯定百分比随机对线上流量做灰度公布。反对对音讯队列中音讯打标，并由对应的 Consumer 生产。尽可能的零代码革新。须要对音讯队列中的音讯做灰度分组，并由对应的 Consumer 将音讯生产。须要具备灰度流量的可观测问题。EDAS 流量管制EDAS 是利用托管和微服务治理的云原生 PaaS 平台，提供利用开发、部署、监控、运维等全栈式解决方案，同时反对 Spring Cloud 和 Apache Dubbo 等微服务运行环境。 在 EDAS 平台中，用户能够通过 WAR 包、JAR 包或镜像等多种形式疾速部署利用到多种底层服务器集群，轻松部署利用的基线版本和灰度版本。同时，EDAS 可能无缝接入 MSE 的服务治理能力，无需额定装置 Agent 即可零代码入侵取得利用无损高低线、金丝雀公布、全链路流量管制等高级个性。 ...

作者：刘军 Java 利用在云计算时代面临“冷启动”慢、内存占用高、预热工夫长等问题，无奈很好的适应 Serverless 等云上部署模式，GraalVM 通过动态编译、打包等技术在很大水平上解决了这些问题，同时针对 GraalVM 的一些应用限度，Spring 和 Dubbo 等支流框架也都提供了相应的 AOT 解决方案。 本文咱们将详细分析 Java 利用在云时代面临的挑战，GraalVM Native Image 是如何解决这些问题，GraalVM 的基本概念与工作原理，最初咱们通过一个 Spring6 + Dubbo3 的微服务利用示例演示了如何将一个一般微服务利用进行动态化打包。 本文次要分为以下四个局部开展： 首先咱们会先看一下在云计算疾速倒退的当下，云上利用应该具备的特点，Java 利用在云上所面临的挑战有哪些。其次，我会介绍一下 GraalVM，什么是 Native Image，如何通过 GraalVM 对 Java 利用进行动态化打出 Native Image 可执行的二进制程序。第三局部，咱们晓得 GraalVM 的应用是有肯定限度的，比方 Java 的反射等动静个性是不被反对的，因而咱们须要提供非凡的 Metadata 配置来绕过这些限度，在这一部分咱们会解说如何退出引入 AOT Processing 来实现自动化的 Metadata 配置，包含 Spring6 框架中 AOT 解决、Dubbo3 框架的 AOT 解决等。最初，咱们将通过一个 Spring6+Dubbo3 的利用示例，来演示如何将这么一个 Java 利用进行动态化打包。Java 利用在云时代所面临的挑战首先，咱们先看一下云计算时代的利用特点，以及 Java 在云时代所面临的挑战。从各个统计机构给出的数据来看，Java 语言依然是当今最受开发者欢送的编程语言之一，仅次于一些脚本开发语言。应用 Java 语言能够十分高效的开发业务利用，丰盛的生态使得 Java 具备十分高的开发和运行效率，有有数的利用基于 Java 语言开发。 ...

作者：谢文欣（风敬） 为什么要做流量隔离源于一个 EDAS 客户遇到的辣手状况：他们线上的一个 Pod CPU 指标异样，为了进一步诊断问题，客户心愿在不重建此 Pod 的状况下保留现场，但诊断期间流量还会通过这个异样 Pod，导致影响服务质量，于是询问咱们有没有方法能够把流入异样节点的流量摘除掉，造成一个隔离的诊断环境。经诊断后，如果异样能够修复，待修复实现后，再解除流量隔离，节点恢复正常工作。 除了在诊断场景须要对所有输出流量进行隔离外，在一些线上演练中还需对特定流量进行隔离以实现模仿演练成果。面对这类流量隔离问题时，咱们首先思考的是全链路流量管制。目前，EDAS 上的全链路流控可能在不重启利用节点的状况下管制流量走向。然而，全链路流控仅能管制微服务框架流量，无奈满足隔离所有或特定流量的需要。 为此，咱们进行了深入研究，实现了一套开箱即用的流量隔离工具，可能动静隔离特定流量，并在隔离后可随时复原，以满足各种场景下的流量隔离需要。 隔离哪些流量流量隔离的目标是阻断利用节点的流入流量，首先明确下微服务利用节点流入的流量有哪些。 流入微服务利用节点的流量大抵能够分为两大类：服务流量、事件流量。以常见的微服务利用为例，其流量组成如下图所示。 服务流量指一个微服务利用的所有节点作为一个网络实体，对外提供一组服务，被其余零碎、服务或用户发动申请产生的调用。对于服务流量，节点自身不间接决定流量的流入与否，而是由一套服务注册与发现机制保护流量门路的逻辑关系。节点通过注册，成为服务的一个端点。调用方对服务发动申请时，被调用方是服务的逻辑地址，通过转发和地址转换，申请被路由到服务端点的实体节点。隔离服务流量的一个可选计划是毁坏服务调用的通信连贯，但这种办法势必会影响服务质量。在放弃服务整体性能失常运行的同时，一个更优雅的计划是毁坏服务与实体节点之间的映射关系。这样，在路由过程中，流量将依照预期避开特定节点，而被疏导至其余节点。服务流量次要涵盖了 K8s Service 以及应用 Nacos 等注册核心公布的由 Spring Cloud、Dubbo 等微服务框架构建的服务。 事件流量指利用外部的事件驱动架构产生的流量，包含由中间件传递至利用节点的事件或音讯，这类通信通常是异步的，例如来自音讯队列 RocketMQ 的音讯流量，来自调度框架 SchedulerX 触发调度的事件流量。中间件和利用节点之间通常遵循 client-server 通信，因而能够思考通过毁坏通信连贯来隔离中间件发来的音讯或事件流量。 服务流量隔离K8s Service对于应用 K8s Service 裸露服务的利用，Service 申明的服务与利用 Pod 之间的映射关系由 Endpoints 对象保护。Endpoints 对象的 subsets 字段示意 Serivce 的一组端点，每个端点代表一个利用 Pod 的网络地址，即一个理论提供服务的 Pod 实例。subsets 字段蕴含了这些端点的详细信息，如 IP 地址和端口。Endpoints 控制器通过 API Server 监听 Pod 的变更状况，并随后同步更新 Endpoints 的端点列表。因而，要隔离 K8s Service 的流量，须要毁坏 Endpoints 对 Pod 的指向，将待隔离的 Pod 网络地址从 Endpoints 的端点列表中移除。同时，须要通过 Informer 机制监听 Endpoints 对象的变动，以保障 Endpoints 在后续变更或控制器 Reconcile 过程中也能维持预期状态。 ...

应用缓存能够无效缩短数据的读取门路和升高I/O操作频次，从而进步数据的读取响应速度。对象存储在原有的单机缓存的根底上，在集群范畴内构建分布式缓存，进而优化数据读取的性能。 对象存储业务层的数据存储模型是依照桶（Bucket）、对象（Object）、块（Block）三个层级来对数据进行存储管理的。针对一次对象数据读取，用户申请会通过负载平衡到业务前端零碎，业务前端零碎通过计算失去对象的块列表并进行遍历，申请键值存储系统获取块数据，最初将读取的块数据有序地返回给用户。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1256937?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

一、背景介绍传统视频指标检测（Video Object Detection, VOD）工作以一段视频作为输出，利用视频的时序信息进行指标检测，并最终输入每一帧视频帧的检测后果。其相比图像指标检测（Image Object Detection, IOD）工作，劣势在于可能利用视频的时序信息，对静止含糊、图像失焦、遮挡、物体姿势变动等艰难的场景具备更强的鲁棒性。然而，传统的VOD和IOD都是离线（offline）的检测，即仅思考算法的检测精度，未思考算法的延时。 为了更加贴近事实场景，ECCV 2020 论文《Towards Streaming Perception》[1]（取得Best Paper Honorable Mention）首次提出了流感知（Streaming Perception）工作，该工作作为VOD的一个细分方向，提出了流均匀精度（Streaming Average Precision, sAP）指标，掂量算法的在线（online）检测能力，即同时掂量算法的精度和延时。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1255157?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

6 月 30 日，由中国信通院主办的“2023 云边协同大会”在北京举办。本次大会以“云智物联，边筑算新”为主题，聚焦分布式云、边缘计算、AIoT 平台等畛域前沿焦点，旨在推动产业翻新倒退。 大会现场对畛域近期权威成绩进行了颁奖公示，阿里云边缘容器服务 ACK@Edge 以“2023 大规模边缘容器集群服务质量和要害性能评测”、“2023 边缘计算技术创新与实际最佳案例”两项后果，展现了其产品服务能力在大规模性能、企业落地生产维度优良的综合能力。 打造性能标杆，ACK@Edge 首批通过“大规模集群服务质量测评”依据中国信通院联结产业界独特编制的《基于云边协同的大规模边缘容器集群服务质量评估模型》系列规范要求，阿里云边缘容器服务 ACK@Edge 顺利完成评测工作，在大规模场景下边缘节点治理能力和性能、节点扩展性测试、稳定性测试、利用散发性能／性能等方面体现优异，成为首批通过该模型规范的认证产品。 面向大规模边缘计算场景，阿里云边缘容器服务 ACK@Edge 提供了企业级边缘容器计划：在整体架构上采纳云边端一体化协同托管计划，将云计算的能力下沉到边缘侧、设施侧，重点提供存储、网络、平安、监控、日志等能力；在集群治理方面，APIserver 和调度器内置了大量性能优化；在云边网络方面，通过对网络插件 Flannel 优化大幅度降低云边流量开销；此外，思考到边缘资源的异构性、地域性以及网络的复杂性等特点，ACK@Edge 提供了异构资源管理、边缘自治、边缘单元化、边缘流量治理、轻量化、原生运维 API 反对等，以原生形式反对边缘计算场景下的利用对立生命周期治理和对立资源调度，保障边缘业务稳定性。 与客户业务同行，携手阿里影业获“可信边缘最佳实际案例”随着各行各业数字化转型水平一直加深，越来越多的算力和业务开始下沉到间隔数据源或终端用户更近的中央，以取得更好的服务效率和更低的老本。ACK@Edge 始终以解决边缘场景下企业对于云原生的需要挑战为出发点，与客户业务同行。 本次获评“可信边缘最佳实际案例”的“阿里影业云边一体协同架构实际”，是电影上演行业在边缘侧首批落地的云原生架构案例。现场入场作为上演服务不可或缺的一环，观众入场体验是服务外围指标，在影演场景不断丰富、行业总量持续增长的背景下，阿里影业业务也迎来高速倒退阶段，对入场服务的速度、稳定性，高可用性、服务老本等方面也提出了更高的要求。 为应答以上挑战和将来业务倒退需要，阿里影业实现了一套面向海量异构设施接入的高可用、高稳定性、可扩大的云边端一体的混合云架构，来反对将来高时延敏感的实操音讯上下行和业务疾速倒退。 ACK@Edge 为该架构打下了松软的混合云根底技术底座，买通了云上和云下资源的对立治理，提供同云上研发体系完全一致的研发模型。 该计划曾经利用于超过 200 场次的各类我的项目中，验票总数近十万张，看到了各方面的晋升，包含利用边缘容灾实现局域集群负载平衡，无需人工监控与操纵，实现主机与备用机的平滑无感切换，缩小 99% 的切换工夫；大幅加强现场服务容灾能力，在保障服务稳定性的同时，晋升了验票环节的用户体验，1 秒实现验票，人均验票工夫缩小 70%；此外，因为机器资源利用更正当，使硬件的投入和部署老本升高  50%。 通过落地基于 ACK@Edge 的云边一体协同架构，阿里影业拓展了更多的上演行业场景，整体服务稳定性与高可用度失去晋升，并且大幅晋升主办方对阿里影业信赖与消费者满意度，造成了帮忙阿里影业在现场服务畛域处于当先的重要撑持。 ACK@Edge 云边端一体化协同减速企业数字化翻新落地ACK@Edge 目前曾经广泛应用于 CDN、实时音视频云服务、在线教育、交通、智慧城市、智慧工业、IoT、物流、水利、能源、农业等场景，笼罩行业用户数百家。 在大会现场，阿里云智能技术专家唐炳昌进行了题为“云边端一体化协同减速企业数字化翻新落地”的主题分享：“将云计算的能力下沉到边缘侧，并通过核心进行对立交付、运维、管控，将是云计算的重要发展趋势。阿里云边缘托管 Kubernetes 集群采纳云边端一体化协同的托管计划，在云端提供规范的 Kubernetes 集群，整合阿里云虚拟化、存储、网络和平安等能力，反对纳管边缘侧的资源和业务，帮忙企业专一于边缘业务利用的开发与治理”，唐炳昌示意。 将来，ACK@Edge 将继续欠缺产品性能和服务能力，在阿里云容器服务 ACK Anywhere 的产品策略下，与分布式云容器平台 ACK One 独特打造容器服务在分布式云场景下的残缺解决方案，助力千行百企业减速数字化翻新落地。 点击此处，拜访 ACK@Edge 详情页理解更多产品能力。

作者：庄宇 Kubernetes 作为一项核心技术已成为古代应用程序架构的根底，将 Kubernetes 作为容器编排零碎已倒退为越来越多企业的必然选择。 随着对云计算接受程度一直进步，以及企业规模和业务继续倒退的独特驱动下，越来越多的企业在思考或曾经采纳多云和混合云计划，以晋升架构的灵活性和健壮性。 Kubernetes 多集群需要的演进及运维挑战企业可能会将集群部署在不同云厂商的私有云 K8s 集群中、本地 IDC 中的 K8s 集群、开源自建集群等等。在帮忙企业可能更好地利用混合环境资源的同时，这些散布在不同状态、地区、基础设施和网络环境的集群，给运维治理带来了极大的挑战，比方要应答不同的拜访控制台、不同的权限管理策略、不同的日志监控工具、不同的平安工具等等。 如果您也正面临着相似的需要和挑战，能够思考应用本文分享的阿里云 ACK One 注册集群，使云上云下 K8s 集群对立治理变得轻松简略。 如何应用 ACK One 简化混合星散群搭建与治理ACK One 是阿里云面向混合云、多集群、分布式计算等场景推出的分布式云容器平台，可能对立治理阿里云上、边缘、部署在客户数据中心以及其余云上的 Kubernetes 集群。 通过 ACK One 注册集群，您能够将来自不同提供商和不同地位的 K8s 集群对立接入到阿里云容器服务 ACK 控制台，提供对立的集群管制面，实现多集群对立的利用散发、流量治理、运维治理、平安治理等。 1. 注册集群外围性能ACK One 注册集群能够帮忙企业应答的 K8s 集群对立治理需要包含： 统一的运维体验K8s 集群对立运维治理，提供与 ACK 统一的运维体验。他云 K8s 集群或者本地 IDC 集群接入 ACK One 注册集群后，能够应用 ACK 控制台对立治理，包含：权限，日志，监控，事件，告警，老本剖析，平安巡检，安全策略。 K8s 集群中的微服务治理微服务引擎 MSE，服务网格 ASM。 云上弹性本地 IDC 中的 K8s 集群弹性扩容阿里云 ECS 节点池，扩容 Virutal Kubelet ECI 弹性容器实例，应答 IDC 资源有余和突发业务流量。 ...

作者：赵佳佳 随着云原生技术的蓬勃发展以及云产品价格愈发低廉，越来越多 Geek 开发者、技术爱好者抉择 OSS 对象存储、ECS 云服务器等根底产品构建本人的网站、网盘等利用。但对于企业而言，面对品种与规格的丰盛的 ECS 云服务器，如何理解实例规格的要害特点，在库存有余、产品下线、应用抢占式实例等场景中，保障业务的稳固运行成为要害。 那么接下来，咱们一起理解 ECS 云服务器如何选型并通过 PTS 进行容量布局，接下来咱们将介绍三种不同的 ECS 选型形式。 01 联合实例规格参数进行选型启动 ECS 实例前，咱们会联合性能、价格、工作负载等因素进行配置抉择。依据不同配置参数，ECS 提供蕴含多种不同实例规格的实例规格族。在理论应用过程中，咱们可通过以下两种形式找到参数最合适的实例规格。 实例规格族 [ 1] ：查阅文档理解实例规格族的产品详情。DescribeInstanceTypes [ 2] ：调用 ECS API 接口，获取最新的性能规格参数。针对这种形式，咱们须要理解实例规格的命名形式，以便咱们可能疾速理解并找到所需的实例规格。实例规格族名称格局为 ecs.<规格族> ，实例规格名称为 ecs.<规格族>.large。具体命名规定阐明如下所示： ecs：云服务器 ECS 产品代号。<规格族> ：由规格族主体+规格族后缀组成。x86 计算规格族和 ARM 计算规格族 异构计算规格族、弹性裸金属服务器、超级计算集群（SCC）实例规格族异构计算规格族、弹性裸金属服务器和超级计算集群（SCC）实例规格族个别采纳自主命名形式，由小写字母和数字混合组成。 large ： large 示意 vCPU 核数， 中的 n 越大，示意 vCPU 核数越多。其中，xlarge 代表 4 核，2xlarge 代表 8 核，3xlarge 代表 12 核等等，以此类推。02 依据自建服务与利用进行选型当企业抉择服务上云的过程中，在采买各种云产品的同时，也会进行各种服务或利用自建，以便满足理论的业务需要。为了不便选型，咱们总结列举了常见自建服务与利用对应的 ECS 实例规格，能够依据企业所应用的利用，并参考选型准则，抉择对应的实例规格族。 03 依据利用场景进行选型除了依据间接参数以及自建利用与服务两种形式之外。在理论生产过程中，咱们会发现很多业务场景不只是单一个服务或者利用就能满足的。同时，相干业务场景的附加要求也会绝对简单。 ...

作者：少焉 随着云原生、微服务技术的倒退，可观测需要变得越来越强烈，作为可观测技术的重要能力之一，云拨测（Synthetics Monitor）因为其零侵入、开箱即用、主动式监测伎俩，也受到很多用户的青眼，很多通过云拨测被动监测本身服务的可用性，先于用户发现线上异样；也会通过云拨测剖析和优化网页加载速度，给他们的用户提供更好的应用体验；同时也有用户通过云拨测进行云服务选型、竞品剖析。 阿里云云原生可观测团队推出基于利用实时监控服务 ARMS、可观测监控 Prometheus 版、可观测可视化 Grafana 版、可观测链路 OpenTelemetry 版的可观测套件后，并欠缺本身可观测产品能力，笼罩更多观测场景。 近日，阿里云 ARMS 云拨测迎来全新降级，带来全新应用体验和场景同时，大幅升高用户应用云拨测老本。 降级 1：普惠降本，上线云主机监测点，每次拨测价格低至 0.001 元云主机是基于阿里云本身 Serverless 计算服务建设的监测点，因为 Severless 本身按需低成本、免运维特点，云主机监测点应用老本非常低，按量后付费价格 0.001 元/次，比原国内PC监测点价格低 30 倍。云主机监测点位于阿里云机房中，反对 HTTP、Ping、DNS、TCP 拨测协定，实用于对在线服务进行可用性的继续监控与巡检。后续，云拨测也将逐步进步云主机监测点的数量和欠缺云主机监测点的拨测场景。 为了使大家更普惠的应用云拨测能力，云拨测公布拨压测门户 [ 1] ，用户只需登录阿里云帐号，无需开明 ARMS 云拨测性能，即可提供肯定额度收费应用拨测能力。 降级 2：场景降级，上线挪动监测点，满足挪动互联网场景下可用性监测和性能剖析需要明天，挪动互联网的是互联网的重要组成部分，很多用户有在挪动场景下进行拨测的需要，新版本的云拨测也上线了挪动互联网监测点，包含 3G、4G、5G 不同类型的监测点，同时覆盖全国次要城市，基于挪动监测点可进行 HTTP（s）、DNS、TCP、Ping、网页拨测、文件下载，全面监测挪动互联网下在线服务可用性、性能。 降级 3：体验降级，控制台全新改版，优化和欠缺工作创立、告警配置流程新版云拨测控制台进行了全面重构，在晋升控制台关上速度的同时，提供更敌对的用户体验。尽量简化和暗藏拨测创立流程中不必要的配置，晋升创立工作效率。新版云拨测也带来新能力「任务分析」，用户可基于该性能进行非常灵活的工作筛选和比照，反对多任务、多地区、多云经营的比照。 另外，新版云拨测也欠缺了告警性能，带来了泛滥用户始终冀望的基于地区维度的告警能力，并反对自定义告警检测周期和告警内容。针对应用体验这边新版本云拨测还有很多优化，如： 监测点类型 上线云主机监测点。上线挪动端监测点（笼罩 100+ 国内城市，反对 3G/4G/5G）。定时工作 创立工作反对可用性断言。反对自定义监测点组，可将罕用监测点保留为自定义监测组，重复使用。反对批量启停工作。反对创立工作标签，基于标签对工作进行治理。工作列表反对显示告警状态、反对可用性排序。反对基于定时工作配置一键发动即时拨测。即时拨测 优化即时拨测发动交互，疾速发动即时拨测。反对多任务比照即时拨测。优化即时拨测剖析界面。任务分析 预置 Grafana 工作概览大盘。反对自定义条件、自定义维度剖析。反对多任务、多地区、多条件比照剖析。反对工作明细剖析。反对 P50、P95、P99 耗时剖析。自定记录谬误响应头和响应内容。优化工作明细详情页面展现。即时拨测 反对工作比照。反对自定义监测点。反对网络品质拨测。反对网页性能工作。反对文件传输工作。告警治理 反对多维度告警（工作、地区、运营商）。反对 1 个拨测工作创立多个告警规定。反对自定义告警查看周期、自定义告警等级、告警内容。反对告警标签、告警正文。反对指定告警告诉策略。开源集成 默认与阿里云 Prometheus 服务集成，指标写入 Prometheus 收费实例。更多信息，请参见云拨测写入 Prometheus 指标阐明 [ 2] 。默认与阿里云 Grafana 服务集成，可通过 Grafana 自定义工作大盘。默认与阿里云 SLS 集成，明细数据写入 SLS Logstore。更多信息，请参见云拨测写入 SLS 字段阐明 [ 3] 。反对通过 Prometheus Remote Read/HTTP API 和 SLS 接口读取云拨测数据。费用 ...

一、我的项目背景AI智慧线上体育/静止健身，是将AI视觉与体育校园体侧、健身、舞蹈教学等多种场景深度交融。实现校园跳绳和仰卧起坐等动作 辨认与主动计数，通过AI静止解决学生体育科学化训练。 二、产品描述1. 产品概述由阿里云|达摩院——视觉智能平台推出的新性能AI智慧静止健身/线上体育由摄像头拍摄人像动作视频，通过AI进行图像和实时检测出，辨认出人体关键点，检测不标准肢体动作，同时可实现实时反馈和计数。已反对的健身动作有15种，还可反对定制健身动作。次要波及：肢体动作计数离线SDK；肢体动作计数反馈离线SDK；动作打拆散线SDK。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1252568?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

一、背景相较于互娱场景的磨皮美颜，广告级、影楼级的精细化美肤给算法带来了更高的要求与挑战。一方面，瑕疵品种泛滥，蕴含痘痘、痘印、雀斑、肤色不均等，算法须要对不同瑕疵进行自适应地解决；另一方面，在去除瑕疵的过程中，须要尽可能的保留皮肤的纹理、质感，实现高精度的皮肤润饰；最初也是非常重要的一点，随着摄影设施的一直迭代，业余摄影畛域目前罕用的图像分辨率曾经达到了4K甚至8K，这对算法的解决效率提出了极其严苛的要求。为此，咱们以实现专业级的智能美肤为出发点，研发了一套高清图像的超精密部分修图算法ABPN，在超清图像中的美肤与服饰去皱工作中都实现了很好的成果与利用。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1199590?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

日前，在 ICT 中国·2023 高层论坛-云原生产业倒退论坛上，由阿里云容器服务提供技术支持的“数禾科技”和“智联招聘”两大案例以及阿里云云原生 AI 套件、云原生 FinOps 老本剖析套件两大产品技术计划，独特取得 2023 年度云原生利用实际先锋——云原生技术服务优良案例。云原生是一种基于容器化、微服务等技术的利用开发和部署模式，它能够帮忙企业疾速构建和部署应用程序，进步利用的可靠性、弹性和可扩展性，让企业能够更加敏捷地响应市场需求，疾速上线新产品和服务，进步数字化转型的效率和速度，利用云原生技术架构和理念构建数字化新底座正在成为各行各业数字翻新的实际重点。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1247204?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

作者： 赵炳堃(秉钧) 在传统的微服务体系中，Spring Cloud Alibaba 和 Zuul 常被用作配合 Spring Cloud 应用的微服务网关。然而，这些传统的 Java 网关在面对大规模流量的场景下仍存在种种问题。例如 Zuul 因为采纳了非异步 IO 的架构，导致了其在面对高流量的状况下容易呈现阻塞的景象，Spring Cloud Gateway 也会在流量很大的状况下产生 Full GC 的状况，导致申请 RT 变长，影响用户体验和业务稳定性。因而咱们须要寻找一个新的选项，来代替这些传统的微服务网关。 Higress: Spring Cloud生态下微服务网关的新抉择Higress 是阿里巴巴开源的一款下一代云原生微服务网关。Higress 能够对接多种注册核心，包含Nacos/Zookeeper/Eureka 等，可能无缝集成 Spring Cloud 利用，对 Dubbo/Sentinel/OpenSergo 等微服务生态也有着深度的集成。与此同时，Higress 采纳 C++内核，相比于传统的 Java 网关来说性能更高，更稳固，比照Spring Cloud Gateway 和 Zuul 来说，性能能够晋升至2-4倍。另外，Higress 还人造兼容 K8s 的Ingress/Gateway API 规范，是一款更合乎云原生时代规范的微服务网关。 更多性能压测试验，请参考：https://mp.weixin.qq.com/s/45ZAc5CGfND46Ao3lbHefQ Higress无缝对接Spring Cloud利用公布实战在古代软件架构逐步走向微服务化、云原生化的过程中，利用的更新和迭代的频率变得越来越快，如何在尽可能保障用户体验不受影响的状况下实现利用的迭代公布就显得至关重要。目前业界广泛采纳的几种典型的利用公布策略包含蓝绿公布、金丝雀公布、A/B Testing公布等。接下来本文将介绍如何应用Higress来实现Spring Cloud Alibaba利用公布的最佳实际。 前提条件装置Higress，并装置Istio CRD，参考Higress装置部署文档。装置Naocs，参考Nacos装置部署文档。Higress反对将Nacos，Spring Cloud利用部署于K8s集群内，或者独立于K8s进行部署。为了演示不便，本文将Higress，Nacos，Spring Cloud利用都部署在本地K8s集群。 1. 通过Higress实现Spring Cloud利用的服务发现和路由1.1. 部署SpringCloudAlibaba利用apiVersion: apps/v1kind: Deploymentmetadata: name: spring-cloud-demo-v1spec: replicas: 1 selector: matchLabels: app: spring-cloud-demo template: metadata: labels: app: spring-cloud-demo spec: containers: - name: server image: higress-registry.cn-hangzhou.cr.aliyuncs.com/samples/spring-cloud-demo:v1 imagePullPolicy: IfNotPresent env: # 注册到的nacos的地址 - name: NACOS_REGISTRY_ADDRESS value: nacos-server.default.svc.cluster.local # 注册时携带的version元信息 - name: SPRING_CLOUD_NACOS_DEMO_VERSION value: v1咱们在k8s集群中部署如上Deployment，其中通过NACOS_REGISTRY_ADDRESS和SPRING_CLOUD_NACOS_DEMO_VERSION两个环境变量指定了Nacos的地址以及注册时携带的version元信息。SpringCloud利用的application.properties配置会读取这两个环境变量，如下所示： ...

流动简介“Serverless 技术实战与翻新沙龙 ” 是一场以 Serverless 为主题的开发者流动，流动受众以关注 Serverless 技术的开发者、企业决策人、云原生畛域创业者为主，流动模式为演讲、入手实操，让开发者通过一个下午的工夫增进对 Serverless 技术的了解，疾速上手 Serverless，拥抱云计算新范式带来的技术红利。 流动信息流动工夫：2023年7月8日（周六）12:30 流动地址： 广州嘉逸皇冠酒店广州天河区中山大道483号 名额有限，立刻报名！还有超多周边礼品！ 报名链接： https://www.huodongxing.com/event/9709144075400?td=3304156735350 流动议题及分享嘉宾① 13:30-14:05｜史明伟（世如）阿里云智能高级技术专家分享主题：Serverless 的起源、倒退和落地实际 议题简介： 以后 Serverless 架构从概念曾经进入到大规模生产落地阶段。本议题讲由浅入深探讨企业在 All on Serverless 过程中的挑战和教训，为给更多落地 Serverless 的企业提供参考和借鉴。 ② 14:05-14:40｜郭志伟(西溯) 阿里云智能技术专家分享主题：RDS 云数据库 Serverless 技术架构及利用实际 议题简介： Serverless 概念自 19 年提出至今，应用层的尝试与翻新川流不息，而数据库畛域的 Serverless 摸索则方兴未艾。传统云托管数据库，立足于 Serverless，依靠 IaaS 层的资源反对，如何为应用层带来极致的弹性、为运维带来智能化便当的体验，从而帮忙客户实现真正的降本增效？本次分享，将介绍阿里云数据库 RDS 的 Serverless 技术架构和细节，并从应用层接入的角度，介绍 RDS Serverless 数据库的具体实际。 ③ 14:40-15:15 ｜黄玉奇（徙远）阿里云智能 Serverless 利用引擎研发负责人分享主题：云原生 Serverless 利用托管架构及平台工程能力介绍 议题简介： Serverless 利用托管在云原生体系的演进脉络云原生 Serverless 利用托管的概念和外延云原生 Serverless 利用托管配套的平台工程能力阿里云 Serverless 商业实际和案例④ 15:15-15:50｜王庆（寒斜） 阿里云智能技术专家分享主题：Serverless 架构的 AIGC 企业实际 ...

作者：溪恒、谢石、遐宇 Kubernetes 自身比较复杂，应用门槛较高，用户在开始容器化迁徙时常常遇到各种各样的问题，因为不足故障定位的技能和工具，用户经常产生挫败感，甚至放弃业务容器化。其中网络问题体现尤为突出，Kubernetes 网络虚拟化导致网络问题排查的难度微小。 KubeSkoop 是阿里云容器服务团队开源的 Kubernetes 容器网络诊断工具，反对支流的网络插件和云厂商的 Kubernetes 集群诊断。它正是为了升高网络问题排查难度，让没有网络常识的人也能够自动化地定位网络问题。 Kubernetes 容器网络诊断工具：https://github.com/alibaba/kubeskoopKubeSkoop 可能主动构建出给定源和目标地址在容器网络中的拜访门路，自动化地采集和剖析链路上每一个网络节点的配置，联合 eBPF 内核监控以及 IaaS 层的网络配置查看，定位出导致网络不通的根因，极大地升高了网络问题定位的工夫，即便没有任何网络技能的用户也能够应用。目前在阿里云容器服务的环境中，作为自运维工具解决了大量客户在大规模 Kubernetes 集群场景下遇到的网络问题。 本文将会对容器网络和传统定位伎俩带来的问题进行简略的介绍，以及对 KubeSkoop 的功能设计等方面进行总体讲解。 容器网络网络连通性-CNI容器网络是 Kubernetes 集群中及其重要的一部分，包含了形成集群网络连通性的 CNI 插件、Service 服务发现机制、NetworkPolicy 网络策略等。Kubernetes 集群网络保障了每个 Pod 领有本人独立的网络空间，并且可能与集群中的 Pod 和 Node 相互通信。 CNI 插件是形成集群容器网络中的外围，实现集群级别惟一的地址调配，将集群维度的网络买通。 不同的 CNI 插件，如 Flannel、Calico、Cilium、Terway 等，有其不同的网络实现，包含地址调配，网络虚拟化实现，网络连通性实现等。服务发现和网络策略除 CNI 插件外，Kubernetes 还提供了 Service 作为服务发现，以及 NetworkPolicy 作为网络策略能力。这些能力也是通过可替换的组件来实现的。 复杂性和网络问题定位因为概念繁多，以及插件实现抉择的丰富性，导致 Kubernetes 网络问题存在着相当的复杂性，包含： 逻辑概念的复杂性Ingress/Service/NetworkPolicy 配置灵便，可能导致配置谬误/规定抵触等问题。应用 ServiceMesh 或第三方 CNI 插件，带来更简单的网络策略和扩大能力。数据面实现的复杂性数据立体通过不同组件的多层解决，且存在多种实现。协定栈链路简单，波及到网卡驱动 /netfilter/route/bridge 等配置。不同云厂商的底层配置不同，平安组、路由表等配置简单。传统的容器网络问题定位伎俩，次要是通过抓包定位丢包点、压测复现、人工查配置等形式。存在着定位流程长、大量工夫开销、人员教训要求低等问题。 在日常的工作中，排查容器网络问题占用了相当大部分的精力。因而，咱们开发了 KubeSkoop 我的项目，来实现针对容器网络场景下问题的主动诊断系统。 KubeSkoop 性能在咱们的剖析中，常见的 Kubernetes 网络问题能够分为以下两类： ...

作者：斜阳 高可用架构演进背景在分布式系统中不可避免的会遇到网络故障，机器宕机，磁盘损坏等问题，为了向用户不中断且正确的提供服务，要求零碎有肯定的冗余与容错能力。RocketMQ 在日志，统计分析，在线交易，金融交易等丰盛的生产场景中施展着至关重要的作用，而不同环境对基础设施的老本与可靠性提出了不同的诉求。在 RocketMQ v4 版本中有两种支流高可用设计，别离是主备模式的无切换架构和基于 Raft 的多正本架构（图中左侧和右侧所示）。生产实践中咱们发现，两正本的冷备模式下备节点资源利用率低，主宕机时非凡类型音讯存在可用性问题；而 Raft 高度串行化，基于多数派的确认机制在扩大只读正本时不够灵便，无奈很好的反对两机房对等部署，异地多核心等简单场景。RocketMQ v5 版本交融了上述计划的劣势，提出 DLedger Controller 作为管控节点（两头局部所示），将选举逻辑插件化并优化了数据复制的实现。 如何实现高可用零碎正本组与数据分片在 Primary-Backup 架构的分布式系统中，一份数据将被复制成多个副原本防止数据失落。解决雷同数据的一组节点被称为正本组（ReplicaSet），正本组的粒度能够是单个文件级别的（例如 HDFS），也能够是分区级 / 队列级的（例如 Kafka），每个实在存储节点上能够包容若干个不同正本组的正本，也能够像 RocketMQ 一样粗粒度的独占节点。独占可能显著简化数据写入时确保长久化胜利的复杂度，因为每个正本组上只有主正本会响应读写申请，备机个别配置只读来提供平衡读负载，选举这件事儿等价于让正本组内一个正本持有独占的写锁。 RocketMQ 为每个存储数据的 Broker 节点配置 ClusterName，BrokerName 标识来更好的进行资源管理。多个 BrokerName 雷同的节点形成一个正本组。每个正本还领有一个从 0 开始编号，不反复也不肯定间断的 BrokerId 用来示意身份，编号为 0 的节点是这个正本组的 Leader / Primary / Master，故障时通过选举来从新对 Broker 编号标识新的身份。例如 BrokerId = {0, 1, 3}，则 0 为主，其余两个为备。 一个正本组内，节点间共享数据的形式有多种，资源的共享水平由低到高来说个别有 Shared Nothing，Shared Disk，Shared Memory，Shared EveryThing。典型的 Shared Nothing 架构是 TiDB 这类纯分布式的数据库，TiDB 在每个存储节点上应用基于 RocksDB 封装的 TiKV 进行数据存储，下层通过协定交互实现事务或者 MVCC。相比于传统的分库分表策略来说，TiKV 易用性和灵便水平很高，更容易解决数据热点与伸缩时数据打散的一系列问题，但实现跨多节点的事务就须要波及到屡次网络的通信。另一端 Shared EveryThing 的案例是 AWS 的 Aurora，Aliyun 的 PolarStore，旁路 Kernal 的形式使利用齐全运行于用户态，以最大水平的存储复用来缩小资源耗费，一主多备齐全共用一份底层牢靠的存储，实现一写多读，疾速切换。 ...

作者：刘霖 背景现状随着 ChatGPT 的广泛应用，各种大规模语言模型层出不穷，其中包含 EleutherAI 推出的 200 亿参数的 GPT-NeoX-20B 和 BigScience 公布的 1760 亿参数的 Bloom 模型。 因为模型越来越大，单张 GPU 已无奈加载整个模型，分布式模型训练成为了一种必然的趋势。在 GPT-NeoX 和 Bloom 的背地，DeepSpeed 框架是实现分布式模型训练的要害。 DeepSpeed 是一个开源的深度学习训练优化库，提供了多种优化策略，如混合精度训练、数据并行、模型并行、流水线并行等，这些策略可用于减速大规模模型的训练。此外，DeepSpeed 还提供了高性能的分布式训练框架，反对多种支流的深度学习框架，并且能够在不同的硬件和云平台上进行训练。借助 DeepSpeed，算法工程师能够更加疾速地训练大规模深度学习模型，从而进步模型的准确性和效率。以后，越来越多企业在云上基于容器和 Kubernetes 进行大规模的分布式深度学习训练，充分利用弹性、扩展性、自动化、高可用等劣势，大幅提高分布式训练的效率和可靠性，同时升高治理老本和复杂性。 然而，随着模型规模扩充以及企业对生产效率的一直谋求，将 DeepSpeed 分布式训练任务在 Kubernetes 中搭建和运行依然存在着很多挑战和难点。例如，GPU资源利用率低，分布式训练扩展性差，以及难以不便地获取实时日志和监控等。 计划介绍目前，阿里云容器服务 ACK 云原生 AI 套件曾经反对 DeepSpeed 分布式训练，为您提供高效便捷的解决方案。 您只需筹备好训练代码和数据，就能够利用命令行工具 Arena 疾速在 ACK 集群中部署基于 DeepSpeed 的分布式训练任务。此外，能够通过 TensorBoard 可视化工具不便地查看训练作业的状态和后果，从而使 DeepSpeed 分布式训练变得更加容易和高效。 对于 ACK 云原生 AI 套件的更多信息，请通过往期文章进行理解：解脱 AI 生产“小作坊”：如何基于 Kubernetes 构建云原生 AI 平台 外围劣势基于阿里云容器服务 ACK 云原生 AI 套件搭建和运行 DeepSpeed 分布式训练任务具备以下劣势： ...

立刻体验基于函数计算部署【文生文】一键部署 ChatYuan 模型： https://developer.aliyun.com/topic/aigc_fc 人工智能生成内容（Artificial Intelligence Generated Content，简称 AIGC）是当下最火的概念之一。AIGC 被认为是继业余生成内容（Professional Generated Content, PGC）和用户生成内容（User Generated Content, UGC）之后，利用人工智能技术主动生成内容的新型生产方式。AI生成内容的模式相当丰盛，除了文字外，还能够进行绘画、作曲、演唱、编剧、设计等。【文生文】一键部署ChatYuan模型不仅可能智能与人对话，还能够为您进行创意写作、征询问答、你也能够用来无聊聊天等等性能。 试验介绍明天咱们将应用阿里云函数计算 FC 来部署【文生文】一键部署ChatYuan模型，给大家展现一下这项技术的魅力，只有您有任何的问题，就能够跟智能AI 进行对话，帮忙你解答。 ChatYuan 模型界面 函数计算的劣势开箱即用，通过利用核心一键部署疾速体验，无需进行简单的环境配置按需付费，通过 Serverless 弹性策略在您启动服务的才开始计费反对 GPU 渲染，出图快，破费低筹备项开明阿里云函数计算： https://free.aliyun.com/?crowd=personal&pipCode=fc 疾速开始抉择 ChatYuan 模型利用在函数计算页面单击左侧“利用”=》“创立利用”搜寻“文生文-ChatYuan 模型”单击“立刻创立 间接部署利用创立利用页面，抉择间接部署首次应用须要依据提醒进行角色名称受权利用可抉择北京、杭州、上海、深圳 任一地区依据抉择的地区，抉择以下对应的镜像，复制到镜像地址框。上海地区镜像地址： registry.cn-shanghai.aliyuncs.com/aliyun-fc/fc-chatyuan:v2 杭州地区镜像地址： registry.cn-hangzhou.aliyuncs.com/aliyun-fc/fc-chatyuan:v2 北京地区镜像地址： registry.cn-beijing.aliyuncs.com/aliyun-fc/fc-chatyuan:v2 深圳地区镜像地址： registry.cn-shenzhen.aliyuncs.com/aliyun-fc/fc-chatyuan:v2 注： 抉择地区页面，两者须要保持一致。 点击“创立并部署默认环境” 函数计算首次启动要花费 3-4 分钟，须要实现镜像拉取，冷启动等操作。 最初画面如下在部署装置后，只需拜访域名，即可进入体验空间。 有奖体验阿里云将提供函数计算 FC 产品试用资源，邀请您体验：函数计算 FC  一键部署通义千问预体验、文生图、图生图、图生文、文生文 5 大经典 AI 场景，让您取得通义千问 30 次对话预体验机会，同时简略、高效实现一键部署图像生成、文字生成服务，速成 AIGC 创作家。 双重奖品设置： 实现任意一个体验场景可得社区 400 积分兑换奖品，还可加入 AI 生成图像较量赢取 Airpods、阿里云定制蓝牙音箱及阿里云定制清雅杯！ ...

分布式推理成为大模型落地的首选计划随着 3 月 15 日 OpenAI 重磅公布了 GPT4，其在司法考试、程序编程上的惊艳体现，将大家对大模型的激情推向了顶点，人们纷纷探讨是否咱们曾经进入到通用人工智能的时代。与此同时，基于大语言模型的利用也如雨后春笋呈现在大家背后，其在协同办公、客服对话、语言翻译、内容生成等方面的应用均来带了前所未有的畅快体验。 在咱们享受大语言模型带来的普惠 AI 能力时，它也给开发者带来了前所未有的挑战。GPT3 模型具备 1750 亿参数量，即便是针对学术界和高级用户的 Alpaca 也具备 70 亿的参数量，因而单机多卡的分布式推理便成为了大模型落地计划的不二抉择。 本文将以 Bloom7B1 模型为样例，分享在阿里云容器服务 ACK 上，进行大语言模型分布式推理的具体实际。 工程化落地是大模型分布式推理的要害随着越来越多的大语言模型公布，其中也有很多体现优良的开源大语言模型能让大家体验，人们通过已有的大语言模型构建本人的利用也不再遥不可及。然而，与以往的模型不同，单张 GPU 卡的显存可能不足以撑持大语言模型。因而，须要应用模型并行技术，将大语言模型进行切分后，在多张 GPU 卡上进行推理。在本文中，咱们应用 DeepSpeed Inference 来部署大语言模型分布式推理服务。 DeepSpeed Inference 是 Microsoft 提供的分布式推理解决方案，可能很好的反对 transformer 类型的大语言模型。DeepSpeed Inference 提供了模型并行能力，在多 GPU 上对大模型并行推理。通过张量并行技术同时利用多个 GPU，进步推理性能。DeepSpeed 还提供了优化过的推理定制内核来进步 GPU 资源利用率，升高推理提早。详细信息可参考DeepSpeed Inference [3 ] 。 有了大模型分布式推理计划，然而想要在 Kubernetes 集群中高效部署大模型推理服务，还存在很多工程化挑战，比方大规模的 GPU 等异构资源如何高效地治理运维和主动调度？如何疾速部署推理服务，服务上线后如何保障资源可能应答稳定的访问量？以及没有适宜的工具进行推理服务时延、吞吐、GPU 利用率、显存占用等要害指标监控，没有正当的模型切分计划，模型版本治理等。 本文应用阿里云容器服务 ACK 云原生 AI 套件进行 DeepSpeed 分布式推理的实际，能够轻松治理大规模异构资源，精细化的 GPU 调度策略和丰盛的 GPU 监控告警能力，应用 Arena 疾速提交和治理可弹性伸缩的推理服务，以及服务化运维等。 实际示例概述本例中会应用以下组件： ...

作者：黄驰琳、露营、车漾 背景KServe 是 Kubernetes 上的规范模型推理平台，专为高度可扩大的场景而构建，反对古代 Serverless 推理工作负载，用于在任意框架上提供机器学习（ML）模型服务。它提供高性能、高度形象的接口，以反对常见的 ML 框架（如Tensorflow、XGBoost、Scikit-Learn、PyTorch 和 ONNX）来解决生产模型服务场景。此外，KServe 封装了主动缩放、网络、健康检查和服务配置的复杂性，反对GPU 主动缩放、归零缩放和金丝雀公布等。为生产级别机器学习服务提供了一个简略、可插拔且残缺的反对，包含预测、预处理、后处理和可解释性的能力。 人工智能生成内容（AIGC）和大型语言模型（LLM）在近一年内方兴未艾，进一步晋升了了公众对 AI 的期望值。为了可能产生新的业务价值，越来越多的公司开始应用 KServe 来部署它们，次要起因是： 分布式解决： 大型语言模型（LLMs）的参数量宏大，须要极高的计算资源，而KServe平台提供了分布式解决能力，能够将计算工作散布到多个节点上进行并行计算，从而减速计算过程。Serverless： KServe 平台是无服务器算法的典型代表，能够在需要变动时主动进行扩缩容。这种个性使得部署大型语言模型变得更加灵便和高效，并可能显著晋升模型的响应速度。统一化部署： KServe 平台为用户提供了一种更加简便和对立的形式来部署和治理大型语言模型。这样一来，用户无需自行设置和配置算法环境，即可开始进行模型的训练和预测工作。监控和治理： KServe 平台具备齐备的监控和治理性能，用户能够清晰地理解到模型的运行状况和性能体现，并可能及时调整参数和解决问题，从而保障模型的高效和牢靠。然而在生产实践中，KServe 对于大型语言模型（LLMs）的反对仍然有不小的挑战。次要问题在于： 模型启动工夫长： 大型语言模型（LLMs）的参数规模相当微小，体积通常很大甚至达到几百 GB，导致拉取到 GPU 显存的耗时微小，启动工夫十分慢。此外，KServe 通过存储初始化器（Storage Initializer）从近程存储中拉取模型到本地，这也须要很长时间，对依据流量进行 KServe 无服务器主动扩缩容性能产生不利影响。容器镜像拉取工夫长： 大型语言模型（LLMs）的运行时环境依赖 GPU 根底环境，相应的容器镜像通常很大，这会导致拉取工夫长，拖慢利用启动速度。模型更新效率低、复杂度高： 大型语言模型（LLMs）由多个文件组成，模型更新时只需局部更新或增加局部文件，但 KServe 须要重启容器和从新拉取模型，无奈反对模型的热降级，这带来效率低和复杂度高的问题。KServe 在 Kubecon 2023 就提到了 Fluid 有可能帮忙解决其在弹性上遇到的问题。Fluid 是一个开源的 Kubernetes 原生的分布式数据集编排和减速引擎，次要服务于云原生场景下的数据密集型利用，例如大数据利用、AI 利用等。参见数据减速 Fluid 概述 [ 1] 。 阿里云容器服务团队和 KServe，Fluid 社区的小伙伴一起摸索在阿里云 Serverless Kubernetes 平台上简略，不便，高性能，生产级别的反对大型语言模型（LLMs）: 服务托管，产品反对： 阿里云服务网格（简称 ASM）对于 KServe 提供了原生反对，要晓得 KServe 依赖于底层Istio的稳定性对于 KServe 来说十分重要，应用托管的服务网格后，高可用、免运维、内建平安最佳实际；用户能够更专一于大语言模型相干的工作。除此之外 KServe 和 Fluid 也能够一键装置。协同社区优化应用模式： 在 KServe 最新版反对除了存储初始化器（Storage Initializer）外，也反对规范的 PVC 模式，通过防止从近程存储中拉取模型到本地，缩小存储有余的危险和晋升启动速度；也能够反对模型热降级。通过弹性分布式缓存减速模型加载流程： Fluid 与 KServe 相结合，通过数据预热到分布式缓存，缩短 Pod 启动工夫 80% 同时反对模型热降级，无容器重启。以上能力齐全通过运行阿里云无服务器 Kubernetes 容器服务（ASK）上，在业务没有运行按需弹性、按秒计费，同时基于申请量的 GPU 无服务器主动扩大，缩放至零。 ...

前言： 2023 年 6 月 6 日，由中国信息通信研究院（以下简称“中国信通院”）承办的“ICT中国·2023 高层论坛-云原生产业倒退论坛”在北京召开，会上正式公布了一系列云原生畛域评估后果。阿里云计算有限公司（以下简称“阿里云”）音讯队列 RocketMQ 通过了“云原生中间件成熟度”评估， 验证了阿里云中间件较强的云原生服务能力，可能帮忙用户更加高效、麻利的进行云转型。 产品介绍阿里云音讯队列 RocketMQ 版是阿里云基于 Apache RocketMQ 构建的低提早、高并发、高可用、高牢靠的分布式“音讯、事件、流”对立解决平台，面向互联网分布式应用场景提供微服务异步解耦、流式数据处理、事件驱动解决等外围能力。 云音讯队列 RocketMQ 具备十分多的劣势。 架构先进， 全面采纳存储和计算拆散的音讯架构，存储和计算能够独立按需程度扩大，满足高效弹性运维和高性能大规格能力的诉求；高性能， 可提供单实例集群最高 100 万 TPS 稳固音讯收发的能力，无需放心大促等峰值流量场景的零碎稳定性；稳固 SLA 保障， 提供业内当先的稳定性 SLA 保障，音讯服务可用性最高 99.99%；弹性低成本， 音讯计算解决提供预留+突发弹性的组合能力，业务无需再为突发流量预留大量 Buffer 资源，最高可节俭一半机器资源；存储实现 Serverless 弹性化；运维可观测 ， 提供丰盛的运维可观测能力，能够一键集成 OpenTelemetry、全链路 Trace、Prometheus 等可观测零碎；提供欠缺的 OpenAPI 能力， 反对集成自助运维零碎。音讯队列 RocketMQ 基于对立音讯存储和轻量计算层，次要利用于微服务异步解耦、流式数据处理、事件驱动等场景。RocketMQ 作为中间件-音讯队列畛域的代表性产品参加云原生中间件系列评估，并在 17 个测试评估我的项目中全副达到测评规范的最高等级。 参评收益Apache RocketMQ PMC Member 林清山老师（花名：隆基） 示意，云计算为各行业的数字化转型带来了全新基础设施，而云原生技术则是开释云计算红利的最短门路。近几年，无论是应用软件，还是根底软件都在进行全面云原生架构降级，积攒了丰盛的云原生技术实际。 在信通院的率领下，阿 里云音讯团队很荣幸能参加到《云原生能力成熟度模型》规范的制订， 为业界中间件产品进行云原生架构设计提供参考模型，也为客户进行中间件技术选型提供指引。将来，中间件的云原生架构将持续深入，深度联合云基础设施，如高性能 DFS、对象存储、eRDMA、神龙裸金属、软硬联合等技术进一步降低成本、晋升弹性能力；并通过全面 Serverless 化的云服务，把中间件云原生架构降级带来的“降本增效”红利真正开释到客户侧。 云原生中间件成熟度评估中间件作为系统软件与应用软件之间的桥梁，在业务构建过程中起着至关重要的作用，在云原生化转型的大趋势下，中间件本身须要适应云原生环境的特点对产品进行迭代优化。在此背景下，中国信通院牵头联结各相干企业，历经半年制订了面向中间件的《云原生能力成熟度模型第 5 局部：中间件》行业标准。同时依靠规范推出相应评估，从弹性、可观测性、可移植性、可维护性、高可用性、安全性、开放性七个维度掂量中间件的云原生成熟度，评估后果分为 1-5 级，有助于定位中间件以后的云原生化程度，明确下一步的建设门路。 ...

作者：金兆旭 上海创米数联智能科技倒退股份有限公司云服务开发及 SRE 工程师 负责公司云端基础设施构建及音讯网关等研发工作；十眠 创米数联是小米生态链首批亿元俱乐部成员，主营业务为智能家居产品的研发、设计、生产和销售，致力于成为以居家平安为外围的产品和服务提供商，提供多品类的全屋智能家居产品及服务。公司以居家平安为外围，洞察用户在寓居环境下的智能化需要，建设物理平安、环境平安、系统安全三类场景及服务体系，次要产品包含智能摄像机、智慧门、智能猫眼、智能门铃、智能插座等。公司旨在实现“看得见的全屋智能”，以智能家庭平安为切入点，提供多品类笼罩的智能家居解决方案。截至 2021 年 12 月 31 日，创米数联曾经在全世界 150 多个国家，销售了超过 5500 万台设施，领有了 1600 万设施和 500 万设施用户日活。 作为小米生态链的一员，创米采纳微服务架构撑持其千万日活的 IOT 设施。随着智能家居市场的疾速迭代，创米面临着公布和迭代的稳定性挑战，同时须要解决多方 IOT 接入面临的性能和平安挑战。本文将为您一一道来创米是如何应答这些挑战的。 云计算时代的蹒跚学步创米云服务从 2016 年开创之初就抉择了云计算+微服务的技术路线，以应答面临的大量线上用户和设施带来的流量挑战。构建微服务之初，市面上可选用的解决方案并不多，咱们自主实现了一些微服务组件，如 frontend 业务网关和配置核心，并在小米生态云上部署容器服务来解决设施音讯、设施插件 API 和微信公众号等相干业务，并利用 HPA 及 CronHPA 等容器弹性伸缩策略来应答动静的海量线上流量。 自此创米数联在云计算时代踏上了摸索服务容器化的第一步。 新业务及新挑战从 2019 年伊始，创米数联提出了研发自有 APP 和适配自有 APP 的智能家居设施的倒退策略。云服务部将研发重心转向自有 APP 云端业务，并逐渐接入自有品牌设施。为了实现寰球业务，创米云服务部将相干服务部署在阿里云的 4 个 Region 的 ACK Pro 专有版 Kubernetes 集群上。阿里云 ACK 为创米云提供了牢靠稳固的基础设施，向下封装好的数十款云产品，升高了云端运维人员的运维压力，疾速对接其余云产品的能力也对开发人员非常敌对，可能让创米云服务在极短的工夫内搭建一套线上可用的环境。 在自有业务研发开始阶段，咱们抉择了 Spring Cloud、Eureka 和 Apollo 等技术栈来搭建咱们的微服务基础架构。然而，通过一年半的摸索，咱们发现以后的混合架构存在着不稳固、上线部署危险大以及高人力保护老本等问题。 因而，从 2021 年开始，创米云服务决定扭转现有的微服务架构，逐渐拥抱云原生。咱们的指标是在满足稳定性和低保护老本等需要的根底上，实现所有组件的可观测性、全链路的流量治理以及更加便捷高效的 DevOps 流程。 ...

AI 技术正在引领科技翻新浪潮，随着 ChatGPT 和 Midjourney 的走红，AIGC 技术正在世界范畴内掀起一股 AI 技术浪潮。开源畛域也涌现了许多相似模型，如 FastGPT、Moss、Stable Diffusion 等。这些模型展现出的惊人成果吸引企业和开发者们投身其中，然而简单繁琐的部署形式成为了拦路虎。阿里云 ASK 提供 Serverless 化的容器服务，用户无需关怀资源及环境配置，能够帮忙开发者们零门槛疾速部署 AI 模型。本文以开源的 FastChat 为例，具体展现如何在 ASK 中疾速搭建一个私人代码助理。目前，ASK 已退出阿里云收费试用打算，为开发者、企业提供肯定额度的试用资源。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1204912?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

随着越来越多的企业上云，企业的外围关注点转变为如何更好地利用云的能力，将产品疾速推向市场，从而实现业务胜利。然而，如果算力的出现模式依然是服务器这样的资源状态，它的应用门槛仍然很高。让算力像电力一样的遍及，云计算须要新的状态，就是 Serverless。 随着用好云成为要害，开发范式也将被从新定义。基于 Serverless 能够轻松构建高弹性利用，从容应对流量稳定。在 Serverless 开发范式下，新性能交付周期大幅缩短，进一步减速业务迭代，博得市场先机。 为了让更多开发者体验到 Serverless 产品技术带来的劣势，阿里云启动第四届云原生编程挑战赛，大赛由阿里云主办，云原生利用平台、阿里云天池平台联结承办，自2015年开始，大赛曾经胜利举办了八届，并从2020年首次降级为云原生编程挑战赛，共吸引了超过53000支队伍，笼罩10余个国家和地区。 往年，云原生编程挑战赛全新降级，围绕"Serverless 引领云上开发新范式”开展，深度摸索 Serverless 冷启动、插件设计、翻新利用三大热门方向，为酷爱编程的极客提供一个挑战世界级技术问题的舞台。 瓜分 36 万元奖金池 冠军： 1 支队伍/赛道，奖金 3 万，颁发获奖证书亚军： 2 支队伍/赛道，奖金 2 万，颁发获奖证书季军： 3 支队伍/赛道，奖金 1 万，颁发获奖证书优胜奖： 4 支队伍，每支队伍奖金 5000 元，颁发获奖证书赛程安顿 大赛参谋 点击此处 ，立刻报名参赛！

作者：凌敏 稿件信息： 作者丨凌敏 采访嘉宾丨阿里云云原生可观测团队 嘉宾介绍： 司徒放，阿里云可观测技术负责人，资深技术专家 徐彤，阿里云可观测高级技术专家曹剑，阿里云可观测高级产品专家 王希正，阿里云可观测高级经营专家 IT 零碎的运维监控最早呈现在上世纪 90 年代。彼时，分布式架构正向传统的单体架构收回挑战，其带来显著劣势的同时，也为零碎开发和运维带来了新的难题。在这一背景下，IT 人员开始引入监控技术，观测主机上的利用运行状况，及时定位问题。 随着分布式系统、微服务、云计算技术衰亡，IT 零碎产生多轮演进，简单的运维环境对监控提出了更高的要求。2018 年，CNCF 将可观测性引入 IT 畛域，取代监控。可观测性也一跃成为云原生技术畛域最热门的话题之一。 5 年后的明天，可观测性技术早已从晚期的运维排查问题工具，逐步进化成业务生产过程中的生产力工具。Gartner 更是将利用可观测性列为“2023 年十大策略技术趋势”，并示意“如果可能在策略中予以布局并胜利执行，可观测性利用将成为数据驱动型决策的最弱小起源”。 作为阿里巴巴团体最早的监控 & 可观测团队，云原生可观测团队早年打造了 EagleEye（鹰眼）作为分布式调用跟踪零碎利用于阿里外部各业务线，随后将该工具进行产品化，联合云上客户的宽泛需要，打造出了阿里云利用实时监控服务 ARMS。 那么，阿里云云原生可观测体系的建设背景与历程是什么样的？可观测体系建设的重难点是什么？如何从外部自研走向产品化？2023 年，企业和开发者应该如何了解可观测性？在本期访谈中，InfoQ 有幸采访到了阿里云云原生可观测团队的多位核心成员，以期找到上述问题的答案。 01 阿里云云原生可观测体系建设历程2010 年 4 月，Benjamin H. Sigelman 等人在 Google Technical Report 上发表了一篇名为《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》的论文，介绍了 Google 生产环境中大规模分布式系统下的跟踪零碎 Dapper 的构建和部署教训。这篇论文正式揭开了分布式链路追踪的技术大幕，也为起初涌现出的包含 EagleEye 在内的分布式调用零碎提供了灵感源泉。 分布式链路追踪 EagleEye 的设计与实现  2012 年，阿里的淘宝电商业务正处于高速增长期，为满足业务疾速迭代的需要，撑持一直进步的交易量，阿里采纳微服务架构对整个业务逻辑做了一次重构。微服务架构在性能、可维护性和可用性上带来劣势的同时，也带来了四大难题： 故障定位难：一个简略的下单购买操作背地是由十几个甚至数十个微服务共同完成的，这些微服务又由不同的团队负责，微服务的适度协同带来的后果就是，一旦呈现问题，须要十几个团队一起来解决；容量预估难：在大促场景下，过来只需依照预估的流量与以后零碎的单机压测容量做比照，再将所有的零碎按比例去扩容即可，但在微服务架构下，每个零碎在外围链路中的参与度、重要性都不同，无奈进行等比例的扩容；资源节约多：这也是容量预估不准造成的结果，同时，资源节约多也会引发性能优化难的问题；链路梳理难：简单的微服务体系，让各个微服务零碎的负责人很难梳理分明每种业务的上下游细节逻辑对本身零碎的影响。“我印象比拟粗浅的是，过后淘宝曾经迭代出了上百个利用，但却没有一个业务架构师可能讲清楚整个业务的零碎架构是什么样子的。正是在这个时候，咱们遇到了 Google 的《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》这篇论文，咱们参考了 Google 的次要思维，在阿里外部做了落地实际。”阿里云可观测技术负责人司徒放回顾道。 ...

近日，阿里云发表与马来西亚外乡数字计划专家Agmo控股（Agmo Holdings Berhad，简称Agmo）开展单干，签订体谅备忘录，联手推出马来西亚首个Agmo电动车超级应用程序。此次单干也标记着阿里云在中国以外的市场首次落地其最新的企业级超级App解决方案（EMAS超级App）。 EMAS超级App解决方案是一个用于建构超级应用程序和相干生态系统的全栈平台，也是阿里云在电子商务行业和可扩大云基础设施上屡教训证的教训成绩。此计划可提供各类性能以帮助企业打造具备丰盛生态系统的超级利用，包含为利用基础设施和业务性能而设的组件、运行小程序的容器，以及各种可让小程序在简便及平安的状态下进行开发与经营的平台。 全新推出的Agmo电动车超级应用程序采纳了阿里云屡教训证的计划以及先进的云技术，将以平台的模式出现一站式的电动车计划核心，有利于整合及纳入数个汽车业和生态系统小程序。通过高深莫测和无缝接轨的用户体验，Agmo电动车超级应用程序解决了电动车用户的痛点，同时进步电动车在马来西亚的使用率。 (在马来西亚迷信、工艺及变革部长郑立慷和马来西亚多媒体大学总裁Dato' Dr. Mazliham Mohd Su'ud的见证下，阿里云智能马来西亚总经理黄焜与Agmo控股首席执行员陈奕强替换签订的单干备忘录开展单干） 马来西亚迷信、工艺及变革部长郑立慷（YB Chang Lih Kang） 见证并主持了本次单干典礼。他示意：“在政府主导的动作和国内制造商提供的价值驱动产品的独特推动下，马来西亚汽车行业目前正见证咱们同胞对电动汽车的采纳激增。咱们赞叹阿里云和咱们外乡机构Agmo的单干致力，因为他们在开发翻新解决方案方面施展着关键作用，该行业对最终用户，尤其是马来西亚人民具备微小意义。通过他们的奉献，咱们正在推动咱们国家通过科学技术成为高科技核心。” （阿里云智能马来西亚总经理黄焜） 阿里云智能马来西亚总经理黄焜示意：“技术已成为了各大企业组织放弃竞争力和创新能力的根本工具。在此单干根底上，咱们非常荣幸Agmo成为阿里云EMAS超级App解决方案的首个国内客户，并采纳咱们尖端的技术劣势来推动电动车的变革浪潮。这个电动车超级应用程序以咱们先进的云技术和数字化计划开展建构，可轻易地与咱们成熟的超级应用程序生态系统相互连接，进而开启有限商机并为本地用户带来晦涩的应用体验。” 思考到电动车用户在以后和预期中所将面对的挑战，以及马来西亚市场迅速普及化的电动车趋势，Agmo创始了一个前所未有的概念，旨在帮助马来西亚电动车驾驶者克服各种要害痛点，例如充电站的类型、免费率，同时还可在繁多平台上应用所有的性能。得益于阿里云的前沿解决方案，这一概念得以落地。 Agmo控股首席执行员陈奕强（Tan Aik Keong） 指出：“面对电动车驾驶者始终以来挥之不去的里程焦虑问题，Agmo电动车超级应用程序的推出将让电动车相干计划富裕商业可行性，为Agmo减速国家转型以赶上电动车趋势的继续策略奠定了重要的里程碑。因而，阿里云EMAS超级App解决方案的整套技术，在实现咱们的指标方面起着关键性的作用。他们开发了可行且易于应用的计划，所以咱们能力将概念引入市场，为一直成长的电动车社群创始具备侧面价值的计划。” 这项全新的单干关系进一步体现了阿里云和Agmo致力于通过先进技术和高效的解决方案，为数字化旅程提供便当的环境，帮助马来西亚降级为高附加值经济体的承诺。Agmo全力支持马来西亚政府通过《低碳挪动出行蓝图》，在2025年前于国内装置10000个公共充电站的指标。

作者：王金山，北京云思畅想科技有限公司技术部微服务架构师，负责公司 API 网关和服务网格等研发工作 时速云介绍时速云成立于2014年10月，致力于通过云原生技术帮忙企业实现数字化转型，领有云原生利用平台 TCAP 和云原生数据平台 KubeData 两大外围产品体系，产品蕴含云原生 DevOps、容器云 PaaS、中间件服务、边缘计算、微服务治理、服务网格、API 网关等。 需要背景 时速云的 PaaS 平台中存在着多款网关软件： 以 HAProxy、Nginx Ingress 为根底的流量网关Spring Cloud 微服务体系的 Spring Cloud Gateway作为 API 网关的 Kong服务网格体系下的 Istio Ingress Gateway以上产品虽说各自有本人的利用场景，然而带来的问题是技术栈各不相同，为了满足不同的需要引入多种工具后，带来的就是保护老本的急剧减少。因而，寻找一种既能够满足所有需要，又能够应用对立技术栈的工具，成为咱们谋求的指标。Higress 正合乎咱们的需要。 Higress 解决方案代替 Nginx IngressHigress 能够作为 K8s 集群的 Ingress 入口网关, 并且兼容了大量 K8s Nginx Ingress 的注解，能够从 K8s Nginx Ingress 疾速平滑迁徙到 Higress。如下是一个基于 Higress 自带注解来实现 REST 路由，并兼容 Nginx Ingress 注解重写门路的示例： apiVersion: networking.k8s.io/v1kind: Ingressmetadata: annotations: # 兼容 Nginx Ingress 注解 nginx.ingress.kubernetes.io/rewrite-target: / # Higress 注解，反对 method/header/query 匹配路由 higress.io/match-method: POST higress.io/exact-match-query-higressQuery: hi higress.io/prefix-match-header-x-higress-header: hi name: foospec: ingressClassName: higress rules: - host: foo.example.com http: paths: - pathType: Prefix path: /foo backend: service: name: foo-service port: number: 5678并且 Nginx Ingress 的 Lua 代码性能比拟差，Higress 比照 Nginx Ingress 的性能晋升很大，如下图所示： ...

作者：沈林 前言事件驱动，这个词在局部人印象中，它是一个过期的技术——没什么新意。从工夫上看，的确也是这样，上世纪 60 年代，事件驱动就曾经被正式提出，常常会被在 GUI 编程中。然而在有些人印象中，事件驱动又是一个十分生疏，十分新鲜的技术。 不论怎么样，事实是曾经有越来越多的公司，开始或则经把事件驱动架构利用到企业的外围业务中，包含：阿里巴巴、喜力、联合利华、美国联邦航空管理局、银行资本市场等等。市场上，也有很多公司推出了本人的产品或解决方案，比方阿里云、AWS、Google，Solace。行业里也孕育出了事件的规范：CloudEventsGartener，则把事件驱动定义为将来十大趋势之一； 这个时候，咱们就要问了，事件驱动架构到底是什么呢？为什么当初，被越来越多的人，开始关注事件驱动架构了呢？ 5 月 28 日，GOTC 2023 寰球开源技术峰会上，阿里云智能技术专家沈林发表主题演讲：Apache RocketMQ 事件驱动引擎。 Apache RocketMQ PMC&阿里云智能技术专家：沈林 什么是事件？说到事件驱动架构，大家第一印象往往会把重点放在“架构”这两个字上，然而，事件驱动架构很大的魅力其实来源于后面“事件”两个字，所以明天，咱们先一起看下什么是事件。RocketMQ 之前始终给人的印象是一个音讯引擎，那为什么咱们在前段时间公布的 5.0 版本中，引入了事件？音讯跟事件，又有什么区别呢？ 事件，如果咱们查阅字典，他会给你这样一个解释：事件是指过来曾经产生的事，尤其是比拟重要的事。 这个很好了解啊。比方，GOTC 大会明天在上海正式揭幕了；方才我的手机铃声响了；这些都是过来曾经产生的事件。 然而，如果咱们接着方才的问题问：事件跟音讯有什么区别呢？这个时候，大家是不是感觉事件这个定义，如同又不那么清晰了？方才咱们说的那些事件，是不是也能够了解为音讯？如果这个时候，老张给我发送了一条短信，那这个短信，算是事件，还是音讯呢？ 咱们能够通过这张图，来简略了解音讯和事件的关系。音讯蕴含两类，一类是 Command 音讯，另一类就是 Event 音讯。 1、Command 音讯是什么？咱们看上面右边这张图，内部零碎发送给本零碎的一条操作命令，就是Command音讯； 2、那什么是 Event 音讯呢？再看上面左边这张图，本零碎收到内部 Command 操作申请，零碎外部产生扭转之后，就产生了 Event； 所以，事件和音讯略微有些不同。事件，能够了解为是一种非凡的音讯，那事件非凡在什么中央呢？次要蕴含 4 个方面： 事件的个性 1：已产生且不可变的事件，肯定是“已发的”。“已产生”的代表什么呢？不可变的。咱们不可能扭转过来，除非你有超能力。这个个性十分重要，在咱们处理事件、剖析事件的时候，这就意味着，咱们相对能够置信这些事件，只有是收到的事件，肯定是零碎实在产生过的行为，而且是 Immutable，不可批改。 比照 Command 音讯，Command 的中文是什么？命令！很显然，它还是没有产生的，而是表白了一种冀望。咱们晓得，“冀望的”不肯定会胜利产生。比方： 把厨房的灯关上；去按下门铃；转给 A 账户 10w；这些都是 Commond，都是冀望产生的行为。然而，最终有没有产生呢？并不知道。 Event 则是明确曾经产生的事件。比方： 厨房灯被关上了；有人按了门铃；A 账户收到了 10w事件的个性 2：无冀望的事件的第二个个性是：无冀望的。事件是主观的形容一个事物的状态或属性值的变动，但对于如何处理事件自身并没有做任何冀望。相比之下，Commond 则是有冀望的，它心愿零碎做出扭转；然而 Event，它只是主观形容零碎的一个变动。咱们举一个例子：交通信号灯从绿灯变成红灯，它就是一个事件。事件自身并没有任何冀望，说要求行人或汽车禁止通行，而是交通法规须要红绿灯，并赋予了其规定。 所以，零碎，个别不会定向的、独自向一个指定的零碎发送事件，而是对立的通知“事件核心”。“事件核心”那外面有各个系统上报上来的，各式各样的事件。零碎会向事件核心阐明：本人这个零碎，会产生哪些事件，这些事件的格局是怎么样的；别的零碎如果感兴趣，就能够来被动订阅这些事件；真正赋予事件价值的，是事件消费者。事件消费者想看看，某个零碎产生了什么变动？OK，那他就去订阅这些事件，所以事件是消费者驱动的。 这跟音讯有什么区别呢？Commond 音讯的发送和订阅，是单方约定好的，外人不晓得，往往是以文档或代码的模式，大家按约定好的协定，发送和订阅生产，这个过程往往是生产者驱动的。 打个比喻，事件就像市场经济，商品被生产进去，具体有什么价值，有多大价值，很大水平上看其消费者。咱们能看到零碎中各种各样的事件，就像橱窗里摆放了各种各样的商品；而 Commond 音讯，有点像计划经济，一出世就带着很强的目的性，“我”就是要“调配”给谁生产。 ...

MQTT over QUIC 多流反对在 5.0.18 版本中，EMQX 利用 QUIC 的多路复用个性，扩大 MQTT over QUIC 实现了多流反对。 启用多流将为音讯通信带来以下改善： 解耦连贯管制和音讯传输；防止主题之间的队首阻塞，每个主题能够有独立的流以打消其余主题长阻塞带来的影响；解耦管制立体流量和数据立体流量；将上行数据（公布）和上行数据（音讯接管）拆分为不同通道，更快地响应客户端操作；为不同主题设置不同流，实现主题优先级管制；残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1174728?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

数据价值取决于对数据的洞察翻新，通过联合开发利用实现数据价值最大化的开释。云计算是大数据的 IT 根底，海量、繁冗的大数据必须依靠于云计算的分布式架构，二者相辅相成，云化渗透率晋升将撑持大数据进一步提速。基于此，首届数据洞察翻新挑战赛正式启动！本届大赛奖金池高达 20 万元，是由阿里云主办的面向宽广开发者的技术比赛，大赛将在阿里云天池平台上举办，旨在激励开发者利用阿里云存储产品和服务，通过“智能运维赛”和“数据管理翻新赛”两个赛道，开发出翻新的利用和解决方案，展现技术实力和创意思维，为行业倒退和社会提高贡献力量。作为基于云计算相干技术延长和倒退而来的全新的产品状态，云存储是古代 IT 设施中重要的一环。2008 年，为了摸索大规模存储解决之道，阿里云存储团队应运而生。在实现了以弹性扩大、灵便高效、降低成本为外围的存储根底服务当前，阿里云正帮忙越来越多的客户实现数据管理的数字化和智能化。为了提供更普惠的云存储服务，阿里云推出了全新的产品类型【预留空间】，同时上线全产品线的收费试用，以期帮忙更多的大学生、开发者和中小企业疾速上云。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1239496?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

作者：王特（亦夏） Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简略易用的分布式事务服务。Seata 为用户提供了 AT、TCC、SAGA、XA 等多种事务模式，帮忙解决不同业务场景下的事务一致性问题。 本文次要介绍 Seata Saga 模式的应用以及最佳实际，围绕三个局部开展，第一局部是 Seata Saga 的简介、第二局部是带大家疾速入门，学习怎么应用 Seata Saga 模式，最初一部分将会给大家分享一些 Seata Saga 实际中的教训，帮忙用户更快、更好得应用 Seata Saga 模式。 Seata Saga 简介1.1 Saga 模式Saga 模式是分布式事务的解决方案之一，理念起源于 1987 年 Hector & Kenneth  发表的 Sagas 论文。它将整个分布式事务流程拆分成多个阶段，每个阶段对应咱们的子事务，子事务是本地事务执行的，执行实现就会实在提交。 它是一种基于失败的设计，如上图，能够看到，每个流动或者子事务流程，个别都会有对应的弥补服务。如果分布式事务产生异样的话，在 SAGA 模式中，就要进行所谓的‘复原’ ，复原有两种形式，逆向弥补和正向重试。比方下面的分布式事务执行到 T3 失败，逆向弥补将会顺次执行对应的 C3，C2，C1 操作，勾销事务流动的 ‘影响’。那正向弥补，它是裹足不前，T3 失败了，会进行一直重试，而后持续依照流程执行 T4，T5 等。 依据 Saga 模式的设计，咱们能够失去 Saga 事务模式的优缺点。 长处： 子事务（或流程），提交是本地事务级别的，没有所谓的全局锁，在长事务流程下，防止了长时间的资源锁定；另外这种流水线的解决模型人造合乎阶段式信号处理模型，能发掘出更高的性能和吞吐。正向服务和弥补服务都是交给业务开发实现的，所以 Saga 模式和底层数据库协定是无关的。XA/AT 模式可能依赖特定的数据库类型和版本，比方 MySQL 是 5.0 之后才反对的 XA，那么低版本的 MySQL 就不能实用到XA模式。毛病： 也是因为正向服务和弥补服务都由业务开发者实现，所以业务上是有开发成本的，侵入性绝对 XA/AT 打一个注解的形式会高很多。因为一阶段子事务流动提交是本地事务级别的，所以 Saga 模式不保障隔离性。提交之后就可能‘影响’其余分布式事务、或者被其余分布式事务所‘影响’。例如：其余分布式事务读取到了以后未实现分布式事务中子事务的更新，导致脏读；其余分布式事务更新了以后未实现分布式事务子事务更新过的字段，导致以后事物更新失落；还有不可反复读的场景等。所以 Saga 模式的应用也须要思考这些问题带来的‘影响’。个别 Saga 模式的应用场景有如下几个： ...

作者：王彬（阿里云解决方案架构师）、姚兰天（Rokid 技术专家）、聂大鹏（阿里云高级技术专家 ） 公司背景和业务Rokid 创建于2014年，是一家专一于人机交互技术的产品平台公司。Rokid 通过语音辨认、自然语言解决、计算机视觉、光学显示、芯片平台、硬件设计等多畛域钻研，将前沿的 Al 和 AR 技术与行业利用相结合，为不同垂直畛域的客户提供全栈式解决方案，无效晋升用户体验、助力企业增效、赋能公共安全，其 Al、AR 产品已在寰球八十余个国家和地区投入使用。 Rokid Air Pro 这款AR眼镜产品，为旅游景点，大型企业，国内科研机构都提供了服务反对。目前 Rokid 已和全国百余家博物馆和景区达成单干，给游客穿越时空，身临其境的不凡参观体验。 架构变革的必要性Rokid 在 AR 的钻研能够追溯到公司创建之初，在2012年 Google Glass 横空出世，其广大的设想空间深深震撼了 Rokid 开创团队。前面尽管因为应用的场景和高额的价格起因，Google Glass 并没有继续的火爆遍及。但能够预计在不久的未来，随着基础设施，生态利用的成熟，和人们继续晋升的对娱乐，办公的体验要求，AR 技术肯定会失去更宽泛的利用。 Rokid 在数字文化畛域，围绕展陈导览解决方案，次要造成了三维建图，场景创作，场景体验三个业务模块，每个模块都有不同的后盾平台撑持。 三维建图： 制作展陈导览的第一步是取景，通过设施获取场地的实在布景，而后通过算法解决，进行三维建模，之后能够通过创作器进行下一步的内容创作。场景创作： 在三维建模生成的视频流上创作，通过 Web3D 渲染引擎，将创作内容与场景紧密结合，联合硬件设施，在 AR 设施应用时，造成一体化的体验成果。场景体验： AR 设施在应用时，依据定位服务，锚定在场景中的地位，依据地位的不同会显示不同的空间内容，达到扩大事实场景的成果。整体的产品架构图如下： 三维建图，场景创作，场景体验三个场景都波及到了的图像处理，须要大量的 GPU 资源。其中三维建图属于离线工作，在构建展陈模型时，须要将整个展陈场合的视频内容进行预处理，是三个场景中耗费算力最大的局部；场景创作须要配合创作软件，GPU 资源次要来自开发机器；场景体验在设施实在运行时提供实时服务，次要性能是定位服务，对服务的实时性要求很高。 为了撑持 GPU 算力的需要，Rokid 在开发的初期就决定尽可能的应用云资源承载，充分利用云计算的红利。最后是购买了 ECS 的 GPU 机型，用于业务的开发和测试。这里很大的问题是在三维建图时，个别都会一次性采集展陈环境的所有场景材料，视频量微小，通过 ECS 串行解决须要工夫很长，一个 1 小时的视频材料，通过一台 ECS GPU 机器须要解决 3 小时左右。Rokid 做的第一步是并行化，通过拆分 CPU 和 GPU 解决逻辑和优化工作编排形式，尽可能的让能够并发解决的局部拉起更多的资源加大并发量，通过这一系列的优化，视频的解决工夫失去了不错的晋升。 ...

5 月 17 日阿里云峰会·常州站顺利召开，现场的【飞天公布时刻】上，阿里云智能资深产品总监陈起鲲就阿里云在 IaaS 层和 PaaS 层公布的新产品和新能力方面做了具体介绍，在阿里云智能新一代云计算体系下，进一步传递了阿里云更稳固、更平安、更高性能、更优老本的产品理念。以对象存储OSS和日志服务SLS为例： • 对象存储OSS归档存储类型再次降级，不仅有本地冗余，更有同城冗余，大大晋升了数据可靠性。此外，归档直读能力可实现归档存储类型的数据无需冻结即可间接拜访，存储老本最高可升高67%。 • 日志服务 SLS 兼容 Elasticsearch API，Kibana 图表无缝平移，性能是自建开源 ES 的十倍，百 TB 老本是自建开源 ES 的44%。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1222518?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

日前，在 ICT 中国·2023 高层论坛-云原生产业倒退论坛上，由阿里云容器服务提供技术支持的 “数禾科技”和“智联招聘” 两大案例以及阿里云云原生 AI 套件、云原生 FinOps 老本剖析套件两大产品技术计划，独特取得 2023 年度云原生利用实际先锋——云原生技术服务优良案例。 云原生是一种基于容器化、微服务等技术的利用开发和部署模式，它能够帮忙企业疾速构建和部署应用程序，进步利用的可靠性、弹性和可扩展性，让企业能够更加敏捷地响应市场需求，疾速上线新产品和服务，进步数字化转型的效率和速度，利用云原生技术架构和理念构建数字化新底座正在成为各行各业数字翻新的实际重点。 本次取得年度云原生利用优良案例奖的数禾科技和智联招聘，正是充分利用云原生架构的先进性，实现利用的疾速部署和更新，以响应业务的疾速变动，同时借助云原生架构的可扩展性和可靠性，无效保障了零碎在高并发和突发峰值状况下的稳定性。 数禾科技 AI 模型 Serverless 容器化数禾科技以大数据和技术为驱动，为金融机构提供高效的智能批发金融解决方案，服务银行、信托、生产金融公司、保险、小贷公司等持牌金融机构，业务涵盖消费信贷、小微企业信贷、场景分期等多个畛域，提供营销获客、危险防控、经营治理等服务。 随着业务的疾速倒退，风控模型对 AI 的需要也随之井喷。如何打造更麻利的 AI 计算服务，撑持业务高速增长，同时节俭资源老本，是摆在数禾科技背后的一大难题。 通过调研，数禾科技与阿里云云原生团队深度单干，联结打造全新的数禾 AI 推理服务平台，整个平台基于阿里云 Serverless 容器服务 ASK 构建，无需购买任何 K8s 节点即可间接部署推理服务容器利用，也无需对 K8s 集群进行节点保护和容量布局。同时，依据推理服务的实时申请量动态创建和销毁POD，资源老本大幅降落，服务的可用性也失去了很好的晋升。此外，通过 ASK Knative 服务，无效解决了数禾模型的灰度公布和多版本并存问题，大幅晋升了模型迭代上线的效率。 目前，该零碎已上线部署数百个 AI 模型服务，每天可能提供数亿次查问决策服务，ASK的实时弹性扩大能力帮忙数禾节约资源老本约 60%， 同时安稳地应答了诸多经营流动等突发峰值场景，整个云原生部署和公布零碎将数禾的均匀部署周期由之前的1天缩短至 0.5天， 无效减速了商业化利用的迭代过程，为金融业务的拓展增长提供了强有力的撑持。 智联招聘降级为云原生架构，开释 Serverless 技术红利智联招聘是中国人力资本生态价值链领导者，成立于1994年，累计服务超过1176万家企业客户和3.21亿职场人用户，月沉闷用户达到5127万。作为一家人力资本生态价值链平台，对于招聘业务的特点、法则有着粗浅的意识和思考，利用零碎也随同着业务倒退更新迭代，期间也经验了传统利用降级迟缓、架构臃肿、不能疾速迭代的阶段。 在2018年初，智联曾经开始了容器化革新，最终实现了业务的疾速迁徙和扩大等能力。在2021年智联持续深度思考，以本身业务特点登程联合云原生技术劣势，确定了Serverless容器混合云是零碎进一步演进的最佳技术计划。 智联招聘在业内率先实现全面容器化革新，并与阿里云联结设计“分布式云容器平台 ACK One +IDC 对立调度计划”。 在应答春招期间顶峰流量阶段，通过ACK One 对立集群治理，IDC 容器集群联合云上资源以及对立可观测性能力、秒级弹性能力，同时兼容线下调度器策略达到老本最优解，无效解决春招期间面临的零碎稳定性、资源量预估艰难、运维难度大等问题。 应用混合云的形式作为计算平台，不用因为业务突发增长的需要而一次性投入大量资金老本用于洽购服务器及裁减机柜。在公共云上能够做到随用随付，对于一些翻新业务想做技术调研十分不便，按量付费，大幅缩小了试错的老本。在效率方面，借助混合云架构深度集成，不便研发人员实现一站式研发、运维工作，整个继续集成能够做到分钟级。 智联招聘的云原生转型助力了公司的疾速改革，云原生架构、DevOps理念的实际，使得智联招聘的开发、测试、运维等工作可能更加协同和高效。此外，云原生架构的高可用性、灵便弹性、自动化个性，也使得智联招聘具备更好的容灾恢复能力和业务可靠性，保障业务在高峰期时可能疾速响应和扩大。 云原生技术创新，服务千行百业随着企业用云水平加深，企业面临云老本治理艰难的新问题；同时，Kubernetes 的复杂性是妨碍很多企业采纳容器的重要因素。基于此类痛点，阿里云公布了云原生  FinOps 老本剖析套件和云原生 AI 套件，通过数字化伎俩和智能化办法，帮忙企业实现老本可视化、可优化、可管制，并实现智能运维，疾速定位问题，晋升运维效率 。 这两款产品技术计划也取得 2023 年度云原生技术创新奖。 ...

6月11日，2023凋谢原子寰球开源峰会正式拉开帷幕。本届峰会以“开源赋能，普惠将来”为主题，设置了开幕式暨高峰论坛、20余场分论坛和开源成绩及重点项目展览。在峰会主论坛，凋谢原子开源基金会理事长孙文龙协各家单位独特倡导发动云原生工作委员会。 倡导发动云原生工作委员会云原生工作委员会，将通过构建开源、凋谢的云原生技术生态，摸索云原生技术创新，推动云原生技术在中国倒退，赋能千行百业数字化转型。 汇聚研产学政的中坚力量，开掘和孵化更多云原生方向的卓越我的项目，为推动云原生产业链的提高与翻新提供更多无效的反对。以卓越的云原生我的项目为引领，促成云原生技术在各行各业的广泛应用，推动数字化数字化转型的减速倒退，为行业和社会带来更多价值。致力于打造具备国内影响力的开源我的项目治理组织，致力为寰球云原生生态体系的倒退奉献更多中国的力量，推动云原生技术的寰球遍及与利用。开源是根底软件的基本。云+开源，将独特成为数字世界的根。阿里云认为数字世界的根底软件应该建设在开源之上，须要全行业共建、共享。因而，阿里云不仅踊跃拥抱开源，也被动回馈开源，引领开源。 ACK Distro 和云原生利用脚手架两大开源我的项目达成捐献动向此次峰会，阿里云不仅参加倡导发动云原生工作委员会，也和基金会就 ACK Distro 和云原生利用脚手架两大开源我的项目达成捐献动向。 ACK Distro 作为异构 IaaS 环境推出的 Kubernetes 发行版，是为了更好的满足客户在数据中心部署 Kubernetes 集群的需要， 让企业在自有基础设施上也能享有和阿里云容器服务ACK 一样平安、牢靠的企业级能力。其外围组件经验了数万内部客户的大规模生产利用，具备业界当先的安全性和可靠性，反对多种芯片体系架构和异构硬件环境，确保 ACK Distro 可能运行在多样化的基础设施上，并充沛开掘这些基础设施的后劲，并具备安全可靠、麻利易用、统一体验、多样兼容等劣势。 通过 ACK Distro，企业在决定将业务迁徙至私有云前，就能够在自有基础设施上享受到和阿里云容器服务 ACK 一样的平安、牢靠的企业级 Kubernetes 集群，并通过阿里云分布式容器云平台 ACK One 体验对立的云原生能力。具备肯定技术能力的企业，也能够间接应用 ACK Distro 麻利易用的集群自动化治理和利用打包交付工具，自主创立云原生利用集群。 云原生利用脚手架是一款基于 Spring Initializr 我的项目根底之上，反对多种工程架构、提供代码示例片段、组件更丰盛、生态更凋谢的一款脚手架。其致力于在当下云原生时代，为宽广开发者提供更简略、更高效的我的项目构建体验。 云原生利用脚手架基于 Spring 开源的 intializr 我的项目进行构建。相比于 start.spring.io 脚手架，云原生利用脚手架不仅能够帮忙用户治理依赖，其更为重要的是帮忙用户生成测试或者能够间接应用的代码片段，可让用户创立完工程就可测试，测试完就能够基于示例代码进行我的项目开发。因而，基于云原生利用脚手架构建我的项目仅需实现：新建工程和运行测试即可，大大提高新建工程的效率。 阿里云云原生继续奉献开源目前，阿里云的开源次要涵盖云原生、操作系统、大数据&AI、数据库四大畛域，是Apache Dubbo、Apache RocketMQ、KubeVela、Flink等代表性开源我的项目的发起者，也是Linux、MySQL、Redis、JVM、Kubernetes、Containerd、Envoy 等出名开源我的项目的外围贡献者和维护者。在云原生畛域，阿里云始终以来继续投入开源建设，推动技术普惠，减速行业倒退。 在分布式应用架构上， 阿里云开源了残缺的分布式框架和组件，帮忙开发者解决了分布式应用的落地难题。 例如，在流量入口层面开源了云原生网关 Higress，高效解决了网关的性能、平安和稳定性难题，在服务集群层面，Apache Dubbo 和 Spring Cloud Alibaba 曾经被宽泛应用，别离解决了服务和服务之间、服务和云产品之间的互通问题；Apache RocketMQ 则满足了分布式应用架构的异步告诉、零碎间解耦、削峰填谷、缓存同步和实时计算等高频需要；Seata 提供的分布式事务能力，解决了性能差、数据一致性不够、或侵入性大的业内痛点；Nacos 作为市场占有率极高的注册配置计划，将来则极有可能作为管制面来帮忙用户晋升微服务的管控体验；Serverless Devs 的开源，则为开发者提供了构建分布式应用的另一种开发范式。 ...

云原生月度动静 云原生是企业数字翻新的最短门路。 《阿里云云原生每月动静》，从趋势热点、产品新性能、服务客户、开源与开发者动静等方面，为企业提供数字化的门路与指南。 本栏目每月更新。 01 趋势热点 Apache RocketMQ 入选可信开源我的项目星云象限领导型象限 日前，由中国信通院主办的 OSCAR 开源生态建设论坛在北京胜利召开。本次论坛，中国信通院公布了可信开源我的项目星云象限。其中，Apache RocketMQ 凭借团队在开源畛域的继续投入与卓越的产品力，入选星云象限领导型象限。 相干文章：最高等级！Apache RocketMQ 入选可信开源我的项目星云象限领导型象限 多层网关已成过来，网关多合一成潮流，Higress 正式公布 1.0 版本 Higress 是标准化、高集成、易扩大、热更新的云原生网关，无缝集成容器和微服务生态，是云原生时代的默认选项。以 Kubernetes Ingress 网关为契机带来了流量网关与微服务网关交融的可能性，联合阿里外部实际积淀 Higress 实现了流量网关 + 微服务网关 + 平安网关三合一的高集成能力，同时深度集成了 Dubbo、Nacos、Sentinel 等，可能帮忙用户极大的升高网关的部署及运维老本，而且能力不打折。 相干文章：多层网关已成过来，网关多合一成潮流，网关革新正过后丨Higress 正式公布 1.0 版本 全新上线函数计算一键部署通义千问预体验流动炽热进行中 AIGC 浪潮已来，从文字生成到图片生成，AIGC 的创造力让人惊叹，更多人开始摸索如何应用 AI 进步生产效率，激发更多创作潜能，然而在理论利用中，AI 技术的高门槛依然让很多人望而生畏，一般开发者或者没有太多编程教训的人是否也能简略、疾速部署一个 AI 模型利用，享受到科技倒退带来的红利呢？阿里云全新上线 Serverless 一键部署通义千问预体验、文生图、图生图、图生文、文生文 5 个经典 AI 场景，简直 0 技术门槛部署 AI 模型利用，让创意更快产生。 链接：https://developer.aliyun.com/topic/aigc_fc 相干文章：通义千问预体验，如何让 AI 模型利用“奔跑”在函数计算上？ 累计下载破 10 万，阿里云 ACR 制品核心 5 月最受欢迎镜像排行榜出炉 ...

作者：之浩、展逸 企业在 Kubernetes 上运行 AI、大数据利用已成支流，资源弹性和开发运维效率失去显著晋升的同时，计算存储拆散架构也带来了挑战：网络提早高、网络费用贵、存储服务带宽有余等。 以 AI 训练、基因计算、工业仿真等高性能计算场景为例，须要在短时间内并发执行海量计算，多计算实例共享拜访文件系统的同一数据源。很多企业应用阿里云文件存储 NAS 或 CPFS 服务，挂载到阿里云容器服务 ACK 运行的计算工作上，实现数千台计算节点的高性能共享拜访。 然而，随着算力规模和性能晋升、以及模型规模和工作负载复杂度的减少，在云原生的机器学习和大数据场景下，高性能计算对并行文件系统的数据拜访性能和灵活性要求也越来越高。 如何能更好地为容器化计算引擎提供弹性和极速的体验，成为了存储的新挑战。 为此，咱们推出了弹性文件客户端 EFC（Elastic File Client），基于阿里云文件存储服务的高扩展性、原生 POSIX 接口和高性能目录树结构，打造云原生存储系统。并且，EFC 与云原生数据编排和减速零碎 Fluid 联合，实现数据集的可见性、弹性伸缩、数据迁徙、计算减速等，为云原生的 AI、大数据利用共享拜访文件存储提供了牢靠、高效、高性能的解决方案。 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 与大数据利用提供一层高效便捷的数据抽象，并围绕形象后的数据提供以下外围性能： 面向利用的数据集对立形象 ...

作者：元毅、坤仑 数禾科技 AI 模型服务基于云原生架构，为不同业务环节提供智能决策反对。随着业务的疾速倒退，摆在数禾背后的难题是撑持模型计算的底层利用资源无奈依据申请量来调整机器资源反对运算能力。同时，随着模型在线推理服务数量的减少，数禾的模型服务也变得越来越宏大、臃肿，难以治理。这种情况不仅导致了资源节约，还减少了保护和降级的老本。 为了解决这些“顽疾”，数禾科技采纳阿里云 ASK 部署线上模型，无需 K8s 节点治理，依据实时流量动静应用 POD，资源老本节俭 60%；通过 ASK Knative 服务，解决了数禾模型的灰度公布和多版本并存问题；得益于ASK 主动伸缩和缩容到 0 的劣势，升高运行老本，大幅晋升服务可用性。 目前，该零碎已上线部署 500+AI 模型服务，每天可能提供上亿次查问决策服务，具备有限横向扩大的能力。同时，数禾科技 AI 模型服务反对主动调整容量，满足不同业务压力下的需要，从而保障业务的稳固运行。不仅如此，采纳云原生架构计划，均匀部署周期由之前的1天缩短至 0.5天，大幅晋升了研发迭代效率，从而减速商业化利用的过程，为金融业务提供新的增长能源。 对于 Serverless Kubernetes（ASK）Kubernetes（K8s）作为一个开源容器编排零碎，被宽泛使用于云原生利用的开发与治理。其劣势在于升高运维老本，进步运维效率，造成了以 K8s 为外围的云原生生态。然而应用 K8s 经常须要用户面对的问题较多，例如资源布局、容量布局、Node 与 Pod 的亲和关系、容器网络布局、节点生命周期治理、操作系统版本、容器运行时版本兼容性等，这些问题显然不是用户所心愿关怀的，用户冀望做的事件是专一在本身的业务逻辑，尽可能不关怀这些基础设施。Serverless 的核心理念在于让开发者更聚焦业务逻辑，缩小对基础设施的关注。因而咱们将 K8s 复杂性下沉，提供 Serverless Kubernetes 的产品能力。 那么 Serverless Kubernetes 有哪些劣势呢？次要包含以下三个方面：免运维、主动弹性、按需付费。 首先，Serverless Kubernetes 组件全托管免运维，反对主动降级 k8s 版本。其次，该产品具备极致弹性能力。能够依据业务需要，主动弹性、秒级扩容，从而在满足业务增长时主动容量布局。最初，应用 Serverless Kubernetes 的用户，只需依据理论使用量按需计费。除此之外，ASK 还提供了新增的 U 实例规格反对，对立反对多款处理器，相比上一代主售实例提价高达 40%。 为了让更多用户体验最佳实际，咱们顺便将其打造成了一个体验场景，配合热门开源的 AI 我的项目 Stable Diffusion，用户能够通过实在的云上环境，轻松体验容器化部署具备企业级弹性能力的 AI 模型。 在 ASK 中部署 Stable Diffusion随着生成型 AI 技术的能力晋升，越来越多的注意力放在了通过 AI 模型晋升研发效率上。作为 AIGC（AI Generated Content）畛域的出名我的项目 Stable Diffusion，能够帮忙用户疾速、精确地生成想要的场景及图片。不过以后间接在 K8s 应用 Stable Diffusion 面临如下问题： ...

作者：乔普、申信 介绍在云原生环境中，集群提供者经常将不同类型的工作负载部署在同一个集群中，利用不同业务的不同峰值成果，实现资源分时复用，防止资源节约。然而，不同类型负载之间混合部署经常会导致资源竞争和互相烦扰。最为典型的场景便是在线和离线负载的混合部署。当离线较多的占用计算资源时，在线负载的响应工夫就会受到影响；当在线长时间较多的占用计算资源时，离线负载的工作实现工夫不能失去保障。这种景象属于 Noisy Neighbor 问题。 依据混合部署的水平、资源类型的不同，解决该问题有许多不同的思路。Quota 治理可从整个集群维度限度负载的资源使用量，Koordinator 在这方面提供了多层次弹性 Quota 治理性能 [ 1] 。单机维度上看，CPU、内存、磁盘 IO，网络资源都有可能被不同负载共享。Koordinator 在 CPU、内存上曾经提供了一些资源隔离和保障的能力，磁盘 IO 和网络资源方面的相干能力正在建设中。 本文次要介绍当不同类型工作负载混合部署在同一个节点上时，Koordinator 如何帮忙负载之间（在线和在线、在线和离线）协同地共享 CPU 资源。 问题形容CPU 资源 Noisy Neighbor 的实质是不同的负载之间无协同地共享 CPU 资源。 Kubernetes 默认的资源模型利用 cgroup（cfs quota） 从 CPU 工夫使用量上来限度不同负载对于 CPU 资源的拜访。这种状况下，一些负载就可能会被操作系统调度器切换所在的 CPU 核。因为不同 CPU 核查不同物理地位的内存拜访工夫不同，切换大概率会导致更长的内存拜访工夫，从而影响负载性能。在 NUMA 架构中，SMT 线程（逻辑核）共享物理核的执行单元和 L2 缓存。当同一个物理核中有多种工作负载时，不同工作负载间就会产生资源争抢，导致负载性能降落。Kubernetes 在单机侧提供了拓扑管理器和 CPU 管理器来尝试解决上述问题。然而，该性能只有在 Pod 曾经调度到机器上之后才会尝试失效。这样就有可能导致 Pod 会被调度到 CPU 资源满足然而 CPU 拓扑不满足负载要求的状况。 解决方案面向利用的 CPU 编排 QoS 语义针对上述问题和有余，Koordinator 设计了面向利用的 QoS 语义和 CPU 编排协定，如下图所示。 ...

作者：寒斜 AIGC 继续火爆寰球，越来越多的场景开始接入并体现不凡的价值。其中利用宽泛的场景之一就是智能常识问答，它扭转了人们学习的形式，从浏览式到问答式，让常识的获取更加精准无效。开源软件领有着宽泛的求知群体，AIGC+ 社区的联合是学习型社区将来演进方向上的一个新鲜的尝试，明天咱们联合 RocketMQ 学习社区的实际来跟大家聊聊构建该类场景的教训以及遇到的一些挑战。 学习社区的新范式学习社区自身的诉求是心愿可能疾速流传常识、晋升影响力，而社区开发者则是心愿更快、更及时、更精确的取得专业知识。 以往从社区获取常识的形式有两种： 翻阅社区的文档和社区提供的源代码进行自主学习；和社区的技术大牛进行交换，获取答案。两种形式都存在肯定的问题， 第一种自学的老本较高，为了更好的了解相干的基本概念，须要依据疾速入门文档一步一步操作，而后持续深刻理解其余的知识点，想要获取更关注的常识老本较高，而且因个体了解的差别，社区流传常识的成果也不肯定可能令人满意；第二种尽管能够精确取得想要的常识，对个体常识的把握也好于第一种，然而社区专家的解答往往不是实时的，所以不论是对于开发者的学习，还是对社区常识的流传来说效率都不高。 当初有了第三种形式：基于大语言模型的专业知识问答，社区开发者能够随时随地进行专业知识发问，享受 24 小时专家服务， 对于学习社区而言，流传本身常识的效率也变得更高了。 专有语料库的智能问答技术基本原理 如图所示， 专有语料库的智能问答零碎分为两个局部： 语料库的录入，管理员将业余的社区材料进行上传，智能问答零碎会对文档进行切片，而后通过 embedding 算法将其转化为向量数据，存储下来期待检索；问题解答，用户输出的问题通过向量转化后通过近似搜索算法跟向量数据库的内容做比对，失去近似值答案后，联合提醒词模版以及用户问题一起输出给大语言模型，大语言模型做演绎总结后返回给用户。所以零碎的残缺性能既蕴含间接的答案输入（依据大模型能力后果可能不精确，次要是“幻答”），也蕴含依据向量近似值检索进去的原文列表。后者作为辅证，帮忙学习者判断答案的正确与否。生产的挑战相较于技术计划的论证，真正想把智能问答能力公布到生产有着十分多的挑战，上面来跟大家独特探讨一下。 平安平安始终是 AIGC 类服务最须要关怀的问题，没有之一。次要蕴含以下几点： 数据安全内容平安，蕴含输入和输入系统安全数据安全次要是指应用大模型服务，尤其是境外服务会导致数据跨境，这是不能被容许的； 内容平安次要是用户输出以及后果输入不能蕴含涉黄涉恐的内容； 系统安全则是攻击者能够通过提醒词诱导导致一些机密信息的泄露。以上的平安问题都是须要被重大关切。 平安问题解决方案数据安全的解法就是应用齐全合规的大模型服务或者齐全托管开源的模型实现 100% 私有化，RocketMQ 学习社区是基于开源的 chatlm6b 问答零碎计划并且应用阿里云多款产品组合，从而实现模型服务和业务逻辑一体化的 AI 利用。 chatlm6b 问答零碎计划： https://github.com/imClumsyPanda/langchain-ChatGLM 内容平安，针对输出内容做平安算法过滤， 阿里云的绿网服务可能很好的撑持这一点，躲避使用者输出不合规的问题，输入后果的约束则是通过提醒词工程实现-仅容许答复畛域内的问题。 系统安全，应答提醒词注入(PI)的危险，则能够思考采纳启发式办法，在歹意输出达到前将其过滤或者应用专用 LLM 来剖析传入的提醒并辨认潜在的攻打。 相干的解决方案能够参考：https://rebuff.ai/ 服务高可用社区的智能问答零碎上线之后，必然要面对更多的拜访申请。模型推理自身无奈并行，象征进入模型推理的申请须要排队解决，如何疾速拉起更多的模型服务，应答并发申请，是线上生产面临的事实问题；此外如何应答单点服务故障以及如何对数据进行容灾备份，都是生产服务必须思考的问题。 老本/效率/体验的均衡如何更快的交付业务服务，如何实现体验和老本的均衡，也是摆在理论生产中的问题。 如果你抉择了模型自托管，有两种应用 GPU 的计划，第一种是本人买卡搭建服务，第二种是租赁云厂商的服务器。第一种须要很强的技术背景，并且须要解决好服务的高可用，第二种则须要对 GPU 的耗费进行精打细算，任何一家云厂商提供的 GPU 服务费用都不低。除此之外随着业务交付工夫的邻近，解决非业务的技术问题也会减少业务交付的危险，业务研发投入的缩小也会影响服务的应用体验。 一句话总结就是，实现老本、效率、体验三者的均衡绝非易事。 RocketMQ 学习社区的摸索RocketMQ 学习社区的构建，采纳的是阿里云 Serverless 架构，实现百分之百的私有化，并且尽最大可能得解决平安问题。通过 Serverless 实现老本/效率/体验的均衡以及服务的高可用。此外在网络层面应用了更平安的 vpn 内网服务，更大程度的杜绝零碎要害信息泄露，同时还保留了切换商业模型服务的能力，不便在后续切换时取得更加精准的问题答案。 RocketMQ 学习社区 Serverless 架构计划 业余平安团队平安水位评估后果 ...

作者：褚杏娟 前言： 云简直给每项基础设施都带来了冲击，网关也不例外。近期，云原生网关概念也越来越被大家热议。那么，到底云原生网关须要具备哪些特点？支流网关产品如何适应云原生？网关规范对立是否必要？云原生网关将来如何倒退？ 此前，Higress 发起人、阿里云微服务引擎负责人李艳林（彦林）受邀与企业用户代表一起聊聊网关的演进历程。 本文依据李艳林（彦林）答复摘取整顿而成。 如何应答业务需要？首先，请针对 UU 跑腿的一个场景来提出本人的解决方案。 UU 跑腿曾经是云原生架构了，但作为一家配送平台，UU 跑腿有大量的客户须要通过网关接入平台，同时也有大量的后端服务须要接入网关，因而确保网关的稳定性和可靠性是十分重要的，这样能力保障业务的持续性和客户的满意度。在这样的需要背景下，Higress 会用怎么的形式来帮忙企业达成指标呢？ 李艳林（彦林）： 我理解到 UU 跑腿业务是线上线下联合的。因而，相比于个别的纯线上业务，对于稳定性的要求会更高一些，这是能够了解的。随着整个业务逐步上云，行业对可靠性的要求会越来越高，特地是网关作为整个公司的入口，如果呈现问题就会带来十分大的损失。咱们在做 Higress 的过程中也是更加关注稳定性。我想分享一些想法。 首先，咱们的架构和内核应用了 Envoy 和 Istio，它们的益处是将数据面和管制面解 耦 。 这意味着，如果管制面呈现问题，数据面不会受到影响。这种拆散无效地防止了管制面的平安和稳定性问题对数据面的影响。在内核上，咱们应用了一种称为 WASM 的沙箱扩大机制。如果扩大逻辑代码呈现问题，WASM 沙箱会做很好的隔离，不会影响整个网关的主业务。这种设计能够在肯定水平上管制整个零碎的爆炸半径。 其次，对于 UU 跑腿和阿里巴巴的 IoT 设施，因为在线上线下联合的过程中，这些设施对稳定性有更高的要求，特地是在多端状况下。如果在个别状况上来更新规定、路由或证书插件，连贯可能会产生抖动。但因为 Higress 采纳了 Envoy 内核，所有规定变更都是热更新的，因而对长连贯都是十分敌对的，不会抖动。这将显著进步在线业务的连续性和稳定性。 最初，简略介绍一下 Higress。尽管咱们在 2022 年 7 月的云栖大会上开源了它，但在阿里云外部，咱们曾经孵化云原生网关大略三到四年了。最后，它是为了解决阿里电商和蚂蚁之间的互通问题，让 RPC 能够间接调用并应用 gRPC 协定。通过几年的验证，包含在双十一等大促场景和成千上万家企业的验证，它当初十分稳固。在这些根底上，Higress 次要关注一些推空爱护和其余细节方面的性能。 企业须要怎么的网关？除了方才提到的，当初企业对网关产品还有哪些要求？当初网关产品曾经解决了哪些问题？还有哪些需要未被满足？ 李艳林（彦林）： 这个话题很有意思，它实际上关乎人们对整个网关将来的定位和趋势判断。从阿里云的角度来看，咱们认为客户最关注的是网关的平安问题。事实上，阿里巴巴最后开发网关也是为了解决平安问题，因为咱们心愿可能通过一个对立的入口来解决平安问题。 以前我在内部也遇到很多客户的利用因为一些问题而被攻打，导致整个危险极大。因而，网关的第一个重要作用就是建设对立的平安防线。Higress 在这方面提供了一些 WAF 插件、认证插件，以及黑白名单机制，能够为企业数字化降级过程中保驾护航。 我认为，无论是国内还是海内，平安都是网关的首要问题。尽管国内许多人关注高可用性，但海内很多人更加重视安全性，它们都在某些私有云上运行，并且十分重视利用平安和基础设施平安。 其次，我想谈谈高可用和稳定性。其实，大家最关怀的问题可能是咱们的网关稳定性如何、是否帮忙咱们解决高可用问题。在这方面，Higress 做了一个深度集成，应用阿里云的 Sentinel，在入口提供整体的降级防护能力，以避免业务雪崩。 往年咱们搞了很屡次大促、海内业务等爆发性增长，当流量达到峰值时，建设防护线以避免异样流量打垮整个零碎十分重要。特地是对于像 UU 跑腿这样有顶峰值场景的业务，保障业务的整体意义更加重大。 过来两年，我在做海内网关竞品剖析时发现，最早的架构可能是 SLB+ECS（单体利用架构），包含云服务都是这样的架构。随着微服务的衰亡，人们开始应用 API 网关等工具来治理微服务，并将其集成到服务网格体系中。在 Serverless 时代，每个畛域都有独立的入口，并且经营数据是独立统计的。这种架构演进也带来了问题。例如，咱们往年做了一个标杆客户，须要挂三层网关，相当于在单体到微服务、再到 Kubernetes 的过程中增加了网关层，导致整个拜访链路多层网关，最终影响 RT 和运维效率。 ...

本文介绍告警对立治理的最佳实际，以帮忙企业更好地解决异构监控零碎所带来的挑战和问题。 背景信息在云原生时代，企业IT基础设施的规模越来越大，越来越多的零碎和服务被部署在云环境中。为了监控这些简单的IT环境，企业通常会抉择应用异构监控零碎，例如Prometheus、Grafana、Zabbix等，以获取更全面的监控数据，以便更好地理解其IT基础设施的运行状况和性能体现。 然而，这种异构监控零碎也带来了一些问题，其中最显着的是告警信息的扩散。因为不同的监控零碎可能会产生不同的告警信息，这些信息可能会扩散在各个系统中，导致企业很难全面理解其IT零碎的告警情况。这使得响应告警变得更加艰难，同时也减少了人工治理的复杂性和工作量。 为了解决这些问题，企业须要一种更加对立和集中的告警治理计划，以确保告警信息可能及时达到正确的人员，以便他们可能疾速采取必要的措施来应答潜在的问题。 告警治理的痛点场景一：企业迁徙上云后，云上产品的告警不对立 在一个典型的云原生业务利用部署架构中，通常会应用到如下产品 ACK、ECS、RDS，利用通过Kubernetes部署在阿里云的ECS上并拜访云上的RDS。在这个架构中通常会用到如下监控产品来对系统进行监控。 通过CloudMonitor对阿里云基础设施ECS和RDS进行监控，当资源出现异常时进行告警。通过Prometheus对Kubernetes以及部署在kubernetes上的Pod进行监控，当Kubernetes出现异常时进行告警。通过ARMS对部署在Kubernetes上的利用进行监控，包含利用间接的调用链。当利用异样时进行告警。通过SLS对利用产生的日志进行监控，当日志出现异常时进行告警。在这样一个场景下因为用到了多个云产品对整个零碎进行监控会导致使用者须要在多个产品上反复配置联系人、告诉形式、值班等运维配置。且不同零碎之间的告警无奈产生有机联合，当一个问题呈现时不能疾速关联不同告警零碎中的相干告警。 场景二：多云、混合云架构下，异构监控零碎告警不对立 当企业的利用部署在多云环境或混合云环境下时，监控零碎产生的告警可能会更加扩散和简单，给企业的运维工作带来很大的挑战。因为不同的云平台和公有云架构之间的差别，监控数据的采集和解决形式也可能不同，因而，不同监控零碎产生的告警信息也可能体现出差异化，这会带来一系列的问题。 首先，不同监控零碎产生的告警信息扩散在不同的中央，运维人员须要消耗更多的工夫和精力去解决这些信息。其次，不同零碎产生的告警信息难以对立进行治理和剖析，使得问题的诊断和解决更加艰难。此外，因为不同零碎的告警信息可能存在反复或抵触，治理和解决这些信息也会变得更加简单。 场景三：自研监控零碎、自定义事件告警接入在利用开发运维过程中，随着零碎规模的扩充和复杂度的进步，各个角落中的胶水代码逐步增多。这些代码尽管是连贯不同模块和零碎的重要纽带，但一旦呈现问题，因为扩散在不同的中央，很难立刻发现和解决。这就使得企业难以保证系统的高可用性和稳定性。如何灵便的低成本的接入这部分代码产生的告警也成为企业应用运维的痛点之一。 对立告警治理在构建对立告警治理平台过程中，不同的监控系统对告警定义、解决流程都不一样，往往会存在上面问题： 不同零碎产生的告警格局不同，接入老本高。不同零碎间的告警接入后因为格局不对立，难以对立解决逻辑。不同告警零碎对于告警等级的定义不同。不同告警零碎对于告警主动复原的解决形式不同。有的告警零碎反对主动复原，有的不反对。ARMS告警治理 [ 1] 设计的集成、事件处理流、告诉策略等性能专门针对告警对立治理的场景，解决了对立治理过程中遇到的诸多问题。 ARMS告警治理如何接入不同格局的告警？传统告警通常包含如下一些内容，这种结构化的告警通常只实用于繁多告警源。当多个告警源的数据汇总到一起后通常会导致数据结构的抵触。因而ARMS应用了半结构化的数据来存储告警。 阿里云监控告警数据格式： Zabbix告警数据格式： Nagios告警数据格式： 半结构化的告警数据结构[ { "labels": { "alertname": "<requiredAlertNames>", "<labelnames>": "<labelvalues>", ... }, "annotations": { "<labelnames>": "<labelvalues>", }, "startsAt": "<rfc3339>", "endsAt": "<rfc3339>", "generatorURL": "<generator_url>" }, ...]labels（标签）：告警元数据，一组标签惟一标识一个事件，所有标签均雷同的事件为同一个事件，反复上报会进行合并，例如：alertname: 告警名称。annotations（正文）：正文是告警事件的附加形容，正文不属于元数据。例如：message: 告警内容。不同工夫点产生的同一个事件他们的标签是雷同的，然而正文能够是不同的。比方告警内容的正文可能不同，例如：“主机i-12b3ac3* CPU使用率继续三分钟大于75%，以后值82%”。startsAt（告警开始工夫）：告警事件开始工夫。endsAt（告警完结工夫）：告警事件完结工夫。generatorUrl（事件URL地址）：告警事件URL地址。如上述代码所示，ARMS参考开源Prometheus告警定义 [ 2] ，应用一个半结构化的数据结构来形容告警。通过高度可扩大的键值对来形容告警，这样就能够非常灵活的对告警内容进行扩大从而接入不同的数据源产生的告警。 任意JSON格局的自定义告警接入能力ARMS告警提供了任意一种JSON格局接入的能力（自定义集成 [ 3] ）。只有告警数据结构满足JSON格局就能接入。如下图所示，自定义告警接入须要先将告警内的JSON数据上传到ARMS告警核心后，通过页面编辑字段映射的形式将告警内容中的要害信息映射到ARMS告警数据结构中。 ARMS定义了如alertname等关键字段，对于更多的扩大字段，用户能够在集成中通过新增扩大字段的形式进行配置。所有的扩大字段都能够使用到前面的告警解决逻辑中。以下图为例将原始告警报文中的hostname字段映射到扩大的hostname字段，hostip字段映射到扩大的hostip字段。 罕用监控工具告警快捷接入能力ARMS默认提供了云上云下多种监控零碎的告警接入能力，能够参考集成概述 [ 4] 进行疾速接入。 ARMS告警治理如何对立告警等级？ARMS中将告警分为P1、P2、P3、P4四个等级。通过配置映射表，将多个不同类型的等级归一到P1-P4四个等级。如下图所示，将L1、Critical、重大告警这三种不同形容的告警等级都映射为P1告警，这样就能够对立不同零碎中对于告警等级的不同定义。 ARMS告警治理对于不同格局的告警如何对立解决逻辑？因为ARMS告警采纳了半结构化的数据结构，能够通过标签来对立告警的解决逻辑。通常咱们须要至多2个标签来对立告警的解决逻辑。一个标签用来决定这个告警应该告诉给哪些人，比方业务标签（service,biz）。另一个标签用来决定这个告警利用通过什么样的形式进行告诉和降级。如下表所示，通常应用告警等级（severity）来定义告警解决的SLA。 ...

作者：木吴 阿里云智能高级技术专家 业务的负载往往不是变化无穷的，而是随着工夫出现肯定的高低稳定。传统的利用构建形式个别是备足充沛的资源以保障业务可用性，造成资源利用率不高的景象。随着容器技术的遍及，利用能够通过弹性伸缩或者利用混部的形式来晋升资源利用率，但因为资源管理的复杂度，难以在业务可用性和资源利用率上获得较好的均衡。 Serverless 平台的呈现，将资源管理的责任从用户侧转移到平台侧。这种责任转移可能让用户专一在业务开发上，而平台自身利用其资源规模和负载多样性的劣势，专一在资源利用率的晋升上。 业务应用 Serverless 平台可能大幅晋升资源利用率，实现降本提效的成果。 利用率的问题业务的负载是动态变化的，而资源的弹性往往跟不上负载变动，所以会呈现资源利用率不高的状况。为了简化部署运维的复杂度，个别利用在部署时往往指定固定的实例数，此时资源和负载的变动如下图所示： 能够看到，有大量的工夫存在资源的节约，按日均匀资源利用率来计算不到 30%。而资源利用率间接关系到老本，如果资源利用率晋升一倍，老本就能降落 50%。最现实的状况是资源齐全贴合负载，如下图所示： 但事实的状况是很难做到，起因有两个： 负载的变动能够是很快的，然而资源的创立却须要更长的工夫资源的弹性成功率不是 100%，出于稳定性思考须要预留资源 Buffer因而，理论的资源情况是介于上述两种状况之间，业务开发者能够通过一些伎俩来晋升资源利用率，使其迫近 100%。接下来咱们看一下一些罕用的晋升资源利用率的伎俩。 晋升利用率：弹性伸缩容器化的利用通常会应用弹性伸缩来晋升资源利用率。最典型的是应用 K8s 的 HPA 策略 [ 1] ，设置一个 CPU 利用率阈值，当容器的 CPU 利用率超过阈值时主动减少容器，低于阈值时主动缩小容器。应用 HPA 后业务负载和资源变动状况如下： 能够看到，在新增的资源创立实现之前，已有的资源要留有一些余量以缓冲负载的回升。在下面这种阶梯形的资源变动状况下利用率是多少呢？让咱们来定量地剖析一下。 能够看到，须要预留的资源和负载的上升幅度以及扩容工夫无关。假如在扩容工夫 T 内，负载从 A 回升到 B，理论须要的资源从 xA 扩容到 xB。为了在资源创立实现之前可能接住负载，当负载为 A 时须要有的资源量是 xB，则资源利用率是负载增长斜率和扩容工夫的一个函数。当负载的增长比例 K 确定时，资源利用率 Util 是一个对于扩容工夫 T 的反向函数，扩容工夫越短，则资源利用率越高。 例如在负载每分钟减少 100% 的状况下，资源利用率和扩容工夫的关系。 当扩容工夫为 1 分钟时，资源利用率为 50%当扩容工夫为 5 分钟时，资源利用率为 17%扩容工夫是晋升资源利用率的要害。从负载开始回升，到新容器创立实现，整个扩容工夫能够分解成如下图所示： 反应时间<!----> 指标采集工夫：例如 CPU 指标的采集须要取一段时间内的 CPU 均匀利用率决策工夫：例如 CPU 指标的采集须要间断 N 次大于阈值才会触发扩容<!----> ...

5  月 17 日，2023 阿里云峰会·常州站上，阿里云正式公布第八代企业级计算实例 g8a 以及性能增强性实例 g8ae。两款实例搭载第四代  AMD EPYC 处理器，标配阿里云 eRDMA 大规模减速能力，网络延时低至 8 微秒。其中，g8a 综合性价比均匀晋升 15%  以上，g8ae 算力最高晋升 55%，在 AI 推理与训练、深度学习、高性能数据库等利用场景性能晋升显著。作为企业级实例，搭载第四代 AMD EPYC（霄龙）处理器的 g8a 和 g8ae 两款实例，得益于阿里云自研的“飞天+CIPU”架构，在计算、存储、网络、平安等畛域的能力全面晋升，在云上提供稳固、强劲、平安的算力，助力用户在云上减速业务翻新。· 网络方面，标配阿里云 eRDMA 大规模减速能力，网络延时最低 8 微秒，极大晋升用户业务集群之间的网络拜访性能。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1215893%20?utm_content=g... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介： 阿里云挪动研发平台EMAS & 低代码开发平台魔笔 5月产品动静已更新：EMAS Serverless SDK uploadFile反对上传文件到指定目录；挪动推送公布Android SDK 3.8.6版本；魔笔新增并优化多种组件物料及功能模块，教学体系新增 Datagrid 实战指南等。内容摘要EMAS Serverless SDK uploadFile反对上传文件到指定目录挪动推送反对小米厂商海内推送挪动推送公布Android SDK 3.8.6版本魔笔新增并优化多种组件物料及功能模块魔笔教学体系新增 Datagrid 实战指南产品动静 产品体验EMAS体验：提供音讯推送、挪动测试、挪动监控、热修复、域名解析等收费应用阈值，点击“立刻开明”即可体验EMAS！EMAS帮忙文档：https://help.aliyun.com/product/434086.html 魔笔体验：提供模型驱动、扩大灵便的低代码开发平台，点击“申请应用”体验魔笔！魔笔训练营：https://www.mobiapp.cloud/link/academy 技术交换欢送退出钉钉技术交换群：EMAS技术交换：35248489 魔笔技术交换：32946835

每天，咱们都会遇到一些没有答案的问题，比方：宇宙中有多少颗行星？ 这个问题没有最终答案，毕竟，仅仅是咱们所在的银河系就有60 亿颗类地行星。 而在阿里云智能资深产品总监、阿里云存储产品负责人 Alex Chen看来，明天人类生产生存中所产生的数据就像浩瀚的宇宙：数据量大，且一直收缩；暗藏着诸多难以预感的危险；同样受到引力的解放。而每一家企业都像一艘宇宙飞船，当飞翔在浩瀚的宇宙中时，须要卓有成效的措施去应答一直疾速收缩的数据、屏蔽各种危险和抗衡各种劫难、解脱数据引力解放实现宇宙速度以及发现数据内暗藏的价值。 一、冷热数据分层、施展规模效应，帮忙客户降本这是一个数据爆炸性增长的年代。据 IDC 公布的报告显示，中国数据量规模将从 2022 年的 23.88ZB 增长至 2027 年的 76.6ZB，年均增长速度 CAGR 达到 26.3%。如果对如此宏大的数据进行分类的话，能够分为须要实时拜访的在线数据和不须要实时拜访的离线数据（比方归档类型的磁带库）。 目前，阿里云对象存储 OSS 上曾经存储了数十 EB 的数据，网盘与相册服务 PDS 为夸克、UC、阿里云盘、中国移动云盘等产品提供数据存储服务，累计服务 8 亿终端用户。为了更好地帮忙客户治理这些数据，对象存储 OSS 提供了 5 种存储类型。在线数据能够放在 OSS 的规范/低频/归档类型中，离线数据则适宜放在 OSS 的冷归档/深度冷归档类型中。 此前 OSS 归档类型中的数据在读取时须要冻结，但归档直读能力的公布，使得冻结的步骤能够省去，间接对数据进行拜访。当须要对数据进行生命周期治理时，能够基于最初一次批改工夫（Last Modified Time）以及最初一次拜访工夫（Last Access Time）的策略创立生命周期规定，定期将存储空间（Bucket）内的多个文件（Object）转储为指定存储类型，从而节俭存储费用。此外，OSS 归档类型还新增了同城冗余规格，进一步晋升了数据可靠性。 近期，阿里云存储公布了 OSS 深度冷归档类型，目录价仅为 0.75分/GB/月, 是靠近磁带库的价格，并且可反对百 TB/日冻结能力，无需简短的冻结工夫。 二、全方位的数据保护，应答多种平安威逼安全可靠是云存储立身之本。为了防备勒索病毒、系统故障、自然灾害、运维事变导致的数据失落和损坏问题，须要在云上和本地的数据中心做对立的数据保护。通过 ECS 快照和混合云备份 HBR，能够为整机/云盘/文件/数据库等提供备份、容灾爱护。 同时，HBR 提供了备份不可篡改的能力，给备份数据多一层爱护；还能够将备份数据进行冷热分层，在保留时长满足审计需要的前提下，达到降本增效的目标。当波及到多账号时，客户能够不便地将快照共享给其余受权用户，也能够应用 HBR 进行跨账号的备份。 为防止 region 级别的劫难，必须做跨区域的复制。对象存储 OSS 就有从一个 region 到另外一个 region 的 replication time control，即十分钟之内这个 object 能够异步复制到另外一个城市，比方从北京复制到广州。块存储 EBS 也具备同样的异步复制的能力。 ...