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

一、技术视线

1、背景形容

在分布式系统搭建的初期，对于组件的选型是须要慎重考虑的，特地是对于同一个场景然而有多个不同组件可选项时，须要通过肯定的调研再去确定最终抉择，从而尽量避免前期业务倒退引起外围组件的替换问题。

不同的技术选型，意味着不同的依赖包和版本，作为工程的根底，简单的零碎中治理宏大的依赖，须要具备体系化的思维。

2、开源体系

从集体习惯上来看，在外围的技术组件选型上，优先思考从Spring和Apache两个生态中寻找，所以要对这两套开源体系下的组件有宽泛的理解，以及相干配套的集成工具，在开发过程中有很多简单的技术实现都是有对应的封装包来解决，更多的时候是不相熟或没留神到；

再者就是很多热门的开源我的项目，这里了解为针对某个场景能够提供更好的解决方案，比方缓存或者任务调度等，在这个抉择中能够优先关注大厂的开源组件，通过简单业务的考验会绝对成熟和稳固。

大部分状况下技术需要基于现有开源生态都是能够寻到相应的解决方案，所以定期关注开源组件的公布更新，对于宽阔思路和视线有极大的帮忙。这里从宽泛的角度看开源体系，理论的我的项目中是有很多轻量级的工具包，能够简化代码和晋升效率。

二、框架层面

1、JDK版本

对于外围框架的依赖，除了选型这个方面，还要思考的就是版本问题，对于很多小厂来说更多的是处在一种"期待"的状态，期待开源市场给出更正当的抉择。

就从JDK的抉择来看，作为Java工程中最底层的依赖，很多我的项目都是从JDK5间接跳跃到JDK8的，少数开源组件的最低依赖也须要JDK8，从版本的公布上看也就算个两头版。

所以在外围依赖上优先思考应用最多的版本，至于后续要降级到什么版本，略微留心留神下就会晓得。如果版本过旧会和大多数组件抵触，如果版本过新要适配突发的问题，从抉择上看不算特地理智。

2、外围框架

外围框架依赖的抉择，须要恪守一个体系的准则，例如在Java工程中必选的Spring体系，在微服务的架构设计中，对于服务注册发现，通信申请，网关路由等性能组件，都能够围绕SpringCloud的相干集成去做抉择，这样能够无效缩小技术带来的累赘，并且具备沉闷的社区和具体的文档撑持。

微服务的架构中，针对单服务的工程代码也会分包治理，不同分层的包治理特定性质的代码文件，除了各个服务依赖公共包core(常见命名)之外，通常至多划分bean、feign、serve三层：

这样分层分包治理工程，服务之间的依赖就会清晰许多，也极大的保障了代码的复用性，版本升级时弃用的代码标记为过期，同时指向新的代码门路，其余服务降级时再追随降级，最终彻底剔除过期代码，以此防止业务倒退导致代码工程的凌乱。

中间件在服务中是必不可少的业务撑持，例如开发中最罕用的几个：缓存治理、音讯队列、任务调度等；

音讯队列：能够通过模式封装，实现音讯的对立总线治理，防止音讯凌乱；例如之前总结过的消息中间件革新计划：

缓存治理：每个服务都或多或少存在缓存需要，缓存机制也具备肯定的共性；

任务调度：通常会将任务调度的组件集成在单个服务中，实现调度治理的根本能力，而后采纳服务间通信机制（例如Feign接口），去触发待工作执行；

中间件并不仅仅是引入依赖而后各种API的调用，基于什么策略和设计模式去治理，会给工程带来不同的影响。

许多我的项目下都会有一个util分包，用来寄存罕用的工具代码文件，如果是在简单的分布式我的项目中，通常打成独立的jar包，起初这些根底的工具类被汇聚到开源我的项目中，极大的升高保护老本，并且能够标准化的应用工具：

对于工具包中提供哪些外围能力，常常查阅相干文档即可，像一些：日期、字符串、汇合、JSON、Http、文件流等常见性能，都会封装相应的解决办法。lombok插件能够高度简化Java对象中代码，以及对象的应用。

工具型的组件，更偏向于在开发过程中明确规定应用哪一个，尽量避免混搭应用，并且要相熟工具包提供的各种能力，缩小不必要的反复封装，对于类库中的罕用办法也能够多浏览，被少数开发认可的代码，必然能够宽阔本人的代码编写思路。

最初，很多技术栈或者开源组件的一直倒退，都是为了能够更好的解决场景问题，这就须要开发人员定期关注技术的发展趋势，具备技术视线和洞察能力。

利用仓库：https://gitee.com/cicadasmile/butte-flyer-parent组件封装：https://gitee.com/cicadasmile/butte-frame-parent