云原生应用程序和数据需要确保安全
云栖号资讯:【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!
将数据作为云原生应用程序的一部分进行管理非常困难。对于许多企业而言,当前冠状病毒疫情带来的压力加剧了他们在软件开发方面所面临的挑战。数字化转型已从一种增长战略变成了一种生存之道。在线商务几乎在一夜之间得到爆炸式增长,达到了只有在假日期间才会出现的水平。
这将是一个推动更多变革的推动力,因为企业或者致力采用新技术,或者努力在竞争中保持领先。基于云原生IT的新方法将会有所帮助。
更敏捷、更多数据……更多问题?
为了采取必要的措施,开发人员正在研究如何利用云原生方法。但是,这不仅仅是将现有应用程序迁移到云平台上并添加更多基础设施那样简单。它需要围绕软件容器构建的新架构和采用的业务流程工具如何在从构建到生产的自动化应用程序中发挥作用,如何在容器之间有效地使用API,然后如何通过应用程序基础设施的动态更改来处理数据。
Kubernetes现在是基于这种方法来编排容器和管理应用程序的一种首选方法。 Kubernetes可以处理设置应用程序工作负载,确保其继续运行,并应对规模挑战。但是,尽管Kubernetes可以编排应用程序,但它不能解决数据管理问题。应用程序创建的所有信息仍然需要管理。
传统上,要想成功地使用像Apache Cassandra这样的数据库,用户必须从操作系统开始理解整个软件堆栈。他们还必须确保其一致性并遵循严格的操作和部署手册。这种方法不仅需要深入了解数据库的工作原理,还需要随着时间的推移进行一些人工干预以处理扩展。
使数据与应用程序一样易于编排
与Kubernetes一起管理云原生应用程序数据需要一些计划。一种方法是使每个服务的数据库实例位于Kubernetes集群之外。这使企业的数据基础设施脱离了控制平台,并为那些现在必须管理两个环境的用户创建了额外的工作。而这种情况并不理想。
更好的方法是从物理角度将数据与应用程序组件一起分布,但需要在同一控制平台内。这确保了每个应用程序服务都可以有效地读写数据,企业可以将这些数据和应用程序作为一个整体进行管理。更重要的是,这种方法应该能够像任何软件容器映像一样在多个云服务或云平台上进行扩展。
为了与诸如Apache Cassandra之类的数据库一起运行Kubernetes,企业将需要在Kubernetes集群中使用Cassandra Operator。这使Cassandra节点可以作为服务在现有Kubernetes集群内部运行。运营商在Kubernetes和更复杂的流程(例如Cassandra)之间提供了接口,以允许对其进行一起管理。启动和停止Cassandra集群,对其进行扩展和处理故障都通过Kubernetes Operator以Cassandra理解的方式进行处理。
更好地参与Kubernetes环境意味着需要深入了解集群状态。实际上,这意味着以前属于数据库内部的某些操作(例如自动重试或建立Gossip链接以跟踪内部集群状态)被提升到API层。然后,Kubernetes可以基于整个集群的健康状况做出决策,以便可以采取任何行动,例如如果需要更多节点,则可以启动这些元素以自动弥补。通过可用指标可以观察到所有这些情况。
围绕数据思考状态
通常情况,Kubernetes中的容器实例是无状态的——根据需要创建它们,然后将其删除,而不是随时间存储。存储需求被认为是短暂的。但是数据管理是不同的。对于像Cassandra这样的数据库,节点将需要持久化数据,因此必须被视为有状态服务。因此,必须使用PersistentVolumes和StatefulSets来添加这些对象,以确保在任何重新启动事件之间将数据卷连接到相同的运行节点。
这种基于Kubernetes的自动化的使用可以使开发人员和操作人员的工作更加轻松。可以使现有服务更高效、更轻松地进行升级,同时可以添加新服务来满足客户需求。除了一起运行Kubernetes和数据库外,还可以考虑它们如何为内部开发人员提供数据库即服务或DBaaS功能。
对于尚未熟悉设置和运行Kubernetes或不想花费太多时间的团队来说,将这些技术结合使用的数据库即服务(DBaaS)选项可以从云平台中按需提供。数据库即服务(DBaaS)可以消除一些管理开销,并使企业更容易专注于如何处理数据,而不是人工管理数据库实例。
支持企业业务的数据处理方法
对于希望更快地实施并交付客户所需的企业而言,迁移到云原生应用程序和数据至关重要。从开发人员的角度来看,将“全局”方法与保持系统运行所需的方法联系起来可能是一项挑战,特别是在扩展数据库需要工作人员具有一定经验的情况下。先前的流程和组织孤岛可能是阻碍这些变化的主要问题,因此需要消除转变为数据驱动的业务所面临的障碍。
对于正在寻求如何为他们的公司提供支持的团队来说,跟上客户需求并更有效地提供服务的压力都是巨大的。微服务的采用无疑对这一过程有所帮助,因为与原有的整体应用程序相比,微服务更容易分解应用程序并快速改进。然而,这种方法日益增加的复杂性会使扩展服务和支持数据变得更加困难。
为了使这一过程更简单,将分布式数据库设计(例如Apache Cassandra)作为带有Kubernetes的云原生应用程序的一部分可以提供帮助。同时,随着围绕Cassandra的更多数据库即服务选项的增长,也使采用和运行分布式数据库设计变得更加容易。
【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/live立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK
原文发布时间:2020-07-23
本文作者:Patrick McFadin
本文来自:“51CTO”,了解相关信息可以关注“51CTO”。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
5个规则,确保你的微服务优化运行
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 最近几年好像大家都开始对微服务着迷,与此同时单体架构也在慢慢淡出人们的视线。 当然,热门的趋势总是来来去去,而且它们所受到的关注往往被媒体夸大了,实际情况并不总是如此。不过,对于微服务来说,人们似乎已经达成共识,认为这个趋势会一直存在下去。这是有道理的。从概念的角度来说,微服务扩展了工程师们几十年来采用的相同原则。 一旦你开始使用微服务架构,也许你需要本文中提到的5个规则,帮助你成功运行它们。 微服务的另一面 关注点分离(SoC)是一项设计原则,规定软件的构建应根据 "关注点 "或总体功能来确定不同的部分,30多年来一直被用来决定如何构建技术。在单体应用中,它体现在典型的3层架构中的表现层、业务层和数据层的分离。 微服务采用了这个概念,并将其颠覆。它们将同一个应用程序以这样的方式分离出来,应用程序的单一代码库可以被分解并单独部署。这样做的好处是巨大的,但也是有代价的,通常体现在时间和金钱两方面的运维成本较高。除了将现有的应用程序过渡到容器所带来的巨大的前期投资之外,维护该应用程序也带来了...
- 下一篇
架构师们,怎么走着走着就变“烟囱”了呢?
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 这两年,随着中台概念的兴起,一种IT过去的常态,现在的明星反面教材——“烟囱式架构”被反复提及并为大家所熟知。作为中台的对立面,烟囱式架构不幸地成为了业界合力吐槽的“倒霉孩子”,那些对比中台理念审视过自身IT系统的传统企业都不禁心虚地喃喃自语道:“嗯,我有病,得治!” 开个玩笑,其实我们并不打算在这篇文章里对烟囱架构进行批判,“家家有本难念的经”,企业形成今天的烟囱式架构是由很多现实问题导致的,并不是什么管理或决策上的疏失,如果说烟囱式架构就是一种“病”,那么可以说“雪崩来的时候,没有一片雪花是无辜的”。 本文我们真正想做的是带着读者从一个生动而现实的案例中观察并思考烟囱式架构的产生背景,演化过程以及它所造就的IT生态给企业带来的影响。所谓“知己知彼,百战不殆”,不管企业要不要上中台,探究形成企业现有IT格局的真正动因,透彻理解烟囱生态的现实处境,对企业领导者和IT团队都是非常重要的,这可以避免一些企业在中台热潮中盲目跟风,或者帮助决策者清晰地认识到在中台化进程中它们真正需要解决的生态顽...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- MySQL8.0.19开启GTID主从同步CentOS8
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS8编译安装MySQL8.0.19
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS关闭SELinux安全模块
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程