近年金融行业,尤其是银行业监管越来越严格,对业务连续性要求的更高,银行系统对于由传统架构迁移至微服务有较迫切的需求,目前在实际部署系统时,一般需要考虑系统的同城双活或同城、异地多活,以保障业务连续性。那么在迁移至微服务架构的过程中,微服务架构上对于双活、多活的需求是如何考虑的?如何实现异常情况下快速无中断切换、不同中心间数据一致性等问题是否有解决建议?
这个问题信息量比较大,同城双活或同城、异地多活甚至目前跨云的多活都是大家所关注的话题。微服务的定义就是服务独立化、动态扩容等一些优点,所以从微服务角度看并不关注多活,双活,只要服务能正常允许即可。但是从架构角度来看,如需要支持多活,双活,那么一些基础设施是否具备了这些特性,比如Redis,Mysql是否支持双主,是否支持主主自动切换,MQ的是否支持。这些工作量非常的大。个人建议在技术能力、人力都不足的情况下不要搞双活,如非得考虑这方案因素,那还是建议去实施主备模式,即每个机房都部署一模一样的系统,当主的出现问题后把流量切到备用上。
收起这个问题其实展开说还是非常复杂的。底层不用区分上层是基于传统的服务方式,还是微服务方式,只需要注意数据同步问题即可。在应用层面,拆分成微服务后,微服务应用数量大量增加,并且会使用到配置中心,注册中心等微服务分布式组件,这些都对网络要求比较高。所以比较好的方式是在一个业务请求在一个机房内完成,同时每个机房部署各自的微服务框架,减少跨机房流量。同时配置相应的微服务监控模块,以及故障自愈。
收起目前应该还没有微服务跨数据中心的合适技术,跨数据中心,需要解决微服务调度、服务发布的问题,还需要面对时延挑战。所以比较好的方法是一个应用的微服务尽量都尽量在一个数据中心部署,考虑容灾可以在另一个数据中心也部署统一套应用,前端通过负载均衡或者服务治理引流。
收起