云原生概念学习

本来只是想学习一下CICD的技术,持续集成持续交付,没想到深入研究发现这个云原生更大的概念,在这里学习记录一下云原生概念的学习,以及满足云原生应用所需要具备的条件。

从云计算到微服务再到云原生计算

云计算发展史

云计算

云计算包含的内容十分繁杂,也有很多技术和公司牵强附会说自己是云计算公司,说自己是做云的,实际上可能风马牛不相及。说白了,云计算就是一种配置资源的方式,根据资源配置方式的不同我们可以把云计算从宏观上分为以下三种类型:

  • IaaS:这是为了想要建立自己的商业模式并进行自定义的客户,例如亚马逊的EC2、S3存储、Rackspace虚拟机等都是IaaS。
  • PaaS:工具和服务的集合,对于想用它来构建自己的应用程序或者想快速得将应用程序部署到生产环境而不必关心底层硬件的用户和开发者来说是特别有用的,比如Cloud Foundry、Google App Engine、Heroku等。
  • SaaS:终端用户可以直接使用的应用程序。这个就太多,我们生活中用到的很多软件都是SaaS服务,只要基于互联网来提供的服务基本都是SaaS服务,有的服务是免费的,比如Google Docs,还有更多的是根据我们购买的Plan和使用量付费,比如GitHub、各种云存储。

微服务

微服务(Microservices)这个词比较新颖,但是其实这种架构设计理念早就有了。微服务是一种分布式架构设计理念,为了推动细粒度服务的使用,这些服务要能协同工作,每个服务都有自己的生命周期。一个微服务就是一个独立的实体,可以独立的部署在PAAS平台上,也可以作为一个独立的进程在主机中运行。服务之间通过API访问,修改一个服务不会影响其它服务。

要想了解微服务的详细内容推荐阅读《微服务设计》(Sam Newman著),我写过这本书的读书笔记 - 微服务设计读书笔记

下文中会谈到Kubernetes与微服务的关系,其中Kubernetes的service天生就适合于微服务。

容器

继虚拟化技术之后,容器技术逐渐成为云计算领域基础设施云化的变革技术,凭借轻量化和标准化的显著特性,容器技术得到国内外越来越多的关注,也对云计算的交付方式、效率、PaaS平台的构建产生深远影响。

容器可以将应用和其运行环境进行标准化封装,保证应用及其运行环境的统一,显眼意见的是,这一特性与微服务理念不谋而合,因而容器技术的成熟为实现微服务提供了进一步发展的客观条件。微服务化的应用很适用运行于容器上,容器可以轻松承载微服务应用,帮助微服务发挥其优势,实现应用弹性伸缩及快速迭代发布。

当一个具有一定规模的单体应用微服务化之后可能对应成百上千个微服务,这些微服务的资源调度、更新发布、运维管理等一系列复杂管理问题该如何应对?这就需要强有力的调度编排能力,而目前最具影响力的调度编排平台当属kubernetes。

基于kubernetes为核心构建的容器平台,可以整体用来支撑微服务化应用的容器管理,这也是目前国内包括BoCloud博云在内的容器PaaS服务商容器云平台的主要构建方式。博云基于K8S自主研发的容器云平台,已在银行、证券、能源等多个行业,实现技术落地拥有大量生产应用案例。

DevOps

DevOps不仅仅是一种技术工具,实际上是一组付过程、方法与系统的统称,用来促进开发运维一体化的实现,实现敏捷迭代、快速发布。在组织架构与企业文化等方面,DevOps强调自上而下的设计,促进开发与运维部门之间的沟通与协作;其次,企业需要透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

容器在DevOps的成功实现中发挥着重要作用,DevOps成功的关键之一是提升开发对运营的影响力,两者的部署和自动化功能与快速应用程序开发和敏捷IT紧密相关。

“云原生”定义**

2018年,随着近几年来云原生生态的不断壮大,所有主流云计算供应商都加入了该基金会,且从Cloud Native Landscape中可以看出云原生有意蚕食原先非云原生应用的部分。CNCF基金会中的会员以及容纳的项目越来越多,该定义已经限制了云原生生态的发展,CNCF为云原生进行了重新定位。

以下是CNCF对云原生的重新定义(中英对照):

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。

云原生准确来说是一种文化,更是一种潮流,它是云计算的一个必然导向。它的意义在于让云成为云化战略成功的基石,而不是阻碍,如果业务应用上云之后开发和运维人员比原先还痛苦,成本还高的话,这样的云我们宁愿不上。

自从云的概念开始普及,许多公司都部署了实施云化的策略,纷纷搭建起云平台,希望完成传统应用到云端的迁移。但是这个过程中会遇到一些技术难题,上云以后,效率并没有变得更高,故障也没有迅速定位。

为了解决传统应用升级缓慢、架构臃肿、不能快速迭代、故障不能快速定位、问题无法快速解决等问题,云原生这一概念横空出世。云原生可以改进应用开发的效率,改变企业的组织结构,甚至会在文化层面上直接影响一个公司的决策。

另外,云原生也很好地解释了云上运行的应用应该具备什么样的架构特性——敏捷性、可扩展性、故障可恢复性。

综上所述,云原生应用应该具备以下几个关键词:

  • 敏捷
  • 可靠
  • 高弹性
  • 易扩展
  • 故障隔离保护
  • 不中断业务持续更新

以上特性也是云原生区别于传统云应用的优势特点。

Cloud Native概念思维导图

云原生的设计哲学

云原生一词已经被过度的采用,很多软件都号称是云原生,很多打着云原生旗号的会议也如雨后春笋般涌现。

云原生本身甚至不能称为是一种架构,它首先是一种基础设施,运行在其上的应用称作云原生应用,只有符合云原生设计哲学的应用架构才叫云原生应用架构。

云原生的设计理念

云原生系统的设计理念如下:

  • 面向分布式设计(Distribution):容器、微服务、API 驱动的开发;
  • 面向配置设计(Configuration):一个镜像,多个环境配置;
  • 面向韧性设计(Resistancy):故障容忍和自愈;
  • 面向弹性设计(Elasticity):弹性扩展和对环境变化(负载)做出响应;
  • 面向交付设计(Delivery):自动拉起,缩短交付时间;
  • 面向性能设计(Performance):响应式,并发和资源高效利用;
  • 面向自动化设计(Automation):自动化的 DevOps;
  • 面向诊断性设计(Diagnosability):集群级别的日志、metric 和追踪;
  • 面向安全性设计(Security):安全端点、API Gateway、端到端加密;

以上的设计理念很多都是继承自分布式应用的设计理念。虽然有如此多的理念但是我们仍然无法辨认什么样的设施才是云原生基础设施,不过可以先用排除法,我将解释什么不是云原生基础设施。

云原生和本地部署应用程序之间的差异

云原生应用程序开发采用与传统企业应用程序完全不同的体系结构。

云原生的优势

编程语言

编写在公司服务器上运行的本地部署应用程序往往使用传统语言编写,如C/C ++,C#或其他Visual Studio语言(如果部署在Windows Server平台上)和企业级Java。如果它在大型机上,可能使用Cobol。

云原生应用更有可能以网络为中心的语言编写,这意味着使用HTML,CSS,Java,JavaScript,.Net,Go,Node.js,PHP,Python和Ruby。

可更新

云原生应用程序始终是最新的,云原生应用始终可用。

本地部署应用程序需要更新,并且通常由供应商按订阅提供,并且在安装更新时需要停机。

弹性

云原生应用程序通过在峰值期间增加的资源来利用云的弹性。如果你的基于云的电子商务应用程序使用频繁,你可以将其设置为使用额外的计算资源,直到峰值消退然后关闭这些资源。云原生应用可以根据需要调整增加资源和规模。

本地部署应用程序无法动态扩展。

多租户

云原生应用程序在虚拟化环境中工作,并与其他应用程序共享资源没有问题。

许多本地部署应用程序要么在虚拟环境中不能正常工作,要么根本不工作,必须要非虚拟化环境。

连接资源

本地部署应用程序与网络资源的连接相当严格,例如网络,安全性,权限和存储。其中许多资源需要进行硬编码,如果移动或更改了任何内容,它们就会中断。

“网络和存储在云端完全不同。当你听到“重新平台化”一词时,通常是为了适应网络,存储甚至数据库技术的变化,以允许应用程序在云中运行,“Deloitte的Kavis说。

停止时间

云中存在比本地部署更大的冗余,因此如果云供应商遭受中断,则另一个冗余区域可以消除中断。

本地部署应用程序可能已准备好故障转移,但如果服务器出现故障,应用程序可能会崩溃。

自动化

云计算的大部分都是自动化的,其中包括应用程序管理。 “云原生交付的好处,特别是速度和敏捷性,依赖于可靠,经过验证和经过审核的已知良好流程的基础,这些流程根据自动化和编排工具的需要而不是通过人工干预重复执行,”Splunk的Mann说。工程师应该考虑自动化是不止一次做的任何事情,以实现可重复性,自助服务,敏捷性,可扩展性以及审计和控制。

本地部署应用程序必须手动管理。

模块化设计

本地部署应用程序往往在设计上是单一的。他们肯定会将一些工作卸载到库中,但最终它是一个包含大量子程序的大应用程序。云原生应用程序更加模块化,许多功能分解为微服务。这允许在不需要时关闭它们,并将更新推广到那个模块,而不是整个应用程序。

无状态

云的松耦合特性意味着应用程序与基础架构无关,这意味着它们是无状态的。云原生应用程序将其状态存储在数据库或其他外部实体中,因此实例可以来去,应用程序仍然可以跟踪应用程序在工作单元中的位置。 “这是松耦合的本质。不依赖于基础架构允许和应用程序以高度分布的方式运行,并且仍然保持其状态独立于底层基础架构的弹性性质,“Kavis说。

大多数本地部署应用程序都是有状态的,这意味着它们会在运行代码的基础架构上存储应用程序的状态。因此,在添加服务器资源时可能会破坏应用程序。

云原生的挑战

Mann说,客户犯下的一个重大错误就是试图将旧的本地部署应用程序直接并迁移到云端。 “试图利用现有的应用程序,特别是单一的遗留应用程序 ,并将它们转移到云基础架构上将无法利用必要的云原生功能。”

相反,你应该以新的方式开展新事物,或者将新的云原生应用程序放入新的云基础架构中,或者通过拆分现有的单块应用来从头开始使用云原生原则重构它们。(译者注:这个观点可能有点绝对,迁移到云,至少可以先开始利用云的一些优势,至少能提高资源利用率。对许多组织来说,重构应用程序也基本是不可能的。)

你还需要放弃旧的开发方法。瀑布模型当然不会再用,甚至敏捷开发可能还不够。因此,你必须采用新的云原生方法,如最小可行产品(MVP)开发,多变量测试,快速迭代,以及在DevOps模型中跨组织边界密切合作。

云原生有很多方面,包括基础架构服务,自动化/编排,虚拟化和容器化,微服务架构和可观察性。所有这些都意味着一种新的做事方式,这意味着在学习新方法时打破旧习惯。请以以有节奏的速度做到这一点。

12因素应用

12因素应用提出已经有几年的时间了,每个人对其可能都有自己的理解,切不可生搬硬套,也不一定所有云原生应用都必须符合这12条法则,其中有几条法则可能还有点争议,有人对其的解释和看法不同。

大家不要孤立的来看这每一个因素,将其与自己软件开发流程联系起来,这12个因素大致就是按照软件从开发到交付的流程顺序来写的。

十二因素应用

1.基准代码

每个代码仓库(repo)都生成docker image保存到镜像仓库中,并使用唯一的ID管理,在Jenkins中使用编译时的ID。

2.依赖

显式的声明代码中的依赖,使用软件包管理工具声明,比如Go中的Glide。

3.配置

将配置与代码分离,应用部署到Kubernetes中可以使用容器的环境变量或ConfigMap挂载到容器中。

4.后端服务

把后端服务当作附加资源,实质上是计算存储分离和降低服务耦合,分解单体应用。

5.构建、发布、运行

严格分离构建和运行,每次修改代码生成新的镜像,重新发布,不能直接修改运行时的代码和配置。

6.进程

应用程序进程应该是无状态的,这意味着再次重启后还可以计算出原先的状态。

7.端口绑定

在Kubernetes中每个Pod都有独立的IP,每个运行在Pod中的应用不必关心端口是否重复,只需在service中指定端口,集群内的service通过配置互相发现。

8.并发

每个容器都是一个进程,通过增加容器的副本数实现并发。

9.易处理

快速启动和优雅终止可最大化健壮性,Kuberentes优秀的Pod生存周期控制

10.开发环境与线上环境等价

在Kubernetes中可以创建多个namespace,使用相同的镜像可以很方便的复制一套环境出来,镜像的使用可以很方便的部署一个后端服务。

11.日志

把日志当作事件流,使用stdout输出并收集汇聚起来,例如到ES中统一查看。

12.管理进程

后台管理任务当作一次性进程运行,kubectl exec进入容器内部操作。

13.API优先

  • 服务间的合约
  • 团队协作的规约
  • 文档化、规范化
  • RESTful或RPC

14.监控

  • 实时监控远程应用
  • 应用性能监控(APM)
  • 应用健康监控
  • 系统日志
  • 不建议在线Debug

15.认证授权

  • 不要等最后才去考虑应用的安全性
  • 详细设计、明确声明、文档化
  • Bearer token、OAuth、OIDC认证
  • 操作审计

致谢&内容来源

Jimmysong