在任何云上运行 云的可移植性你考虑过吗
云可移植性是构建可扩展、有弹性、云原生应用程序的一种策略。谈到云原生*通常也会暗含地考虑到云的可移植性。云原生是一种应用程序开发和部署架构方法*可最大限度利用云计算资源的弹性和敏捷性。然而*当团队开始使用单一云平台*并围绕这个平台的供应商所提供的专用工具和托管服务进行构建时*很快就会面临供应商锁定的局面。
延伸阅读*了解 Akamai cloud*computing
可移植的工作负载能在不同计算环境和基础设施平台上轻松迁移、部署和管理。借此*企业能够避免被供应商锁定*并保持云战略的灵活性。
如果从一开始就选择“云中立”的方法*并使用能与任何云平台相兼容的工具*我们就可以根据需求的变化灵活做出改变。可移植性战略还能让我们更深入地了解资源的使用方式和原因*并根据应用和业务需求选择不同的云平台*甚至在不同平台间转移。
设计云可移植性策略
如果你正在考虑云应用架构*那么可以通过以下无方面考虑着手*设计成功的可移植工作负载。
确定需求
实现可移植工作负载的第一步是客观地确定工作负载需求。我们可能经常会看到这样的情况*在进行最开始的这一步工作之前*主观臆断就已经污染了整个过程*因为人们的目光会被云提供商的诱人服务所吸引。因此*这里的重点是*在考虑云平台之前*就先确定需求范围。
这就好比采取一种简单的方法来了解满足最终成果所需的全部功能和特性*进而确定软件栈和依赖项*以及满足这些需求的其他组件。有了这样一个客观、简洁的视角*就好比通过广角镜头去观察云。这种方式才能更好地凸显能在任何云平台的核心云基础设施上运行的各种功能。
确定锁定点
无论应用程序仍处于构建或规划阶段*还是已经在云平台上开发和部署*都要对当前架构设计进行评估*以发现当前平台上使用的独有组件和服务。
如果已经确定了可能被供应商锁定的点*请花时间评估具体原因。首先请回答以下问题*
- 为了更快速地推出或缩短上市时间*是否选择*或至少考虑过某种解决方案*
- 解决方案是根据咨询结果确定的*还是基于与该平台上其他服务的支持/互操作性来决定的*
- 当时选择这个解决方案时的成本*和现在的成本相比有何变化*
回答完这些问题后*我们就可以开始规划理想的开源解决方案或其他可提供相同或类似功能的替代解决方案*评估实施所需的工作*并制定执行计划。如果在所有评估后*仍然决定坚持使用特定平台的服务*请确保自己还有退出策略。云计算供应商锁定有两种形式*架构锁定和运营锁定。围绕专有云服务深思熟虑制定的退出策略可以减轻这两种担忧。
可扩展、可持续运行的构建
利用负载均衡技术*结合容器化、计算实例映像、配置管理以及有状态和无状态组件的分离*可顺利实现横向扩展和分发。在可能的情况下*状态应该是声明性的*由单一的“事实来源”进行维护和管理*并自动复制和同步。
模块化设计
单体架构可能会变得繁琐、难以管理*从而降低以可移植方式进行更改所需的灵活性。因此*工作负载应采用模块化设计*明确定义不同组件*并作为一个松散耦合的系统协同工作。云原生设计提供了一种更新或替换单个组件而不影响整个工作负载的高效流程*最终提高了可维护性、适应性和可移植性*
一切皆代码
如果要开发云原生应用程序*那么我们应该熟悉声明式部署方法*将工作负载的每一部分*应用程序、基础架构和配置管理*都编成代码。采用这种方法*我们可以自动部署新环境*如开发、暂存、测试环境*或复制现有环境。这将简化蓝/绿部署流程*并在发生灾难时快速恢复。
GitOps方法为我们提供了实现可移植性的单一途径*能通过自动化管道的可靠性优势来规范部署*提高合规性/审计的可视性*并将策略的实施以代码方式来执行。
通过上述五方面的思考*我们就可以结合自身需求*制定出适合的云可移植性战略*从而在云原生应用中获得真正的灵活性*真正让工作负载能在任何云平台上流畅运行和迁移*从方方面面享受到云原生所应提供的价值。
如您所在的企业也在考虑采购云服务或进行云迁移*
点击链接了解Akamai Linode的解决方案
https://www.linode.com/lp/akamai*cloud*computing*freetrial/?utm_campaign=F*MC*62425&utm_id=apj_cc&utm_source=OSCHINA_article&utm_medium=CPC&utm_content=OSCHINA_240531_BlogArticles101

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
PieCloudDB Database Flink Connector: 让数据流动起来
面对客户环境中长期运行的各种类型的传统数据库,如何优雅地设计数据迁移的方案,既能灵活地应对各种数据导入场景和多源异构数据库,又能满足客户对数据导入结果的准确性、一致性、实时性的要求,让客户平滑地迁移到 PieCloudDB 数据库生态,是一个巨大的挑战。PieCloudDB Database 打造了丰富的数据同步工具来实现数据的高效流动,本文将聚焦 PieCloudDB Flink Connector 工具进行详细的介绍。 拓数派旗下 PieCloudDB 是一款云原生分布式虚拟数仓,为企业提供全新基于云数仓数字化解决方案,助力企业建立以数据资产为核心的竞争壁垒,以云资源最优化配置实现无限数据计算可能。PieCloudDB 通过多种创新性技术将物理数仓整合到云原生数据计算平台,实现了分析型数据仓库上云虚拟化,打造了存储计算分离的全新 eMPP 架构,突破了传统 MPP 数据库多种瓶颈限制,打破客户生产环境数据孤岛的同时,也实现了按需瞬间扩缩容,大大减少了存储空间的浪费。 Apache Flink 是一个分布式流计算处理引擎,用于在无界或有界数据流上进行有状态的计算。它在所有的通用集群环...
- 下一篇
技术分享 | SpringBoot 流式输出时,正常输出后为何突然报错?
项目背景 一个 SpringBoot 项目同时使用了 Tomcat 的过滤器和 Spring 的拦截器,一些线程变量在过滤器中初始化并在拦截器中使用。 该项目需要调用大语言模型进行流式输出。 项目中,笔者使用 SpringBoot 的 ResponseEntity<StreamingResponseBody> 将流式输出返回前端。 问题出现 问题出现在上述第 3 点:正常输出一段内容后,后台突然报错,而报错内容由拦截器产生。 笔者仔细查看了报错日志,发现只是拦截器的问题:执行时由于某些线程变量不存在而报错。但是,这些线程变量已经在过滤器中初始化了。 那么问题来了:为什么这个接口明明可以正常通过过滤器和拦截器,并开始正常输出,却又突然在拦截器中报错呢? 场景重现 Filter @Slf4j @Component @Order(1) public class MyFilter implements Filter { @Override public void doFilter(ServletRequest servletRequest, ServletResponse serv...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- 2048小游戏-低调大师作品
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果