银行业的很多应用,特别是一些核心应用很难做到完全的无状态化,典型的比如需要根据应用容器(或所在宿主机)生成交易流水号的应用。交易流水号很重要,通过它可以知道一笔交易在内部都经过了哪些处理环节,要明确到是哪个容器处理在这个处理环节里。这种情况下就很难做到无状态化。此外,很多核心应用还需要本地保存日志,需要每个容器将自己的日志写入独立的PVC。这种情况下也无法做到无状态化。好在K8S通过StatefulSet提供了对有状态应用的支持,运维难度其实和无状态的差别并不大。
收起不妨基于这样的考虑尝试下
收起无状态应用:Stateless Application 是指并不会在会话中保存下次会话中去要的客户端数据。 每一个会话都像首次执行一样,不会依赖之前的数据进行响应。
有状态的应用: Stateful Application 是指会在会话中保存客户端的数据,并在客户端下一次的请求中来使用那些数据。
在无状态应用中,会话数据将会被存储在客户端或者透传给需要的这些数据的服务。在开发离线应用时,这是一个非常重要的的因素。通过这种方式来开发,会话数据将会被存储在终端用户的设备上,例如:当网络不可用时,用户将数据存储在自己的设备上,当网络重新连接时,会话数据将被上传并复制到云中。
在分布式系统中,无状态应用使实现了分布式水平扩展成为可能。当分布式系统中的一个组建是无状态时,能够在出现故障时轻松的重新部署,也能够自由的水平扩展来适应负载。组建之间也能够方便的使用API来进行通信。
这个问题应该是问怎么样去做有状态应用。
我先回答一下如何做无状态应用,应用部署包的组成主要为代码,配置文件,初始化脚本,启停脚本,各类依赖管理。
无状态应用,我们要显式声明应用依赖管理,配置文件应该外部化,或环境变量,或配置中心管理,我们build出的镜像应该能在各种环境下使用。日志输出应该对接elk,要对日志输出格式进行改造,适配集中式日志系统规范。
有状态应用,我们除了要对接共享存储之外,还要注意有状态应用的扩缩容,比如如何弹性扩容三主三从redis集群,读写分离mysql,这些都是共享存储之外需要做的。
对于共享存储,对于强监管的银行应用,我们要做好存储的生命周期管理,审计,权限控管,配额管理,qos,故障追踪,平滑扩容等等一系列共享存储本身技术之外的东西
1、应用(主要介绍java应用)无状态化分为两个部分,session无状态化和存储无状态化。
2、一般银行应用均采用F5作为负载均衡,并采用session粘滞模式,如应用容器化则需实现session无状态化,如果采用springboot技术,添加@EnableRedisHttpSession来开启spring session支持,同时在application.properties中配置redis服务器信息;如果传统应用采用非springboot技术,容器采用tomcat,可以采用tomcat-redis-session-manager组件。以上redis建议采用高可用模式(如哨兵或集群),并强烈建议redis开启密码认证等安全配置。
3、有少部分应用需要挂载NAS存储,如应用容器化则需有两种方案,一种方案是宿主机和容器都挂载NAS存储,但这样会加强运维复杂度以及存储管理难度,不建议;第二种方案是存储无状态化,需采用分布式对象存储代替传统NAS存储,同时应用需改造采用S3接口,银行引入新技术分布式对象存储的可用性有待进一步验证,形成风险点。
4、建议挂载NAS存储的应用暂不上容器,规避技术复杂性,而敏态业务(互联网)应用改造上容器。
5、建立《容器平台应用适云规范》。