共计 5671 个字符，预计需要花费 15 分钟才能阅读完成。
云原生的实质和最终成果
要明确什么是云原生，就要先弄明确云计算是什么有什么问题，云计算将计算资源、网络、存储等基础设施对立治理，通过资源规模化和自动化治理，实现升高资源的老本和进步资源的管理效率，云计算实质上解决的是资源的自动化治理问题，但数字化和信息化的要害在利用，云计算没有解决利用的治理问题，利用的治理和运维是难题，对人依赖度很高， 云原生的呈现就是为了解决利用的治理问题，利用治理比资源管理简单很多，波及到利用开发、利用架构、利用交付和利用运维等应用层的治理，还要配合利用解决资源自动化治理问题，云原生实质就是解决利用的自动化治理问题。
从成果来看，云原生的最终目标是让开发者聚焦本人的业务，业务之外（基础设施、利用架构、利用运维）的事件不必关怀，只须要懂业务就能发明出本人想要的利用，并能按需交付客户。
应用 Kubernetes 落地云原生困难重重
以后云原生相干的技术很多，其中最要害是容器、微服务架构、Kubernetes，他们颠覆式的解决了利用治理自动化问题。
- 容器技术解决了利用打包和部署自动化问题，通过容器打包保障了利用根底环境的一致性，实现了一次打包，处处运行。同时容器能够定义利用运行资源，部署时按需占用资源，实现从利用角度解决资源管理自动化。
- 微服务架构解决了简单利用的解耦和治理问题，当业务越大越简单，微服务架构将业务拆分和解耦成多个模块，并通过服务治理实现微服务运行和治理的自动化。
- Kubernetes 解决了利用编排和调度自动化问题，它是利用自动化治理最要害的拼图，底层基于容器、SDN、SDS，能实现各类型利用和微服务部署和运维过程自动化。
为了实现利用治理自动化，还有很多云原生相干的技术，像 SDN（网络自动化治理）、SDS（存储自动化治理）、Helm（简单利用交付自动化）、Service Mesh（无侵入扩大服务治理能力）、Monitoring（监控自动化）、Logging（日志自动化）、Tracing（性能剖析自动化）、Chaos engineering（容错自动化）、Gateway（网关自动化）、SPIFFE（利用拜访平安自动化）等等，这些技术能够跟 Kubernetes 联合起来应用，解决利用各个运维特色的治理自动化问题。
下面这些技术次要围绕着 Kubernetes，所以落地过程次要是 Kubernetes 落地，Kubernetes 落地过程个别分为两局部，Kubernetes 的搭建和 Kubernetes 的应用。对于 Kubernetes 搭建，基于以上技术自主搭建残缺的 Kubernetes 集群非常复杂，既要学习这些技术还要理解他们的原理，最艰难的是要把他们有机的组装起来。不过大多公司有专职的保护工程师，能够抽出大把工夫来学习和尝试。或者，抉择私有云厂商提供的 Kubernetes 商业服务，所以，搭建 Kubernetes 是有门路落地的。
相比搭建 Kubernetes，Kubernetes 的应用个别是开发人员，开发人员人数泛滥，应用习惯和学习门槛决定了开发人员的接受度，而云原生平台的应用不仅要扭转开发习惯，还要学习很多新技术，落地过程困难重重。
- 须要学习很多新概念和技术。 云原生相干的技术和概念有很多，光 Kubernetes 就有很多新的概念和形象，像 Workload、Pod、Service、Ingress、ConfigMap、PV 等，如果要用好还须要学习 Kubernetes 周边的很多概念和技术。
- 已有利用须要革新，开发习惯须要扭转。 已有的利用要运行在 Kubernetes 上，须要会写 Dockerfile 和 YAML，如果要革新成微服务架构，还须要依照框架的 SDK 革新代码，跟之前的开发习惯会有很大变动。
- 如何将利用高效交付给客户，Kubernetes 及下面这些技术并没有解决。 利用只有交付给客户能力产出价值，以后交付客户的自动化水平不高，Kubernetes 并没有解决交付过程自动化的问题。在 To C 的场景，业务频繁迭代，交付的频率很高，须要保质保量。在 To B 场景，交付更加简单，不同的客户有不同的要求，须要针对不同客户有不同的交付模式，比方 SaaS、公有交付、离线交付、个性化交付等，交付也是老本里的大头。
利用形象模型是云原生可落地的要害（实现思路）
云原生落地的难点在应用，如果能将云原生底层简单的技术包装成开发者相熟的应用层属性和动作，开发者就不必学习新的概念和技术；如果能将业务跟运维能力解耦，跟微服务框架解耦，就能实现开发者按需扩大运维能力和切换微服务框架，实现对业务按需赋能；如果能实现依据不同客户类型，自定义交付流程和自动化交付，就能大大降低交付老本，晋升客户满意度；当以上三点都能解决，就能够让开发者聚焦在业务自身，业务之外的事件不必关怀，有更多精力关注客户价值输入。
基于以上思考，通过利用形象模型是个解决思路，对利用整体进行包装和形象，蕴含利用运行所需的全副运行定义，与底层技术和概念隔离。向上用户不须要再学习和理解零碎级概念和技术，利用外部把业务和扩大能力解耦，应用利用级概念开发和治理，须要扩大服务治理、运维、平安等能力时按需开启插件。向下则包装 Kubernetes 的概念和形象，屏蔽掉底层基础设施的差别，实现利用形象模型能够运行在各类基础设施上。
利用形象模版外围设计在三方面：
- 利用级形象
- 架构充沛解耦
- 应用利用模版交付
利用级形象能简化了解和应用
利用级形象是“以利用为外围”的形象模型，对用户裸露利用级的概念、属性和动作，底层 Kubernetes 和零碎级的概念和技术，要么齐全实现自动化，要么包装成利用级的属性和动作。 为了实现灵便的利用编排和自动化调度，Kubernetes 定义了很多概念，提供丰盛的扩大机制，并以 YAML 的形式跟它交互，Kubernetes 的这些可编程的体验，对治理和扩大 Kubernetes 的人来说，是十分好的个性，但对于一般开发者，门槛太高，并且很多概念和技术跟本人开发的业务并没有间接关系，所以对于一般开发者来说须要更加敌对的操作体验，不须要学习就能应用。
利用级形象和 Kubernetes 概念 粗粒度的对应关系：
| 利用级属性 | Kubernetes 概念 |
|---|---|
| 利用运行环境 | Containers |
| 利用运行属性 | Workload |
| 利用网络属性 | SDN |
| 利用存储属性 | SDS |
| 利用对外服务属性 | Ingress |
| 利用对内服务属性 | Service |
| 利用插件 | Pod |
| 利用配置 | ConfigMap |
利用级形象并不是要将 Kubernetes 概念全副暗藏起来，而是对于不同的使用者，职责不同展示不同的交互界面。 对一般开发者职责是开发业务，只须要关怀利用级的概念，提供利用级的操作界面。但对于云原生平台的管理人员，除了关怀利用级的概念，还要关怀 Kubernetes 的治理和保护，有能力的话还能够扩大平台的能力，所以对于平台管理人员，提供高级的裸露 Kubernetes 概念的操作界面，或者间接操作 Kubernetes 也能够治理平台上的利用，通过这种形式也躲避了，因为包装概念产生的“黑箱”导致对平台的可观测性和可掌控性有余。
架构充沛解耦，依据应用场景按需组合
基于利用级的形象，利用模型通过规范的 Kubernetes API 实现跟基础设施的解耦，所有符合标准 Kubernetes API 的基础设施都能够实现对接和部署，比方各私有云厂商的 Kubernetes 实现、K3s、KubeEdge 等，通过这样的解耦，开发者只须要关怀业务和能力扩大，不必在关怀基础设施的差别，对接利用模型的利用不须要改变就能通明部署到私有云、公有云和边缘设施上，实现了利用级多云。
通常在利用里，还会包含一些跟业务无关的性能，他们的作用是为了让利用更好的运行，比方：服务治理、微服务框架、运维工具、平安工具等，这些能力跟利用有强耦合关系的，须要改代码扩大能力，将这部分能力解耦，利用就只须要关注在业务了，而且扩大的能力有很强的复用性，其余利用也须要。
利用中扩大能力的解耦应用 Kubernetes 的 Pod，Pod 中蕴含一个或多个容器，所有容器共享网络、存储，利用运行在一个容器，扩大的能力通过扩大容器的形式运行，通过共享的网络和存储实现了利用和扩大能力的解耦，这种解耦形式对业务齐全无侵入，扩大的能力用插件的模式包装，就能够实现利用按需装置和启动插件，依据网络流向和容器启动程序能够定义几种类型插件：
| 插件类型 | 阐明 |
|---|---|
| 入口网络插件 | 网络流量先到入口网络插件，而后到业务容器。例如：网关、WAF、平安工具、限流 |
| 进口网络插件 | 网络流量先到业务容器，而后到插件容器。例如：负载平衡、断路器、加密拜访 |
| 出入网络插件 | 网络流量先到插件容器，再到业务容器，再回到插件容器。例如：Service Mesh proxy |
| 旁路插件 | 网络上旁路运行。例如：性能剖析、监控、调用链分析、日志治理 |
| 初始化 插件 | Pod 的 Init 容器，Pod 启动先启动 Init 容器。例如：数据库初始化 |
依照 Pod 机制实现的插件只能扩大单个业务容器的能力，而要对利用扩大微服务架构能力，须要对每一个业务容器扩大服务治理的插件，这跟 Service Mesh 的实现机制统一，Service Mesh 的 Data Plane 须要对每个业务容器注入 Proxy，对于残缺利用就是扩大 Service Mesh 能力，对残缺利用扩大的能力是利用级插件，依据注入 Proxy 的差别能够反对多种类型的 Service Mesh 实现，比方：Istio、Linkerd、Dapr，利用能够按需开启 Service Mesh 能力，或更换实现框架。当利用跟微服务架构解耦，每一个业务容器不再受微服务框架和开发语言限度，每个业务容器只须要专一业务自身，业务容器之间也同步实现理解耦。
通过将架构充沛的解耦，解耦后的业务、插件、对接多云的能力都能实现随便组合，开发者抉择喜爱的开发语言开发业务组件，依据业务契约编排依赖关系，依据服务治理和运行稳定性要求，按需开启 Service Mesh 插件和其余运维插件，运行的基础设施环境，也依据理论须要主动对接。
利用模版成为能力复用和利用交付的载体
利用模型以利用模版的模式具象化展示和存储，利用由源码、容器镜像和插件拼装而成，而后一键导出成利用模版，利用模版设计次要围绕使用者，让使用者能用起来，让利用交付并产出价值，从而拉动利用的迭代和开发。从应用体验上，利用模版能够一键装置和一键降级，通过“利落拽”的形式实现业务拼装。利用模版有很强灵活性，利用模版反对不同颗粒度大小，模版和模版能拼装出新的模版，新的模版还能够继续拼装，颗粒的大小由使用者决定，由使用者赋予它意义。利用模版能够交付到兼容 Kubernetes API 的分支版本，实现一键装置和降级，或将利用模版寄存到利用市场，实现即点即用的成果。
利用模版须要具备四个特点：
- 模块化，能够造成可复用的能力单元，按需拼装应用场景。
- 自治，自力更生，能够独立装置、降级和治理，确保组合的灵活性。
- 可编排，模版和模版能够拼装出新模版，具备有限拼装能力。
- 可发现，通过外部服务和内部服务两种形式体现，可供业务和技术、开发者和其余利用拜访。
通过利用模版实现可复用模块和能力的打包。 利用的架构充沛解耦后，业务组件和扩大插件实践上能够复制到其余利用中，但间接复制代码或镜像十分低效，而且还有很多运行环境相干的配置须要思考，将业务组件和扩大插件打包成利用模版，并将利用模版公布到利用市场供其他人应用，能够最大水平实现模块和能力的复用，缩小反复造轮子。
通过利用模版实现 SaaS、私有化和离线环境的自动化交付，和个性化场景模块拼装。 利用模板中蕴含利用运行态所需的全副资源，对接到客户运行环境，就能够实现一键装置和运行，屏蔽了客户环境差别，一套产品模版能够交付所有类型客户，对于离线环境，利用模版以文件的模式导出，到客户离线环境再导入运行即可。对于性能须要个性化的场景，利用利用模版对业务模版打包的能力，先拼装曾经模块化的能力，而后再定制化开发，新开发的性能，如果可复用还能够持续公布成利用模版，供后续复用。
不懂 Kubernetes 实现云原生的体验
基于以上的设计思路，让开发者专一于业务自身，回到用户成果和价值体现的原点上，不必关怀底层简单的技术和不相干的概念，全面实现利用自动化。
开发利用的体验：
- 代码无需改变，就能变成云原生利用。 对于新业务或已有业务，代码不须要改变就能将其容器化。不须要懂 docker、Kubernetes 等技术，就能将利用部署起来，具备云原生利用的全副个性。
- 业务积木式拼装编排。 可复用的业务模块积攒到利用市场，当由新业务须要开发，基于利用市场曾经业务模块，通过“利落拽”的形式拼装，而后再开发没有的业务能力，当积攒的业务模块越多，开发新业务的速度越快。
- 开箱即用的 Service Mesh 微服务架构，并可一键更换 Service Mesh 框架。 不必学习微服务框架的 SDK，通过无侵入的形式实现 Service Mesh 微服务架构，支流的 Service Mesh 框架以插件的模式存在，须要时开启，如果感觉不好还能够随时更换。
应用利用的体验：
- 像装置手机 App 一样装置云原生利用。 云原生利用以利用模版的模式寄存到利用市场，当对接各种基础设施或云资源，实现利用即点即用或一键装置 / 降级。
- 一般开发者不须要学习就能实现利用运维。 通过利用级形象，一般开发者理解利用级属性就能实现利用运维，并通过插件扩大监控、性能剖析、日志、平安等运维能力，利用运维不再须要专用的 SRE。
- 简单利用一键交付客户环境。 简单利用公布成利用模版，当客户环境能够联网，对接客户环境一键装置运行，当客户环境不能联网，导出离线利用模版，到客户环境导入并一键装置运行。
实现计划
基于下面的设计思路，咱们在 Kubernetes 根底上实现了 Rainbond，并将它开源。Rainbond 提供开箱即用的体验，应用简略，不须要懂容器和 Kubernetes，反对治理多种 Kubernetes 集群，提供企业级利用的全生命周期治理。次要性能包含利用开发环境、利用市场、微服务架构、利用交付、利用运维、利用级多云治理等。
