中间件|分布式项目中，选型与依赖管理 Java

文章图片

文章图片

文章图片

\">
JAR包：如果我依赖你，那劝你别依赖我。

一、技术视野1、背景描述
在分布式系统搭建的初期，对于组件的选型是需要慎重考虑的，特别是对于同一个场景但是有多个不同组件可选项时，需要经过一定的调研再去确定最终选择，从而尽量避免后期业务发展引起核心组件的替换问题。
不同的技术选型，意味着不同的依赖包和版本，作为工程的基础，复杂的系统中管理庞大的依赖，需要具备体系化的思维。
2、开源体系

从个人习惯上来看，在核心的技术组件选型上，优先考虑从Spring和Apache两个生态中寻找，所以要对这两套开源体系下的组件有广泛的了解，以及相关配套的集成工具，在开发过程中有很多复杂的技术实现都是有对应的封装包来解决，更多的时候是不熟悉或没注意到；
再者就是很多热门的开源项目，这里理解为针对某个场景可以提供更好的解决方案，比如缓存或者任务调度等，在这个选择中可以优先关注大厂的开源组件，经过复杂业务的考验会相对成熟和稳定。
大部分情况下技术需求基于现有开源生态都是可以寻到相应的解决方案，所以定期关注开源组件的发布更新，对于开阔思路和视野有极大的帮助。这里从广泛的角度看开源体系，实际的项目中是有很多轻量级的工具包，可以简化代码和提升效率。
二、框架层面
1、JDK版本
对于核心框架的依赖，除了选型这个方面，还要考虑的就是版本问题，对于很多小厂来说更多的是处在一种\"等待\"的状态，等待开源市场给出更合理的选择。
就从JDK的选择来看，作为Java工程中最底层的依赖，很多项目都是从JDK5直接跳跃到JDK8的，多数开源组件的最低依赖也需要JDK8 ，从版本的发布上看也就算个中间版。
所以在核心依赖上优先考虑使用最多的版本，至于后续要升级到什么版本，稍微留心注意下就会知道。如果版本过旧会和大多数组件冲突，如果版本过新要适配突发的问题，从选择上看不算特别明智。
【中间件|分布式项目中，选型与依赖管理】2、核心框架
核心框架依赖的选择，需要遵守一个体系的原则，例如在Java工程中必选的Spring体系，在微服务的架构设计中，对于服务注册发现，通信请求，网关路由等功能组件，都可以围绕SpringCloud的相关集成去做选择，这样可以有效减少技术带来的负担，并且具有活跃的社区和详细的文档支撑。
三、单工程分层微服务的架构中，针对单服务的工程代码也会分包管理，不同分层的包管理特定性质的代码文件，除了各个服务依赖公共包core(常见命名)之外，通常至少划分bean、feign、serve三层：

core：各个服务依赖的基础包，封装技术层面的解决方法，或业务的复用功能；
bean：工程对象(入参出参)和常量管理，一般不包括数据表的映射对象；