配置框架整改思路

原则：当前只提疑问和思路，只关注框架和概念，不关注细节和实现。
目标：做到框架和业务的最大限度的解耦，以便于问题的界定和定位，减轻框架的负担，提高框架敏捷性。

1.模板的适配和解析：
   当前：框架提供扩展点，所有业务模块自己适配，然后统一由框架 解析 并 保存 在框架数据库中；

   思路：这部分有两点可以考虑：

              1).解析是否可以放到业务模块自己去做？

              2).数据是否可以放到业务自己去保存？

2.数据操作：
   当前：全部由框架提供接口，在框架做数据的创建、查询、修改、删除等操作；
   思路：由各业务自己做相关操作，框架提供回调接口，业务自己实现？

3.部署、拆除：
   当前：框架提供统一接口，所有业务丢请求和数据给框架，然后框架打包处理；

   思路：1).部署流程直观感觉太复杂，层次较深，问题定位比较麻烦，流程是否可以简化，有哪些步骤可以剥离出来？

              2).定位日志打印太多，可能有敏感信息，造成安全红线问题，这个必须注意；
              3).出现过的一个问题：下发任务时，一直报“正在运行业务配置，当前不支持此操作”。

                  两点：a).提示是否合适，真实情况就是任务冲突，但是这个提示给人的感觉是框架提供的是单线程的操作，

                                 只能单个下发；

                             b).为什么会任务冲突？初步定位是任务抛异常后，缓存没有清空，哪里没有清缓存？

                                 当前的部署进度缓存机制是否合理？

              4).wlan业务的一个具体场景问题：创建一个父模板和子模板实例，但是都没有下发到设备，然后在组中由父模板绑定子模板一起下发，

                  但是在设备上还没子模板，这时部署就失败了。这种场景怎么支持，因为用户创建一个子模板后不一定就要单独部署，很可能和父模板绑定一起部署？

              5).多客户端中，两个任务，每个任务关联不同设备，同时下发，是否可以支持？
              6).比较逻辑是否可以优化，有更高效、更清晰的实现？