首页 文章 精选 留言 我的

精选列表

搜索[编译原理],共10000篇文章
优秀的个人博客,低调大师

Android面试,IntentService的原理及使用

在Android开发中,我们或许会碰到这么一种业务需求,一项任务分成几个子任务,子任务按顺序先后执行,子任务全部执行完后,这项任务才算成功。那么,利用几个子线程顺序执行是可以达到这个目的的,但是每个线程必须去手动控制,而且得在一个子线程执行完后,再开启另一个子线程。或者,全部放到一个线程中让其顺序执行。这样都可以做到,但是,如果这是一个后台任务,就得放到Service里面,由于Service和Activity是同级的,所以,要执行耗时任务,就得在Service里面开子线程来执行。那么,有没有一种简单的方法来处理这个过程呢,答案就是IntentService。 什么是IntentService,IntentService是继承于Service并处理异步请求的一个类,在IntentService内有一个工作线程来处理耗时操作,启动IntentService的方式和启动传统Service一样,同时,当任务执行完后,IntentService会自动停止,而不需要我们去手动控制。另外,可以启动IntentService多次,而每一个耗时操作会以工作队列的方式在IntentService的onHandleIntent回调方法中执行,并且,每次只会执行一个工作线程,执行完第一个再执行第二个,以此类推。 所有请求都在一个单线程中,不会阻塞应用程序的主线程(UI Thread),同一时间只处理一个请求。 那么,用IntentService有什么好处呢?首先,我们省去了在Service中手动开线程的麻烦,第二,当操作完成时,我们不用手动停止Service。 Code 接下来让我们来看看如何使用,我写了一个Demo来模拟两个耗时操作,Operation1与Operation2,先执行1,2必须等1执行完才能执行: 新建工程,新建一个继承IntentService的类,我这里是IntentServiceDemo.java public class IntentServiceDemo extends IntentService { public IntentServiceDemo() { //必须实现父类的构造方法 super("IntentServiceDemo"); } @Override public IBinder onBind(Intent intent) { System.out.println("onBind"); return super.onBind(intent); } @Override public void onCreate() { System.out.println("onCreate"); super.onCreate(); } @Override public void onStart(Intent intent, int startId) { System.out.println("onStart"); super.onStart(intent, startId); } @Override public int onStartCommand(Intent intent, int flags, int startId) { System.out.println("onStartCommand"); return super.onStartCommand(intent, flags, startId); } @Override public void setIntentRedelivery(boolean enabled) { super.setIntentRedelivery(enabled); System.out.println("setIntentRedelivery"); } @Override protected void onHandleIntent(Intent intent) { //Intent是从Activity发过来的,携带识别参数,根据参数不同执行不同的任务 String action = intent.getExtras().getString("param"); if (action.equals("oper1")) { System.out.println("Operation1"); }else if (action.equals("oper2")) { System.out.println("Operation2"); } try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } } @Override public void onDestroy() { System.out.println("onDestroy"); super.onDestroy(); } } 我把生命周期方法全打印出来了,待会我们来看看它执行的过程是怎样的。接下来是Activity,在Activity中来启动IntentService: public class TestActivity extends Activity { /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); //可以启动多次,每启动一次,就会新建一个work thread,但IntentService的实例始终只有一个 //Operation 1 Intent startServiceIntent = new Intent("com.test.intentservice"); Bundle bundle = new Bundle(); bundle.putString("param", "oper1"); startServiceIntent.putExtras(bundle); startService(startServiceIntent); //Operation 2 Intent startServiceIntent2 = new Intent("com.test.intentservice"); Bundle bundle2 = new Bundle(); bundle2.putString("param", "oper2"); startServiceIntent2.putExtras(bundle2); startService(startServiceIntent2); } } 最后,别忘了配置Service,因为它继承于Service,所以,它还是一个Service,一定要配置,否则是不起作用的,开始我就是忘了,结果半天没反应。 <service android:name=".IntentServiceDemo"> <intent-filter > <action android:name="com.test.intentservice"/> </intent-filter> </service> 最后来看看执行结果: 从结果可以看到,onCreate方法只执行了一次,而onStartCommand和onStart方法执行了两次,开启了两个Work Thread,这就证实了之前所说的,启动多次,但IntentService的实例只有一个,这跟传统的Service是一样的。Operation1也是先于Operation2打印,并且我让两个操作间停顿了2s,最后是onDestroy销毁了IntentService。 我是天王盖地虎的分割线 本文转自我爱物联网博客园博客,原文链接:http://www.cnblogs.com/yydcdut/p/3960886.html,如需转载请自行联系原作者

优秀的个人博客,低调大师

《云计算:原理与范式》一导读

前 言 云计算(cloud computing)如今已成为信息与通信技术(ICT)产业中的又一个流行语(buzzword)。众多IT厂商承诺提供计算、存储和应用托管服务,其服务范围涵盖了几大洲,并提供基于服务水平协议(Service Level Agreement,SLA)支持的性能和运行时间。尽管这些“云”是传统数据中心的自然进化,它们以展现资源(计算、数据/存储及应用)作为基于标准的Web服务并遵循“实用”的定价模式进行区分。根据客户的计算资源、存储及数据传输的利用率收费。这些“云”提供了基于订阅的访问基础设施、平台及应用的基础设施即服务(Infrastructure as a Service,IaaS)、平台即服务(Platform as a Service,PaaS)和软件即服务(Software as a Service,

优秀的个人博客,低调大师

Kubernetes核心原理(二)之Controller Manager

版权声明:本文为博主原创文章,未经博主允许不得转载。如需转载请联系本人,并标明出处和作者。 本文CSDN博客地址:http://blog.csdn.net/huwh_/article/details/75675761 1.Controller Manager简介 Controller Manager作为集群内部的管理控制中心,负责集群内的Node、Pod副本、服务端点(Endpoint)、命名空间(Namespace)、服务账号(ServiceAccount)、资源定额(ResourceQuota)的管理,当某个Node意外宕机时,Controller Manager会及时发现并执行自动化修复流程,确保集群始终处于预期的工作状态。 每个Controller通过API Server提供的接口实时监控整个集群的每个资源对象的当前状态,当发生各种故障导致系统状态发生变化时,会尝试将系统状态修复到“期望状态”。 2.Replication Controller 为了区分,资源对象Replication Controller简称RC,而本文是指Controller Manager中的Replication Controller,称为副本控制器。副本控制器的作用即保证集群中一个RC所关联的Pod副本数始终保持预设值。 只有当Pod的重启策略是Always的时候(RestartPolicy=Always),副本控制器才会管理该Pod的操作(创建、销毁、重启等)。 RC中的Pod模板就像一个模具,模具制造出来的东西一旦离开模具,它们之间就再没关系了。一旦Pod被创建,无论模板如何变化,也不会影响到已经创建的Pod。 Pod可以通过修改label来脱离RC的管控,该方法可以用于将Pod从集群中迁移,数据修复等调试。 删除一个RC不会影响它所创建的Pod,如果要删除Pod需要将RC的副本数属性设置为0。 不要越过RC创建Pod,因为RC可以实现自动化控制Pod,提高容灾能力。 2.1.Replication Controller的职责 确保集群中有且仅有N个Pod实例,N是RC中定义的Pod副本数量。 通过调整RC中的spec.replicas属性值来实现系统扩容或缩容。 通过改变RC中的Pod模板来实现系统的滚动升级。 2.2.Replication Controller使用场景 使用场景 说明 使用命令 重新调度 当发生节点故障或Pod被意外终止运行时,可以重新调度保证集群中仍然运行指定的副本数。 弹性伸缩 通过手动或自动扩容代理修复副本控制器的spec.replicas属性,可以实现弹性伸缩。 kubectl scale 滚动更新 创建一个新的RC文件,通过kubectl 命令或API执行,则会新增一个新的副本同时删除旧的副本,当旧副本为0时,删除旧的RC。 kubectl rolling-update 滚动升级,具体可参考kubectl rolling-update --help,官方文档:https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/ [root@node5 ~] # kubectl rolling-update --help Perform a rolling update of the given ReplicationController. Replaces the specified replication controller with a new replication controller by updating one pod at a time to use the new PodTemplate. The new-controller.json must specify the same namespace as the existing replication controller and overwrite at least one (common) label in its replicaSelector. Usage: kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC) [flags] Aliases: rolling-update, rollingupdate Examples: # Update pods of frontend-v1 using new replication controller data in frontend-v2.json. $ kubectl rolling-update frontend-v1 -f frontend-v2.json # Update pods of frontend-v1 using JSON data passed into stdin. $ cat frontend-v2.json | kubectl rolling-update frontend-v1 -f - # Update the pods of frontend-v1 to frontend-v2 by just changing the image, and switching the # name of the replication controller. $ kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # Update the pods of frontend by just changing the image, and keeping the old name $ kubectl rolling-update frontend --image=image:v2 3.Node Controller kubelet在启动时会通过API Server注册自身的节点信息,并定时向API Server汇报状态信息,API Server接收到信息后将信息更新到etcd中。 Node Controller通过API Server实时获取Node的相关信息,实现管理和监控集群中的各个Node节点的相关控制功能。流程如下 1、Controller Manager在启动时如果设置了--cluster-cidr参数,那么为每个没有设置Spec.PodCIDR的Node节点生成一个CIDR地址,并用该CIDR地址设置节点的Spec.PodCIDR属性,防止不同的节点的CIDR地址发生冲突。 2、具体流程见以上流程图。 3、逐个读取节点信息,如果节点状态变成非“就绪”状态,则将节点加入待删除队列,否则将节点从该队列删除。 4.ResourceQuota Controller 资源配额管理确保指定的资源对象在任何时候都不会超量占用系统物理资源。 支持三个层次的资源配置管理: 1)容器级别:对CPU和Memory进行限制 2)Pod级别:对一个Pod内所有容器的可用资源进行限制 3)Namespace级别:包括 Pod数量 Replication Controller数量 Service数量 ResourceQuota数量 Secret数量 可持有的PV(Persistent Volume)数量 说明: k8s配额管理是通过Admission Control(准入控制)来控制的; Admission Control提供两种配额约束方式:LimitRanger和ResourceQuota; LimitRanger作用于Pod和Container; ResourceQuota作用于Namespace上,限定一个Namespace里的各类资源的使用总额。 ResourceQuota Controller流程图: 5.Namespace Controller 用户通过API Server可以创建新的Namespace并保存在etcd中,Namespace Controller定时通过API Server读取这些Namespace信息。 如果Namespace被API标记为优雅删除(即设置删除期限,DeletionTimestamp),则将该Namespace状态设置为“Terminating”,并保存到etcd中。同时Namespace Controller删除该Namespace下的ServiceAccount、RC、Pod等资源对象。 6.Endpoint Controller Service、Endpoint、Pod的关系: Endpoints表示了一个Service对应的所有Pod副本的访问地址,而Endpoints Controller负责生成和维护所有Endpoints对象的控制器。它负责监听Service和对应的Pod副本的变化。 如果监测到Service被删除,则删除和该Service同名的Endpoints对象; 如果监测到新的Service被创建或修改,则根据该Service信息获得相关的Pod列表,然后创建或更新Service对应的Endpoints对象。 如果监测到Pod的事件,则更新它对应的Service的Endpoints对象。 kube-proxy进程获取每个Service的Endpoints,实现Service的负载均衡功能。 7.Service Controller Service Controller是属于kubernetes集群与外部的云平台之间的一个接口控制器。Service Controller监听Service变化,如果是一个LoadBalancer类型的Service,则确保外部的云平台上对该Service对应的LoadBalancer实例被相应地创建、删除及更新路由转发表。 参考《Kubernetes权威指南》

优秀的个人博客,低调大师

KVM 虚拟化架构和实现原理

目录 目录 KVM虚拟化架构 devkvm QEMU OpenstackKVMQEMU 的关系 KVM的虚拟化实现 KVM虚拟化架构 KVM是嵌入在Linux操作系统标准内核中的一个虚拟化模块,它能够将一个Linux标准内核转换成为一个VMM,嵌有KVM模块的Linux标准内核可以支持通过kvm tools来进行加载的GuestOS。所以在这样的操作系统平台下,计算机物理硬件层上直接就是VMM虚拟化层,而没有独立出来的HostOS操作系统层。在这样的环境中HostOS就是一个VMM。 每个由KVM创建的GuestOS都是HostOS(或VMM)上的一个单个进程。而在GuestOS上的User-space中运行的Applications可以理解为就是进程中的线程。 需要注意的是:KVM只是虚拟化解决方案的一部分,想要实现全虚拟化,还需要其他的条件: 1. CPU处理器提供的虚拟化支持(VT-x 硬件辅助虚拟化,可以为GuestOS创建虚拟化处理器,本质是对寄存器的隔离模拟和对指令集的划分)。 2. 内存可以通过kvm虚拟化成独立的虚拟化地址(/dev/kvm) 3. I/O虚拟化(QEMU) ==> KVM虚拟化 = KVM内核模块 + /dev/kvm + QEMU /dev/kvm Linux操作系统标准内核中的KVM内核模块生成了一个名为/dev/kvm的设备,有了/dev/kvm设备,使得GuestOS的地址空间(内存地址、磁盘地址)能够独立于标准内核或其他任何GuestOS的地址空间。Linux操作系统目录结构包含的/dev目录树下的设备对于所有User-space进程或线程(无论是在GuestOS上,还是在VMM上)来说都是通用的,但是每个打开/dev/kvm设备的不同的进程或线程,所能使用的都是唯一且各不相同的地址映射(为了支持GuestOS间的隔离)。 KVM内核模块通过/dev/kvm设备提供了内存虚拟化,给予GuestOS与内核或者其他GuestOS相对独立的地址空间。每个GuestOS都有自己的地址空间,并且这些地址空间是在实例化GuestOS时创建映射的。映射给GuestOS的物理内存实际上是映射给这个GuestOS在VMM中相应进程的虚拟内存。 有两种支持Guest地址到Host(VMM)地址的转换方法: 应用LinuxOS维护的一组影子页表(shadow page table) CPU也可以通过在访问未经映射的内存位置时使用VMM(主机内核)来支持内存转换进程。 所以总的来说,/dev/kvm设备的作用就是:将不同的GuestOS之间的地址隔离,或将GuestOS和HostOS(VMM)之间的地址隔离 QEMU QEMU是一个I/O虚拟化解决方案,能够对一个完整的计算机物理层环境进行虚拟化(EG. 磁盘、图形适配器、网络设备)。 在GuestOS中生成的所有I/O请求都会被QEMU中途截获,并重新发送到QEMU进程模拟的User Mode中。 Openstack、KVM、QEMU 的关系 KVM 用来模拟 CPU 的运行,但缺少了对 Network 和 I/O 的支持。QEMU-KVM 是一个完整的模拟器,它基于 KVM 上,提供了完整的 Network 和 I/O 支持。其中 Openstack 为了跨 VM 性,所以不会直接控制 QEMU-KVM,而是通过 libvit 的库去间接控制 QEMU-KVM 。 KVM的虚拟化实现 KVM内核模块为Linux标准内核引入了一种除现有的Kernel Mode和User Mode之外的新进程模式。这种新模式就称为Guest Mode模式,顾名思义,它用来执行GuestOS的代码。 Linux标准内核的执行模式可以针对不同的运行内容和目的进行定义。Guest Mode的存在就是为了执行GuestOS的代码,但是只针对那些非I/O的代码。I/O代码还需要QEMU来作为支持。 GuestOS可以在两种模式下运行: 在Guest Mode中运行的GuestOS可以支持标准的内核。 在User Mode下运行的GuestOS则支持自己的内核和User-space(Applications)。 相同的是,GuestOS只能够在User Mode下执行I/O操作,而且这是单独使用QEMU-KVM进行管理的。

优秀的个人博客,低调大师

Openstack组件实现原理 — Keystone认证功能

目录 目录 前言 Keystone安装列表 Keystone架构 Keystone的管理对象 一个理解Keystone管理对象功能的例子 Keystone管理对象之间的关系 Keystone V3的新特性 V3的改进 Authorization授权功能的应用 Authentication认证功能的应用过程 前言 Keystone实现始终围绕着Keystone所实现的功能来展开,所以在理解其实现之前,建议大家尝试通过安装Keystone这一个过程来感受Keystone在Openstack架构中所充当的角色。下面给出了Keystone-M的安装过程。 Keystone安装列表 Openstack组件部署 — Overview和前期环境准备 Openstack组建部署 — Environment of Controller Node Openstack组件部署 — Keystone功能介绍与认证实现流程 Openstack组件部署 — Keystone Install & Create service entity and API endpoints Openstack组件部署 — keystone(domain, projects, users, and roles) Keystone架构 Keystone的管理对象 User:指使用Openstack service的用户,可以是人、服务、系统,但凡使用了Openstack service的对象都可以称为User。 Project(Tenant):可以理解为一个人、或服务所拥有的 资源集合 。在一个Project(Tenant)中可以包含多个User,每一个User都会根据权限的划分来使用Project(Tenant)中的资源。比如通过Nova创建虚拟机时要指定到某个Project中,在Cinder创建卷也要指定到某个Project中。User访问Project的资源前,必须要与该Project关联,并且指定User在Project下的Role。 Role:用于划分权限。可以通过给User指定Role,使User获得Role对应的操作权限。Keystone返回给User的Token包含了Role列表,被访问的Services会判断访问它的User和User提供的Token中所包含的Role。系统默认使用管理Role admin和成员Role _member_ 。 Policy:OpenStack对User的验证除了OpenStack的身份验证以外,还需要鉴别User对某个Service是否有访问权限。Policy机制就是用来控制User对Tenant中资源(包括Services)的操作权限。对于Keystone service来说,Policy就是一个JSON文件,默认是/etc/keystone/policy.json。通过配置这个文件,Keystone Service实现了对User基于Role的权限管理。 Token:是一个字符串表示,作为访问资源的令牌。Token包含了在 指定范围和有效时间内 可以被访问的资源。EG. 在Nova中一个tenant可以是一些虚拟机,在Swift和Glance中一个tenant可以是一些镜像存储,在Network中一个tenant可以是一些网络资源。Token一般被User持有。 Credentials:用于确认用户身份的凭证 Authentication:确定用户身份的过程 Service:Openstack service,即Openstack中运行的组件服务。 Endpoint:一个可以通过网络来访问和定位某个Openstack service的地址,通常是一个URL。比如,当Nova需要访问Glance服务去获取image 时,Nova通过访问Keystone拿到Glance的endpoint,然后通过访问该endpoint去获取Glance服务。我们可以通过Endpoint的region属性去定义多个region。Endpoint 该使用对象分为三类: admin url –> 给admin用户使用,Post:35357 internal url –> OpenStack内部服务使用来跟别的服务通信,Port:5000 public url –> 其它用户可以访问的地址,Post:5000 public url可以被全局访问,private url只能被局域网访问,admin url被从常规的访问中分离。 一个理解Keystone管理对象功能的例子 如果把宾馆比作为Openstack,那么宾馆的中央管理系统就是Keystone,入住宾馆的人就是User 。在宾馆中拥有很多不同的房间,房间提供了不同的服务(Service)。在入住宾馆前,User需要给出身份证(Credential),中央管理系统(Keystone)在确认User的身份后(Authenticaiton),会给你一个房卡(Token)和导航地图(Endpoint)。不同VIP(Role)级别的User,拥有不同权限的房卡(Token),如果你的VIP(Role)等级高,你可以享受到豪华的总统套房。然后User拿着房卡(Token)和地图(Endpoint),就可以进入特定的房间去享受不同的Services。每一个服务(Services)中都拥有着一些特定资源(Project),例如:按摩服务中可以使用的精油种类和数量。User可以根据自己的权限来使用这些资源。 组件 类比 Openstack 宾馆 Keystone 中央管理系统 Project 旅游项目,拥有宾馆的某些资源 User 旅客 Credentials 旅客的身份证 Authentication 确定旅客身份的过程 Token 房卡 Role VIP等级 Endpoint 服务提供场所的地址 Service 宾馆可以提供的服务类别 Keystone管理对象之间的关系 Keystone V3的新特性 这节的内容引用自IBM developerWorks Tenant 重命名为 Project 添加了 Domain 的概念 添加了 Group 的概念 在本系列的Openstack-M版本中就使用了Keystone-V3。 V3的改进 问题1:在Keystone V2中,资源分配是以Tenant为单位的,这不太符合现实世界中的层级关系。如一个公司在 Openstack中拥有两个不同的项目,他需要管理两个Tenant来分别对应这两个项目,并对这两个Tenant中的用户分别分配角色。由于在Tenant之上并不存在一个更高层的概念,无法对 Tenant 进行统一的管理,所以这给多 Tenant 的用户带来了不便。 解决:V3 利用 Domain 的概念实现真正的多租户(multi-tenancy)架构,Domain 担任 Project 的高层容器。云服务的客户是 Domain 的所有者,他们可以在自己的 Domain 中创建多个 Projects、Users、Groups 和 Roles。通过引入 Domain,云服务客户可以对其拥有的多个 Project 进行统一管理,而不必再向过去那样对每一个 Project 进行单独管理。 简而言之,Domain的引入是为了将多个Project进行封装,成为单一实体再交付给相应的一个客户使用。 问题2:在 Keystone V2中,用户的权限管理是以每一个用户为单位,需要对每一个用户进行角色分配,并不存在一种对一组用户进行统一管理的方案,这给系统管理员带来了额外的工作和不便。 解决:V3引入了Group的概念,Group 是一组 Users 的容器,可以向 Group 中添加用户,并直接给 Group 分配角色,那么在这个 Group 中的所有用户就都拥有了 Group 所拥有的角色权限。通过引入 Group 的概念,Keystone V3 实现了对用户组的管理,达到了同时管理一组用户权限的目的。这与 V2 中直接向 User/Project 指定 Role 不同,使得对云服务进行管理更加便捷。 类比操作系统中的用户组,是批量便捷操作的体现。 Authorization授权功能的应用 授权(Authorization):授予用户在一个服务中所拥有的权限 V3的组织结构 一个 Domain 包含有 3 个 Project,可以通过 Group1 将 Role Sysadmin直接赋予 Domain1,那么 Group1 中的所有用户将会对 Domain1 中的所有 Projects 都拥有管理员权限。也可以通过 Group2 将 Role Engineer 只赋予 Project3,这样 Group2 中的 User 就只拥有对 Project3 相应的权限,而不会影响其它 Projects。 不妨回顾一下,在Openstack组件部署 — keystone(domain, projects, users, and roles)一篇中,我们在domain default内创建了用于管理的project admin、、User admin和Role admin,并且将Role admin赋予了Project admin中的User admin。使得User admin拥有了管理员的权限。当然我们在这个操作中,并没有使用到Group的功能,仍然直接对Tenant中的User分配了角色。 openstack domain create --description "Default Domain" default openstack project create --domain default --description "Admin Project" admin openstack user create --domain default --password-prompt admin openstack role create admin openstack role add --project admin --user admin admin #User admin与Project admin关联,并指定该用户在该租户下的角色Role admin,这样用户admin才能够访问租户admin的资源 Authentication认证功能的应用过程 身份认证(Authentication):令牌Token的发放和校验 Keystone 和其它 OpenStack service之间的交互和协同工作:首先User向Keystone提供自己的Credentials(凭证:用于确认用户身份的数据,EG. username/password)。Keystone会从SQL Database中读取数据对User提供的Credentials进行验证,如验证通过,会向User返回一个Token,该Token限定了可以在有效时间内被访问的 OpenStack API Endpoint和资源 。此后User所有的Request都会使用该Token进行身份验证。如用户向Nova申请虚拟机服务,Nova会将User提供的Token发送给Keystone进行Verify验证,Keystone会根据Token判断User是否拥有执行申请虚拟机操作的权限,若验证通过那么Nova会向其提供相对应的服务。其它Openstack和Keystone的交互也是如此。 所以Keystone在Openstack中所处的位置如下图所示:

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

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

Spring

Spring

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

Rocky Linux

Rocky Linux

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

用户登录
用户注册