作者：CNStack 容器平台、龙源电力：张悦超 、党旗
龙源电力集团是世界第一大风电运营商， 随着国家西部大开发战略推进，龙源电力已经把风力发电场铺设到全国各地，甚至是交通极不便利的偏远地区，这使龙源电力成为全球装机容量、风电占比最大的运营商，但与此同时企业也面临诸多基础设施建设和维护的挑战。分设在全国 30 多个省的 240 多座风电场站有近千台服务器，因为大多地理位置偏僻，所以中心到边、端维护不便；另外，风电场站计算资源有限，网络 IP、带宽等资源稀缺给 IT 架构规划、管理带来较高成本。同时，运行在省中心、风电场站的不同业务应用对计算、存储、网络资源需求差异性大，也需要兼顾存量资源的统一管理，场站应用系统的维护更新需要大量重复性工作，管理成本高、难度大等问题逐渐成为企业发展的瓶颈。
CNStack（云原生技术中台）是阿里云云原生最佳实践的输出载体，它可以在多云、混合云场景下集中纳管基础设施资源，统一编排和调度工作负载，帮助客户高效构建高性能、高可用、高可靠和安全合规的现代化应用，提升企业数字化转型的整体效能。CNStack 致力于帮助企业 IT 架构重组升维，提供用最低的成本构筑业务发展护城河，产生更大的市场利润技术原动力。CNStack 在过去两年持续打造企业级分布式基础设施 OS，帮助应用开发者屏蔽底层计算、网络复杂拓扑，和异构差异性，并通过适应性优化 IaaS+ 服务，向以业务为中心的企业提供更多目标为导向的组合效用输出。
龙源项目是典型的边缘场景，虽然云中心到省中心架设专线实现了全网算力节点的网络互通，但是由于广袤的地理分布，导致网络带宽资源稀缺，网络传输质量无法保障。省中心、风电场站不仅是地理上的概念，也是业务多租户隔离的独立单元，在这些单元内部，由于地理上相对靠近，其网络质量及带宽限制相对宽松。基于 OpenYurt的 CNStack 云边协同服务（CNStack EdgePaaS）很好地解决弱网环境下云边协同和边缘自治问题。OpenYurt 是阿里云开源的业界首个以无侵入方式将 Kubernetes 扩展到边缘计算领域的项目，于2020年9月成为 CNCF 沙箱项目。OpenYurt 针对边缘场景中网络不稳定、云边运维困难等问题，对原生 Kubernetes 无侵入增强，重点提供了边缘节点自治、云边运维通道、边缘单元化的能力。
OpenYurt 提出的“节点池”概念，对应龙源项目的组织拓扑，实现了下图的部署结构：
“节点池”带来的可不仅仅是资源分组管理这么简单，OpenYurt 还提供了更多专门针对边缘场景的特性：
区别于传统的应用多单元管理，边缘场景下的业务单元数量会显著增加。如果采用传统的分发模式，边缘UnitedDeployment 部署模型将用户的工作负载部署在不同的节点池中，业务的实例数、版本、镜像、配置等信息都可以按照节点池的维度进行统一管理、统一分发，而不是每个单元独立管理。
在边缘场景下，业务负载会按照站点的维度创建多实例。不同站点之间的应用，只能通过本站点的应用访问，而不能由相邻站点访问。为此，OpenYurt 提供了服务拓扑的能力，确保边缘节点应用只能由相同节点池的节点访问，或者只能由本节点访问。
传统的 Kubernetes 对网络有着很高的要求，一但发生了网络中断，Kubernetes 会基于可用性的原因，将工作负载调度到别的可以联通的节点上。这个特性在中心化的集群是很棒的特性，但是这个特性在边缘场景下反倒会带来很大的负面影响。因为这种中断通常只会发生在边缘与中心之间，这种中断一但发生，用户期望的结果是边缘侧的工作负载继续工作，待网络恢复后，中心侧恢复对比边缘业务负载的管理即可。通过 OpenYurt，中心侧会在边缘节点不可用的情况下，阻止工作负载的驱逐，同时确保和中心断联的节点上的工作负载继续运行。
部署在边缘节点上的 CRD Controller，或者 DaemonSet 类型的管控组件都可能对集群不同范围的资源做list/watch，可能造成边缘节点到中心节点较多开销的网络 I/O 负担。为此设计的 OpenYurt Pool-Coordinator 组件，会为节点池维度的资源提供边缘侧缓存，从而降低因为这些资源的大量 list/watch 请求造成的云边网络带宽问题，相比原生 Kubernetes 云端出口流量峰值降低90%。
待 Pool-Coordinator 实例启动，会由选主机制选出的 Leader YurtHub 将 Pool-Scope 资源，例如 endpoints/endpointslice 拉取至边缘，进而同步至 Pool-Coordinator 组件，缓存起来，以供节点池内全部节点使用。节点池内全部节点上运行的 Yurthub，将 Pool-Scope 资源读请求代理至 Pool-Coordinator。理论上，针对一个资源的全量请求，一个节点池只需要一条云边长链接即可，节点池内的这些资源的读请求，都交由 Pool-Coordinator 向下提供服务，从而很大程度降低云边网络消耗。特别是在具有带宽要求的弱网络场景，Pool-Coordinator 可以削弱由于边缘基础容器启动/重建导致的大量请求，以及减少运行时期的云边资源下发量，因此适配于龙源电力部分弱网络边缘节点。Pool-Scope 资源默认定义为 endpoints 和 endpointslices 两种资源。这两种资源在 Yurthub 代理的云边流量中占比较高，这在规模较大集群中体现的更为明显；另外 Pool-Scope 资源要求为节点池内公用的资源，与调用方所属节点无关，这也适配于上述两者。Pool-Scope 资源可由用户配置其他资源，例如 Pods，Node，以及 CR，以应对在特定资源量大的网络优化场景。
该功能已在 Openyurt 最新版本（v1.2）中发布，近期将应用到龙源项目中。
除此以外，CNStack 管控组件经过一系列优化升级，已经将单个边缘节点到中心 master 节点单向实时网络 I/O 从32Mb/s控制在200Kb/s以内。
在边缘场站除了算力节点以外，还有很多 IOT 设备，例如摄像机，交换机，无线 AP 等等。这些设备并不是安装后就不管，而是同样有升级的需要。以无线 AP 为例，一个 AP 的系统升级包有几十 mb，但是龙源的一个场站就可能存在几个甚至是几十个无线 AP，如果这些 AP 的升级操作全部从云中心或者省中心获取升级包，将会产生极大的流量开销。我们采用了，以站点粒度统一分发，再通过站点内共享的方式，实现对云边之间网络流量的节约：
首先在云中心打包需要分发的内容，以内容服务的方式分发到各个场站。此步骤只需要花费"内容分发服务*站点数"的流量。内容分发服务在边缘侧部署以后，无线 AP 再通过 ftp 协议访问本站点的服务端点，这样，无论边缘侧有多少无线 AP，云端之间只需要花费一份内容流量即可。
通过此套方案，获得了如下的效果：
CNStack EdgePaas 还将对内容分发服务进一步升级，大幅提升内容分发能力：
在边缘站点侧，CNStack EdgePaas 提供站点维度的访问代理，数据消费者只需要使用标准协议（http、ftp、sftp）即可获取关注的数据。同时依托于服务协同中就近访问的特性，用户无需为每个站点的应用做单独的配置，全部共享一个服务即可实现内容的获取。
同时，此方案还具备预热的能力。由于内容分发的流程是独立于数据消费流程的，所以可以在消费行为发生之前，提前将消费者需要使用的数据主动对送到业务单元，进而实现数据预热。
龙源项目遍布在全国各地的省中心及边缘场站节点虽然网络链路上与云中心打通，但是边云网络带宽资源稀缺，应用镜像数量、规格都较大给容器镜像分发造成了巨大挑战。中心化镜像仓库服务极易造成云边网络拥塞。
基于 Harbor 的镜像复制能力，提供两级镜像仓库服务方案，实现边缘镜像加速。在各个区域分别部署各自的 docker registry 实例，跟云端的 harbor 服务一起形成一主多从的架构。基于 Harbor 的复制功能配置同步关系，让云端的镜像自动同步到各个区域中的 docker registry 实例。各个区域内的边缘节点直接从本区域的 docker registry 实例拉取镜像。
该方案达成的效果：
龙源管理平台除了需要承载容器化的业务系统之外，还需部署管理运行在虚拟机内的业务系统，容器化应用与虚拟化应用间还需要互相访问。
CNStack 虚拟化服务（CNStack Virtualization）基于 KubeVirt、hybridnet、open-local 等云原生软件构建了云原生虚拟化产品能力，使用一套控制平面同时管理容器和虚拟机，为用户提供虚拟机资源的管理能力，实现容器与虚拟机的资源共池管理、灵活分配、统一调度。
云原生虚拟化基于容器来管理运行 KVM 虚拟机，通过 Kubernetes 自定义资源（CRD）的形式使得虚拟机资源可被视为 Kubernetes 集群的“一等公民”，提供了不同于容器的虚拟机生命周期管理接口，通过与标准的 CNI 容器网络插件和 CSI 容器存储插件对接，使得虚拟机与容器可复用 Kubernetes 集群内的网络与存储资源：
龙源项目多类型业务分别还包括 CPU 和 GPU 应用，CNStack 可以运维和调度其分布在各边缘场站的异构GPU 节点。CNStack 提供了丰富的 GPU 友好的管理界面，如导入、识别、GPU 设备故障检测等。为了更有效地利用 GPU 并实现成本效益，CNStack 还提供了 GPU 共享调度和 GPU 隔离功能。
通常情况下，Nvidia GPU 容器调度将一个 GPU 卡分配给一个容器。然而，在图像和视频推理场景中，一个容器中的算法模型可能无法充分利用一张 GPU 卡的算力，导致资源浪费。在成本效益的背景下，GPU 共享是一个必然的需求。为了实现 GPU 容器层面的共享，需要对一张 GPU 卡进行细粒度资源划分，将 GPU 的细粒度资源上报到 Kubernetes，然后由调度器进行精细化调度和分配，实现 GPU 的共享使用。CNStack 通过如下核心组件实现了 GPU 共享调度和 GPU 隔离能力：
除了需要适配复杂业务模型的异构应用生命周期管理外，龙源项目的网络要求适配和多 ISV 基于大规模研发的风控问题也面临诸多挑战。
关于龙源项目的网络需求，经过与客户、业务方的沟通确认，总结了以下几点：
Hybridnet 网络插件是阿里自研的通用开源 CNI 实现，旨在提供全场景下的 Kubernetes 容器网络部署能力。
目前 hybridnet 已经全面支持了 IPv4/IPv6 双栈场景以及 VXLAN（overlay）、VLAN（underlay）、BGP（underlay）网络的混合部署，并且通过精简的架构设计，实现了不输于 flannel 的稳定性（控制组件和数据面解藕）。
基于 hybridnet 的能力，CNStack 通过如下设计满足了龙源场景诉求：
所有 Pod 默认部署为 overlay 形态（hybridnet 实现的 VXLAN 网络），容器只有 IPv6 地址，使用 IPv6 链路进行通信，这样，平台本身只依赖底层 IPv6 网络通信，并且不占用额外的底层网络地址。2. 对于部分存在 IPv4 通信诉求的 Pod，hybridnet 基于底层 IPv6 网络虚拟出 IPv4 的 overlay 容器网络地址，提供给没有完全适配 IPv6 网络的应用 Pod 使用，不占用额外的底层网络地址，并且不依赖底层 IPv4 网络。
结合每个省站的网络规划，增量为省站配置 IPv4/IPv6 的 underlay 网络（hybridnet 实现的 VLAN 网络），与物理交换机协同工作，实现容器网络和底层网络直接打通，并且为虚拟机分配对应 underlay 网络的地址。
基于 User-Agent 的限流能力
在龙源项目中，业务系统由多 ISV 协同开发，各 ISV 选择的 Kubernetes 扩展开发框架不尽相同，操作Kubernetes 资源规模和频率也无法控制，所以极易产生到 Kubernetes apiserver 超出预期的调用量，可能造成雪崩效应。所以，首先为 apiserver 开启限流，kube-apiserver 支持 MaxInflight 和 APF（API Priority and Fairness）两种限流能力：
另外，针对 MaxInflight 和 APF，它们都是通过 User 来做限流，也就说它们需要先经过认证。但是，认证并不是廉价的，在大量请求到来时，API Server 将消耗大量 CPU 来解 x509 证书或 ServerAccount Token 的验证。在应对大量请求的时候，应该通过最小开销来决定是否放行请求。综上来说，已有的限流能力并不能方便、有效地对不同客户端的请求进行不同程度的限流，并且在判断是否放行请求时会存在较大的开销。为此，CNStack容器服务 （ACK Distro）在 API Server 中增加了基于 UA（User-Agent） 的限流能力，UA 限流能力可以根据请求中的 User-Agent、请求的操作类型，请求的资源，在 API Server 认证之前就决定是否放行该请求，实现以最小的开销来对请求进行区分限流。
如图所示，是 UA 限流判断的时间点。它会从 HTTP 请求中取出 User-Agent、resource、verb 等内容组成一个三元组，如果该三元组与用户设置的 UA 规则中的三元组相匹配的话（User-Agent 支持正则表达式），则会使用令牌桶算法根据 UA 规则的中 QPS/Burst 值判断是否放行该请求。如果放行该请求，则会进入认证阶段；如果拒绝该请求，则会返回 429 状态码，并允许请求的客户端在 1 秒后进行重试。
综上，UA 限流可以方便、有效地针对不同客户端的请求进行不同程度的请求，并且以最小开销来决定是否放行请求，同时精确 UA 匹配，避免误伤。
etcd 集群拆分
鉴于龙源集群的规模，以及多 ISV 业务应用需要频繁、大量创建 deployment/pod 等集群资源的业务需要，对 etcd 性能要求较高。针对 event 资源来说，频繁创建、删除的操作会产生大量该资源，但该资源对集群的正常运行影响并不大，因此为了降低单 etcd 集群的压力，该资源可以被存储到其他 etcd 集群中。针对 lease 资源来说，如果该资源请求超时，则会导致许多控制器选举失败。一旦控制器被重启，则会重新发起全量的 List 操作，进一步加剧对 etcd 和 apiserver 的压力。因此，该资源不适合存储于压力较大的 etcd 集群中，但是该资源相比 Pod 等资源是可以重新生成的。所以，该项目中 CNStack ACK Distro 将 event、lease 两种资源存储到独立的 etcd 集群中，减少了单 etcd 集群的压力，最终减小了单 etcd 集群压力大带来的影响，保证集群的稳定性。
阿里云 CNStack 应用于龙源电力项目的分布式云解决方案已于近期完成测试上线，实现中心到240多个风电场服务器的统一可视化管理，支持同一个平台对运行于虚拟化、容器上的 CPU、GPU 多类型应用资源共池调度，多租户资源隔离应用开发和运维等，部分云化能力对边缘场景提供就近服务，极大降低边云网络传输开销。该解决方案利用容器及云原生技术帮助企业完成一次 IT 架构的跃迁，实现边缘资源、应用运维效率10倍提升，边缘场站资源利用率3倍提升，斩获云原生技术实践联盟（CNBPA）颁发的2022年度公共事业行业最佳云原生实践奖。 2023年，阿里云 CNStack 继续深层解决企业生产环境实际问题，已在边云网络带宽优化，云化能力边缘就近服务，中心化 NoOps 运维等方面规划多项能力，持续打造智慧新能源最佳实践。
参考资料：
CNStack：
https://www.aliyun.com/product/aliware/cnstack
https://github.com/alibaba/CNStackCommunityEdition
ACK Distro：
https://www.aliyun.com/product/aliware/ackdistro
https://github.com/AliyunContainerService/ackdistro
Hybridnet：
https://github.com/alibaba/hybridnet
Open-Local：
作者：刘裕惺CNStack相关阅读：CNStack多集群服务：基于OCM打造完善的集群管理能力CNStack虚拟化服务：实现虚拟机和容器资源的共池管理CNStack云边协同平台：实现原生边缘竟能如此简单01前言CNStack2.0（以下简称CNStack）作为阿里云云原生最佳实践的输出载体，其目标是提供一个开放、共享、标准化的云原生生态系统，使企业能够更加轻松地构建和管理云原生应用。其中，在平台侧能力扩展方面，CNStack基于“云服务”及“云组件”标准规范及相应工具链，提供了开放、标准、易用的能力。目前，CNStack已发布的云服务包括：多集群管理，分布式应用管理、分布式存储、虚拟化服务、云
企业碳排放解决方案合约案例助力双碳1.区块链为“双碳”带来了什么？|研讨会回顾原文介绍：6月22日，由微众区块链、金链盟、FISCOBCOS开源社区联合举办的“‘链’筑可持续”ESG系列研讨会第一期在线举行。本期研讨会以“区块链助推‘双碳’战略”为主题，邀请权威专家和代表企业共话“双碳”工作推进中存在的难点痛点，以及区块链技术如何助推“双碳”战略。研讨会由微众银行区块链CMO李贺主持，邀请了广州碳排放权交易所总经理助理李原、微众银行区块链首席架构师兼金链盟FISCOBCOS首席架构师张开翔、零数科技双碳事业部总经理沈文昌、碳抵科技副总经理耿振博、万物数创CTO黄一分别做主题演讲。随着碳达峰碳中
背景与挑战随着电网公司数字化转型工作的推进和云平台、大数据、物联网、移动化、智能化等新技术的应用，推进高效一体化网络排障定位与深入推进人工智能及大数据技术等在电网信息系统运维中的应用，以及运用前沿科技技术，提高生产管理效益，提升数字电网建设过程中数据的价值已成为电网公司数字化转型工作的必然要求。与此同时，伴随着电力行业数字化转型的不断发展，相关企业业务系统的不断更新与设备数量的大幅增加，由此引发了电力行业以下痛点：监控层面：缺乏非侵入式的业务数据监控手段；工作流程层面：缺乏统一的IT服务入口和服务管理流程；人员层面：业务体系复杂，不同业务部门各自为政；故障处理层面：问题发生后被动处理，且故障分
IC笔试有：JL科技、TR半导体、HZW、MX半导体、RSKX、TCL部分题目暂时还是做不出来，先好好复习一遍，会有柳暗花明的时候的。目录RY10.11TCL10.9位宽定义正确的是逻辑与或和按位与或的题目运算符优先级的题目代码覆盖率有哪些的题目使用fifo实现monitor和scoreboard之间的通信，当monitor占据主动地位，scoreboard被动接收时，下列说法不正确的？有关sequence说法不正确的？linux修改权限关于寄存器级流水线设计描述正确的是？（多线）简述一下带rsp的mastervip的流程（主观题）时序违例有哪几种，解决办法是什么？（主观题）简述TLM定义，t
大家都知道数据中心耗电惊人，电力，对于数据中心来说就好比粮食，人不可七日无粮，数据中心不可七分钟无电！ 目前在数据中心运营过程中，由于电力故障，设备故障，雷击事件等导致的数据中心用电安全事故时有发生。大型数据中心供电的任何故障都可能给业主和客户带来重大的经济损失或者灾难性的后果。对于数据中心运营商来说，品牌和股价等隐形价值的负面影响难以估量。 因此，数据中心能否可靠运营的关键之一是IT设备的不间断供电。在保证不间断供电的前提下，不断提升不间断供电架构的可用性，是数据中心用户一直以来的核心需求。 数据中心的电力保障通常由两个变电站的两路高压市电接入机房，且每路变压器足以承担整个ID
估计基于ChatGPT服务在16个A100GPU上运行的假设，ChatGPT可能需要更多的GPU来为其用户提供服务。由此自然也可以推断，ChatGPT很可能部署在多个地理位置。这使得估算ChatGPT的每日总碳足迹变得非常困难，因为我们需要确切知道有多少GPU在哪些区域运行，以便将每个区域的电力碳强度纳入碳足迹估算。另一方面，估算ChatGPT的耗电量原则上更简单，因为我们不需要知道ChatGPT在哪些地理区域运行。下面我将解释如何估算ChatGPT的能源消耗，我特别估算了2023年1月ChatGPT的用电量。范围仅限于2023年1月，因为我们有一些ChatGPT本月的流量估算。估算ChatG
目录1.潮流计算：2.潮流计算常用算法：2.1牛顿-拉夫逊算法2.1.1牛顿-拉夫逊法的基本原理2.1.2 潮流计算的修正方程2.1.3节点电压用极坐标表示时的牛顿-拉夫逊法潮流计算2.1.4潮流计算程序框图2.2PQ分解法3.MATLAB实例计算1.潮流计算： 潮流计算是电力系统分析中的一种最基本的计算，对给定系统进行潮流计算可以得到各母线上的电压、网络中的功率分布及功率损耗等。 复杂电力系统分析计算的一般方法是对整个电力系统建立数学模型，并通过计算机编程求出个节点的电压及电力系统中的功率分布。2.潮流计算常用算法：2.1牛顿-拉夫逊算法2.1.1牛顿-拉夫逊法的
目录一、前言二、华为HPLC模组简介三、HPLC模组拆解过程四、模组电路原理图逆向五、电力载波收发原理分析六、通用单片机实现电力载波收发七、结束语一、前言 电力线载波通信（PLC）是一种使用电力线进行数据传输的通信技术，即利用现有电网作为信号的传输介质，使电网在传输电力的同时可以进行数据传输。目前根据所用频段的不同，低压电力线载波通信一般分为窄带电力线载波通信（10KHz~500KHz）和宽带电力线载波通信（2MHz~20MHz）。这里的频率可以简单理解为单片机串口的通信波特率，频率越小通信速度越慢，频率越大通信速度越快。为了研究电力载波通信原理，笔者以华为的一款宽带电力载波模组为例进行
当前，新一轮科技革命和产业变革加速演进，物联网、大数据、云计算、人工智能、5G等新一代信息技术快速发展。在众多技术手段中，数字孪生技术以虚实结合为主，架起虚拟世界与现实世界之间沟通的桥梁，为人们提供了更加便捷有效的管理手段。针对发电厂、变电站、输电线路等发电侧与电网侧数字化应用场景，数字孪生系统可为业务场景的全生命周期管理提供智慧化解决方案。数字孪生电力3D可视化管控平台北京智汇云舟科技有限公司成立于2012年，专注于创新性的“视频孪生（实时实景数字孪生）”技术研发与应用。目前，智汇云舟依托自研“孪舟”数字孪生专属引擎，推出了“披萨”低代码PaaS视频孪生开发平台、“速融咖啡”视频孪生一体机及
我有一个3集合架构，如下所示：用户收藏有关于他们的朋友和每个艺术家的收听计数（权重）的信息{user_id:1,Friends:[3,5,6],Artists:[{artist_id:10,weight:345},{artist_id:17,weight:378}]}艺术家集合模式包含有关艺术家的名称、不同用户给他们的标记的信息。{artistID:56,name:"EdSheeran",user_tag:[{user_id:2,tag_id:6},{user_id:2,tag_id:5},{user_id:3,tag_id:7}]}包含各种标记信息的标记集合。{tag_id:3,ta
