『数据库』微服务化的基石——持续集成( 六 ) |Java|美好，一直

在梳理配置的时候，可以按着三类归类，分门别类管理。
在使用了容器之后，很多的内部配置项可固化在配置文件中，放在容器镜像中，需要启动的时候修改的，则通过环境变量，在启动容器的时候，在编排文件中进行修改。
依赖的内部服务的地址，在容器平台kubernetes里面，可以通过配置服务名进行服务发现，仅仅在配置文件中配置名称就可以了，不用配置真实的地址， kubernetes可以根据不同的环境，不同的namespace自动关联好，大大简化了配置。当然也可以用服务中心Dubbo和Springcloud做内部服务的相互发现。
依赖的外部服务的地址，例如mysql ， redis等，往往不同的环境不同，也可以通过配置kubernetes外部服务名的方式进行，而不用一一核对，担心测试环境连上了生产环境的IP地址。
还有一些集中配置项，需要动态修改的，例如限流，降级的开关等，需要通过统一的配置中心进行管理。
九、有关数据库版本代码可以很好的版本化，应用也可以用镜像进行原子化的升级和回滚。
唯一比较难做到的就是数据库如何版本化管理。
有一个开源工具 flyway 可以比较好的做这件事情。
在代码中， flyway需要有以下的结构：

在src/db/migration中有sql文件，命名规则，如：V1__2017_4_13.sql， V开头+版本号+双下划线+描述，后缀为sql
增加flyway的java类，实现migration方法

在数据库中， flyway会自动增加SCHEME_VERSION表。
当服务启动的时候， java类的migration方法会被调用，它会按照指定路径中sql语句的版本号进行排序并且按照这个排序去执行，当每一个sql文件被执行后，元数据的表就会按照格式进行更新。

本文插图

image
当服务重启的时候， Flyway 再次扫描sql的时候，它就会检查元数据表中迁移版本，如果要执行的迁移脚本的版本小于或者等于当前版本， Flyway将会忽略，不再重复执行。
但是flyway从来不解决数据库升级和回滚的代码兼容性问题。
太多的人问这个问题了，代码可以灰度发布，数据库咋灰度？代码升级了，发现不对可以回滚，数据库咋回滚。
如果可以停服的话，自然是使用数据库快照备份的方式进行回滚了。
如果不可以停服，没办法，只有在代码层面做兼容性。每次涉及数据库升级的都是大事情，代码当然应该有个开关，保证随时可以切回原来的逻辑。
【『数据库』微服务化的基石——持续集成】作者：Java微服务链接：https://www.jianshu.com/p/3ce17e089444来源：简书著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。