ToB企服应用市场:ToB评测及商务社交产业平台

标题: 云原生的概念 [打印本页]

作者: 络腮胡菲菲 时间: 2022-8-31 14:40
标题: 云原生的概念
云原生其实是一种思想

云原生其实是一种思想，并不是一种工具，云原生更多的是一种泛化的东西，是一种思想观念，首先要有意识的去想云原生这种东西，其次，他是一种技术、流程和企业管理方法的集合，所谓的技术，k8s是他的一部分，所谓的企业管理方法，比如说基于DevOps，构建CI/CD的流水线

两个层面去了解云原生

1 应用层面

原来我们作为业务开发只关心业务逻辑开发的场景会越来越弱化，不能再局限于我只写一段业务逻辑，这样会制约我们的视野，所谓的云原生就是，除了要关心我们的业务，还要关心我们的这块业务最终是要上云的，上云和不上云有哪些差异呢？

上云就要有扩展的思考，是不是要在容器里边运行，容器的适配性有没有去做，有没有去考虑
在云上运行，对于云原生来说他通常的存算分离的思想，我们应该将尽可能多的服务变为无状态的应用，无状态的应用就是说不应该保存任何的配置信息，应该数据库分离，应该代码与配置分离，这样的可以不经过版本发布去做一些配置变更，有任何的节点出现故障，可以很暴力的去替换它，这里边就有存算分离，无状态应用的概念
要在云上优雅的运行，就需要有探活的能力，是不是已经服务就绪了，是不是正常的工作，这些健康检查的能力要有，服务运行在云上，肯定要和其他的微服务整合在一起，形成一个生态，日志是不是已经为云适配了，业务指标是不是已经正常的漏出和采集了，是不是和上下游的服务做了分布式的tracing，使得可以根据调用链去做一些数据分析，所以说我们不仅要关心我们的业务逻辑，还要关心在云上如何进行优雅运行的这些特性，这些都是跟应用本身相关的
还有，在运行时态，还有很多其他的事要考虑，怎么保证应用高可用，要不要跨地域部署，要多少副本，每个副本多少个实例，要做弹性么，这些都是应用侧去考虑的一个全局的事情

2 平台层面

平台侧在云原生技术栈有更高的要求，这种更高的要求就是应对了在前一代云平台的那用半自动化平台所演进出来的更进一步的体系，它追求的是一种全自动化的体系，原来各个云平台厂商都在解决业务的部署，版本的发布，灰度控制、故障转移、自动扩缩容，所有的这些问题，其实都是业界面临的共同问题
原来技术不统一，各家都在自己做自己的，现在有了kubernetes，有了云原生这个技术栈，就是世界上这个领域最专精的一批专家，通过开源的方式，把所有这些共同的问题全部在kubernetes以及云原生的技术栈的框架里边统一解决掉了，留给每家企业要做的事情就是落地，落地的话无非就是将kubernetes装到我们的环境里，数据中心或者上到某个云上边，依据公司自身的情况，去做一些配置，去做一些整合，去跟自己的服务做一些整合，或者跟一些云提供商做一些整合，最终的目的是通过这种整合使得我们的云原生平台和我们的周边环境形成一个完备的自动化体系，不用再铺人去开发这一套东西，拿来直接用就可以了
云原生的技术手段

1. 应用的容器化封装

使用轻量级的技术来伪装一个虚拟化操作系统，使得更多的资源来给应用，因为不需要模拟一个操作系统，只是伪装一个操作系统，不需要那么多的计算资源，那么这些资源都可以给到应用，而且是一个轻量级的，性能非常好
基于容器化技术，用了cgroup，那么所有的资源用量，cpu、内存、磁盘、IO，这些信息都可以用cgroup暴露出去，这样，应用的监控就统一了，所以，容器化的意义在于：一个是通过轻量级的技术来封装应用，做了很好的资源隔离和资源管控，还有就是通过统一的技术栈，把资源用量暴露出去，这样的话，就拉通了整个平台的监控，不需要再去构造一套监控系统了
2. 不可变基础架构

使用容器镜像OverlayFS,容器镜像构建出来是什么样的，再建一个新的实例，就跟当时的状态是一样的，这样就满足了我们应用无状态的特性，我们就可以用很少的人去管理成千上万的实例，任意一个实例出现问题，只要去替换就好了，而且底层的os是只读的文件系统，这样保证底层的基础架构师不可变的，不可变的好处是可以随意替换。
这也是之前虚拟化技术的痛点所引发的思考，演变出来的一些需求和能力。以前在虚拟化的世界里，交付的是一个个OS，给出一个ip以及用户名和密码，就可以登录到这个节点，登录到这个节点之后，能干什么云平台这边就不管了，很多人就可以在上边做操作，人为的都是不可靠的，今天做了这个操作，明天做了另一个操作，不说很久，几个月之后谁都不知道这个机器做了什么操作，没有人能说清楚，那么有一个问题，突然这个实例出现了故障，要把它换掉，中间的哪些变更都是不可追溯的，那么替换就几乎是不可能的，如果有了不可变基础架构的话，这些问题就不可能存在了，直接登录到机器上去做变更的这条路已经被堵死了，所以我们就可以做到实例坏了换一个
3. 声明式API

kubernetes的杀手锏，把所有在kubernetes管纳范围的对象，比如说计算节点、作业，负载均衡的配置，DNS的配置，接入的网络，存储卷等所有我们可以用到的都抽象成为一个个声明式API。
我们可以定义很多对象，当然包含很多的组，他归了很多类，比如管理应用的、管理节点的，这些对象就可以定义。比如说这个是一个节点，这个是一个Pod，这个节点是用来声明算力的，比如说需要跑什么样的业务，需要多少资源，它定义了很多很多的一些api，把它所管纳的对象全都定义为了api，它从诞生开始，就把自己定义为下一代云原生的标准，它声明了这些api以后呢，google它并没有闭门造车，它去找了AWS，找了红帽，找了微软，找了中国的腾讯华为阿里等各个大的云提供商，这些api是不是认可，如果你认可的话我们一起共建，所以它相当于订立了一个标准，以一个中立的方式订立了一个标准，有了这个标准，在去找各个大厂背书，每家都背书了，相当于每家都变相的支持kubernetes，那么kubernetes的部署率就越来越高了，他就变成了下一代的标准，变成了一个事实的标准，声明式API使得kubernetes的地位越来越不可撼动
4. 服务网格

以前大家做微服务治理都是用springcloud，这种微服务的框架，它提供了一些能力，比如路由管理、限流、熔断，但是springcloud有个问题是绑死了技术栈，只有java可以用，其他语言就没有了，这样就没有一套微服务框架去用了，那怎么办，能不能把流量的治理，熔断限流这些基础能力，偏平台的能力从业务代码中抽离出来，而不以sdk的方式跟应用紧耦合，而是通过类似sidecar模式，在我们的应用旁边再跑一个进程，这个进程里边去实现一些负载均衡、熔断限流的能力，所有的流量都经过我的sidecar，这样这个sidecar就可以做很多事情，协议升级，统一监控，熔断限流，负载均衡，安全保证这些事情都可以去做。
容器技术使我们的应用统一了，服务网格使我们的网络流量也统一了。
云原生的意义

提升系统的适应性、可管理性和可观察性
使工程师能以最小的成本进行频繁和可预测的系统变更
提升速度和效率，助力业务成长，缩短I2M（Idea to Market）

可观察性是非常重要的一环，需要要知道业务跑成什么样子了，基于容器技术和服务网格我们的监测是统一的。
容器的这种便捷性和资源封装的能力，使我们cicd的pipline的构建成本很低，docker的口号 build once run anywhere，一次构建，处处运行，那么这样就天然适配cicd，cicd通了后devops整个流程就通了，这样工程师做频繁变更的可能性就提升了，风险就小了。
基于极客时间孟凡杰老师的年中复盘整理

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)