利用jdbc向其他服务器批量导入odoo模板库(数据库-postgreSQL)

　　加班时，先问问自己，这次加班有意义吗？

　　最近上线了一个项目，本人来做点小结。

　　我做了些什么：

　　1.搭建基于springboot的Web项目；

　　2.实现了quartz定时任务，用到了CronTrigger，通过Cron表达式定制任务执行时间；

　　3.尝试oauth2，失败了，离成功距离不远了，已经拿到了token,与客户端的oauth机制实现了接口对接调用，但是回调页面失败，因为odoo有个选库功能没有对接上，由于上线紧迫，被迫改了方案；

　　4.整合一个文件上传模块到项目，上传execl文件，进行文件格式、大小、文件内容的检查，持久化到数据库，作为批量建库的数据源；

　　5.实现在linux环境下利用postgres的命令批量导库、建表，通过一个存储有数据源的表，向不同的服务器导入数据库和表，需要约定数据库的拥有者，建库的角色，以及对一个客户端的环境配置postgres的命令运行环境，还有免密码环境配置，通过java调用Runtime的exec方法执行psql语句，对不同的服务器导入sql脚本，对应的服务器上必须有postgreSQL数据库。

　　6.整合了一个定时任务管理模块，该模块只有两张表，结合quartz的11张表，定制一个定时任务，后续会开发出多任务。

　　项目的环境：

　　1 .运行环境：LINUX

　　2.第一层:F5,现实负载均衡，目前并发是一台机器的并发量是25(非java程序,基于Python开发的odoo框架)；

　　3.第二层：基于Nginx集群，做灰度发布，通过配置，在通过Nginx集群中的某一个Nginx后向应用层发送一个gary标识，作为回找Nginx集群的key被odoo应用层接收，odoo返回信息时，通过该gray找到对应的Nginx集群；

　　4.第三层：odoo应用层，该层为N个odoo应用程序，也是分担客户端请求，它们的任务是接收到信息后找到对应的数据层，进行业务逻辑处理后将数据返回给Nginx集群，通过gray找到对应的Nginx，原路返回；

　　5.第四层：持久层，对应着不同的地区，通过数据库编号和地区名称标识不同的地区数据库，存放大量的业务、界面、用户等数据。

　　总结：

　　1.批量导库的方案选取不妥，因为开发环境和生产环境的差异，尤其涉及到对权限和环境有要求时，很容易被坑埋，搞不好可能“一着不慎满盘皆输”，所以技术选型的时候要充分理解生产环境，避免一些不必要的坑导致项目失败；

　　2.环境搭建不规范，用到了jdbc的方式进行建库建表，有人会说很low,的确很low，但是开发经验丰富的人也经历过，在上线时间紧迫和人员不足的情况下（我们项目主，我还是个主力。。。），有时候不是在于low不low了，有东西交出去才是重点，用一些自己都没办法玩的框架，一个不慎就可能交不上东西；

　　3.自身实力不足，对底层原理理解甚少，对新的中间件不敢使用，这也是在开发中深深的体会，如今springcloud中间件可以说是层出不穷，功能可以满足绝大部分开发需求了，但是由于自己没有接触、不了解、不理解所以放弃使用，加上上线的时间紧迫，也没有精力研究，另外一方面也说明了自己的基本功不够，对原理的理解不够，拿到一个新的框架和组件使用起来非常吃力。

　　解决方案：

　　1.先把Think in Java再看一遍，本书之前看不懂，现在大多数地方能看懂了，坚持把该书啃完；

　　2.多了解和理解spring的全栈，我选取springcloud中一些能够高频率的被企业使用的中间件，理解、玩熟练；

　　3.把docker玩熟练。

转载于:https://www.cnblogs.com/yulonglyw/p/9385129.html