共计 3095 个字符，预计需要花费 8 分钟才能阅读完成。
📄
文|togettoyou
目前次要负责云原生服务治理平台的研发
日常致力于 Go、云原生畛域
本文 3164 字 浏览 5 分钟
▼
云原生 仿佛曾经是一个陈词滥调的概念了，相干的文章层出不穷。
自己当初工作中负责云原生服务治理平台的研发（次要治理各类云原生基础设施，平台服务和第三方托管利用），但即便如此，常被问起云原生是什么时，我也很难简洁的向人表述分明，导致自我也常常问一遍，云原生到底是什么，我又在做什么。
PART. 1 云原生到底是什么
云原生是一个组合词，即 Cloud Native。
Pivotal（已被 VMware 收买）官网的 What is cloud native?[1] 一文中提到云原生是一种构建和运行应用程序的办法，云原生开发交融了 DevOps、继续交付、微服务和容器的概念在外面。
CNCF（云原生计算基金会）在 cncf/toc[2] 给出了云原生 V1.0 的定义：
云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。
这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩，云原生技术使工程师可能轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会（CNCF）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。
联合官网的定义，我集体对云原生简洁的了解就是：云原生并不是某种具体技术，而是一类思维的汇合，用来帮忙疾速构建和运行应用程序，其中既涵盖着一整套技术体系 （容器、服务网格、微服务、不可变基础设施和申明式 API）， 也蕴含着利用开发的治理要点 （DevOps、继续交付、康威定律[3]）， 只有合乎这类思维的利用就能够称为云原生利用。
PART. 2 云原生技术体系
云原生的一整套技术体系其实是紧密联系的，这得从软件架构的逐渐演进说起。
即：单体 -> 微服务 -> 基于 K8s 上的微服务 -> 服务网格
单体架构，将所有的性能集成在一个工程里，我的项目倒退晚期，利用的开发绝对简略，即便须要对利用进行大规模更改、测试、部署也很容易，甚至是横向扩大。运行多个实例后，一个负载均衡器就能够搞定。
随着时间推移，一个胜利的利用必然变得越来越臃肿，代码库随之收缩，团队治理老本一直进步，即俗话说的陷入单体天堂。面对单体天堂，开发者难以了解代码全副，开发速度变迟缓，部署周期变长，而且横向扩大也会遇到挑战，因为利用不同模块对资源的需要是互相冲突的，有些可能须要的是更大内存，有些可能须要的是高性能 CPU，作为单体利用，就必须都满足这些需要。
当呈现一个问题，天然会有针对该问题的解决方案，云原生技术体系之一的 微服务架构 就是针对单体天堂的解决方案。既然单体利用是将全副性能都集成在一个工程里去编译部署，那当初只有把各个性能拆分进去（通常是依据 业务能力 或者依据 子域 合成，子域围绕 DDD 来组织服务），将每个拆分的模块作为一个独自的服务，独立部署（服务之间通常通过 REST+JSON 或 gRPC+ProtoBuf 进行通信），使这一个个的服务独特提供整个利用的性能。
但微服务也不是银弹，引入微服务架构后，分布式系统也带来了各种复杂性。诸如配置核心、服务发现、网关、负载平衡等业务无关的基础设施层面都须要开发者自行在业务层面实现。
比方一个常见的微服务架构解决方案（图源 凤凰架构[4]），就须要开发者自行引入各种组件:
我的项目开发实现后终归要到部署流程的，晚期的传统做法是把应用程序间接部署到服务器上，但服务器的零碎、环境变量等是会一直变动的，甚至装置了新的利用，就会引起和其余利用的抵触，导致利用自身须要跟着用户零碎环境的扭转而做出扭转。为了解决这个问题，不可变 基础设施 的口号就喊响了。
- 第一阶段是将服务部署为虚拟机，将作为虚拟机镜像打包的服务部署到生产环境中，每一个服务实例都是一个虚拟机。
- 第二阶段，为了缩小开销，将服务部署为 容器，作为容器镜像打包的服务部署到生产环境中，这样每一个服务实例都是一个容器。
不可变基础设施：
任何基础设施的实例一旦创立之后变为只读状态，如须要批改或降级，须要应用新的实例替换旧的。容器镜像就是一种不可变基础设施的具体实现。
当初容器未然成为了微服务的好搭档，服务实例隔离，资源也能够不便管制，但成千上百的容器，治理起来过于麻烦。于是，容器编排工具又进去了，Kubernetes 目前根本对立了容器编排的市场，实现了容器集群的自动化部署、扩缩容和保护等性能。但 Kubernetes 可不只局限于容器编排，上文的微服务架构中，须要开发者自行在利用层面解决业务无关的基础设施层面的一系列问题，当初 Kubernetes 就能够解决大部分，如图（图源 凤凰架构[5]）：
Kubernetes 的编码方式其实就是一种 申明式 API（指通过向工具形容本人想要让事物达到的指标状态，而后由这个工具外部去计算如何令这个事物达到目标状态）。
目前为止，我曾经提到了云原生技术体系中容器、服务网格、微服务、不可变基础设施和申明式 API 外面的四种了，还有一个 服务网格。
一步步倒退下来，都是为了把 业务和基础设施解耦，让开发者能够疾速开发本人的业务，无需关怀底层基础设施。服务网格也是想干这事的，心愿将更多业务无关的性能下沉到基础设施，号称微服务 2.0。
服务网格外围在于将客户端 SDK 剥离，以 Proxy 组件形式独立过程运行，每个服务都额定部署这个 Proxy 组件，所有出站入站的流量都通过该组件进行解决和转发，这个组件被称为 Sidecar（边车利用）。
Sidecar 只负责网络通信，还须要有个组件来对立治理所有 Sidecar 的配置。在服务网格中，负责配置管理的局部叫管制立体（control plane），负责网络通信的局部叫数据立体（data plane）。数据立体和管制立体一起形成了服务网格的根本架构。
据说再更进一步就是无服务（Serverless）了。
「云原生治理要点」
DevOps（Development 和 Operations 的组合词）是一组过程、办法与零碎的统称，用于促成开发（应用程序 / 软件工程）、技术经营和品质保障（QA）部门之间的沟通、合作与整合。
——百度百科
DevOps 的两个核心理念是 CI（继续集成）和 CD（继续交付 / 部署）。
「结 尾」
感激浏览到这里，本文较为毛糙的形容了云原生作为一种思维，其技术体系之间的分割，如果有误欢送探讨和斧正！
「参考资料」
[1] What is cloud native?:
https://tanzu.vmware.com/cloud-native
[2] cncf/toc:
https://github.com/cncf/toc/blob/main/DEFINITION.md
[3] 康威定律:
https://zh.wikipedia.org/zhmy/%E5%BA%B7%E5%A8%81%E5%AE%9A%E5%BE%8B
[4] 凤凰架构:
http://icyfenix.cn/exploration/projects/microservice_arch_springcloud.html
[5] 凤凰架构:
http://icyfenix.cn/exploration/projects/microservice_arch_kubernetes.html
本周举荐浏览
如何在生产环境排查 Rust 内存占用过高问题
新一代日志型零碎在 SOFAJRaft 中的利用
终于！SOFATracer 实现了它的链路可视化之旅
蚂蚁团体技术危险代码化平台实际（MaaS）
