返回顶部

Java开发中那些非常好用的主流技术工具

[复制链接]
东方不buyLv.1 显示全部楼层 发表于 2022-7-8 17:25:44 |阅读模式 打印 上一主题 下一主题
  最近几年,Java的技术栈发展得非常快,成百上千的技术工具正不断地涌出来,这也造成了一个问题:

  我们作为开发者,到底应该选哪些工具搭建出最合适的技术栈呢?

  今天我就推荐一波我常用的工具和框架,这些也是最核心的每个人都会用到的工具和中间件。

  一、项目工具

  1.1IDE

  主流的Java开发工具现在非IntelliJIDEA莫属。前几年,可能Eclipse还能和IDEA一争高下,到了现在已经基本是IDEA的天下了。

  就拿我自己来说吧,我最早用IDEA,后来用了几年Eclipse,再后来又用回了IDEA。

  包括我身边的程序员,之前用Eclipse的人,这几年不少人都换成用IDEA了。

  如果你问我用IDEA到底哪最爽,我觉得有3点:

  代码智能提示,爽!

  代码自动生成,爽!

  代码调试,爽!

  而这3点,恰恰就是能极大提高程序员开发效率的3点。所以建议做Java后端开发的程序员,可以优先考虑IDEA作为开发工具。

  1.2版本管理工具

  对于项目中的代码版本管理工具,Git已经处于垄断地位了,新项目的话不需要再考虑SVN、CVS了。

  之所以Git现在处于垄断地位,主要胜在2点:

  Git是分布式的,不会因为版本管理服务器崩溃导致完整的代码历史版本丢失。

  Git创建分支是非常廉价的操作,可以随意创建分支,从而使并行开发很容易落地。而SVN、CVS这些版本管理工具创建分支则非常笨拙,并行开发非常麻烦。

  上述第1点大大提升了代码资产的安全可靠程度;第2点则完美适应当代的敏捷开发需求。也因此,Git大行其道就不足为怪了。

  1.3构建工具

  Java项目的构建工具现在是龙争虎斗,业内一般有两个选择:Maven和Gradle。

  如果是后端的Java项目,那绝大部分用的还是Maven去构建项目。如果是前端的Android项目,则选择Gradle。

  Gradle本身要比Maven先进很多:它配置灵活,性能优秀,真的是个非常优秀的构建工具。

  那为什么在后端Java项目构建的时候,大部分用的还是Maven呢?

  因为Gradle本身太过灵活了,这种灵活带来了两个和后端项目构建特性不太匹配的问题:

  Gradle因为灵活,所以用法规则多变,导致学习门槛过高——后端项目本身的构建流程,套路比较死板,变化非常少,所以不需要太多的构建特性、构建规则。也就是说,灵活本身引入的多种用法、规则、特性对后端项目意义不大,为了构建工具本身的使用,去投入时间学习,本身性价比不高。

  上面说了,后端项目本身的构建流程是比较套路化的,需要进行一些强约束,去保证这种套路的可靠与稳定。而Gradle因为本身比较灵活的配置规则,反而失去了Maven的那种强约束,这就很可能因为失去了约束,从而造成团队在使用Gradle的时候,出现各种冲突和潜在的错误,造成项目构建的不稳定,这对后端项目来说是得不偿失的。

  二、开发框架

  2.1Web框架

  现在的Web项目开发,大部分都转向了SpringBoot了。使用SpringBoot有三个最大的好处:

  配置非常少,可以说是即插即用。

  基于Spring构建,入手门槛非常低。

  直接运行,不需要再考虑Web容器的问题。

  SpringBoot大部分人都很熟了,不再赘述了。

  2.2持久层框架

  项目开发中用到的持久层框架,基本有两类:

  Mybatis系列衍生框架。

  JPA系列衍生框架。

  在国内来讲,大部分持久层框架还是首选Mybatis,貌似在国外大部分项目是用的JPA框架。

  在我看来,互联网项目、toC的项目更适合Mybatis,toB的项目更适合JPA。

  toC项目的业务需求经常是灵活多变的,所以,往往它需要项目的技术也要跟着灵活多变,而Mybatis本身就是SQL的简单封装,很容易加表加字段、改SQL。

  而toB项目则不一样,需求基本比较稳定,设计好的数据模型不会频繁变化,所以不太需要Mybatis的灵活性,反而更需要对随意修改模型进行一系列的强约束。而这也是JPA自身的特性:非常规范,且有众多约束,要改JPA的数据模型成本比较大。

  因此,大家选持久层框架的时候,要看清项目的特性,根据实际情况选择用Mybatis还是JPA。

  2.3RPC框架

  现在Java项目的架构,基本都在转向分布式架构。分布式系统的整合,核心就是RPC,因此很多项目中都引入了RPC框架。

  RPC框架,现在用的比较多的是Dubbo框架。

  Dubbo性能非常好:

  很多RPC框架底层使用的通信协议是HTTP,而Dubbo则选择了TCP协议作为通信协议。仅从性能上来说,TCP的性能肯定要比HTTP好上许多。

  而且Dubbo自身还大量使用了NIO异步编程去进一步做了性能优化。

  所以,如果项目中需要使用RPC,可以首先考虑Dubbo框架。

  三、中间件

  3.1Web服务器

  现在的Java开发,由于大部分使用了SpringBoot,所以以前大家常用的什么Tomcat、Jetty、Resin等Web容器都不怎么单独部署使用了。

  但是,有一个Web容器反而还愈加兴旺起来,这就是Nginx。

  Nginx在Java项目开发里,地位是非常特殊的。它在Java项目架构里起到了两个作用:

  处理静态资源请求的Web容器——Nginx在Java项目中,专门负责处理对图片、html、js、css等这类静态资源的Http请求。

  反向代理做分发——除了做专门处理静态资源请求的Web容器之外,Nginx同时还会把对servlet、controller等这些动态资源的请求,转发给后面的SpringBoot中内置的Tomcat容器。

  多说一句,因为反向代理这个特性,Nginx后面会被部署上集群,Nginx在转发请求的时候,同时也会做负载均衡的请求分发的反向代理。

  3.2消息队列

  如今,大家做架构越来越趋向分布式架构。分布式架构里,常用的通信手段,除了网络请求,就是消息队列了。

  现在主流的消息队列框架有RabbitMQ、RocketMQ、Kafka等。

  RabbitMQ性能虽然低一些,但是容易上手,更适合用在中小项目。

  另外,做金融领域相关项目,用消息队列的话可以优先考虑RabbitMQ,原因有以下两点:

  RabbitMQ是AMQP协议的实现,而AMQP协议本身就是来自于金融行业的软件专家们联手制定的,非常成熟和全面,已经成了工业标准。

  RabbitMQ是Erlang写的,Erlang的虚拟机对内存和CPU过载的保护非常成熟,也因此塑造了Erlang应用本身的可靠和健壮。

  大项目、非金融项目,大家可以在RocketMQ、Kafka这两者之间选择。

  RocketMQ和Kafka差不多90%的功能和概念都是相通的,只是RocketMQ在Kafka理念的基础上做了一些改进,适用的业务场景也更广泛。

  在流数据处理上,大家应该优先考虑Kafka,原因是Kafka的流数据处理生态更加的完善周全。

  3.3数据库

  互联网领域,主流数据库就是MySQL。在一些传统行业,比如银行,Oracle用得不少。

  Oracle贵,互联网项目的一个特点就是数据库服务器数量贼多,如果用Oracle的话,成本太高了。

  而且大家越来越有版权意识,国家对这方面也抓得越来越紧,所以,在互联网领域几乎都在用MySQL。

  使用MySQL,常见的有MHA方案——MySQL的高可用方案,基本架构就是一主两从。当主机出故障了,从机就会被提升为主机。

  3.4外置缓存

  对于高并发的架构,外置缓存不可或缺,其中最最最常见的就是Redis。

  之所以大家都采用Redis做外置缓存,原因有三点:

  Redis本身性能非常好。

  Redis有很多数据结构去适配不同的业务缓存需求。

  Redis的集群高可用方案和分片存储的高性能方案相对成熟。

  以上,就是Java开发中经常遇到的主流技术工具了。

  免责声明:以下文章来源于四猿外,作者四猿外

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

达内教育:成立于2002年。致力于面向IT互联网行业,培养软件开发工程师、测试工程师、系统管理员、智能硬件工程师、UI设计师、网络营销、会计等职场人才 达内使命:缔造年轻人的中国梦、缔造达内员工的中国梦 达内愿景:做管理一流的教育公司
  • 商务合作

  • 微信公众号

  • Powered by Discuz! X3.4 | Copyright © 2002-2021, 达内教育 Tedu.cn
  • 京ICP备08000853号-56 |网站地图 | 京公网安备 11010802029508号