畅聊云原生—从概念到趋势
发布时间：2022-07-02 13:34:57 所属栏目：云计算 来源：互联网
导读：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. 牛。 Pets-宠物 在传统的数据中心，服务器被视为宠物：一台物理机器，被赋予一个有意义的名字，并由你照顾。你通过向同一台机器添加更多的资源来进行扩展。如果服务器生病了，你要照顾它直到恢复健康。 在这种模式下，服务器被视为不可缺少的系统组件，永远不可能停机。一般来说，它们是人工建立、管理和手动"喂养"的。这方面的例子包括大型机、单独的服务器、HA(Highly Available,高可用)负载均衡器/防火墙、主/从数据库系统等。 Cattle-牛 而Cattle的服务模式是不同的。你把每个实例作为一个虚拟机或容器来配置。它们是相同的，并分配给一个系统标识符。你通过创建更多的实例来进行扩展。当一个实例变得不可用时，没有人注意到。 Cattle的模式使用不可改变的基础设施。服务器不会被修复或修改。如果一个服务器出现故障或需要更新，它就会被销毁，然后配置一个新的服务器。所有这些工作都通过自动化完成。 由两台以上的服务器组成的阵列，一般使用自动化工具构建，阵列中没有哪个服务器是不可替代的。通常情况下，故障事件不需要人工干预，因为阵列表现出 "绕过故障"的属性，通过重新启动故障服务器或通过三重复制或编码擦除等策略复制数据。 这方面的例子包括网络服务器阵列，多主机数据存储，如Cassandra集群，以及几乎所有的负载平衡和多主机。 （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的时候，也是违反这条原则的。且不说不清晰的第三方依赖容易导致"投毒"，这对代码的问题定位、维护、交接都是很大的负担。 Config-配置分离至环境 Store config in the environment。 配置数据和构建产物完全分离，配置数据单独管理，只在运行环境中出现。 反例：环境相关的配置，混在容器镜像、甚至代码包中，每个环境需要单独构建打包一个版本。这种做法在传统的开发模式中很常见。 Backing Services-分离后端服务 Treat backing services as attached resources。 把后端服务当作附加资源。后端服务是指程序运行所需要的通过网络调用的各种服务，包括数据库，缓存，消息队列等。 反例：把缓存服务和应用服务打包到同一个容器镜像，通过/var/redis.sock这样的Domain Socket形式访问;或者把第三方应用服务的源码直接复制到自己的代码中，在一个进程中互相调用。 Build, release, run-分离构建、发布、运行 Strictly separate build and run stages。 每个版本必须在构建、发布和运行阶段实行严格的分离。每个版本都应该被标记为唯一的ID，并支持回滚的能力。CI/CD系统有助于实现这一原则。 反例：开发改完代码，本地打个Patch发给运维，也不告知产品经理改了什么，直接口头告诉运维批量更换某些文件。 Processes-无状态的服务进程 Execute the app as one or more stateless processes。 每个微服务应该在自己的进程中执行，与其他正在运行的服务隔离。如果存在状态，应该将状态外置到后端服务中，例如数据库、缓存等。 反例：应用服务的多个实例之间互相通信，共享一些内存数据;或者开发自治的集群选主、任务分发等功能。 Port Binding-端口绑定 Export services via port binding。 每个微服务都应该是独立的，其接口和功能都暴露在自己的端口上。这样做提供了与其他微服务的隔离。 反例：提供出去部署的包的是放到Tomcat的war、放到IIS的dll，自己本身没有描述通信协议，也没有指定绑定的端口，完全依赖Tomcat/IIS的配置。 Concurrency-并发能力 Scale out via the process model。 通过进程模型进行扩展，扩展方式有进程和线程两种。进程的方式使扩展性更好，架构更简单，隔离性更好。线程扩展使编程更复杂，但是更节省资源。 反例：把Session放到内存中。 Disposability-快速启动和优雅终止的易处理 Maximize robustness with fast startup and graceful shutdown。 快速启动和优雅终止可最大化健壮性，只有满足快速启动和优雅终止，才能使服务更健壮。 反例：很重的Java服务启动耗时十几分钟;缩容靠kill -9强杀进程;服务也没有实现收到SIGTERM信号进入"跛脚鸭状态"，也没有等待请求处理完再关闭进程。 Dev/prod parity-环境等同 Keep development, staging, and production as similar as possible。 尽可能地保持整个应用生命周期的环境相似，包括开发环境、预发布环境、线上环境等。 反例：开发环境不容器化，产线容器化;开发环境用的MariaDB，产线用的MySQL;开发环境数据库没主从，产线配置了主从同步。这样在MySQL读写分离时，主从同步那几毫秒的延迟导致各种奇怪Bug，在开发环境也许永远都重现不出来。 （编辑：开发网_郴州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330466号