Dubboamp;hsfamp;Spring-cloud的区别
Dubbo:
简介:Dubbo是一个分布式服务框架,以及SOA治理方案。其功能主要包括:高性能NIO通讯及多协议集成,服务动态寻址与路由,软负载均衡与容错,依赖分析与降级等。
底部NIO基于netty框架;
HSF:
简介:HSF提供的是分布式服务开发框架,taobao内部使用较多,总体来说其提供的功能及一些实现基础:
1.标准Service方式的RPC
1)、Service定义:基于OSGI的Service定义方式
2)、TCP/IP通信:
IO方式:nio,采用mina框架
连接方式:长连接
服务器端有限定大小的连接池
WebService方式
3)、序列化:Hessian序列化机制
2.软件负载体系
3.模块化、动态化
4.服务治理
性能:
Dubbo & HSF compare
Dubbo优点:
1. Dubbo比HSF的部署方式更轻量,HSF要求使用指定的JBoss等容器,还需要在JBoss等容器中加入sar包扩展,对用户运行环境的侵入性大,如果你要运行在Weblogic或Websphere等其它容器上,需要自行扩展容器以兼容HSF的ClassLoader加载,而Dubbo没有任何要求,可运行在任何Java环境中。
2. Dubbo比HSF的扩展性更好,很方便二次开发,一个框架不可能覆盖所有需求,Dubbo始终保持平等对待第三方理念,即所有功能,都可以在不修改Dubbo原生代码的情况下,在外围扩展,包括Dubbo自己内置的功能,也和第三方一样,是通过扩展的方式实现的,而HSF如果你要加功能或替换某部分实现是很困难的,比如支付宝和淘宝用的就是不同的HSF分支,因为加功能时改了核心代码,不得不拷一个分支单独发展,HSF现阶段就算开源出来,也很难复用,除非对架构重写。
3. HSF依赖比较多内部系统,比如配置中心,通知中心,监控中心,单点登录等等,如果要开源还需要做很多剥离工作,而Dubbo为每个系统的集成都留出了扩展点,并已梳理干清所有依赖,同时为开源社区提供了替代方案,用户可以直接使用。
4. Dubbo比HSF的功能更多,除了ClassLoader隔离,Dubbo基本上是HSF的超集,Dubbo也支持更多协议,更多注册中心的集成,以适应更多的网站架构。
Dubbo在安全机制方面是如何解决的?
Dubbo主要针对内部服务,对外的服务,阿里有开放平台来处理安全和流控,所以Dubbo在安全方面实现的功能较少,基本上只防君子不防小人,只防止误调用。
Dubbo通过Token令牌防止用户绕过注册中心直连,然后在注册中心上管理授权。Dubbo还提供服务黑白名单,来控制服务所允许的调用方。
HSF优点:
1.HSF框架采用 Netty + Hession数据序列化协议实现服务交互,Netty + Hession的组合在互联网高并发量的场景下,特别是在TPS 上达到10w 以上时,性能和效率远比REST 或者Web Service 高。
2.HSF框架的容错机制,配置服务器是采用长连接的方式与服务节点进行网络通讯,一旦发现有服务提供者实例出现故障,配置服务器在秒级就会感知到,此时会将出问题这台服务提供者的信息从该服务的服务器列表中删除,并将更新后的服务器列表采用推送的方式同步给与该服务相关的所有服务调用者端,这样当下次服务调用者再进行此服务的调用时,就不会因为随机的方式再次对已经停止服务提供的服务器发起服务的调用。
3.HSF框架的线性扩展支持
Spring cloud:
Spring Cloud为开发人员提供了快速构建分布式系统中的一些通用模式(例如配置管理,服务发现,断路器,智能路由,微代理,控制总线,一次性令牌,全局锁,领导选举,分布式 会话,群集状态)。 分布式系统的协调引出样板模式(boiler plate patterns),并且使用Spring Cloud开发人员可以快速地实现这些模式来启动服务和应用程序。 它们可以在任何分布式环境中正常工作,包括开发人员自己的笔记本电脑,裸机数据中心和受管平台,如Cloud Foundry。
Dubbo和spring cloud的区别 : 两个框架的定义层面也不一样,么办法比较,具体可以参照项目需求来选择;
Spring Cloud与Dubbo对比
那么第一次实施微服务架构时,我们应该选择哪个基础框架更好呢?
以下内容均为作者个人观点,知识面有限,如有不对,纯属正常,不喜勿喷。
Round 1:背景
Dubbo,是阿里巴巴服务化治理的核心框架,并被广泛应用于阿里巴巴集团的各成员站点。阿里巴巴近几年对开源社区的贡献不论在国内还是国外都是引人注目的,比如:JStorm捐赠给Apache并加入Apache基金会等,为中国互联网人争足了面子,使得阿里巴巴在国人眼里已经从电商升级为一家科技公司了。
Spring Cloud,从命名我们就可以知道,它是Spring Source的产物,Spring社区的强大背书可以说是Java企业界最有影响力的组织了,除了Spring Source之外,还有Pivotal和Netfix是其强大的后盾与技术输出。其中Netflix开源的整套微服务架构套件是Spring Cloud的核心。
小结:如果拿Dubbo与Netflix套件做对比,前者在国内影响力较大,后者在国外影响力较大,我认为在背景上可以打个平手;但是若要与Spring Cloud做对比,由于Spring Source的加入,在背书上,Spring Cloud略胜一筹。不过,英雄不问出处,在背景这一点上,不能作为选择框架的主要因素,当您一筹莫展的时候,可以作为参考依据。
Round 2:社区活跃度
我们选择一个开源框架,社区的活跃度是我们极为关注的一个要点。社区越活跃,解决问题的速度越快,框架也会越来越完善,不然当我们碰到问题,就不得不自己解决。而对于团队来说,也就意味着我们不得不自己去维护框架的源码,这对于团队来说也将会是一个很大的负担。
下面看看这两个项目在github上的更新时间,下面截图自2016年7月30日:
- Dubbo : https://github.com/dubbo
最后更新时间为:2016年5月6日
- Spring Cloud : https://github.com/spring-cloud
最后更新时间为:12分钟前
可以看到Dubbo的更新已经是几个月前,并且更新频率很低。而Spring Cloud的更新是12分钟前,仍处于高速迭代的阶段。
小结:在社区活跃度上,Spring Cloud毋庸置疑的优于Dubbo,这对于没有大量精力与财力维护这部分开源内容的团队来说,Spring Cloud会是更优的选择。
Round 3:架构完整度
或许很多人会说Spring Cloud和Dubbo的对比有点不公平,Dubbo只是实现了服务治理,而Spring Cloud下面有17个子项目(可能还会新增)分别覆盖了微服务架构下的方方面面,服务治理只是其中的一个方面,一定程度来说,Dubbo只是Spring Cloud Netflix中的一个子集。但是在选择框架上,方案完整度恰恰是一个需要重点关注的内容。
根据Martin Fowler对 微服务架构 的描述中,虽然该架构相较于单体架构有模块化解耦、可独立部署、技术多样性等诸多优点,但是由于分布式环境下解耦,也带出了不少测试与运维复杂度。
根据微服务架构在各方面的要素,看看Spring Cloud和Dubbo都提供了哪些支持。
Dubbo | Spring Cloud | |
---|---|---|
服务注册中心 | Zookeeper | Spring Cloud Netflix Eureka |
服务调用方式 | RPC | REST API |
服务网关 | 无 | Spring Cloud Netflix Zuul |
断路器 | 不完善 | Spring Cloud Netflix Hystrix |
分布式配置 | 无 | Spring Cloud Config |
服务跟踪 | 无 | Spring Cloud Sleuth |
消息总线 | 无 | Spring Cloud Bus |
数据流 | 无 | Spring Cloud Stream |
批量任务 | 无 | Spring Cloud Task |
…… | …… | …… |
以上列举了一些核心部件,大致可以理解为什么之前说Dubbo只是类似Netflix的一个子集了吧。当然这里需要申明一点,Dubbo对于上表中总结为“无”的组件不代表不能实现,而只是Dubbo框架自身不提供,需要另外整合以实现对应的功能,比如:
- 分布式配置:可以使用淘宝的diamond、百度的disconf来实现分布式配置管理。但是Spring Cloud中的Config组件除了提供配置管理之外,由于其存储可以使用git,因此它天然的实现了配置内容的版本管理,可以完美的与应用版本管理整合起来。
- 服务跟踪:可以使用京东开源的Hydra
- 批量任务:可以使用当当开源的Elastic-Job
- ……
虽然,Dubbo自身只是实现了服务治理的基础,其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现,但是几乎大部分关键组件都能找到第三方开源来实现,这些组件主要来自于国内各家大型互联网企业的开源产品。
RPC vs REST
另外,由于Dubbo是基础框架,其实现的内容对于我们实施微服务架构是否合理,也需要我们根据自身需求去考虑是否要修改,比如Dubbo的服务调用是通过RPC实现的,但是如果仔细拜读过Martin Fowler的 microservices 一文,其定义的服务间通信是HTTP协议的REST API。那么这两种有何区别呢?
先来说说,使用Dubbo的RPC来实现服务间调用的一些痛点:
- 服务提供方与调用方接口依赖方式太强:我们为每个微服务定义了各自的service抽象接口,并通过持续集成发布到私有仓库中,调用方应用对微服务提供的抽象接口存在强依赖关系,因此不论开发、测试、集成环境都需要严格的管理版本依赖,才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题,以及这也会直接影响本地开发的环境要求,往往一个依赖很多服务的上层应用,每天都要更新很多代码并install之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具,这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化,服务提供方和调用方的依赖只是依靠一纸契约,不存在代码级别的强依赖,当然REST接口也有痛点,因为接口定义过轻,很容易导致定义文档与实际实现不一致导致服务集成时的问题,但是该问题很好解决,只需要通过每个服务整合swagger,让每个服务的代码与文档一体化,就能解决。所以在分布式环境下,REST方式的服务依赖要比RPC方式的依赖更为灵活。
- 服务对平台敏感,难以简单复用:通常我们在提供对外服务时,都会以REST的方式提供出去,这样可以实现跨平台的特点,任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时,不得不实现一层代理,用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在,当要对外提供服务时,主要在API网关中配置映射关系和权限控制就可实现服务的复用了。
相信这些痛点也是为什么当当网在dubbox(基于Dubbo的开源扩展)中增加了对REST支持的原因之一。
小结:Dubbo实现了服务治理的基础,但是要完成一个完备的微服务架构,还需要在各环节去扩展和完善以保证集群的健康,以减轻开发、测试以及运维各个环节上增加出来的压力,这样才能让各环节人员真正的专注于业务逻辑。而Spring Cloud依然发扬了Spring Source整合一切的作风,以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体,并继承了Spring Boot简单配置、快速开发、轻松部署的特点,让原本复杂的架构工作变得相对容易上手一些(如果您读过我之前关于Spring Cloud的一些核心组件使用的文章,应该能体会这些让人兴奋而激动的特性,传送门)。所以,如果选择Dubbo请务必在各个环节做好整套解决方案的准备,不然很可能随着服务数量的增长,整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud,相对来说每个环节都已经有了对应的组件支持,可能有些也不一定能满足你所有的需求,但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。
Round 4:文档质量
Dubbo的 文档 可以说在国内开源框架中算是一流的,非常全,并且讲解的也非常深入,由于版本已经稳定不再更新,所以也不太会出现不一致的情况,另外提供了中文与英文两种版本,对于国内开发者来说,阅读起来更加容易上手,这也是dubbo在国内更火一些的原因吧。
Spring Cloud由于整合了大量组件,文档在体量上自然要比dubbo多很多,文档内容上还算简洁清楚,但是更多的是偏向整合,更深入的使用方法还是需要查看其整合组件的详细文档。另外由于Spring Cloud基于Spring Boot,很多例子相较于传统Spring应用要简单很多(因为自动化配置,很多内容都成了约定的默认配置),这对于刚接触的开发者可能会有些不适应,比较建议了解和学习Spring Boot之后再使用Spring Cloud,不然可能会出现很多一知半解的情况。
小结:虽然Spring Cloud的文档量大,但是如果使用Dubbo去整合其他第三方组件,实际也是要去阅读大量第三方组件文档的,所以在文档量上,我觉得区别不大。对于文档质量,由于Spring Cloud的迭代很快,难免会出现不一致的情况,所以在质量上我认为Dubbo更好一些。而对于文档语言上,Dubbo自然对国内开发团队来说更有优势。
Spring Cloud与Dubbo对比
Spring Cloud与Dubbo对比
提到Dubbo,我想顺便提下ESB,目前央视新华社也在用ESB来做任务编排,这里先比较下Dubbo和ESB:
这里我会罗列下常用的一些依赖包,为了更好理解每个依赖所负责的区域,我还是用一张和之前类似的图来展示各块的功能:
Spring Cloud与Dubbo共存方案
一、背景
假设有一个遗留的Dubbo系统,现在想改用Spring Cloud。
由于遗留Dubbo系统比较庞大,短期之内无法完成技术栈的迁移。因此需要“分步走”,即:初期实现两者共存,后期逐步绞杀Dubbo应用,最终实现技术栈的统一。
p.s. 这里并没有贬低Dubbo的意思,仅是按照该场景讨论。
二、头脑风暴
架构迁移、技术栈更换、项目重构时的第一步往往不是“改造”,而是“停止修改”。基于这个原则,个人不太倾向于去立即大幅重构Dubbo应用原先的代码。原因有二:首先是原则问题,更重要的是时间成本、技术风险很难得到控制。
而,假如新编写的Spring Cloud应用去进行迁就,例如:
完全不动Dubbo遗留系统,使用RestTemplate或Feign编写Dubbo(DubboX)的RESTful API客户端代理 —> 有一定的实现复杂度、Dubbo接口改造成RESTful API后,消费方都需要再次修改(开始是代理,后来不用代理,因此有二次修改的问题)。
索性将Spring Cloud应用也整合Dubbo—>存在改造不完整、技术栈不统一、无法约束开发人员用哪种方式API、额外的复杂度的问题(越多的组件、越多的环节意味着越多的坑)。
考虑到一般来讲,遗留系统的改造过程中一般都是新系统调用老系统,很少出现老系统大规模调用新系统的场景(至少我这边目前是这样^_^)。因此,笔者列出几种仅需少量的代码编写成本即可实现Spring Cloud与Dubbo短期/长期共存,并且侵入性较小,同时还允许我们改造遗留Dubbo系统的几种方案,算是抛砖引玉。期待朋友们提出更优雅、成本更小的方案。
三、亮代码
Sample1:借助Ribbon调用Dubbo应用。
优点:
架构不依赖Eureka或其他服务注册组件,借助Ribbon去调用Dubbo微服务暴露的RESTful API;
缺点:
如果Dubbo微服务较多时,均需手动配置,不适合新式的部署环境(例如Docker,因为每次部署IP/端口可能都不同)
Sample2:借助Sidecar
使用Sidecar,Dubbo微服务必须实现健康检查(对于Spring Boot程序即:添加spring-boot-starter-actuator依赖)。
优点:
这种方式下,Dubbo应用也可通过Sidecar调用Spring Cloud微服务的接口,Sidecar是连接Spring Cloud应用于Dubbo应用的桥梁。
可以通过Sidecar传播Dubbo微服务的健康状态到Eureka Server。
缺点:
在于每个Dubbo微服务节点必须额外部署一个Sidecar应用。
在Dubbo微服务调用Spring Cloud微服务时,增加了调用链的长度。(需使用Sidecar转发)
Sample3:借助Eureka实现整合
将Dubbo应用也注册到Eureka上。
优点:
没有多余的组件(除了Dubbo的注册中心ZK)
没有什么局限
缺点:
对于非Spring Boot的应用,改造有一定的成本。
GOING FAR
本项目中几个Demo中,都是手动编码为Dubbo应用开放RESTful API的,实际迁移过程可以借助cglib或者lombok之类的工具,实现从Dubbo接口道RESTful API的转换。本仓库主要还是为大家提供思路,不做具体讨论。
代码下载地址
https://github.com/itmuch/spring-cloud-dubbo-together
总结
通过上面再几个环节上的分析,相信大家对Dubbo和Spring Cloud有了一个初步的了解。就我个人对这两个框架的使用经验和理解,打个不恰当的比喻:使用Dubbo构建的微服务架构就像组装电脑,各环节我们的选择自由度很高,但是最终结果很有可能因为一条内存质量不行就点不亮了,总是让人不怎么放心,但是如果你是一名高手,那这些都不是问题;而Spring Cloud就像品牌机,在Spring Source的整合下,做了大量的兼容性测试,保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西,就需要对其基础有足够的了解。
从目前Spring Cloud的被关注度和活跃度上来看,很有可能将来会成为微服务架构的标准框架。所以,Spring Cloud的系列文章,我会继续写下去。也欢迎各位朋友一起交流,共同进步。
比较spring cloud和dubbo,各自的优缺点是什么?
dubbo由于是二进制的传输,占用带宽会更少
springCloud是http协议传输,带宽会比较多,同时使用http协议一般会使用JSON报文,消耗会更大
dubbo的开发难度较大,原因是dubbo的jar包依赖问题很多大型工程无法解决
springcloud的接口协议约定比较自由且松散,需要有强有力的行政措施来限制接口无序升级
dubbo的注册中心可以选择zk,redis等多种,springcloud的注册中心只能用eureka或者自研
但如果我选,我会用springcloud。
从公司整体规划:我不会选择很久没人维护的dubbo,重启之后也未必是原班人马
从程序员招聘难度:招springcloud的程序员会更好招,因为更新更炫
从系统结构简易程序:springcloud的系统结构更简单、“注册+springmvc=springcloud”,而dubbo各种复杂的Url,protocol,register,invocation,dubbofilter,dubboSPI,dubbo序列化..........炫技的成分更多一些
从性能:dubbo的网络消耗小于springcloud,但是在国内95%的公司内,网络消耗不是什么太大问题,如果真的成了问题,通过压缩、二进制、高速缓存、分段降级等方法,很容易解
从开发难易度:dubbo的神坑是jar包依赖,开发阶段难度极大,我曾经带一个三十人的团队,因为jar包升级问题,把每个人的电脑都操作过,尤其每个人电脑的库路径、命令、快捷键、键盘,鼠标快慢都不一样,那会儿我默默的在心中艹了dubbo发明者全家老小一百二十遍。springcloud比较自由,但带来的问题是无法“强力约束接口规范”,建议用行政方式解决,且我们团队的强力行政约束做的还是比较好的,在接口管控层面比较强效,一个没有行政组织能力的IT团队真的是个废渣,用什么框架都不好使。
从后续改进:dubbo的改进是通过dubbofilter,很多东西没有,需要自己继承,如监控,如日志,如限流,如追踪。springcloud自己带了很多监控、限流措施,但是功能可能和欧美习惯相同,国内需要进行适当改造,但更简单,就是ServletFilter而已,但是总归比dubbo多一些东西是好的
从配套措施:springcloud一直宣称自己是“一套全方面的解决方案”。。。。。。我起初信了,后来发现上当了,实话说:有,但是不是很健全,100分打50的样子,很多你还需要改造。而DUBBO相反,一直宣称自己是“一套全方面的服务化方案”。。。。。。纯服务化顶个鸟用,任何系统都是相辅相成配套的,一个完整的系统,要有前台、中台、后台、前台包括前端和交互,中台包括交易、任务、数据,后台包括财务、账户、管理...........单纯的服务化解决不了“任何问题”,唯有体系才能解决。在这个层面,springcloud是个往“体系”方向发展的方案,而dubbo仅是个工具而已,两者相比,就好比始祖鸟与草履虫的区别。
从技术实力层面:对比双方的源码,不得不说dubbo作者的技术能力要高于springCloud,而springBoot的作者技术能力要高于dubbo。即:springboot>dubbo>springcloud。我喜欢springboot这种大道至简的风格,keep it simple and stupid。而dubbo好嘛......你先看看dubboSPI,再看看Protocol$Adpative里面那一群绕来绕去的瞎几把绕的玩意儿,你会迅速判断出:这群屌丝在炫技。尽管dubbo从上之下分为十层四五十个组件,第一感官上是哇塞好全面好伟大的样子,但深入之后你会觉得,这技术是很炫,设计的确实很全面,但是用不到,例如:请各位大神给我解释一下,在zookeeper地址中,使用逗号分隔和分号分隔地址的区别。。。。。用途不大,但是代码里为了这个就走向了“完全不同”的一条分支。用俗语评价,就是“臃肿且无用代码过多,在文档里还非得为了这个说出123456来”。说完dubbo再说springCloud........它没有技术含量,完全没有,就是一堆简单组件拼装在一起,如configserver、eurekaserver、robin、feignClient、htstrix等,每个都特别简单,没什么技术含量,但我喜欢这种的,就喜欢这种大道至简的简单。
最后说springBoot,我要用“纯粹”两个字来评价这个框架,真的很纯粹,并且从其代码架构的总体思路一致性,目标的纯粹性,具体模块的干净利落,确实是个好框架,值得大家一读。
从系统应用层面:在技术实力满分一百能打85分的鄙人的眼中,dubbo和springcloud,不就是两个框架么?我们是要拯救世界的人,这俩块鹅卵石一块圆的一块方的,能垫脚就行,没有区别。
Dubboamp;hsfamp;Spring-cloud的区别相关推荐
- spring boot和spring cloud的区别_Spring聊聊application和bootstrap
用过Spring 的小伙伴都知道, application.yml或者 application.properties 是Spring 的引导配置文件,但是有了解过其中区别吗?本文将从这个问题入手,深入 ...
- Spring Cloud Alibaba与Spring Cloud的区别
Spring Boot是一个快速开发的脚手架,用来快速创建独立的.生产级的基于spring的应用程序. --特性 无需部署war文件 提供starter简化配置 尽可能自动配置Spring以及第三方库 ...
- spring boot和spring cloud的区别_微服务实战系列(三)-cloud、boot及maven关系
1 . 问题描述 随着springboot.springcloud的不断迭代升级,开发效率不断提升,越来越多的开发团队加入到spring的大军中,今天用通俗的语言,介绍下什么是springboot,s ...
- spring cloud微服务_年后进大厂,必备这份微服务面试题:Dubbo+SpringBoot+Cloud
Dubbo面试题 Dubbo与DubboX区别 Dubbo中zookeeper做注册中心,如果注册中心集群都挂掉,发布者和订阅者之间还能通信么? Dubbo中有哪些角色? Dubbo在安全机制方面是如 ...
- SpringCloud 微服务入门-Spring Cloud 与微服务概述
导语 首先要了解的是微服务是一种架构风格,跟SOA类似.而Spring Cloud 则是实现这种架构风格的一种技术栈.类似于实现SOA架构风格,用到的具体的技术栈就是ESB.博主也在之前的博客中分 ...
- spring cloud微服务_面试败给微服务?别怕,我带你一起手撕Dubbo,SpringBoot与Cloud...
面试居然败给微服务???这是个神马情况??没关系,这次我来带你一起总结Dubbo+Spring Boot+Spring Cloud,让我们一起手撕微服务!!! 01 微服务之Dubbo Dubbo 支 ...
- 【建议收藏】35个Spring Cloud 连环炮
关注"Java后端技术全栈" 回复"000"获取大量电子书 大家好,面试连环炮系列,继续走起,今天给大家分享的Spring Cloud面试连环跑. 需要文章的高 ...
- 【Java学习路线之JavaWeb】Spring Cloud教程(非常详细)
文章目录 读者 阅读条件 微服务是什么 微服务,我们可以从字面上去理解,即"微小的服务",下面我们从"服务"和"微小"两个方面进行介绍. 微 ...
- Spring Cloud基本介绍
✨ Spring Cloud基本介绍 1.微服务中的相关概念 1.1服务的注册与实现 1.2负载均衡 1.3熔断 1.4链路追踪 1.5API网关 2.Spring Cloud的介绍 2.1基本认识 ...
最新文章
- 二叉树中序遍历方法实现
- TC264信标组 双车组 资源规划 库函数示例
- FPGA之道(43)编写纯净的组合或时序逻辑
- 从零开始学_JavaScript_系列(16)——CSSlt;3gt;(文本、对齐、圆角、盒模型、背景)...
- mybatis-plus根据多个字段排序_Mybatis Plus学习笔记(逻辑删除/动态填充/常用插件)...
- SM2 国密算法被 Linux 内核社区接受
- 面试官:如何实现 List 集合去重?
- 同步与阻塞的区别与联系
- 系统设计说明书案例_VAV系统设计要点与案例分析
- python新手入门到放弃_python萌新:从零基础入门到放弃
- 区块链如何推动人力资源和薪酬管理体系变革?
- android指南针校准 代码_Android:指南针的制作
- Android之飞鹅WiFi打印机
- ctfshow 做题 MISC入门 模块1-10
- 我的世界 服务器文件ess,《我的世界》ess指令大全 ess指令作用
- 程序员突破年薪50万的唯一门坎-文档写作能力(一)
- WIN10锁屏久了宕机(死机)解决方案
- 自研数据分析工具——yandas系列一:分析泰坦尼克号沉船事件中的乘客信息表
- MySQL慢SQL探究
- 服务器装系统进pe界面就死机了,电脑可以进入PE系统,但重装就是重启,装不了系统是什么原因?...
热门文章
- python就业班 miniweb框架_Python“mini-web”项目实战再度来袭!同学们厉害了
- 软件测试自动化验证码,自动化测试如何解决验证码的问题
- PHP实现无限级分类(递归+引用)
- GroupDocs.Conversion Crack,强大 .NET 文档转换组件
- Axure 9 实战案例,基本元件的应用 5,利用情形实现B站图文登录验证
- 如何强迫您的Apple Watch与iPhone同步
- dnf选择服务器显示数字,DNF:遴选属性如何选择?两种方法精确找到最优解
- 2015阿里看雪移动安全挑战赛-第二题
- 高级软件工程第六次作业:“希希敬敬对”团队作业-3
- 读华为副总裁徐家骏总结的个人心得