从0-1 的java 后端工程项目设计及其反思
作者：互联网
工程项目分层架构回顾
项目启动前的模块划分设计
项目实践后，相关的模块划分还是相对比较合理的，但有些细化和优化，通过idea 的模块依赖图，生成的组件依赖图为
举例其 实现细节处，如 assignmentImpl,classroomimpl,userimpl 模块
自动生成的依赖图，可能显得不是很明显， 在之前没有预想到的，是 baseconstants 这块，这块有些内容校验和安全校验的基本接口，和基本 enum ,action 变量， 因为把内容校验，合理性校验，前置到 DTO层，这样的话，对于前端来的内容就可以统一控制。
通过业务模块，划分模块的方式还是相对合理，如果后面模块拓展，单独拆成微服务也就是很快的事情，因为前期已经做了代码隔离。
项目中可待优化点思考
- 关于 外部信息注入的思考，这里的外部信息 指的是通过 cookie 或者 header 带过来的用户注册信息， 比如说用户信息吧 ，之前 抽象出 LoginInfoHolder ，并且把依赖下沉到底层依赖，这样的话， 各个模块需要当前用户信息的时候就可以简单注入当前的用户信息。 用户信息拦截在 前端流量接入层，也就是web controller 层，加interceptor 来进行拦截，并将用户或者其他信息 注入 LoginInfoHolder. 后来思考了一下， 如果 不把 这个LoginInfoHolder 放到底层依赖，只放到前端流量接入层，也就是 web controller 层，这样的话，每次从 controller 层 到 业务 buiness service层，需要传递用户 参数， 但是这样的好处是，能给我们的单测接口带来极大的便利， 因为单测的时候，我们可以通过业务接口调用，来模拟网络层的接入，而且信息完备， 不用费力模拟 cookie 和 header 带的一些加密信息， 虽然看起来 业务 buiness 层，好像每个方法都需要传递当前用户参数 uid ，好像是麻烦了一些，但是 数据流的流向却变得很清晰（相当于不要全局数据当前访问用户信息这个概念)，易于模拟和测试。这个理念可以在后期 实现的时候进行优化思考 实施。
照着1中的实施的话，为保证完善，可以先通过大服务接口的单元测试，就能测出较多的明显幼稚的问题。
2. 列表的查询，没有用到缓存优化， 当qps大的时候，单查数据库带来很大的压力。而且作业，班级列表，这两块大部分时候可能变化不大， 在业务列表的 Cache使用这块， 可以考虑用一个 统一的标志 方式（声明式的方式） 声明特定的返回结构，重点在于，列表可缓存不容易遗忘的方式，在列表内容改变的时候，又要注意能及时删除缓存，不会造成缓存污染，这其中的代码实现方式还需要思索一下，最好能进行 强约束，用隐藏式约束，在团队配合的情况下，总会有人没有思考到缓存过期，失效的问题，所以这就要求设计者，做出强制性要求的设计，而不只是字面或者口头约束，要让缓存真正成为利器，而不只是辅助。在首页或者调用量大的地方，缓存的使用很有必要，不然导致db压力激增。
- 比较普通的处理方式就是，使用jetCache 的 @Cached 和 @CacheInvailed 方式来缓存
3. 权限校验前置的思考也是较为合理的，内容安全，和参数合理性校验前置比较合适，前置到 web 接入层,利用好aop的能力
4. 关于删除操作，要删除关联的数据思考，防止没有完全数据的删除，也就是删除欠缺。
5. 微服务 可以通过路径，子路径来区分 微服务里面的微服务，完全服务gateway 的predicate
项目中的坑点和解决分析
- 前端的跨域问题， 刚开始往 网关去查 发现 gateway 没有流量进入，这时候就应该怀疑是 LB层（nginx) 自行处理了 跨域问题，去 nginx 配置文件一查，果然就是，解决。
- 跨域允许header 也需要单独配置，需要注意。如果nginx 处理了跨域，就不用在 api网关层或者微服务层去允许跨域了。
- 外部依赖调用的时候，要注意 超时问题， 不能默认三方依赖服务稳定，要处理好异常状态。 例如 腾讯的内容校验接口， 当图片大小较大，安全校验时长就很长，这时候多张图片统一校验的时长就不可接受，就要考虑内容校验时机，应该考虑的是
分而治之的策略，把调用时机分摊到每张图片上传的时候，如果校验失败，告知前端，校验失败，前端不会显，这样不会给用户用时很久的感觉，也能带来较好体验，因为用户当即能知道哪个图片内容违规
4. 不要乱删账号，删了测试账号，没有删除关联关系的时候，后面又要花些没有必要的时间去排查异常，这些异常还是自己不合规操作造成的。
标签：缓存,java,跨域,校验,信息,用户,工程项目,模块,反思 来源： https://blog.csdn.net/dongjijiaoxiangqu/article/details/113259274