携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第1天，点击查看活动详情
1-1、出现背景
企业为了节省成本，对资源最大化利用、更加细密度控制底层资源、产品的快速迭代更新上线以及稳定性保障。在企业IT建设发展中发生了三个阶段：
-
服务器
以“设备”为中心 -
云计算化
以“资源”为中心 -
云原生化
以“应用”为中心 【高内聚，低耦合】
1-2 、云原生之前的应用
业务需求：网站
非业务需求：安全、负载均衡、运行环境等等
这个阶段大量的时间精力在非业务需求
1-3、云原生后的应用
云实现非业务需求，更多精力可以在业务需求，云原生模式
云原生不只是说要迁移到云，而是要充分利用云基础设施和服务的独特性来快速交付业务价值。
这个阶段关注如何编写应用程序来利用这种新的基础设施的灵活性，以及获得什么业务收益？
一个云SDK的例子：
1-4云原生化后的好处
敏捷性和生产力：支持业务指标指导下的快速创新。降低维护风险并保持环境的持续更新。
弹性和可伸缩性：以自修复和无停机时间的持续可用性为目标。提供弹性缩放和容量无限的感觉。
优化和效率：优化基础设施和人力资源成本。可以在不同位置和提供商之间自由迁移。
云原生化后的云设施，一般会提供以下内容：
- 自助配置：可以即时申请新的虚拟资源（服务器、存储、网络等）。
- 弹性：根据需求自动调整资源（及相关成本）。
- 自动恢复：资源可按设计自动从故障中恢复，将对服务故障的影响降至最低。
- 不可变部署：例如，基于容器镜像的部署。
- 声明式配置：“基础设施即代码”提供将来状态。万物可配置，一切配置都是代码。
- 运行时无关：平台将组件（例如容器）视为黑盒，不需要理解它们的内容。
- 组件编排：通过通用的声明式策略和配置赋能管理（监控、伸缩、可用性、路由等）。
随着云平台及概念的成熟，云原生中的云实际上还会对底层基础设施的进一步抽象。后期我们可能会涉及更多，如构建自动化、服务网格、日志、跟踪、分析、软件定义网络和存储等等，相信随着时间推移，这些方面也会变得更加标准化。
1-5 云原生定义
目前云原生没有确切的定义，云原生一直在发展变化之中，解释权不归某个人或组织所有。
技术的变革，一定是思想先行，云原生是一种 构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud 表示应用程序位于云中，而不是传统的数据中心；Native 表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（例如：K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps 支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。
真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。
1-6 云原生关键词
（1）微服务
随着应用规模越来越大容易造成性能、管理以及后期扩展瓶颈，为了满足系统可靠性、并发量以及快速开发的需求。出现了微服务思想，它将单一服务拆分成一组小服务、服务之间相互协调、配合，这种思想比传统的应用程序更有效地利用计算资源。
（2）容器
容器的本质是一个进程。它极其轻量、秒级部署的特点，因此微服务思想非常适合在容器去实践，每个容器承载一个服务，一台服务器同时运行多个容器，从而就能很轻松地模拟出复杂的微服务架构。Docker最主流容器管理工具，制定了容器标准。
容器技术使得应用具有了一种“自包含”的定义方式。所以，这样的应用才能以敏捷的、以可扩展可复制的方式发布在云上，发挥出云的能力。这也就是容器技术对云发挥出的革命性影响所在，所以说，容器技术正是云原生技术的核心底盘。
（3）容器编排工具
容器技术使得微服务架构落地，那么就需要对容器进行管理。一款容器编排系统应该具有以下特点：
有序组织： 按照业务特点将容器组织成一个个的功能集合或单元，形成各种组合形式，并且可自由的在不同组合之间切换；
合理调度： 按照设定的规则，为应用进程找到最佳的运行环境，使得硬件资源与应用进程形成最佳匹配组合；
自动控制： 无需人工干预，依靠自身能力按照事先设定的规则，持续监控应用状态，通过动态调整使得最终状态与期望状态保持一致，保证应用的持续可用。
Docker本身提供Docker Swarm进行容器编排管理，但面对稍微大一点的集群规模效果并不理想。
Google2014年开源了一款容器集群管理系统Kubernetes（简称K8S），是目前非常强劲的容器编排工具，因为Google 在十年前就已经将容器化作为基础架构，borg 是 Google 内部的大型集群管理系统。在docker 大规模容器化后，Google为了迅速占领容器化管理，Google 基于 borg 的设计理念开发新的组件系统Kubernetes，并且开源给了CNCF。
（4）CNCF
CNCF(Cloud Native Computing Foundation)于 2015 年 7 月成立,隶属于 Linux 基金会,初衷围绕“云原生”服务云计算, 力于维护和集成开源技术，支持编排容器化微服务架构应用。它的成立标志着云原生正式进入高速发展轨道。
（5）服务网格（Service Mesh）
处理服务与服务之间通信的基础设施层，是一种微服务的基础架构，使实例之间的通信更加流畅、可靠和迅速。Service Mesh的出现，弥补了Kubernetes在微服务的连接、管理和监控方面的短板，为Kubernetes提供更好的应用和服务管理。因此，Service Mesh的代表Istio一经推出，就被认为是可以和Kubernetes形成双剑合璧效果的微服务管理的利器，受到了业界的推崇。
（6）不可变基础设施
任何基础设施的实例一旦创建之后变成为只读状态，如需要修改和升级，则使用新的实例进行替换，在k8s中能够很明显体现。这样做的目的是避免因传统业务环境下，每次对业务的修改造成隐藏式的问题。
（7）声明式API
k8s的各类资源是通过各种 API 对象来提供,定义k8s中的YAML文件，表示所期望的最终状态是什么样子，系统将不断向该状态驱动。
声明式API描述的是状态，不关心过程
命令式API是要告诉做的过程
1-7 云原生落地问题
企业对云原生的应用需求：
- 降本增效
- 增加服务的可扩展性、弹性功能、灵活性
- 开发人员专注于业务，加速业务上线，可持续
- 高效运维管理，减少由于人为错误导致的故障风险，自动化的实时修补和升级等需求
目前的落地方面主要存在以下问题：
-
云原生模式出现，很多公司都会选择拥抱开源文化并且开源事实标准去影响产业。开源也是培养用户、确定行业标准和赚钱的重要手段。这里面开源的技术栈非常多，涵盖了基础设施、中间件、应用程序，覆盖了软件开发的交付、监控、运维等不同阶段。如何选择合适的技术栈来打造适合企业自身发展的云原生能力是充满挑战的。
-
与此同时，很多企业有众多遗留系统和技术栈，那在转型云原生的时候如何能够利用云原生技术栈来完成系统的迁移，甚至在整个过程中去消除一些技术债，对于容器内与容器外的混合环境中的管理这些都是充满挑战的。
-
对于开发与运维相关人员，云原生的技术及理念都需要在实践中逐渐学习，传统基础设施及相关流程会成为引入新技术及理念的很大阻力，在实践中业务会处于新旧并存混合环境中。
-
传统的安全是基于边界防护的网络安全架构，是以职能区分、以人为主的防护策略安全，这已经不太能满足云原生的安全需求，云原生时代物理安全边界逐渐模糊，需要基于动态工作负载完成安全防护，变成了人人有责、无处不在的云原生安全体系。传统安全主要是在右侧，云原生最大的特点是要求安全左移也就是安全前置，在开发的过程中就要考虑安全，将安全投资更多的放到开发安全，包括安全编码、供应链(软件库、开源软件等)安全、镜像及镜像仓库安全等，因此传统策略很多已经不再适用，对人员的安全意识和安全技能产生了额外要求。
-
并不是所有业务都适合云原生，需要慢慢尝试。
