持续Java学习中

开发中常见案例就是，开发任务进行到一半，发现之前技术方案中的做法有问题，于是推翻重来，这是我们都不愿意看到的。当然根据我在实际工作中的观察，如果需求影响面很大，基本都无法难盘点到每一个影响点，那问题就变成了如何尽可能多的盘点。本文亦在分享一个基础版的技术方案模板，让大家在编写技术方案时，能够在一个相对完整的方案流程中，根据自身团队及业务需求的特性，快速上手，提高编写技术方案效率，最终形成自己编写技术方案的方法论

看了大部分的消息中心解决方案，发现大家的中心思想都大差不差，区别基本都是在符合自身业务场景的做了一些定制化处理。本文为我对消息中心基本骨架的知识梳理，亦在帮助大家对消息中心设计有一个基本的理解。

写在前面，最近被分配了一个技术任务，简单描述为自研框架（类比Spring）整合一个微服务网关，并且能用就行。有人可能会问，想用微服务网关，不是直接引入zuul或者gateway相关的依赖，然后配置一下不就好了吗？为什么我还会写这篇博客。这里原因主要有两个：1. 框架是自研的，虽然底层也是基于Spring构建，但Spring MVC部分完全不一样，执行流程需要研究2. 这些微服务网关都是基于Spring Boot的自动装配机制实现的（根据名字其实我们也不难理解，毕竟都是spring-cloud-xx

文章目录Task任务有问题的版本修改后的版本一修改后的版本二最近在看处理一个Bug的时候，发现了自己之前写的代码的一些问题，还好后来自己提出了优化，修改掉了。特作此记录。项目背景：我需要根据集合中的数据记录，将每一条数据封装为对应的报文，然后调用发送给外部接口，最后解析对应的返回报文，最终将数据落库。由于数据库的数据记录比较多，所以这个操作是一个十分耗时的操作，所以我第一反应就是使用多线程进行处理，最终我决定使用线程池进行该任务的操作。下列代码我根据真实的项目代码抽象而来。Task任

文章目录一、亲身案例二、改进方式三、原理分析该篇博客为总结自己曾写下的Bug一、亲身案例当时的场景为：在controller层获取一笔交易单的信息（前台传给controller层为Map类型的键值对），然后controller层直接将这个Map参数对象转发给Service层，在Service层进行一个对象属性的封装，继而调用mapper层接口完成数据的持久化。问题出现在Service层，由于这一笔交易单信息会涉及多张表的数据信息，为了代码结构的优美，我特地在Service层的方法中，调用同类