首页 文章 精选 留言 我的

精选列表

搜索[组织重构]，共10002篇文章
优秀的个人博客,低调大师

解耦重构 Internet BGP SDN

1 介绍/Why 高清视频直播和云计算的蓬勃发展，带来互联网流量持续高速增长，主流云公司的Internet出口带宽都已经达到Tbps级别。 鉴于网络的拥堵大部分发生在出口互联，Edge Peering Fabric的架构设计直接影响到终端客户的用户体验， 2017年Google/Facebook对外发布了两种不同的Edge 设计理念，本文试着以Google Espresso为主详解下一代Cloud Edge的架构，并简单介绍一下Facebook Edge Fabric。 借助成功部署业界第一个SDN网 B4数据中心互联的经验，Google工程师重新设计了全新的Espresso Peering Fabric。在2017年Espresso已经部署了3年多，服务20%的Google用户，也就是说你看5次Youtube，就有一次机会Espresso控制器帮你调优转发路径。Espresso采用SDN动态调整BGP出口带宽，快速迭代最新特性，在全球TE控制器配合下，Espresso可以提供比传统BGP路由多传送13%的客户流量。同时可以显著提高每条链路利用率和端到端用户体验。有效减少了客户流量的Rebuffers（减少35%-170%）。 首先简单介绍一下Google的网络，截止2018年1月，Google全球有33个数据中心，100+多个POP站点，同时在不同运营商网络中有很多Offnet Cache站点。信息从Google数据中心信息大致经过DC-POP-Cache三级网络发送到最终用户。 Google的广域网实际上分为B2全球骨干网和B4（DCI）数据中心互联网。如下图所示。B4作为Google全球数据中心互联采用自研交换机设备，运行纯IP网络。B2连接数据中心和POP点，采用厂家路由器设备，并且运行MPLS RSVP-TE进行流量工程调节，正在进行SDN/SR改造。简单的说，B4负责数据中心到数据中心的流量转发（Machine to Machine），B2负责数据中心到用户的流量转发（Machine to User）。关于B4详细信息，请参考Google B4 广域网SDN 的前世今生 Google在ONS Summit 2017上推出了他的第四个SDN控制器Espresso（浓缩咖啡），在Metro网络中新引入SDN控制器来调整出方向（Egress）流量。在Google B4 DCI网络中，所有设备都是Google自己设计实现的。可以做到很好的端到端控制， Host/Switch/WAN全路径流量可规划和可编程（Walled Garden）。如何在开放的Internet BGP Peering上来提供Application Aware SDN？Google 尝试用全新的Espresso来解决这个问题。 Espresso首要需求是：动态调整每用户/每应用流量，在PR出口避免拥塞。现有的互联Peering网络是依赖于BGP设计的。BGP设计之初是为了提供稳定的联通性，完全没有考虑网络的动态变化，网络的需求，容量和性能都在每时每刻变化（BGP doesnt consider Demand, Capacity and Performance）。举个例子，对8.8.8.0/24的网段，可能有两个ISP或者ASBR都发送相同的路由。ASBR会根据BGP策略选择一个最优路径，比如上图中，选择ASBR1。过了10分钟，到ASBR1的链路拥塞了，BGP不会做任何动作。只有当这个8.8.8.0/24 prefix从路径1不可达，BGP才会选择次优化路径。BGP号称是动态路由协议，实际上是非常静态的。但是BGP也不是无可救药，BGP有很多灵活的策略，比如根据Local Preference /Community/ Add Path 去调整选路。 不过需要网络管理员手动调节。 虽然BGP有这么多问题，但是大多数的传统的SP/ISP还在采用BGP互联，Google/Facebook还不能抛弃BGP，所以Google/Facebook引入SDN控制器来自动调节BGP出口流量。 Google Metro原有设计最重要的缺陷是没有全局观Metro View，没有办法进行全局优化，引入新的特性。通常Google在Metro实时监测百万用户的流量带宽时延，不同应用不同优先级流量在链路分布。但是很难（受限）在路由器上进行细颗粒度的控制/改写override BGP转发行为。即便是可能去更改，也需要厂商路由器设备去配合。一般至少需要一年时间去通知厂商开发一个特性，才能成功部署在OTT网络中。无法满足Google的应用快速迭代要求。 1.1 Egress/Ingress Peering Engineering 传统的流量工程仅仅 关注在IGP域部分，致力于避免网络内部拥塞。对于Cloud/Video/CDN等业务，网络的瓶颈还存在于BGP Peering部分。传统运营商能采用什么思路来解决BGP流量工程问题呢。如何找到没有拥塞的ASBR和BGP Peering链路进而提高网络传送能力？ C/J的路由专家和OTT专家讨论之后，提出了两种不同的思路来解决。核心思想都是给Peering Link分配标签，一种方式通过BGP-LU携带，另外一种通过BGP-LS携带。 ●draft-gredler-idr-bgplu-epe-xx(RtBrick/Juniper) ●draft-ietf-idr-bgpls-segment-routing-epe-xx(Cisco/ Arrcus) 下面以BGP-LU方式为例解释一下流程： ●引入SDN控制器搜集全网BGP prefix路径信息和Peering链路流量信息（Netflow/Telemetry） ●SDN控制器跟ASBR建立BGP-LU（3107）邻居，并且给每个Peer分配一个标签。 ●SDN控制器根据实时链路状态，计算最优路径，例如每隔30秒来根据（latency/bandwidth/optical SRLG etc）来选择避免拥塞的ASBR或者某个链路。 ●SDN控制器在Ingress头结点（可以是vRouter/TOR，也可以在GW router）进行策略控制： 1.外层隧道采用Segment Routing压上多个标签，外层SR标签找到ASBR，内层BGP-LU标签找到Peering 2.外层隧道也可以采用GRE/LDP等，建立Ingress/ASBR的直连MPLSoGRE隧道。在ASBR上解掉GRE封装，通过查找MPLS标签来指导Peering转发。 在BGP EPE转发路径上有个比较特殊的属性，从用户网络AS内部到Peer ASBR的转发，不需要查询Internet路由表，仅仅需要MPLS转发。 入方向（Ingress）流量根据Global LB(Google采用Meglev)或者BGP Addpath（运营商）来优化。这里不再详述。注意入方向进到ASBR流量可以是IP，ASBR只需要存储Google/Facebook内部网络的Prefix转发表（<<128K）。 利用给每个Peering分配标签特性，把完全Internet转发表的需求转移到Ingress Router（或者Host），可以采用新型态的LSR /Lean Core设备做Internet Peering，可以大幅减少网络投资。同时引入SDN控制器可以动态监控网络拥塞情况，动态调整BGP转发策略，极大的减少了网络的人工干预。关于更多详细的BGP EPE解决方案，请参考我们在2016年初在New Zealand Apricot上的演讲。http://t.cn/RnXyHhR 2 Espresso详解 前面讲到Espresso来改造Google Metro，通常来讲Metro提供三个基本的功能 ●路由器：提供BGP路由与合作伙伴对等交换。 ●服务器池：负载分担和CDN静态缓存内容分发 ●服务器池：提供反向TCP代理 全新的Cloud Edge架构设计需要支持超低时延应用，提供重要的Anti-DDoS功能，并且能有效利用CDN减少经过云骨干网的流量。 从上图可以看到主流的OTT都部署了反向web代理。以Facebook为例，从首尔访问俄勒冈的数据中心，在跨越太平洋光缆一般要引入75ms的单程延迟。如果没有采用反向web代理（图左），从客户开始访问到收到网页，需要600ms。利用在东京的POP点里面的反向Web代理之后，延迟可以降低到240ms。用户体验得到极大提高。 2.1 Espresso系统架构 为了更好的规划Metro里的流量调度，Espresso引入了全球TE控制器（B4中也采用了）和本地控制器（Location Controller）来指导主机发出流量选择更好的外部Peering 路由器/链路，进行per flow Host到Peer的控制。 并且解耦了传统Peering路由器，演进为Peering Fabric和服务器集群（提供反向Web代理）。 控制和转发流程： ●外部系统请求进入Google Metro，在Peering Fabric上被封装成GRE，送到Meglev负载均衡和反向web代理主机处理。如果可以返回高速缓存上的内容以供用户访问，则该数据包将直接从此处发回。如果CDN没有缓存，就发送报文通过B2去访问远端数据中心。 ●主机把实时带宽需求发送给全局控制器（GC） ●GC根据搜集到的全球Internet Prefix情况，Service Class和带宽需求来计算调整不同应用采用不同的Peering路由器和端口进行转发，实现全局出向负载均衡。 ●GC通知本地控制器（LC）来对host进行转发表更改。同时在PF交换机上也配置相应的MPLSoGRE 解封装。 ●数据报文从主机出发，根据GC指定的策略，首先找到GRE的目的地址（PF），PF收到报文之后，解除GRE报文头。根据预先分配给不同外部Peering的MPLS标签进行转发（注意，采用集中控制器，不需要引入BGP-LU来分配MPLS标签）。如上图所示，如果采用红色MPLS标签，就会转发给红色链路。 下面针对不同的子系统详细讲解。 2.2 全局和本地控制器 全局控制器是一个分布式系统，持续不断的搜集各类信息，并且定期产生针对应用优化过的转发规则。进行并且通过本地控制器（LC）在各个区域发布。本地控制器提供本地决策，来快速应对本地链路和Prefix的变化。 为了实现应用感知，全局控制器需要搜集： ●BGP Peering/Prefix信息，类似BMP全网路由和Peering关系。 ●用户带宽和性能需求，通过L7 Proxy搜集每用户带宽，延迟需求，并汇总。一般针对/24目的路由产生相近的延迟数据。 ●PF出接口每队列链路利用率 全局控制器的输出是一个Egress Map规则，对特定{ POP | Prefix |Class }，选择出口{ ASBR | Port }。 本地服务器收到GC的应用优化规则，结合从EBGP过来的实时peering路由信息，来产生主机转发表。为了Anti-DDoS攻击，还需要LC来下发大规模ACL转发表项到主机。一台本地控制器可以控制大概1000台服务器，持续不断的更新主机转发表项和ACL。 上图可以看到，LC 收到GC 转发规则之后，对每个主机，需要产生不同的{ Prefix | Application Class } 采用不同的出口{ PF | Port | %}，并且迭代找到相应的GRE/MPLS 封装。 2.3 解耦Peering Router 演进到Peering Fabric Espresso 另一个主要的设计原则是解耦路由器，演变成Peering Fabric。 传统的Peering 设备，由厂家统一提供软件和硬件。软件新特性开发周期过长。把非必要的功能从 Peering 路由器拿掉，仅保留最简单的MPLS（Label-Switch Fabric）数据转发平面。SDN 软件特性 开发工作由Google 工程师主导，可以极大提高网络可编程性（Programmability）： 1. BGP Speaker 功能，从路由器移出来，采用Google 自研Raven BGP 协议栈，运行在专用服务器上，可以支持更多的Peering，运行更复杂的优化算法，更精细的路由器控制。仅仅实现必要的Feature。 ●a. 支持多核和Scale Out 控制平面，支持BGP Graceful Restart ●b. 同一个Peering fabric可以运行多个Raven实例。多个session可以平均分配到Raven实例。当Raven出错时，仅仅影响少量的BGP session ●c. 之前采用Quagga，面临一些问题，Quagga只有单线程，C语言调试工具太少等。 2. 服务器集群：出方向（Egress）报文Internet路由查表/封装和ACL访问控制列表等放到在Edge里面的大规模服务器集群。 ●a. 每个Host里面都存放完整Internet路由表。IPv4 FIB采用Compressed Multibyte Tire 算法，采用Binary Tire做IPv6 FIB查表。 ●b. Espresso现网运行环境每个Host中，大概有190万Prefix/Service Class Tuple表项，占用 1.2GB内存。 峰值可以做到每Host传送37Gbps报文，大概3Mpps。查FIB表CPU占用率 2.1-2.3%左右。 ●c. Host里存储大规模Internet Facing ACL（MPLS Switch硬件表项太小），配合支持Anti-DDoS等业务，一小部分常用ACL放到PF里面进行业务线速转发。 3. Peering Fabric（PF, MPLS Switch）：进行MPLS转发，仅支持小规模FIB表和ACL表项。减少路由器成本 ●a. 采用Openflow来编辑MPLS转发表，并且配置IP-GRE规则来匹配BGP协议报文发送去相应服务器，并生成MPLSoGRE转发表。 ●b. Switch里面保留常用ACL（小规模）线速转发。5% ACL可以匹配99%的流量。在软件Host里面保存另外95%的ACL，从PF透过GRE tunnel把流量转到Host做进一步处理。 4. Peering Fabric 控制器 ●a. 映射BGP Peering到不同的Raven实例。 ●b. 管理PF转发表 2.4 配置管理红色按钮-Big Red Button Espresso采用自动化Intent-Based配置管理工具。 收到人工可读的意向（Intention）配置管理工具会翻译详细的可以被设备理解的配置。 为了安全性和易用性考虑，Espresso提供了一个大红按钮（Big Red Button，BRB）配置管理功能。管理员可以很容易安全的关闭部分/全部系统功能： ●可以告诉LC下发给所有主机采用本地最佳路由，不用接受全局控制器指令。 ●可以移除一个或多个BGP邻居。 ●点击BGP管理GUI可以移出流经这个Peer的流量。 3 Facebook Edge Fabric简介 2017年Sigcomm大会，Google和Facebook同时发布了两种不同的Edge架构。下面简单介绍一下Facebook Edge Fabric的架构。 ●首先，Edge Fabric也引入一个SDN/BGP控制器。 ●SDN控制器采用多重方式搜集网络信息 ●控制器基于实时流量等相关信息，来产生针对某个Prefix的最优下一跳。指导不同Prefix在多个ASBR之间负载均衡。 ●控制器和每个Peering Router建立另一个BGP 控制session，每隔30秒钟用来改写Prefix，通过调整Local Preference来改变下一跳地址。 ●因为BGP不能感知网络质量，Edge Server对特定流量做eBPF标记DSCP，并动态随机选一小部分流量来测量主用和备用BGP路径的端到端性能。调度仍然发生在PR上，出向拥塞的PR上做SR Tunnel重定向到非拥塞的PR上.如下图所示： 从上图可以看出Facebook采用的都是业界主流厂商支持的协议来实现Edge Fabric。同时有这样一些限制： ●SDN控制器单点控制PR设备。如果PR设备已经Overload，需要通过PBR和ISIS SR Tunnel转移到另一个没有拥塞的PR，流量路径不够全局优化。 ●控制器只能通过Prefix来控制流量，但是同一个prefix，可能承载视频和Voice流量，带宽和时延要求不同，Edge Fabric没有Espresso那么灵活。 Facebook介绍，最早他们的尝试过集中不同的方案，从Host选路到PR，都不太成功。 ●从Host建立LSP到PR ●从Host 标识DCSP，PR根据DSCP转发到不同端口 ●从Host采用GRE tunnel到PR。 最后选择了BGP Inject@PR方案，他们认为是现阶段比较适合的方案。在最近的Network@Scale 2018大会上，Facebook工程师说，未来Edge Fabric架构可能考虑转向BGP EPE和Segment Routing。 下表我们总结了两种方案的比较，请参考。 4 总结和展望 本文介绍了三种不同的思路来解决BGP出口流量调度问题。 ●BGP EPE：采用标准协议为主，SDN控制器通过BGP LU/BGP-LS/Netflow方式选路。 ●Facebook Edge Fabric：SDN控制器计算最佳路径，BGP Local Preference 方式来路由注入 ●Google Espresso：主机存放完整Internet路由，SDN控制器找到相应ASBR/Port. 从端到端架构图中，可以看出在一个POP或DC WAN，Core/Aggregation设备大多已经采用Lean /BGP Free Core解决方案不用存储完整Internet路由。通过Espresso，Google改造/解耦了Peering/ASBR路由器，通过把大部分软件控制功能移到服务器。PF设备可以采用更简单的MPLS Switch（QoS能力强，大Buffer，小型FIB表，小型ACL表，类似B公司Jericho系列）。加上之前B4已经采用了CLOS架构的Stargate Switch设备。 Google已经成为业界第一个在WAN网络中没有采用传统Router的OTT公司。全网已经改造为Switch/Server的架构。对于在POP和DC中有大规模服务器的Google来讲，在POP中的每个Server处理内容的基础上加上1.2GB内存和2-3%的CPU来实现Internet路由查表和隧道封装基本上是可以接受的。 相比Facebook Edge Fabric，Google Espresso完美的解决了Application Aware TE问题，但是开发工作量也是巨大， Google为Espresso开发了很多全新组件： { 全新层次化SDN控制器GC/LC，全新BGP协议Raven实现，全新主机IPv4/IPv6 转发表， 全新路由器解耦PF MPLSoGRE隧道接口，实时L7 Proxy流量需求 } Espresso 仅仅改造了Metro POP, 今后会不会在B2采用类似Espresso架构来打通Backbone和Peering Fabric进行跨越B2全网流量调度？期待Sigcomm 2019 Google能够揭晓更多B2改造成果！ 国内OTT Metro改造展望 云计算进入下半场，企业上云（Cloud Onboarding），网络SDN动态调整的能力越发重要。从云到网需要端到端联动{ VPC/DCI | Metro | Cache | SDWAN }，OTT SDN全网改造势在必行。 Google的网络改造方案是否过于复杂（Over Engineering）？Facebook Edge Fabric过于简化，能否找到一条更适合中国OTT的技术路线来改造POP点？本人认为: 1. 技术路线应该选择类似BGP EPE方案，跟Google保持一致。 ●a. 不要采用BGP Inject方式，防止PR设备过载。并且可以做全局调度 2. 有条件情况下尽量采用Segment Routing + EPE 方式 ●a. Google采用MPLSoGRE，是因为Metro/PoP一般比较小，内部也不会太拥塞。如果从超大数据中心跨越骨干网，最好是采用SR+EPE，避免鱼形TE问题。 ●b. 对于BGP协议在服务器实现的方式，入方向BGP协议报文可以走GRE。 3. 跟云平台和OTT网络用户确定流量需求接口，支持Application Aware SDN ●a. 不光基于Prefix进行流量调度，最好分不同业务Class来指导转发。 4. 设备形态 ●a. 大云公司可以尝试BGP跑在服务器，并且在Host支持IPv4/IPv6全internet转发表。但是需要工程师不断调优。最近Linux Native 支持VRF，FRR等开源软件也支持EVPN on Host。 ●b. 建议采用PTX/NCS/Jericho/Jericho2等类似设备，尤其是10T盒子/Chassis内置HBM2，一般1M FIB起跳，减少转发表没有太多设备成本节省。 随后我们会继续详解Google/Facebook/AWS 等OTT网络架构，下篇想谈谈Facebook DC, Fabric Aggregator, Express backbone，Edge Fabric和Open/R等，接下来也会详解AWS网络和云架构。敬请期待。 原文发布时间为：2018-10-16 本文作者：gated 本文来自云栖社区合作伙伴“SDNLAB”，了解相关信息可以关注“SDNLAB”。
2018-10-16
优秀的个人博客,低调大师

记一次代码重构

单一职责 功能单一 功能单一是SRP最基本要求，也就是你一个类的功能职责要单一，这样内聚性才高。 比如，下面这个参数类，是用来查询网站Buyer信息的，按照SRP，里面就应该放置查询相关的Field就好了。 @Data public class BuyerInfoParam { // Required Param private Long buyerCompanyId; private Long buyerAccountId; private Long callerCompanyId; private Long callerAccountId; private String tenantId; private String bizCode; private String c
2018-08-08
优秀的个人博客,低调大师

诺基亚组织架构调整，公布 AI 新战略

诺基亚在2025年资本市场日活动期间宣布将通过新战略引领人工智能（AI）驱动的网络转型，并把握AI超级周期价值。 诺基亚同时公布了新的长期财务目标、业务战略关键绩效指标（KPI）、运营模式演进方案及集团领导团队调整。为执行新战略方向，诺基亚正将运营模式简化为网络基础设施（Network Infrastructure）与移动基础设施（Mobile Infrastructure）两大主要业务运营部门。这些变革旨在强化诺基亚的创新道路，提升客户服务能力，创造股东价值。公司目标至2028年将年度可比营业利润提升至27亿至32亿欧元区间。 诺基亚新战略将聚焦以下五大战略方向： 加速AI与云领域的增长； 通过AI原生网络与6G引领下一代移动连接； 携手客户与合作伙伴共同创新实现增长； 将资本集中于诺基亚能具备差异化优势的领域； 实现可持续回报。 为更好应对AI超级周期对先进连接需求激增的态势，诺基亚将自2026年1月1日起重组为两大核心业务运营部门。 此次重组将网络基础设施部门确立为增长型业务板块，旨在把握全球AI与数据中心的快速建设机遇，同时持续为电信客户群进行创新。该部门继续由David Heard领导，下设光网络（Optical Networks）、IP网络（IP Networks）和固定网络（Fixed Networks）三个业务单元。 新设立的移动基础设施部门整合了诺基亚核心网产品组合、无线网络产品组合及原属NokiaTechnologies的技术标准业务。该部门将聚焦核心网与无线网络技术及服务领导力，引领行业迈向AI原生网络与6G时代。这一新部门整合了一系列价值创造源于基于3GPP标准的移动通信技术的产品组合，并通过知识产权许可实现强劲现金流。该部门将由Justin Hotard暂代领导，下设核心网软件（Core Software）、无线网络（Radio Networks）与技术标准（Technology Standards）三个业务单元。 作为这些变革的一部分，诺基亚宣布对其领导团队进行进一步调整，自2026年1月1日起生效：Raghav Sahgal将出任诺基亚首席客户官，并留任集团领导团队，负责为诺基亚客户打造无缝的客户体验。Patrik Hammarén留任集团领导团队，担任技术标准（原Nokia Technologies）业务总裁，体现出技术标准为诺基亚创造的重要价值。Tommi Uitto则将于12月31日退出集团领导团队。 通过对业务组合的全面评估，诺基亚将部分虽具增长潜力但不符合公司未来战略核心的业务单元划入新设的“Portfolio Businesses”部门，期间公司将评估其最佳价值创造方案。 诺基亚计划将以下业务单元划归至Portfolio Businesses部门： 固定无线接入FWA CPE（现属网络基础设施部门的固定网络业务）； 站点实施与外部设备（现属网络基础设施部门的固定网络业务）； 企业园区边缘解决方案（现属云与网络服务部门）； 微波射频系统（现属移动网络部门）。 诺基亚计划于2026年内确定各业务单元最终发展方向。过渡期间将优先保障客户与员工业务的连续性。在过去12个月里，这些业务单元合计实现净销售额约9亿欧元，营业亏损1亿欧元。 诺基亚国防（Nokia Defense）业务将作为孵化单元成立，旨在成为公司国防业务组合的核心市场推广与研发中心。依托诺基亚联邦解决方案（Federal Solutions）在美国的坚实基础，该公司将在美国、芬兰和其他盟国市场拓展机会，基于网络与移动基础设施核心技术提供国防级解决方案。 诺基亚制定了新的长期财务目标：到2028年实现可比营业利润27亿至32亿欧元，较过去12个月（2024年第四季度至2025年第三季度）的20亿欧元显著提升。这是诺基亚的独立长期目标，不属于集团层面的财务展望，并取代了诺基亚此前设定的长期目标，即增速超过市场平均水平、可比营业利润率至少达到13%以及可比营业利润的自由现金流转化率达到55%至85%。 针对不同业务领域趋势，诺基亚将采用差异化战略杠杆最大化股东价值。公司引入系列战略KPI以体现战略预期成果。这些针对业务的KPI不属于集团层面的财务展望。 网络基础设施净销售额增长：诺基亚的目标是在2025-2028年期间实现净销售额复合年增长率6%-8%，其中包括光网络与IP网络合计增长10%-12%。 网络基础设施营业利润率：到2028年达到13%-17%。 移动基础设施毛利率：到2028年达48%-50%。 移动基础设施营业利润：在15亿欧元的基础上实现增长。 集团公共及其他运营费用：到2028年，运营费用将从目前的3.5亿欧元降至1.5亿欧元。 自由现金流转化率：诺基亚的目标是实现65%至75%的可比营业利润自由现金流转化率。 诺基亚的新部门将于2026年1月1日成立，并将从2026年第一季度开始按照新的业务部门架构报告财务业绩。诺基亚计划在2026年第一季度根据新的报告结构发布2024年和2025年的重述财务报表。为帮助投资者了解新报告框架下的业务范围，诺基亚提供以下业务大致细分数据（近似值），这些数据也已计入Infinera收购的模拟报表调整。 *本临时财务信息包含对Infinera收购的模拟报表调整。 自2026年第一季度财报起，诺基亚将按季度完整披露新部门的完整部门业绩报告（即净销售额、毛利润、营业利润），并公布主要业务经营部门内部各业务单元收入明细。网络基础设施部门的业务单元包括光网络、IP网络与固定网络；移动基础设施部门的业务单元包括核心网软件、无线网络与技术标准。
2025-11-20

资源下载

更多资源
腾讯云软件源

腾讯云软件源

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

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

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

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

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

时间: 2026-08-21 大小: 5MB 下载: 2次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

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

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

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册