首页 文章 精选 留言 我的

精选列表

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

WCF服务重构实录（下）

前两篇写了在IIS7下部署SVC文件引导WCF服务，采用了net.tcp文件，但是实际的开发中，由于项目的架构已经确定，不宜做大的改动，且为了试项目组成员开发方便，我们之前的项目架构是这样的： 主体是WebHost，这是用来托管WCF服务的，放弃了ConsoleHost，那么现在的问题是能不能仅仅通过配置文件来托管服务，不必通过SVC文件的连接呢，MSDN上给出了一个很好的解决方案：http://msdn.microsoft.com/zh-cn/library/ee816902(en-us,VS.100).aspx 主要使用的是一个配置元素<serviceActivations>，MSDN给出的说明是： 一个配置元素，用于添加可定义虚拟服务激活设置（映射到 Windows Communication Foundation (WCF) 服务类型）的设置。使用此配置元素可以在不使用 .svc 文件的情况下激活承载在 WAS/IIS 中的服务。 主要语法是： view source print ? <SERVICEHOSTINGENVIRONMENT> <SERVICEACTIVATIONS> <ADDfactory="String"service="String"/> </SERVICEACTIVATIONS> </SERVICEHOSTINGENVIRONMENT> 那么有了这个好组件，我们就拿来改造现有的服务吧。 首先，之前的服务配置是 view source print ? <SERVICES> <SERVICEbehaviorconfiguration="MyBehavior"name="WCFLib.Add"> <ENDPOINTaddress=""binding="netTcpBinding"contract="WCFLib.IAdd"bindingconfiguration="netTcpBindConfig"></ENDPOINT> <ENDPOINTaddress="mex"binding="mexTcpBinding"contract="IMetadataExchange"></ENDPOINT> </SERVICE> </SERVICES> 我们为这个配置增加服务激活配置 view source print ? <SERVICEHOSTINGENVIRONMENT> <SERVICEACTIVATIONS> <ADDservice="WCFLib.Add"relativeaddress="NewAddService.svc"/> </SERVICEACTIVATIONS> </SERVICEHOSTINGENVIRONMENT> 来看一下现在完整的配置 view source print ? <SYSTEM.SERVICEMODEL> <BINDINGS> <NETTCPBINDING> <BINDINGname="netTcpBindConfig"> <SECURITYmode="None"> <TRANSPORTclientcredentialtype="Windows"protectionlevel="EncryptAndSign"/> <MESSAGEclientcredentialtype="Windows"/> </SECURITY> </BINDING> </NETTCPBINDING> </BINDINGS> <SERVICEHOSTINGENVIRONMENT> <SERVICEACTIVATIONS> <ADDservice="WCFLib.Add"relativeaddress="NewAddService.svc"/> </SERVICEACTIVATIONS> </SERVICEHOSTINGENVIRONMENT> <SERVICES> <SERVICEbehaviorconfiguration="MyBehavior"name="WCFLib.Add"> <ENDPOINTaddress=""binding="netTcpBinding"contract="WCFLib.IAdd"bindingconfiguration="netTcpBindConfig"></ENDPOINT> <ENDPOINTaddress="mex"binding="mexTcpBinding"contract="IMetadataExchange"></ENDPOINT> </SERVICE> </SERVICES> <BEHAVIORS> <SERVICEBEHAVIORS> <BEHAVIORname="MyBehavior"> <SERVICETHROTTLINGmaxconcurrentcalls="1000"maxconcurrentinstances="1000"maxconcurrentsessions="1000"/> <SERVICEMETADATAhttpgetenabled="true"/> <SERVICEDEBUGincludeexceptiondetailinfaults="true"/> <DATACONTRACTSERIALIZERmaxitemsinobjectgraph="6553600"/> </BEHAVIOR> </SERVICEBEHAVIORS> </BEHAVIORS> </SYSTEM.SERVICEMODEL> 删除SVC文件后的目录是这样的 那么怎么使用这个没有SVC文件的WCF服务呢，很简单，我们只要认为有这个服务就可以了，删除之前的Client中的引用，我们重新添加引用一下 再运行一下试试看 本文转自xshf12345 51CTO博客，原文链接：http://blog.51cto.com/wengyuli/583882，如需转载请自行联系原作者
2017-11-07
优秀的个人博客,低调大师

GNOME 将彻底重构“窗口管理”

GNOME 46 或更高版本可能会对桌面的默认窗口管理 (Window Management) 进行彻底改造。 近日，GNOME 开发者 Tobias Bernard 通过一篇长文详细介绍了 GNOME 设计团队为重新设计桌面窗口管理所做的工作。终极目标是重新设计足以成为默认方案而非可选方案的方法。 Tobias Bernard是交互设计师，负责 GNOME 的设计，他研究了现在操作系统里放置窗口的常见方法（平铺、层叠/浮动），发现对新手用户而言，手动放置和缩放窗口的工作很繁琐。 他因此提出了自己的概念性设计，希望创造更理想的窗口管理方式。一些关键细节包括： 自动执行人们可能想要的操作，必要时允许调整 将工作空间 (workspaces) 作为工作流的完全集成部分来使用 从应用程序中获取更丰富的元数据，以便更好地进行整合 窗口采用三种布局排列方式相结合： 马赛克 (Mosaic)，类似于平铺，并结合平铺和浮动的优势，且更自由 靠近边缘平铺，相当于局部的平铺 浮动，经典的层叠窗口模型 毫无疑问这是一项重大工作，将涉及大量窗口元数据，并需要在某些领域进行更多用户研究。目前该项目还处于非常早期的阶段，点此查看更多信息。
2023-08-09
优秀的个人博客,低调大师

解耦重构 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

资源下载

更多资源
腾讯云软件源

腾讯云软件源

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

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

Nacos

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

时间: 2026-08-21 大小: 189MB 下载: 7次
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

用户登录
用户注册