畅聊云原生—从概念到趋势
发布时间：2022-08-04 16:07:55 所属栏目：云计算 来源：互联网
导读：1、 云原生是什么? 云原生(Cloud Native)，从字面上理解就是云计算和土著的意思云计算上的原住民。 从Cloud来看，云可以看作是一种提供稳定计算存储资源的对象。为了实现这一点，云提供了虚拟化、弹性扩展、高可用、高容错性、自恢复等基本属性。 再看Native
|
1、 云原生是什么? 云原生(Cloud Native)，从字面上理解就是云计算和土著的意思——云计算上的原住民。 从Cloud来看，云可以看作是一种提供稳定计算存储资源的对象。为了实现这一点，云提供了虚拟化、弹性扩展、高可用、高容错性、自恢复等基本属性。 再看Native，云原生和在云上跑的传统应用不同。一些传统应用是基于SOA(Service-Oriented Architecture,面向服务架构)架构来搭建的，然后再被放到云上。这些传统应用没有充分运用到云的优势。 因为云作为一种分布式架构，它的原住民应该也是要符合这一特性的——就像我们常说的一方水土养一方人，如果水土不服那就会很糟糕!而微服务是具有分布式设计的属性的。 其次云作为一种PaaS(Plarform as a Service, 平台即服务)服务，云上的原住民的整个生命周期都应该是基于云的理念来实现的，那么就需要一套自动化的开发流程来实现。 这些是从字面上对Cloud Native的解构，然后我们再来看看云原生计算基金会(Cloud Native Computing Foundation, 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. 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. 根据官方定义，我们总结下云原生就是： 基于容器、服务网格、微服务、不可变基础设施和声明式 API 构建的可弹性扩展的应用。 基于自动化技术构建具备高容错性、易管理和便于观察的松耦合系统。 构建一个统一的开源云技术生态，能和云厂商提供的服务解耦。 云原生是关于速度和敏捷性的。企业的业务系统正在从实现业务能力演变为加速业务速度和增长的战略转型武器。 同时，随着用户的要求更多，业务系统也变得越来越复杂。它们更加期望快速的反应能力，创新的功能，以及零停机。 性能问题、重复性的错误和无法快速迭代已不再被接受。当出现上述这些情况，你的用户将会访问你的竞争对手。 2、云原生的关键因素 云原生的速度和敏捷性来自于许多因素。 本章我们将会讲述其中最主要的六大因素。 （1）云架构(Cloud Infrastructure) 云原生系统充分利用了云服务模式的优势。这些系统的设计目的是为了在动态、虚拟化的云环境中茁壮成长。它们广泛使用PaaS的计算基础设施和管理服务。它们将底层基础设施视为一次性的-在几分钟内完成配置，并通过自动化按需调整、扩展或销毁。 在云原生领域，有一个类比的概念叫做Pets vs. Cattle，字面理解的意思就是宠物 vs. 牛。 Cattle-牛 而Cattle的服务模式是不同的。你把每个实例作为一个虚拟机或容器来配置。它们是相同的，并分配给一个系统标识符。你通过创建更多的实例来进行扩展。当一个实例变得不可用时，没有人注意到。 Cattle的模式使用不可改变的基础设施。服务器不会被修复或修改。如果一个服务器出现故障或需要更新，它就会被销毁，然后配置一个新的服务器。所有这些工作都通过自动化完成。 （2）现代设计(Modern Design) 你会如何设计一个云原生应用程序?你的架构会是什么样子的?你会遵守哪些原则、模式和最佳实践?哪些基础设施和操作问题是重要的? 十二因素 如何构建一个云应用?业界广泛接受的一个准则就是十二因素。 12因素是一系列云原生应用架构的模式集合。这些模式可以用来说明什么样的应用才是云原生应用,可以用来衡量一个后端服务是否适合上云。 本节的反例并不是指技术本身不够好，而是指它们的一些原生特性对于开发复杂的应用不够友好。 CodeBase-基准代码 One codebase tracked in revision control, many deploys。 一份基准代码可以多份部署，可通过版本控制进行追踪。 反例：多个无关项目、数百万行代码全部放到一个仓库;对于差异需求，直接复制项目仓库单独开发，同时维护多个仓库代码。 Dependencies-显式和隔离的依赖 Explicitly declare and isolate dependencies。 每个微服务都可以显式声明依赖并且互不干扰，拥抱变化而不影响整个系统。 反例：Node.js之父Ryan Dahl另起炉灶创造了Deno，Deno的import远程代码就是Node世界的npm反向极端，造成了隐式依赖;Golang在1.13之前没有go module的时候，也是违反这条原则的。且不说不清晰的第三方依赖容易导致"投毒"，这对代码的问题定位、维护、交接都是很大的负担。 Backing Services-分离后端服务 Treat backing services as attached resources。 把后端服务当作附加资源。后端服务是指程序运行所需要的通过网络调用的各种服务，包括数据库，缓存，消息队列等。 反例：把缓存服务和应用服务打包到同一个容器镜像，通过/var/redis.sock这样的Domain Socket形式访问;或者把第三方应用服务的源码直接复制到自己的代码中，在一个进程中互相调用。 （编辑：PHP编程网 - 黄冈站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330482号