1 企业标准三层架构前提上首先是业务解绑
2 在业务级别相关应用实现了容器及快速部署升级(devops等)通过相关的pass平台进行容器级别调度
3 保证灰度级升级后可以逐步将现有业务进行容器云等环节的迁移部署
注:容器解决方案是目前趋势和快速交付等环节的方向,慢慢走向成熟中
1、目前传统三层架构的实现技术基本都可以在OpenShift容器云平台上复现,只不过为了能过获得更好的云化执行效果,我们通常需要从几个方面调整。a,中间件轻量化以提升加载速度。b,代码轻量化/解耦化以提高业务代码CI/CD的能力和效果。c,数据库解耦化以提高面向数据层的敏捷性。
2、中间件轻量化可以借助一些工具来快速实现,例如通过 Redhat JBoss Migration Bench 可以快速将一些重量级中间件上的应用平滑迁移至 OpenShift JBoss 服务器Migration Bench包括了对依赖库的分析,对特定配置文件的分析和自动迁移(例如 weblogic.xml),对数据库连接池的引用与自动迁移,以及对其它各类特定固化资源引用的分析,从而提升容器化中间件对OpenShift的适应度,降低中间件的启动速度,提高云化中间件的多实例协同工作能力。
3、代码轻量化包括了对一些复杂固化框架的重新考虑和一些原本打包在一起的业务模块的拆分,例如原本我们使用 EAR package 时为了实现应用的整体可迁移性会把一切应用的所需统一打在一个 Package 里面,这会造成业务启动加载的大量内存及实现的消耗,也会造成每个 Package 的不可拆分性。通常在容器云平台上,我们建议以每个小业务模块为单元,最大以 war 包 package 为单元。所有的依赖关系进行重新整理,每应用仅负责自身的依赖保障,不加载额外库,每模块独立实现对数据的要求,不在应用包内做总体数据缓存,而是仅对使用数据进行缓存。以上这些调整会牵涉应用内部逻辑,因此通常是随着容器化改造逐渐完成的,先构建CI/CD总体通道,再通过CI/CD通道逐步优化。
4、面向数据库的解耦是最复杂的,一方面要在服务就近构建新的数据缓存体系,另一方面数据缓存体系要与原数据通道进行一致性适应调整,包括读写适应,数据O/Rmapping适应,最终一致性保障重新规划,数据同步频率适应等一系列问题。这些都需要在业务模块设计中重新 Desgin ,这就是为什么我们容器化就会带来微服务化改造、微服务化就需要引入 Domain Driven Desgin 设计理念的原因。这部分通常是最难的,我们可以留在最后慢慢实现。
收起