跳到主要内容

云原生

更新于:2024年1月29日

云原生

image-20220423230816205

目录

[TOC]

1、什么是云原生

1、2010年 Paul Fremantle,WSO2 的 CTO 和联合创始人

Paul Fremantle,WSO2 的 CTO 和联合创始人,于 2010 年提出的 Cloud Native

image-20230922072918833

从上图的描述可以看出,最早期关于云原生的定义已经比较准确了,也基本涵盖了云原生的两个关键词:云(在云环境中运行、多租户等)和原生(分布式、弹 性)。

然而在 2010 年,微服务的概念都还没被提出来,更别提容器和 K8S 生态了。可以说上面这个定义虽然准确,但是已经不符合高速发展的技术时代的需求了。

2、2013年 Adrian Cockcroft, 时任 Netflix 云架构师、2016 年 AWS 的 VP

Adrian Cockcroft, 时任 Netflix 云架构师、2016 年 AWS 的 VP,于 2013年提出的 Cloud Native

image-20230922072927165

届时,Netflix 在 AWS 上面运行着上万个实例,每天都有数以千计的实例被创建或删除。Netflix 在云环境上的成功实践,吸引着大批人员和公司争相模仿。Adrain 在介绍 Netflix 的成功经验时,主要是从目标、原则和措施等方面进行了描述。

在 Adrain 对 Cloud Native 的目标描述中,可扩展性、高可用、敏捷、效率这四个词极为关键,这也是为什么现如今大量的企业在进行云原生转型的主要原因,可 以说云原生成为了企业架构转型的必经之路。

为了实现这个目标,Adrain 提出了五大原则,而这五大原则如果你去细细琢磨,你会发现它们都是为上面四个目标服务的。这个时候,微服务、DevOps 的概念相 继兴起,成为了的云原生的一部分或者说云原生的手段,此外,敏捷开发被开始被大家提倡,用来助力互联网公司加快研发速度、提升用户体验。

3、2015年 Matt Stine,Pivotal 公司技术领导者

Matt Stine,Pivotal 公司技术领导者,在2015年发布的电子书《MIgrating to Cloud Native Application Archtecture》一书中对如何 将应用迁移到 Cloud Native 做了详细的介绍

image-20230922072935234

Matt 认为在单体架构向 Cloud Native 迁移的过程中,需要文化、组织、技术共同变革。Matt 首次强调了文化与组织的变革对云原生的重要性,我觉得这个观点时 至今日依旧至关重要。从组织文化的角度来讲,一切以人为主,需要建立自由开放的环境,高度信任,自我驱动,充分发挥每一个人的力量,而不是让工程师成为 螺丝钉。应当避免大事小事都拿到会议室讨论,造成决策瓶颈。

另外,Matt 在延续前人思想总结的前提上,首次将“十二因子”与云原生关联起来。十二因子的概念简介见下图:

image-20210907210834871

云原生学说发展到这,已经趋于成熟了,但是以上几乎都是个人的定义和看法。业务场景是千变万化的,一方面每个人站的角度不一样,心中的架构也会不同;另 一方面,架构是在持续演进的,随着新技术层出不穷,云原生定义也会继续不断演进。

2015年由 Linux 基金会发起了一个 The Cloud Native Computing Foundation(CNCF) 基金组织,CNCF 基金会的成立标志着云原生正式进入高速发展轨道, google、Cisco、Docker 各大厂纷纷加入,并逐步构建出围绕 Cloud Native 的具体工具,而云原生这个的概念也逐渐变得更具体化。这也是非常具有历史意义 的,CNCF 对于 云原生的推动起到了巨大的作用。


  • 12facor

https://12factor.net/zh_cn/

image-20210907211453818

image-20210907211627393

image-20210907211702818

简介

如今,软件通常会作为一种服务来交付,它们被称为网络应用程序,或软件即服务(SaaS)。12-Factor 为构建如下的 SaaS 应用提供了方法论:

  • 使用标准化流程自动配置,从而使新的开发者花费最少的学习成本加入这个项目。
  • 和操作系统之间尽可能的划清界限,在各个系统中提供最大的可移植性
  • 适合部署在现代的云计算平台,从而在服务器和系统管理方面节省资源。
  • 将开发环境和生产环境的差异降至最低,并使用持续交付实施敏捷开发。
  • 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展

这套理论适用于任意语言和后端服务(数据库、消息队列、缓存等)开发的应用程序。

背景

本文的贡献者参与过数以百计的应用程序的开发和部署,并通过 Heroku 平台间接见证了数十万应用程序的开发,运作以及扩展的过程。

本文综合了我们关于 SaaS 应用几乎所有的经验和智慧,是开发此类应用的理想实践标准,并特别关注于应用程序如何保持良性成长,开发者之间如何进行有效的代码协作,以及如何 避免软件污染

我们的初衷是分享在现代软件开发过程中发现的一些系统性问题,并加深对这些问题的认识。我们提供了讨论这些问题时所需的共享词汇,同时使用相关术语给出一套针对这些问题的广义解决方案。本文格式的灵感来自于 Martin Fowler 的书籍: Patterns of Enterprise Application ArchitectureRefactoring

读者应该是哪些人?

任何 SaaS 应用的开发人员。部署和管理此类应用的运维工程师。

image-20210907211854193

12-factors I. 基准代码 一份基准代码,多份部署 II. 依赖 显式声明依赖关系 III. 配置 在环境中存储配置 IV. 后端服务 把后端服务当作附加资源 V. 构建,发布,运行 严格分离构建和运行 VI. 进程 以一个或多个无状态进程运行应用 VII. 端口绑定 通过端口绑定提供服务 VIII. 并发 通过进程模型进行扩展 IX. 易处理 快速启动和优雅终止可最大化健壮性 X. 开发环境与线上环境等价 尽可能的保持开发,预发布,线上环境相同 XI. 日志 把日志当作事件流 XII. 管理进程 后台管理任务当作一次性进程运行

4、2015年 CNCF

CNCF 于 2015 年定义的 Cloud Native

image-20230922072945278

上面的定义简而言之,就是把云原生定位为:容器化封装+自动化编排管理+面向微服务。这主要因为 CNCF 基金会在当时的核心拳头软件就是 K8S,因此在概念 定义上主要是围绕着容器编排建立起来的生态。其实这也是为什么我们可以看到 CNCF 定义云原生的时候有时感觉就是再说容器生态。


image-20231013231244506

5、2017年 Pivotal 官网定义的 Cloud Native

Pivotal 官网定义的 Cloud Native (2017年)

image-20230922072952837

到了 2017 年, 云原生应用的提出者之一的 Pivotal 在其官网上将云原生的定义概况为DevOps、持续交付、微服务、容器这四大特征,这也成了很多人对 Cloud Native 的基础印象。也有人在此基础上简化为**云原生三架马车:微服务、容器、DevOps。**至此,云原生的概念具体落实到微服务、容器、DevOps 这类具体的技 术上面了,而不是停留在概念上。

到了2018年,随着 Service Mesh 的加入,CNCF 对云原生的定义发生了改变,而这也逐渐作为被大家认可的官方定义。

6、2018年 CNCF 重新定义的 Cloud Native

image-20230922073001360

image-20230922073008479

可以看出这一阶段 CNCF 对云原生的定义加上服务网格和声明式 API,同时为这一概念阐述更深一层的意义,也就是建立一个统一中立的开源云生态(至于是否中 立嘛这里就不谈了)。这对云原生的生态定位会是很重要的一点,也算 CNCF 最初成立的宗旨之一吧,打破云巨头的垄断。

云原生极速发展到今天,已经涌现了批量的新型技术和开源项目,一些传统的开源项目也在向云原生转型,以支持云原生生态为荣并且作为口号大肆宣传。上图云 原生生态图景中展现出来的开源项目和技术密密麻麻,数不胜数,而且几乎每月都会有新的项目加入,每年也都有新的项目加入 CNCF 基金会进行孵化,同时也有 已经加入的项目成功毕业。


2大架构特征:不可变基础设施,声明式API

image-20231013231335166

7、什么是云原生?(==eBay 孟凡杰大佬==说)

image-20210805215820289

什么是云原生
• 在包括公有云、私有云、混合云等动态环境中构建和运行规模化应用的能力
• 云原生是一种思想,是技术、企业管理方法的集合
• 技术层面
• 应用程序从设计之初就为在云上运行而做好准备
• 云平台基于自动化体系
• 流程层面
• 基于 DevOps, CI/CD

#备注
什么叫敏捷开发
openstack云:创建虚机就是一条命令的事儿,但是其对虚机后续的生命周期不能进行自动化管控;
如何构建应用高可用:pass团队负责构建高可用;
容器技术的封装能力和分发能力;

image-20210805215955225

什么是云原生
• 基于多种手段
• 应用容器化封装
• 服务网格
• 不可变基础架构
• 声明式 API
• 云原生的意义
• 提升系统的适应性、可管理性、可观察性
• 使工程师能以最小成本进行频繁和可预测的系统变更
• 提升速度和效率,助力业务成长,缩短 I2M(Idea to Market)
  • 什么是云原生?

    孟凡杰大佬:就是云原生上下通吃 往下到基础架构 网上到应用 它把边界打破了。

    image-20230922073116284

    image-20230922073249478

    image-20230922073334745

🍀 Q:孟凡杰对云原生的理解-2021.08.17

我是这么看的 云原生的世界里 没有纯后台开发,只管业务逻辑的世界越来越小, 比如你做java开发, 微服务架构下的spring cloud你至少要懂 。spring cloud现在也支持kubernetes native 的服务发现, 也在被istio取代 所以未来应该是相通的 ,除非把自己局限在代码逻辑的部分 ,否则学习云原生技术栈是有用的。

image-20230922073356831

8、什么是云原生?(字节跳动-资深架构师 罗广明)

image-20230922073417432

  • 云原生(Cloud Native)是一种构建和运行应用程序的方法,是一套技术体系和方法论。

  • 云原生从字面意思上来看可以分为云和原生两个部分:

    • 云是和本地相对的,传统的应用必须跑在本地服务器上,现在流行的应用都跑在云端,云包含了IaaS、PaaS和SaaS等。
    • 原生就是土生土长的意思,我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的,要充分利用云资源的优点,比如 云服务的弹性和分布式优势。

image-20230922073424828

image-20230922073431377

总结

讲到这里,相信的大家对于云原生也有了自己的体会和认知。总而言之,个人的定义难免偏颇或者有缺失,组织的定义也同样如此,都是在构建一个自己的理想生 态。但是了解云原生的概念起源和发展,有助于我们理解云原生的含义以及其未来发展的趋势,这一点至关重要。

总结来说,云原生是一套适用于云计算时代的IT架构与方法论,而这一套方法论需要从架构、研发流程、文化三个角度去实现,相互配合,缺一不可。

image-20210907211335092

如果硬是要给云原生的做一个总结,我们可以参考如下观点:

云原生的组成

  • 架构:以云和微服务架构为基础构建系统

  • 云包含了敏捷基础设施及公共基础服务

  • 考量架构的质量:一致性、性能、可扩展性、可用性等

  • 研发流程:自动化的研发环境是 Cloud Native 的基础

  • 独自、快速完成交付,研发效率极大提升

  • 组织文化:以人为主、自由开放、自我驱动、高度信任

  • 充分发挥个人力量,避免大事小事会议讨论,造成决策瓶颈

9、什么是云原生(唐继元)-2022.4.24

image-20220424220122266

image-20220424230439558

image-20220424230619624

10、什么是云原生

2、云原生核心项目概览

  • CNCF 云原生整体视图

image-20231013231441525

image-20231013231503688

provisioning 供应

compliance 合规

orchestration 编排

coordination 协调

  • 云原生核心项目概览

image-20220423230816205

TEKTON:CD工具(声明式api) api网关:api-server

🍀 landscape

image-20230922073443177

🍀 云原生参考架构

image-20220424234111708

3、云原生技术演进路线

Pets vs Cattle

image-20220424220818695

scale out 水平扩展,向外扩展 scale up 向上扩展

云计算发展历史

image-20220424221621208

业界认为HEROKU是pass的鼻祖,包括后面要讲的应用开发的12因素也是HEROKU提出来的,包括我们现在pass的一些理念或者实践,都是HEROKU提出来的。
2011也是比较关键/重要的一年;
FaaS ;

LXC里面的技术也是谷歌做了大量的贡献;

🍀 CNCF未来发展规划: http://copu.softic.com.cn/priyanka.html

image-20220424222019954

孟凡杰大佬说(应用架构演进/Kubernetes架构演进/服务网格化)

image-20210805220548758

云原生技术演进路线
• 应用架构演进
• 单体应用到分层架构到 `SOA` 到微服务
• kubernetes 架构演进
• API 定义标准化
• 基于扩展API形成的系统生态
• 实现标准化
• 接口和实现分离:CRI、CNI、CSI

image-20210805220655519

云原生技术演进路线
• 服务网格化
• 基于 Sidecar,提升数据面的可管理性
• 协议升级
• API 级别的认证鉴权
• 提升可观察性

字节跳动-资深架构师 罗广明说

image-20230922073537119

1.容器

image-20230922073543785

image-20230922073551247

2.kubernetes

image-20230922073558417

image-20210907193342511

image-20230922073605911

image-20230922073613012

image-20230922073621833

3.Service Mesh

微服务

image-20210907195646143

image-20230922073631001

image-20230922073637884

image-20230922073645317

image-20230922073654642

image-20230922073701865

image-20230922073707225

image-20230922073711871

image-20230922073718112

image-20230922073726578

image-20230922073732922

image-20230922073739215

image-20230922073744690

4.持续交付

image-20230922073751896

image-20230922073759287

云原生技术(唐继元

(字节跳动研发总监,pass团队负责人)-2022.4.24

image-20220424232200735

Service Mesh:
springcloud微服务框架: sdk(日志,监控,负载均衡)
但,会存在一个问题,在升级的时候,例如说我的sdk升级了,那么应用要升级,还要去重新编译,甚至可能我还要去改代码。

🍀 https://12factor.net/

image-20220424233649781

image-20220424232432633

image-20220424232640134

🍀 云原生对Paas非常重要

image-20220424230832935

4、云原生的发展趋势

image-20220424220705691

1.孟凡杰大佬说

image-20210805220754223

image-20210805220837922

image-20210805221030155

云原生的发展趋势
• 应用规模化
• 从概念验证阶段到大规模生产应用
• 计算边缘化
• 以数据中心为主的云计算到面向边缘节点的边缘计算
• 部署多样化
• 私有云和公有云融合的多云和混合云
• 应用复杂化
• 简单的无状态应用到复杂的有状态应用管理
• 传统微服务框架到服务网格
• 长生命周期的服务到短生命周期的无服务
• 以此带来的运维职责不断下移
• 不断的局部技术革新
• 基于 XDP 和 eBPF 的网络加速和应用隔离
• 基于 WebAssembly 实现的个性化 proxy plugin
• 不断增强的安全保证手段
• Kata、gVisor
• 基于零信任架构的细粒度安全保证手段

2.云原生在中国的发展趋势(字节跳动-资深架构师 罗广明)

image-20230922073817406

image-20230922073823872

image-20230922073830189

image-20230922073837255

image-20230922073844287

image-20230922073851411

image-20230922073858750

image-20230922073904924

image-20230922073909399

3.云原生当前发展趋势唐继元(字节跳动研发总监,pass团队负责人)-2022.4.24

🍀 云原生当前发展趋势-Serverless

image-20220424234909089

image-20220425180714550

Serverles可以概括为FaaS+LaaS。
FaaS:是一个函数计算平台。(业务只需要开发业务逻辑函数即可,同时业务人员还要配置好我的事件触发。)
BaaS:更多的是公有云/私有云上提供的一个中间件服务,存储服务;
只有FaaS可能还不够,业务人员可能需要一些微服务来辅助;
终端用户:这边是给一个事件触发;

🍀 云原生当前发展趋势-WebAssembly/WASM

image-20220425183806760

可以毫不客气地说,它有点类似于一把瑞士军刀。

我们知道,原来的浏览器都是一段js的代码,js会调用一些css,html做一些展示。但是传统的js,它做不了一些复杂的功能。
所以,后来就引入了WASM,WASM能在js之外做一些比较强大的计算能力。然后有了WASM之后,这个计算能力的代码也可能是c++/c/rust的。在浏览器中,通过WASM的形式它会把我们的那些语言翻译成字节码,然后再在浏览器里去运行。

这个就有点类似于我们的jvm。我们知道JVM在编译java的时候生成的是一个字节码,但是jvm可以将字节码翻译成一些可执行程序,具有很好的可移植性。

WASM最大的好处:接近原生性能运行,为它会把字节码翻译成一些机器语言,类似就是汇编。

我们知道Envoy是服务网格数据面常用的组件(sidercar envoy)。envoy的功能非常强大,但是它里面的filter也是有限的,有些场景,envoy是不能做处理的,如说我们的rpc框架,有些rpc框架它是不能在envoy里面做过滤的。

那么引入了wasm之后,我就可以通过WASM的形式往envoy里面添加我的过滤器,而且,我们这知道envoy是c++编写的,c++算是面向对象里比较复杂的一门语言了,所以很多人可能不太会写c++语言,那么有了wasm以后,我们可以以其他的形式去写这个filter,并且wasm可以接近原生的性能去运行。

istio的产品化,envoy调优!

🍀 云原生当前发展趋势-eBPF

image-20220425193428906

eBPF利用了内核里面的一些钩子,比如说Socket Filter,XDP,Traffic Control,Secomp,Trace Event。
基本可以这样说,内核里面有钩子的地方,基本有eBPF生存的地方。

另外一个好处:eBPF它的程序是在用户态去写的,我们知道,原来要在内核里面写一个钩子的话,基本上是以内核的方式去开发,开发了之后,我还要去重新编译内核,我还要去替换我原有操作系统里面的内核。但eBPF就非常棒,它可以在用户态去编写,编写完了之后,然后再编译成Bytecode。然后Bytecode通过eBPF Verifier去检验,这个在内核里面会不会使内核崩溃,它是不是合法的等。然后再通eBPF这个vm(它也是一个沙箱),它是在内核里面的一个沙箱,通过即时编译转化成汇编,然后再在内核里面去执行。

所以说,eBPF它也是非常的强大,可以认为是另一把瑞士军刀。

那么eBPF目前用在什么地方呢?
1.网络层面:能够实现一个新的网路。甚至,eBPF能够构建新的内核协议栈,网络协议栈就不用linux传统的那个协议栈了。
2.安全层面:eBPF在一些钩子函数上,能更多地去检查到来的一些请求,一些流量,能够提前做一些安全性的检查。
3.可观察性和事件跟踪:因为我的钩子已经非常丰富了,所以我可以做一些很多很多的跟踪。

cilium是新的网络cni插件;

eBPF也有它的一个局限性,它要求的内核版本要非常高。(因此可能商业化的话环境用eBPF用的比较少,但公司自用的话,可能会用的比较多!)

🍀 云原生当前发展趋势-GitOps

image-20220425213428651

🍀 云原生当前发展趋势-其他

image-20220425213512465

5、如何学习云原生技术

image-20210805221220904

如何学习云原生技术
• 代码驱动
• 掌握 Go 语言编程能力
• 从点到面
• 学习容器技术
• cgroup、namespace
• 网络协议栈
• 文件系统

image-20210805221259324

如何学习云原生技术
• 抓住核心掌控全局
• 深入理解 kubernetes
• API 定义
• 控制器模式
• 核心组件
• 大规模生产化
• 多集群
• 服务网格和多网格

6、云原生训练营设计思路

image-20220423234831368

• 多重视角
• 管理员角度:
• 如何构建和运维支持生产化作业的多租户集群。
• 如何应对规模化所带来的挑战。
• 研发人员角度:
• 如何将不同类型应用的接入到容器化平台。
• 理解如何保证应用的服务可用性。
• 不同角色如何做好协同,避免出现生产故障。

image-20220423234949901

• 循序渐进的内容深度
• Go 语言基础。
• 从容器技术展开,到 Kubernetes 平台以及衍生项目 Istio 等。
• 理解 Kubernetes 作为开放式平台,如何与企业服务进行整合。
• 如何进行多集群管理,构建两地三中心的部署模式。

image-20220423235035237

• 理论与实践结合
• 编写应用;
• 容器化;
• 部署至 Kubernetes 集群;
• 生产化运维和服务管控。

7、CNCF 2020 年度报告

image-20210805221456682

CNCF 2020 年度报告
• kubernetes 在生产中的使用率从 78% 增加到 83%
• 容器在生产中的使用率从 84% 增加到 92%,超过 5000 个容器的用户在 2020 年达到 23
69% 的招聘经理在寻找云和容器专家

数据来源:https://www.cncf.io/wp-content/uploads/2020/11/CNCF_Survey_Report_2020.pdf

8、云原生在企业中的实际应用及对人选的要求

image-20220425213729915

1.云原生在企业的应用特点

image-20220425213804349

2.云原生在企业的应用-应用多云

image-20220425214403107

3.云原生在企业的应用-DevOps

image-20220425214901596

Junit 做一些测试;

4.云原生在企业的应用-微服务

image-20220425215232978

我们知道java应用非常广,企业大部分(60%-70%)微服务框架都是使用SpringCloud,而且它已经有SpringCloud的应用了。

经过和大部分客户沟通,客户希望我原有生产上SpringCloud应用的代码是不改变的。

所以,第一个遇到的问题就是:基于k8s搭建的这种服务网格如何和SpringCloud去兼容呢?是不是说我们用共同一个注册中心,或者我们注册中心之间同步能实现呢?

第二个问题:
比如说我有一些springcloud的业务希望能迁移到云原生平台上来,那么我们知道,在云原生平台,我们的mesh是有一个sidercar的,同时呢 我们的sprincloud app里面是有sdk,但sdk它会去做服务注册,服务发现,负载均衡。但我们知道sider也是做服务发现和负载均衡的,这里就会有冲突。而我们的企业又不希望去改变我们的springcloud app,甚至你想让他去掉sdk,他们业务认为代价会非常大,他们也不愿意去掉。像这种情况,我们如何去兼容我们的sidercar呢?如何去兼容我们的服务网格呢?这也是我们需要去思考和解决的!

这些解决方案在网上都可以找到的,因为目前istio已经是很成熟的了。

5.云原生在企业的应用-其他

image-20220425220737662

6.云原生工程师必备的知识点

image-20220425221035311

https://www.zhihu.com/question/64903911

image-20220425221450869

9、解析云原生工程师的核心能力及工作要点

image-20220425221515512

1.云原生工程师核心能力

image-20220425221558865

2.云原生工程师工作要点

image-20220425221753336

10、大厂面试官关注的3个云原生技术要点

image-20220425221854669

🍀 面试官关心的云原生面试技术3要点

image-20220425221927160

🍀 软技能

软件能:领导力,沟通力,表达力

🍀 面试问题1

🍀 面试题2

🍀 面试题3

🍀 面试问题4

🍀 面试官看重的经验与能力

🍀 面试问题5

🍀 面试问题6

11、学习云原生我能获得什么

FAQ

公开课:云原生的未来(漂亮外国小姐姐)

  • 视频位置

链接:https://pan.baidu.com/s/1d3pOIS5Z4KtrtwZCM2Tx3Q?pwd=30vq 提取码:30vq

image-20220602164149165

  • 演讲内容

image-20220602160105837image-20220602160143782

image-20220602160249898

image-20220602160315172

image-20220602160405389

image-20220602160537063

image-20220602160633650

image-20220602160710415

image-20220602160826893

image-20220602160943591

image-20220602161020062

image-20220602161048727

image-20220602161637496

image-20220602161655831

image-20220602161727005

image-20220602161834250

image-20220602161909502

image-20220602162002631

image-20220602162025441

image-20220602162040634

image-20220602162221578

image-20220602162247599

image-20220602162351122

image-20220602162406620

image-20220602162510770

image-20220602162543564

image-20220602162639850

image-20220602162709890

image-20220602162735799

image-20220602162804274

image-20220602162850531

image-20220602162909305

image-20220602162941875

image-20220602163020147

image-20220602163140083

image-20220602163238504

image-20220602163244591

image-20220602163333178

Q:Java会在云原生后没落吗?

孟凡杰say:

我认为,Java在云原生还是会有很长的寿命的。因为java现在web应用基本上被java统一了嘛;那你一个技术栈转到另一个技术栈是很难很难的,因为涉及到业务迁移的事儿都会比较难;

但在云原生时代,java生态里面慢慢会有些东西交到云原生里面,比如Service mesh在大方向上会替代Spring Cloud,会替代和Java绑定框架。但是要用多少年来替代它,我是没办法去预测的;我是极度看好Service mesh的。大家如果知道在互联网公司,做业务的迁移有多难,就知道我在说什么了。

关于我

我的博客主旨:

  • 排版美观,语言精炼;
  • 文档即手册,步骤明细,拒绝埋坑,提供源码;
  • 本人实战文档都是亲测成功的,各位小伙伴在实际操作过程中如有什么疑问,可随时联系本人帮您解决问题,让我们一起进步!

🍀 微信二维码

x2675263825 (舍得), qq:2675263825。

image-20230107215114763

🍀 微信公众号

《云原生架构师实战》

image-20230107215126971

🍀 个人博客站点

https://onedayxyy.cn/

🍀 语雀

https://www.yuque.com/xyy-onlyone

🍀 csdn

https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

image-20230107215149885

🍀 知乎

https://www.zhihu.com/people/foryouone

image-20230107215203185

最后

好了,关于本次就到这里了,感谢大家阅读,最后祝大家生活快乐,每天都过的有意义哦,我们下期见!


0%