持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第21天，点击查看活动详情
随着服务化不断普及，单体应用逐渐演进为一个个独立部署的微服务，这自然导致耗时更多的（相对于jvm内部调用）远程Api调用越来越常见；而另外一方面我们对服务的性能要求越来越苛刻，通常要求服务响应时间<500ms，挑战很大；所以，并发处理自然成为重要的性能提升手段，这不仅仅是因为并发处理可以提高多核CPU利用率，更加重要的是，绝大多数的微服务天然就是一个偏IO型的系统，因为线程很多处于Blocked状态，在等待网络响应和DB磁盘响应，内 存和CPU压力并不大，所以适当加大并发度有其合理性的；
但是团队在无约束的Java多线程编码的过程中，问题暴露非常多，主要包括：
1). 多线程对开发人员技能门槛要求高，不易写好，BUG多，多线程BUG本就是偶发不易稳定复现；
2). 开人员必须自己处理线程/线程池、阻塞、回调，线程操作和业务代码焦灼在一起混沌不清；
3). 在多线程里面随意做DB修改操作，使功能完全丧失了事务保护（Spring的事务保护是基于线程上下文的）
4). 模式五花八门，有直接使用Thread的，有使用CompletableFuture的，有使用第三方线程池的......，很多的误用；
5). 缺少保护机制，很多没有使用线程池，有些是每个功能点自己私开线程池，使得系统整体处于不可控状态；
6). 缺少配置化、监控机制、优雅关闭等好的配套措施；
为了解决上述问题，减少并发编程过程中产生的问题、让开发人员专注业务逻辑，开发了统一的并行处理组件，
提供如下特性：
1). 开人员沿用命令式的编程习惯，不需直接操作任何线程相关内容就可以达到并发编程目的；
2). 线程池集中管理，避免分散和不可控；
3). IO型线程池,更加适合微服务系统特点，吞吐量大，线程切换成本少；
4). 提供线程池灵活配置、并行任务自动分批；
5). 提供线程的优雅关闭（可配置）；
6). 提供完备的线程池的监控机制(可配置)；
7). 提供并行处理的事务解决方案（最终一致性）；
8). 和底层实现框架完全接口隔离，便于后续升级或切换；
