企业应用容器化改造方式
应公司要求,我把企业容器化的方式在medium上进行了发布。这里列下最初的原始中文版。
应用容器化改造,一般有以下三种方式:
- 方式一:单体应用整体容器化,应用代码和架构不做任何改动。
- 方式二:将应用中升级频繁,或对弹性伸缩要求高的组件拆分出来,将这部分组件容器化。
- 方式三:将应用做全面的微服务架构改造,再单独容器化。
具体见下表:
表1 应用容器化改造方式
应用容器化改造方式 | 优点 | 缺点 |
---|---|---|
方式一: 单体应用整体容器化 | - 业务0修改:应用架构和代码不需要做任何改动。 - 提升部署和升级效率:应用可构建为容器镜像,确保应用环境一致性,提升部署效率。 - 降低资源成本:容器对系统资源利用率高。相比虚拟机技术,一个相同配置的主机,往往可以运行更多数量的应用。 | - 整体性架构扩展难度大,随着应用程序代码扩展,更新和维护工作非常复杂。 - 推出新功能、语言、框架和技术都比较困难。 |
方式二: 先将部分组件容器化(将对弹性扩展要求高,或更新频繁的组件拆分出来,先容器化改造) | - 渐进式变革:在原有架构推倒重建太伤筋动骨,通过较为缓和的改动,更容易接受。 - 弹性更灵活:将对弹性要求高的组件容器化,当需要扩展时,只针对该容器扩展,弹性更灵活,且能降低系统资源。 - 新特性上线更快:将更新频繁的组件容器化,只针对这个容器进行升级,上线更快。 | 需要对业务做部分解耦拆分。 |
方式三: 整体微服务架构改造,再容器化 | - 单独扩展:拆分为微服务后,可单独增加或缩减每个微服务的实例数量。 - 提升开发速度:各微服务之间解耦,某个微服务的代码开发不影响其他微服务。 - 通过隔离确保安全:整体应用中,若存在安全漏洞,会获得所有功能的权限。微服务架构中,若攻击了某个服务,只可获得该服务的访问权限,无法入侵其他服务。 - 隔离崩溃:如果其中一个微服务崩溃,其它微服务还可以持续正常运行。 | 业务需要微服务化改造,改动较大。 |
捐赠本站(Donate)
如您感觉文章有用,可扫码捐赠本站!(If the article useful, you can scan the QR code to donate))
- Author: shisekong
- Link: https://blog.361way.com/how-to-containerized/6769.html
- License: This work is under a 知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议. Kindly fulfill the requirements of the aforementioned License when adapting or creating a derivative of this work.