云原生是什么？-技术圈

　最近几年，相信大家都越来越多的在各种场合各种平台听到过了 “云原生” 这个词。
　　比如，关于云原生应用的 “Twelve-Factor App” 理论，现在已经是基础设施的现象级容器技术，几乎已经等同于容器本身的 Docker，还有容器编排技术 Kubernetes，以及 Kubernetes 背后的 CNCF（云原生计算基金会）。
　　那么，什么才是 “云原生” 呢？什么样的系统架构才能被称为云原生架构呢？

PS：因为公众号本身的限制，源码的 GitHub 地址均无法正常跳转，可以翻到底部，阅读原文查看原始博客文章。

什么是云原生？

在 CNCF 官网的 About 板块，有 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.

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.

下面是不精准的翻译：

云原生技术使组织能够在现代动态环境（例如公共云、私有云和混合云）中构建和运行可扩展的应用程序。容器、服务网格、微服务、不可变基础设施和声明式 API 是这种方法的例证。
这些技术使松散耦合的系统具有弹性、可管理性和可观察性。与强大的自动化相结合，它们使工程师能够以最少的工作量频繁且可预测地进行高影响力的更改。
CNCF 旨在通过培育和维持一个由供应商中立的开源项目生态系统来推动这种范式的应用。我们将最先进的模式民主化，使每个人都可以使用这些创新。

这个说明更多的是描述了云原生能带给我们什么，我在 CNCF 2019 年 5 月 21 日的一篇公告 Cloud Native Computing Foundation grows to more than 400 members 中找到了更精确的描述：

Cloud native computing uses an open source software stack to deploy applications as microservices, packaging each part into its own container, and dynamically orchestrating those containers to optimize resource utilization.

皇家翻译：

云原生计算使用开源技术栈来部署微服务应用，将每个组件打包到它自己的容器中，并且通过动态编排以优化资源利用率。

提取一下里面的关键词：开源技术栈、微服务应用、容器化、动态编排，重新组织一下，即为：云原生应用就是把微服务架构的应用，以容器化的方式部署在具有动态编排能力的云平台（Kubernetes）上。

如何设计一个云原生的程序？

以下内容均节选翻译自资深云原生领域专家 Siddharth Patnaik 发表的文章 Cloud Native Application Architecture，有兴趣的同学可以拜读原文。

PS：是在 Google Translate 的基础上进行的二次翻译，受译者水平所限，可能会有错漏，会尽可能保证内容通顺且语义流畅。

Cloud-native is about how applications are created and deployed, not where.

云原生关注的是应用如何构建和部署，而非在哪里运行。

设计为松散耦合的微服务

微服务是一种将单个应用程序开发为一组小型服务的方法，每个服务都在自己的进程中运行，并使用 HTTP 等轻量级协议进行通信。这些服务是围绕业务能力构建的，并且可以通过完全自动化的部署机制独立部署。

使用最佳的语言和框架

云原生应用程序的每项服务都应当使用最适合该功能的语言和框架开发。
云原生应用程序是多语言的。
服务使用多种语言、运行时和框架。
例如，开发人员可能会基于 WebSockets 构建一个实时流服务，使用 Node.js 开发，同时选择 Python 来构建基于机器学习的服务，并选择 spring-boot 来暴露 REST API。开发微服务的细粒度方法使他们能够为特定工作选择最佳语言和框架。

以交互和协作为核心的 APIs

云原生服务使用基于协议的轻量级 API，如表征状态传输 (REST) 来公开其功能。内部服务使用二进制协议（如 Thrift、Protobuff、GRPC 等）相互通信以获得更好的性能。

无状态且可大规模扩展

云原生应用程序将其状态存储在数据库或其他一些外部实体中，以便实例可以随意增减，任何实例都可以处理请求。
它们不依赖于底层基础设施，这允许应用程序以高度分布式的方式运行，并且仍然独立于底层基础设施的弹性性质保持其状态。
从可扩展性的角度来看，架构很简单，只需将商品服务器节点添加到集群中就可以扩展应用程序。

韧性作为架构核心

根据墨菲定律 ——“任何可能失败的事情都会失败”。
当我们将此应用于软件系统时，在分布式系统中，故障必定会发生。
硬件可能会失败、网络可能会出现暂时性故障、极少情况下，整个服务或区域都可能会遇到中断，但即使是这样的小概率事件也必须进行预案。
韧性是系统从故障中恢复并继续运行的能力。这不是试图避免故障，而是以一种避免停机或数据丢失的方式响应故障。韧性的目标是在发生故障后将应用程序恢复到完全正常运行的状态。韧性提供以下功能：

高可用性 — 应用程序能够继续在健康状态下运行，而不会出现明显的停机时间。
灾难恢复 — 应用程序从罕见但重大事件中恢复的能力：非暂时性、大规模故障，例如影响整个区域的服务中断。

使应用程序具有弹性的主要方法之一是通过冗余。HA 和 DR 方案使用多节点集群、多区域部署、数据复制、无单点故障、持续监控等实现。

以下是一些实施弹性的策略：

重试暂时性故障 — 暂时性故障可能是由于网络连接暂时中断、数据库连接断开或服务繁忙时超时造成的。通常，可以通过重试请求来解决暂时性故障。
跨实例负载均衡 — 一切皆集群。无状态应用程序应该能够通过向集群添加更多节点来扩展。
优雅降级 — 如果服务失败并且没有故障转移路径，应用程序可能能够优雅降级，同时仍然提供可接受的用户体验
限制大量租户 / 用户 — 有时少数用户会产生过多的负载。这可能会对其他用户产生影响，从而降低应用程序的整体可用性。
使用断路器 — 断路器模式可以防止应用程序重复尝试可能失败的操作。断路器包装对服务的调用并跟踪最近失败的次数。如果故障计数超过阈值，断路器开始返回错误代码而不调用服务。
应用补偿交易 — 补偿事务是撤销另一个已完成事务的影响的事务。在分布式系统中，实现强事务一致性可能非常困难。补偿事务是一种通过使用一系列可在每一步撤消的较小的单独事务来实现一致性的方法。
测试弹性 — 通常弹性测试不能像测试应用程序功能一样完成（通过运行单元测试、集成测试等）。相反，您必须测试端到端工作负载在仅间歇性发生的故障条件下的执行情况。例如：通过进程崩溃、证书过期、使依赖服务不可用等来注入失败。像【chaos monkey】这样的框架可以用于这种混乱测试。
打包成轻量级容器并编排
容器可以将应用程序隔离到共享操作系统内核的小型轻量级执行环境中。通常以兆字节为单位，容器使用的资源比虚拟机少得多，而且几乎可以立即启动。Docker 已经成为容器技术的标准。它们提供的最大优势是便携性。
云原生应用程序使用 Kubernetes 进行部署，Kubernetes 是一个开源平台，旨在自动化部署、扩展和管理容器化应用程序。Kubernetes 最初由 Google 开发，现已成为部署云原生应用程序的操作系统。它也是最早在 CNCF 毕业的几个项目之一。
通过 CI/CD 实施敏捷 DevOps 和自动化
DevOps，“开发” 和 “运维” 的合并描述了实现快速敏捷开发和可扩展、可靠运营所需的组织结构、实践和文化。DevOps 是关于使开发和运维团队保持一致的文化、协作实践以及自动化，以便他们在改善客户体验、更快地响应业务需求以及确保创新与安全和运营需求之间取得平衡方面拥有统一的心态。现代组织相信开发人员和运维人员以及职责的合并，以便一个 DevOps 团队承担这两项职责。通过这种方式，您只有一个团队负责开发、部署和在生产中运行软件。
持续集成和持续交付:

持续集成 (CI) 和持续交付 (CD) 是一组操作原则，使应用程序开发团队能够更频繁、更可靠地交付代码更改。CI 的技术目标是建立一种一致且自动化的方式来构建、打包和测试应用程序。随着集成过程的一致性，团队更有可能更频繁地提交代码更改，从而带来更好的协作和软件质量。
持续交付从持续集成结束的地方开始。CD 自动将应用程序交付到选定的基础架构环境。它获取由 CI 构建的包，部署到多个环境中，如 Dev、QA、Performance、Staging 运行各种测试，如集成测试、性能测试等，最后部署到生产中。持续交付通常在管道中很少有手动步骤，而持续部署是一个完全自动化的管道，它可以自动化从代码签入到生产部署的整个过程。