zhao_god的专栏

各个系统也都是不同厂商开发的，使用的架构、编程语言、报文内容格式各不相同，而同时为一家机构服务时就需要系统间进行数据交互，交互就涉及到系统对接，系统对接因为各方面的差异，对齐工作就显得格外繁琐。所以服务总线、集成平台应运而生，系统双方不用关注对方的请求协议、内容类型等，由服务总线或者集成平台进行协议转换、内容对照等，节省了大量对接时间。本文以集成平台的使用为背景。Groovy动态加载接口，Nacos动态接口变化的集群通知

医院有很多的业务系统，像LIS、PACS、HIS、面向患者的小程序等等，这些系统都不是孤立存在的，系统间都有很多接口调用，数据交互。目前线上有一套集成引擎，不过这套集成引擎每次对接都要开人人员定制化开发，然后从中做转发，为了减少成本，对集成引擎进行了升级，使用配置化方式完成对接，这样就不需要开发人员接入，实施人员便可以完成这项工作，但是新集成引擎面临一个问题，就是如何替换线上已有的接口，同时还不需要调用方和被调用改造，实施人员又能通过配置实现替换，因此想到了使用Groovy动态加载代码实现创建接口。

参数配置中还必须有这个参数spring.datasource.type，而且这个类型也决定了使用哪种数据源，再看我们的参数配置，也确实有这个配置spring.datasource.type=com.alibaba.druid.pool.DruidDataSource（把这个去掉启动就会报错，无法初始化数据源），搞清楚了源头我们继续跟进入参properties,发现了spring.datasource这个前缀，跟我们的配置中心是匹配的，但是像maxActive这些参数在这个类中是没有的。

http方式是需要通过http调用查询目标服务的接口，将结果展示出来，但是目前官方的http调用只支持json类型的返回数据源，对text类型并不支持，官方的解释是json已经满足了大部分场景，所以只支持这一种。总结：这样的改造是最少的，还有一种方式是通过sql方式，那样就需要系统将druid数据源的监控指标通过后台线程采集到表里，需要对druid内置的api进行重写，这样我觉得更麻烦，改开源代码的改动量更少一些，顺便还能提个PR，但是......没关系，至少是一次不错的尝试ヾ(◍°∇°◍)ﾉﾞ。

基于Sonarqube代码检测和gitlab生命周期钩子实现对提交代码的检测控制，不符合标准的不能提交，达到控制代码质量的目的