所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。

随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应用的云平台被越来越多的提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型,它们是关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务以及关注业务应用的软件即服务。

在容器技术、可持续交付、编排系统等开源社区的推动下,以及微服务等开发理念的带动下,应用上云已经是不可逆转的趋势。随着云化技术的不断进展,云原生的概念也应运而生。

云原生概念的诞生

云原生(Cloud Native)的概念,由来自Pivotal的MattStine于2013年首次提出,被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合,并得到了社区的不断完善,内容非常多,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)和12要素(The Twelve-Factor App)等几大主题,不但包括根据业务能力对公司进行文化、组织架构的重组与建设,也包括方法论与原则,还有具体的操作工具。采用基于云原生的技术和管理方法,可以更好地把业务生于“云”或迁移到云平台,从而享受“云”的高效和持续的服务能力。

The Twelve-Factor App

顾名思义,云原生是面向“云”而设计的应用,因此技术部分依赖于传统云计算的3层概念,基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS),例如,敏捷的不可变基础设施交付类似于IaaS,用来提供计算网络存储等基础资源,这些资源是可编程且不可变的,直接通过API可以对外提供服务;有些应用通过PaaS服务本来就能组合成不同的业务能力,不一定需要从头开始建设;还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务,即SaaS能力,用户直接面对的就是原生的应用。

云原生并不是一个产品

最近讨论云原生应用越来越多。关于云原生应用,简单地说,就是大多数传统的应用,不做任何改动,都是可以在云平台运行起来,只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式,仅仅是把虚拟机当物理机一样使用,不能够真正利用起来云平台的能力。

云并非把原先在物理服务器上跑的东西放到虚拟机里跑,真正的云化不仅是基础设施和平台的事情,应用也要做出改变,改变传统的做法,实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变,真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多,如容器技术、微服务、可持续交付、DevOps等。

而云原生应用最大的特点就是可以迅速部署新业务。在企业里,提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险,因为犯错及改错也需要花费同样的时间成本,竞争优势就会由此产生。

所以云原生不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。意义在于让云成为云化战略成功的基石,而不是障碍。它可以根据商业能力对公司进行重组的能力,既包含技术、也包含管理,可以说是一系列云技术和企业管理方法的集合,通过实践及与其他工具相结合更好地帮助用户实现数字化转型。

云原生计算基金会(CNCF)

CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软、思科等巨头。

目前CNCF所托管的应用已达14个,下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。

Cloud Native Landscape新版

CNCF(云原生计算基金会)认为云原生系统需包含的属性:

容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。

自动化管理:统一调度和管理中心,从根本上提高系统和资源利用率,同时降低运维成本。

面向微服务:通过松耦合方式,提升应用程序的整体敏捷性和可维护性。

正因为如此,你可以专注于创新,解决业务问题,而不是把时间花在“静态、不灵活的传统架构”存在的许多技术问题。

云原生的四要素:持续交付、DevOps、微服务、容器

从云原生的概念中,我们总是能看到持续交付、DevOps、微服务、容器等技术的出现,那么它们到底是什么,这里引用Pivotal台湾云计算资深架构师的部分观点,为大家逐一揭开他们的神秘面纱!

01

持续交付——缩小开发者认知,灵活开发方向

首先是持续交付,什么样的时候客户要求持续交付?敏捷开发要求持续交付,因为敏捷开发要求随时有一个版本可以上到大群环境,所以要持续交付。

而换句话说,持续交付就是不误时开发。举一个例子,有些公司非常喜欢谈需求,谈很久,可是开发只剩1/3时间就开发完成,然后交付,再上线运营。这就会碰到一个问题,就是你开始谈需求到最后交付产品的时间,短则三月,长则半年,这中间市场已经变化了,需求也随之变化了。因此市场上出现了新的想法,即是不是能够小步快跑,把交付的周期缩短一点,我可以实现快速交付,每次交付都可以重新确认方向,这样尽量避免与未来期待的落差。

用小步快跑的方式,打破瀑布式开发流程

那么问题来了,持续交付对于开发的人谈的需求、开发的方式有改变,那它对于开发有影响吗?如果说公司的开发团队一天可以交付五次,那研发团队要帮忙部署一次吗?现在公司大部分部署都是研发团队帮忙部署应用的,研发团队部署五次,要改版五次就需要部署一次,这是无法实现的。而且每次部署的时候都要面对停机,而实际公司的应用经不起一天停机五次部署,在互联网的思维之下,零宕机时间已经是现在企业的基本要求。于是“蓝绿部署”的概念营运而生。即在一个环境里面,第一版还在线上服务,第二版先做封测,封测完成后,让外面的流量进来一些,看log是不是开发人员要的,确认后再把全部的流量导到新的版本上。

图:蓝绿(Blue-Green) 部署

但“蓝绿部署”在系统过多过复杂的情况下,在传统架构上实现非常困难,所以企业要做到zero down time的持续交付就需要有良好的平台與工具协助。因此,持续交付的优势在于,它可以缩小开发者认知,重新确认开发方向。

02

微服务——内聚更强,更加敏捷

第二部分是微服务。微服务是什么?有客户表示,提供商出产品,客户把应用全部放上去,结果就是一个微服务。这种认知是错误的,因为微服务是一个架构的改变。那么微服务是怎么做的呢?它所面临的最大挑战是什么?

是切割。那么如何切割呢?其实这件事情早在1968年康威就提出了——康威定律,系统的服务划分应该是根据组织架构的功能来划分。1968年康威就提出了这个想法,我认为拿来做微服务的切割非常适用。

Going Agile - Breaking the monolith

Conway's Law and Microservices

这样按照组织架构划分的优势在于:

1.内聚更强,所有遵循同一种业务准则的人内聚在一起,就容易解决问题。

2.服务解耦,变更容易,更加敏捷。当做到解耦合的时候,要变更就容易。所以微服务应该是切分成这个样子,由上而下来切,根据Function来切。

另外一个划分微服务的技巧,可以运用领域驱动设计(Domain Driven Design)的理论,而领域驱动设计亦可算是面向物件的一种设计思维;聚合可以让微服务划分更有依据,也让未來的系統变更具有弹性。值得一提的是领域驱动设计,也提供微服务中的事物问题。因为过去巨石应用进行两个报数的阶段,相当容易也常见,但在微服务架构中,如何在分散的服务中进行事物就显得相当困难。利用领域驱动设计的Event Souring进行设计,是目前最好的解決办法。

那么在什么情况下需要微服务?我认为有三个标准:

1.有HA(High Available)的需求需要微服务。

2.有性能调校的需求(例如:图片的呈现或者搜寻)需要微服务。

3.经常变更的需要微服务。

实际上,微服务需要关注的源代码范围比较小,使得各个服务解耦、变更容易,内聚更强,因为都会集中在服务里。另外,它更容易单独改版,因为微服务之间是用RESTful间接起来的,用RESTful只要API的界面不改,原则上则不会错,也更敏捷。

但微服务也会留下一些问题,例如App团队如何分工?环境怎么配合?如何实现自动化部署?

03

容器技术——使资源调度、微服务更容易

再来看看容器。在机器上运行的容器只是主机操作系统上的一个进程,与任何其他进程无异。那么,为什么容器如此受欢迎呢?原因在于这个进程被隔离和限制的方式。这种方式很特殊,可简化开发和运维。

其实1979年就有容器技术,很多人会以为说Docker是不是等于容器,其实Docker不等于容器。容器的历史可追溯到Linux操作系统。容器利用了Linux的内核功能。Linux中容器的核心概念(cgroup、namespaces和filesystems)在独立的区域运行。容器的神奇之处在于将这些技术融为一体,以实现最大的便利性。

VMware之前的技术专家在2011年发展出一个技术,把这个技术贡献出来成立了一个Cloud Foundry基金会。Docker在2013年才开始有,而且它第一版是用SLC的技术去做的。后来陆续一路成长,使得为服务的实现更容易了。

从 Infra 角度来看技术演进

从上面这个表中可以看出,从左边开始,IaaS,虚拟化技术有了之后,刚刚提到的所谓第三代平台,这四个区块开发人员交付的内容不一样。所有的IaaS、CaaS、PaaS、FaaS一路的变化演进,对于客户的负担越到后面越小,而对于开发人员的想象力则愈发抽象。

大家一定会遇到下列这些计算,一个是所谓的单体应用,或者翻译成巨石应用。此外,你们一定会有一些批次的管理,另外就是所谓的数据库的部分,开始可能会有容器技术,像K8S、Dock

Docker是软件行业最受欢迎的软件容器项目之一。思科、谷歌和IBM等公司在其基础设施和产品中使用Docker容器。

Kubernetes是软件容器领域的另一个值得关注的项目。Kubernetes是一个允许自动化部署、管理和伸缩容器的工具。为了便于管理其容器,谷歌建立了Kubernetes。它提供了一些强大的功能,例如容器之间的负载均衡,重启失败的容器以及编排容器使用的存储。

容器生态图 /作者:Jimmy Song

容器为云原生应用程序增加了更多优势。使用容器,你可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上,而无需重新配置环境,这样就实现了强大的可移植性。

04

DevOps——以终为始,运维合一

最后让我们走向DevOps,它不是一种工具,DevOps其实要谈的是运维合一。

DevOps如果从字面上来理解只是Dev(开发人员)+Ops(运维人员),实际上,它是一组过程、方法与系统的统称,其概念从2009年首次提出发展到现在,内容也非常丰富,有理论也有实践,包括组织文化、自动化、精益、反馈和分享等不同方面。

首先,组织架构、企业文化与理念等,需要自上而下设计,用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合,简单而言组织形式类似于系统分层设计。

其次,自动化是指所有的操作都不需要人工参与,全部依赖系统自动完成,比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次,DevOps的出现是由于软件行业日益清晰地认识到,为了按时交付软件产品和服务,开发部门和运维部门必须紧密合作。

总之,DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。在内部沟通上,你可以想象DevOps是一个敏捷思維,是一个沟通的文化。当运营和研发有良好的沟通效率,才可以有更大的生产力。如果你的自动化程度够高,可以自主可控,工作负担降低,DevOps能够带来更好的工作文化、更高的工作效率。

总结

综上所述,云原生的DevOps、平台、持续交付、微服务都是云原生不可或缺的一部分,需要以全局地眼光看待问题,脱离任何一个元素,对于企业来说都是“管中窥豹”、“一叶障目”,只有加以整合才能见到云原生的全局风貌。

面对业态各异的业务上云以及碎片化的物联网解决方案部署,利用云原生思维和模式,构建基于云原生的物联网平台以及解决方案,势必将加速企业,甚至整个社会的数字化转型。

本文资料来源:

1.《Golang Cloud Native编程》,作者:Mina Andrawos

2.《云原生应用的下一站》,作者:Jimmy Song

3.《什么是云原生应用 有哪些关键点?》,51CTO

4.《云原生架构实践》,作者:网易云基础服务架构团队

5.《见微知著:驱动云原生架构,全新应用分享》

云原生到底是什么?一文了解云原生四要素!相关推荐

  1. 华为云计算机玩游戏,华为云电脑到底能不能玩游戏?体验一下绝地求生游戏效果...

    华为云电脑到底能不能玩游戏?华为云电脑说白了其实就是一个整合了云桌面服务系统的APP应用.可以下载在手机和平板上使用.可以兼容windows系统生态下的所有应用软件,使用基本和Windows系统一样. ...

  2. 云栖科技这家公司切入企业级文档云市场,希望解决移动和安全两个痛点

    电梯停在十六楼,一眼望去整层都是本次采访公司的办公区域.走进其中,公司整体装修风格采用了多种明亮的颜色.茶水间.开放办公区.敏捷开发区.培训区,办公室也有着十分清晰的功能布局,每个小细节都别有用心.采 ...

  3. 3ds Max云渲染有多快,3ds Max云渲染怎么用?

    本地渲染效果图和动画3D项目是一个非常耗时的过程,当在场景中使用未优化的几何体或在最终渲染中使用大量多边形模型时,诸如此类的变量最终会增加渲染项目所需的时间和处理器能力.随着提供的渲染服务的云渲染平台 ...

  4. 云原生的基石,一文读懂容器、Docker、Pod到底是什么!

    作者 | Aholiab 责编 | Carol 出品 | CSDN(ID:CSDNnews) 封图|CSDN下载自视觉中国 云原生(Cloud Native),是2013年由Pivotal公司率先提出 ...

  5. 云原生的基石,一文读懂容器、Docker、Pod到底是什么

    课程概要 云原生(Cloud Native),是2013年由Pivotal公司率先提出的概念.云原生以容器化.微服务.可持续交付性,帮助企业构建和运行可弹性扩展的应用.由于云原生应用构建简便快捷,部署 ...

  6. HDC.Cloud2021|开发者们都在谈的云原生到底长什么样?

    本文分享自华为云社区<HDC.Cloud2021|开发者们都在谈的云原生数据库是什么样的?>,原文作者:华为云头条. 近几年,云原生的风越刮越大,成为云计算领域炙手可热的话题.身为开发者, ...

  7. 华为22级专家十年心血终成云原生服务网格进阶实战文档,是真的6

    前言 有人调侃我们说: 程序员不如送外卖.送外卖是搬运食物,自己是搬运代码,都不产出新的东西-- 透支体力,又消耗健康,可替代性极强,30岁之后就要面临被优化的危险-- 想跳槽,但是更高的平台难进,同 ...

  8. nexus4恢复原生系统_深度好文!新浪微博架构师详析微博云原生技术的思考与实践...

    来源 | 刘超的通俗云计算 作者 | 陈飞 责编 | Carol 出品 | CSDN云计算(ID:CSDNcloud) 现在越来越多的企业开始全面拥抱云计算,开始关注云原生技术. 从管理物理数据中心到 ...

  9. 【云原生】什么是云原生?如何学习云原生?一篇文章带你了解云原生

    云原生,相信这个名词大家并不陌生:云原生在近期可谓是爆火,伴随云计算的滚滚浪潮,云原生(CloudNative)的概念应运而生,云原生很火,火得一塌糊涂.可是现在很多人还是不知道什么是云原生,所以今天 ...

最新文章

  1. 为什么大多Virtual Globe程序纵向旋转效率比较低
  2. 单点登陆的ASP.NET应用程序设计[zt]
  3. 【小练习04】HTML+CSS--医药健康小页面
  4. C#设计模式系列:享元模式(Flyweight)
  5. vector的简单实现
  6. Storm 06_Storm 容错机制
  7. Struts 2.x No result defined for action 异常
  8. python snownlp_snownlp · PyPI
  9. houdini flowmap
  10. 网络安全扫盲贴 史上最全网络安全问题解答
  11. cp 命令 提示cp: 略过目录 “/root/temp/sk”
  12. 查看php的错误日志文件,php查看错误日志
  13. Java8新日期和时间API
  14. 全球与中国1,6-己二硫醇市场深度研究分析报告
  15. C++问题速记:十六进制数0x9C40(40000)被表示为unsigned int问题
  16. python练习——基础训练(韩信点兵)
  17. 华米:2014年做智能手环踩过的那些坑
  18. FDDB测试使用(生成ROC曲线)
  19. android闹钟 推迟功能,闹钟延迟76秒才播放音乐
  20. Verizon CEO称三星是黑马 建议推出自有系统

热门文章

  1. symantec忘记了密码时如何卸载?
  2. Panic的概念和使用
  3. 厉害了!你的技术真的到天花板了吗?年薪50W
  4. 考研政治与专业课总结(持续更新)
  5. 网络安全工程师做什么?
  6. pwm一个时间单位_「硬见小百科」什么是PWM“死区”?
  7. 智能车辆路径跟踪:carsim和simulink联合仿真,基于车速的变权重多点预瞄驾驶员模型个例
  8. 非此即彼的逻辑错误_英语逻辑错误一览
  9. 浅谈Fiddler4 如何进行Idea抓包操作
  10. VisualVM 启动报错Error Starting VisualVM:You are running VisualVM using Java Runtime Environment(JRE)