一、云原生为何如此重要
①、研发管理效率提升
②、硬件成本极大下降
二、部署流程的三大打通
①、打通微服务云原生基础环境：服务治理，服务监控
②、打通云原生CICD流程：统一的AB测试 灰度
③、打通团队敏捷管理的流程：统一的，最终的极速迭代，极速上线
真正的做到敏捷开发，敏捷迭代
三、资源管理有着巨大的问题
①、无论生产环境，还是测试环境，大部分公司的颗粒度都是虚拟机：ECS，以虚
拟机为单位进行资源，分配同样也是以虚拟机为单位进行资源回收。都说资源不
够。这种粗放的管理的方式会造成严重的资源假缺现象。为什么是假缺使用现象：
因为去看他们的cpu，和内存使用率都是非常非常低的
②、所以我们要解决上面的现象必须要做云原生技术的升级：升级到以容器为单位
的精细化的管理模式从而大大提升资源的利用率：降低资源的成本以及维护资源的
成本。
四、高并发，高可用手段
K8S+SpringCloud+QPS高并发自动伸缩，DevopsAB测试流水线，灰度流水线灰
度方案中的ingress边缘灰度方案：具有高并发，高可用，而且代码的入侵性很小
容器与镜像的关系
镜像：镜像是只读文件，提供运行程序完整的软硬件资源。
容器：容器是镜像的实例，由docker负责创建，容器之间彼此隔离。
五、什么是云原生
2018年之前的
①、持续交付，持续集成
持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模
式，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。最佳实践：
CI/CD，gitlab,Jenkins,流水线pipeline,tekton等
②、DevOps
即开发，运维，体化，涉及软件在整个开发生命周期中的持续开发，持续测试，持
续集成，持续部署和持续监控，最佳实践Git,Jenkins,Barnboo.Docker,Kubernetes
③、微服务
几乎每个云原生的定义都包含微服务：dubbo,springcloud
④、容器
2013年，Docker项目正式发布，2014年，K8S项目正式发布Docker是应用最为广
泛的容器引擎，在思科谷歌等公司的基础设施中大量使用K8S是常用容器编排系
统，用于容器管理，容器间的负载均衡。Docker是容器的时期时代。容器也不一
定是Docker，K8S是大型的容器管理中间件平台
2018年之后的：加了服务网格：云原生的核心就是容器和微服务
①、但是非常特别的是：将服务网格单独列出来，而不是将服务网格作为微服务的
一个子项或者实现模式体现了云原生中服务网格这一个新生技术的重要性而不可变
基础设置和声明是API这两个涉及指导理念的加入，则强调了这两个概念对云原生
架构和影响和对未来发展指导作用。
演进的背景是跨语言的。在分布式场景：用golang,python,不仅仅用java
那么这些不同的语言之间：怎么做操作：
②、把业务代码和基础代码进行解耦：服务治理的代码有服务发现，负载均衡，限
流客户端。这些是在每个微服务里面都要加载的核心组件，在微服务里面更是客户
端组件。
如何做跨语言的交流呢？
①、做个解耦：把服务治理的代码下沉，从业务代码里面剥离出来，服务治理的代
码单独部署，单独弄个进程，业务代码弄个进程；对于容器来说，相当于是部署了
两个容器，但是这两个容器之间可以做到通信，只要保证服务治理的代码和业务代
码的保证协议一致性，所以服务治理的代码可以跨语言
②、用什么语言写业务代码都没关系。我们可以不用像java那样重量级的语言来开
发服务治理，比如用轻量级的go语言来开发，所以说性能也能提升。所以出来了边
车模式：在部署的时候是绑定式的部署
服务网格新时期
服务网格和微服务的本质区别：主要在于单体服务进行业务服务和非业务基础服务
进行解耦
①、非业务基础服务：交给基础框架进行管理和控制
②、非业务基础(sidecar)+服务治理中间件组成一个网络结构，被称之为服务网格
每个容器有两个服务：业务的服务+非业务服务
为啥叫做服务网格，主要从架构层面看起来跟网络很像
如果每一个格子都是一个sidecar数据单元，然后sidecar进行彼此通信，所以这些
单元格组成数据面，这些sidecar数据单元（单元格：rpc,负载均衡；心跳),由统一
的控制/配置中间组件(类似nacos注册中心)进行配置和控制，那些控制组件组成了
控制面。宏观上。服务网格=数据面+控制面
