1.简介

云原生：是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud + Native：

  • Cloud 表示应用程序位于云中，而不是传统的服务器中；
  • Native 表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳的姿势运行，充分利用和发挥云平台的弹性+分布式优势。

云原生一直在发展变化中，没有确切的定义，我们通常将云原生定义为四要素：微服务 + DevOps + 持续交付 + 容器。

总而言之，符合云原生架构的应用程序应该是：

  • 基于微服务架构提高灵活性和可维护性，
  • 借助敏捷方法、DevOps支持持续迭代和运维自动化，
  • 采用开源堆栈（K8s + Docker）进行容器化，
  • 利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

什么是云原生？_API


微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用。微服务的理论基础是康威定律，指导服务怎么切分，大概意思是组织架构决定产品形态。


微服务架构的好处就是按功能切分之后，服务解耦，内聚更强，变更更易；另一方面也可以根据DDD来划分服务。

云原生技术的了解

什么是云原生

  • 云原生应用架构的几个主要特征：
  • 符合12因素应用
  • 面向微服务架构
  • 自服务敏捷架构
  • 基于API的协作
  • 抗脆弱性


  • 云原生系统的设计理念如下:
  • 面向分布式设计（Distribution）：容器、微服务、API 驱动的开发；
  • 面向配置设计（Configuration）：一个镜像，多个环境配置；
  • 面向韧性设计（Resistancy）：故障容忍和自愈；
  • 面向弹性设计（Elasticity）：弹性扩展和对环境变化（负载）做出响应；
  • 面向交付设计（Delivery）：自动拉起，缩短交付时间;
  • 面向性能设计（Performance）：响应式，并发和资源高效利用；
  • 面向自动化设计（Automation）：自动化的 DevOps；
  • 面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪；
  • 面向安全性设计（Security）：安全端点、API Gateway、端到端加密；
  • 云原生应用程序被设计为在平台上运行，并设计用于弹性，敏捷性，可操作性和可观察性。
  • 弹性包含失败而不是试图阻止它们；它利用了在平台上运行的动态特性。
  • 敏捷性允许快速部署和快速迭代。
  • 可操作性从应用程序内部控制应用程序生命周期，而不是依赖外部进程和监视器。
  • 可观察性提供信息来回答有关应用程序状态的问题。
  • 微服务、健康报告、遥测数据、弹性、声明式的，而不是命令式的
  • Serverless: 无服务器平台是云原生化的，并通过设计对事件做出响应。他们在云中工作得很好的原因是他们通过HTTP API进行通信，是单用途功能，并且在他们所称的功能中声明。该平台还可以通过在云中进行扩展和访问来提供帮助。
  • 云原生应用程序不能直接在PaaS上运行或与服务器的操作系统紧密耦合。它们期望在一个拥有大多数自治系统的动态环境中运行。
  • 云原生基础设施在提供自主应用管理的IaaS之上创建了一个平台。该平台建立在动态创建的基础设施之上，以抽象出单个服务器并促进动态资源分配调度。
  • 云原生是关于不需要人类做出决定的自治系统。它仍然使用自动化，但只有在决定了所需的操作之后。只有在系统不能自动确定正确的事情时才应该通知人。
  • 云原生应用程序不依赖于人员设置ping检查或创建Syslog规则。他们需要从选择基本操作系统或软件包管理器的过程中提取自助服务资源，并依靠服务发现和强大的网络通信来提供丰富的功能体验。
  • 云原生准确来说是一种文化，更是一种潮流，它是云计算的一个必然导向。它的意义在于让云成为云化战略成功的基石，而不是阻碍，如果业务应用上云之后开发和运维人员比原先还痛苦，成本还高的话，这样的云我们宁愿不上。
  • 云原生也很好地解释了云上运行的应用应该具备什么样的架构特性——敏捷性、可扩展性、故障可恢复性。
  • 敏捷, 可靠, 高弹性, 易扩展, 故障隔离保护, 不中断业务持续更新
  • Kubernetes是Google基于Borg开源的容器编排调度引擎，作为CNCF（Cloud Native Computing Foundation）最重要的组件之一，它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态，Kubernetes可以帮你将系统自动得达到和维持在这个状态。
  • Kubernetes 用户可以通过编写一个yaml或者json格式的配置文件，也可以通过工具/代码生成或直接请求Kubernetes API创建应用，该配置文件中包含了用户想要应用程序保持的状态，不论整个Kubernetes集群中的个别主机发生什么问题，都不会影响应用程序的状态，你还可以通过改变该配置文件或请求Kubernetes API来改变应用程序的状态。
  • Service：直接用Service提供cluster内部的负载均衡，并借助cloud provider提供的LB提供外部访问
  • Ingress：还是用Service提供cluster内部的负载均衡，但是通过自定义LB提供外部访问
  • Service Load Balancer：把load balancer直接跑在容器中，实现Bare Metal的Service Load Balancer
  • Custom Load Balancer：自定义负载均衡，并替代kube-proxy，一般在物理部署Kubernetes时使用，方便接入公司已有的外部服务


  • 技术路线: 容器->Kubernetes->微服务->Cloud Native（云原生）->Service Mesh（服务网格）->使用场景->Open Source（开源）。
  • Kubernetes中的基本资源类型分成了三类：
  • 部署：Deploymnt、ReplicaSet、StatefulSet、DaemonSet、Job、CronJob
  • 服务：Service、Ingress
  • 存储：PV、PVC、ConfigMap、Secret


  • Pod hook（钩子）是由Kubernetes管理的kubelet发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为Pod中的所有容器都配置hook。
  • Hook的类型包括两种：
  • exec：执行一段命令
  • HTTP：发送HTTP请求。







参考资料

https://www.cnblogs.com/longjiang-uestc/p/12443961.html







参考资料：