近期为公司做的Java方向的技术选型,记录如下:
1、web服务器
使用 Apache服务器(成熟稳定开源的产品,且目前公司内很多项目在其上运行)
2、构建工具
Maven(强大,主流、便利,从项目结构生成,项目依赖包、插件到项目编译、打包)
3、核心框架
选用 spring boot
spring-boot 2.1.x(强大的框架,既有spring的IOC、AOP的全功能,又新增了 统一spring各版本依赖包、简化开发的新特性)
spring-cloud版本 Greenwich(分布式系统一站式解决方案,但是标准中会用到spring-cloud的组件)。
对比dubbo,选用spring-cloud,原因是spring-cloud 更加完备,组件完整,是一套完整的解决方案,而且是基于http-json的协议,对于其他
平台或者语言更加兼容,比如.net core.
严格意义上来说,以上两个都不算是一个框架,而是一套快速开发整合包。
4、日志处理
建议采用 logback
5、搜索引擎
如果有ElasticSearch(基于Lucene,分布式、Restful、成熟、稳定、主流)
6、身份验证框架
如果有,使用shiro(Apache出品,功能全、方便、可靠)
7、消息中间件
Kafka或者rabbitMQ(kafka Apache出品,java编写,RabbitMQ也是很多项目已经使用,成熟、稳定、方便)
使用场景:若项目涉及多模块/服务 之间数据传递/交互,则需要使用消息中间件
8、缓存技术
redis (一套成熟稳定的中间库解决方案)
使用场景:项目中存在数据频繁访问或者并发访问情况,则需要使用缓存。
9、序列化
json格式(文本格式、方便、支持广泛)
用于 前后端交互、api消息等
10、持久化技术
Mybatis或者Mybatis-plus
选用理由:对比 JPA还是选用了 mybatis:
1)mybatis是轻量级框架、灵活、且更容易使用
2)JPA虽然是全自动、且对于不同数据库的支持更好,但是由于后期业务可能更细化调整,所以对于sql优化,sql改写、调整,mybatis 支持更好,另外,现有系统和未来系统基本采用
Oracle数据库,所以不用考虑移植性。
11、数据库
选用 Oracle数据库
选用理由:主流数据库 oracle、mysql、mssqlserver、db2 等,
由于其他的不常用,所以只对比 oracle 与 mysql
mysql 的优势在于 开源、免费、可定制化修改
oracle的优势在于 性能、安全、综合管理能力更强,。
考虑公司不需要对数据库做更深入的定制化管理,且考虑安全、性能和已经购买过的特性,推荐Oracle。
而且公司现有项目大多使用oracle,两种数据库在语法上有差别,且在数据库使用习惯上也有不同比如主键使用(mysql更像mssqlserver,倾向自增长,而oracle倾向uuid)
再者,考虑到mysql管理工具少,不比oracle有成熟的命令行、图形界面;mysql对于权限安全的管理没有oracle强大;oracle有恢复数据等服务而mysql没有。
所以选用 oracle。
注:如果是爬网等项目使用nosql数据库,建议采用mongo
12、数据库连接
选用连接池技术:
HikariCP或者 druid
13、web框架
不再使用spring-mvc等web技术,使用Restful api和前后端分离的方式。
选择原因:前后端分离,更加解耦合,也适合后端部分容器化,且将来可以实现一套后台对应pc端、移动端。
更加适合后端加入微服务治理
14、前端技术
vue全家桶、css3.0
选择原因:现有项目均采用前后端分离技术,所以在技术选型中去除了spring-mvc等web框架的使用,
注解:(若是将来不加入微服务治理的纯web项目:可以考虑 spring-mvc框架,前端技术采用 site-mesh+freemarker或着thymeleaf)
15、接口文档
swagger2,(和spring-cloud结合很好,也能单独使用,无其他替换方案)
16、监控和保护(spring-cloud实现组件,可选)
如果有,那么
断路器保护 hystrix(hystrix框架可通过隔离服务间的访问点、停止他们之间的级联故障、提供可回退操作来实现容错)
链路跟踪,选用sleuth框架集成zipkin 来实现(sleuth是springcloud提供的框架,整合zipkin后,即可进行服务跟踪、数据分析等操作)
17、网关及服务治理(spring-cloud实现组件,可选)
如果有,那么都是选择springcloud提供的组件
服务治理选择 Eureka,注册发现服务
服务端负载均衡选用 Ribbon,用于对服务调用的负载均衡
网关选用 Zuul,实现网关集群。
18、其他部分
访问协议:ssl 即https 方式(安全性考虑)
代码管理:采用现有统一的 svn代码管理(专有服务器,安全性考虑)
容器化引擎:使用Docker为容器化引擎配合,后期加入容器编排解决方案考虑使用kubenetes(spring-cloud实现组件,可选)
物理服务器:基于linux操作系统,选用 centos 7.x及以上版本。
整体结构如下: