1. 云架构（云原生）

1.1 何为云原生

云原生是一条最佳路径或者最佳实践。更详细的说，云原生为用户指定了一条低心智负担的、敏捷的、能够以可扩展、可复制的方式最大化地利用云的能力、发挥云的价值的最佳路径。

云原生的技术范畴包括了以下几个方面：

• 第一部分是云应用定义与开发流程。这包括应用定义与镜像制作、配置 CI/CD、消息和 Streaming 以及数据库等。
• 第二部分是云应用的编排与管理流程。这也是 Kubernetes 比较关注的一部分，包括了应用编排与调度、服务发现治理、远程调用、API 网关以及 Service Mesh。

• 第三部分是监控与可观测性。这部分所强调的是云上应用如何进行监控、日志收集、Tracing 以及在云上如何实现破坏性测试，也就是混沌工程的概念。
• 第四部分就是云原生的底层技术，比如容器运行时、云原生存储技术、云原生网络技术等。
• 第五部分是云原生工具集，在前面的这些核心技术点之上，还有很多配套的生态或者周边的工具需要使用，比如流程自动化与配置管理、容器镜像仓库、云原生安全技术以及云端密码管理等。
• 最后则是 Serverless。Serverless 是一种 PaaS 的特殊形态，它定义了一种更为“极端抽象”的应用编写方式，包含了 FaaS 和 BaaS 这样的概念。而无论是 FaaS 还是 BaaS，其最为典型的特点就是按实际使用计费（Pay as you go），因此 Serverless 计费也是重要的知识和概念。

即云原生，是一种架构、软件开发思想，就是为了让应用程序（项目，MySQL、elasticsearch……）运行在云上的解决方案，叫做云原生（云架构）

云原生特点：

• 容器化 ： 应用程序运行在容器中
  容器部署项目，起到了隔离的作用 （k8s编排容器）
• 微服务 ： 实现云原生最好采用微服务架构
  微服务按照function拆分后，可以做到高内聚，低耦合。实现CI/CD（可持续交付、可持续迭代）
• DevOps
  开发+运维 – 开发和运维的结合体。DevOps是一种敏捷思维，开发一种组织形式，可以实现项目可持续交付，部署。
• CI/CD
  持续交付：不停机更新

1.2 如何云原生

云原生与本地部署的区别（好处）：

• 1、本地部署应用可能需要停机更新，而云原生就不需要，始终是最新的状态，支持频繁的变更。
• 2、本地部署应用无法进行动态扩展（动态伸缩容），云原生可以利用云资源的弹性进行自动伸缩容，从而为企业降本增效。
• 3、本地部署应用对物理硬件IP,网络端口有强依赖，云原生就不需要了
• 4、本地部署应用需要人肉运维方式，云原生实现自动化运维 （运维： 使用k8s, iaas层是运维）

实现云原生：
采用微服务架构 是 云原生环境的标配，使用云原生模式部署架构项目，项目必须采用微服务架构。微服务架构的项目离开了云原生，部署，运维的效率就大大折扣。

已知的两套微服务架构方案：

• Springcloud Alibaba
  • Nacos
  • Sentinel
  • dubbo
  • …
• Springcoud netflix
  • Eureka
  • Ribbon
  • …

2. 云原生架构理念：

云技术发展：

云原生架构理念：

• iaas 【Infrastructure as a service 基础设施即服务】
  用户：购买服务器，建设机房，DNS,交换机，路由，网络… (硬件环境)
  云计算提供商：提供 网络、存储、dns、服务器…服务，用户只需要租用云主机即可，不需要关系硬件建设。
  网络、存储、dns、服务器，操作系统 这样服务就叫做基础设施即服务。

  思考： 用户购买一台iaas服务？ 就相当于买了一台空的服务器。

• paas【platform as a service 平台级服务】
  在iaas基础上安装一些软件：基础服务软件—MYSQL,RocketMQ,ElasticSearch…作为基础服务

  思考：用户购买这样的服务后，此时用户只需要关系项目业务代码开发，基础软件服务不需要自己安安装。

• caas【container as a service】
  容器就是一个服务，所有的软件服务都运行在容器中

• saas【software as a service 软件级服务】
  钉钉 （多租户）
  微信企业版 （多租户）
  OA（多租户）
  财务（多租户）

• faas【function as a service】，baas 【backend as a service】
  函数即是一个服务—微服务架构（按照function拆分）
  视频服务提供商（直播）---- 函数收费 （函数运行，收费）
  CDN服务商 （视频缓存服务）---- 函数收费
  短信服务 — 发一条短信
  支付服务 — 函数收费

• service mesh
  服务网格架构：服务治理—服务限流、服务降级、服务监控…… istio
  客户端 --> proxy代理服务–> 服务（集群）
  客户端 + proxy（集成在一起：服务治理–降级，限流、监控…）–> 服务 + proxy（集成在一起：服务治理–降级，限流、监控…）（集群）

  注意：
  一般企业直接使用 proxy代理模式就ok，至于服务治理用 springcloud
  service mesh 不建议使用，落地非常困难，技术能力要求很高

• serverless
  server 服务器，less 无 —> 无服务器，无服务架构
  未来开发境界：程序员只需要关心代码业务开发即可，服务器环境不需要关心，所有的服务都上云。

  未来：
  公有云： 阿里云，腾讯云、网易云，百度云，滴滴云…
  私有云： k8s 自己公司构建自己的私有云 ------ 很多公司在使用私有云

3. 构建云计算平台虚拟技术的选择

要根据云计算类型：私有云、公有云、混合云，来选择适合的虚拟技术

Docker，进程级别隔离，适合：

• 1、服务应用开发，测试，部署 — docker容器技术解决服务从开发，测试，部署 实现 可持续部署，可持续交付 （DevOps）
• 2、应用开发模式是纯粹应用开发模式，可以使用容器技术

虚拟化KVM，物理硬件隔离，隔离的更彻底，适合：

• 1、构建安全级别更高的私有云环境，必须使用kvm虚拟化技术
• 2、公有云 虚拟机技术 ---- （内部paas ，saas 服务可以容器化部署）
• 3、混合云 虚拟机技术

公司中：只是用于业开发，实现可持续服务交付，部署 ------- 不需要使用虚拟化技术，直接使用容器化方式，对项目进行测试，部署即可。

即基础设施(iaas)、基础软件级(paas)服务用虚拟技术、软件服务(saas)用容器技术

思考问题：

问题1：物理硬件进行虚拟化处理，使用了很多虚拟机？ 庞大的虚拟化集群网络如何管理？？

解决方案：Openstack

问题2：docker部署服务（微服务架构：按照function拆分，服务非常之多………）,docker容器越来越多………,同时面临很严重的问题，管理庞大容器资源非常困难。

解决方案：k8s对容器进行编排管理

4. 应用架构部署模式变迁

物理机模式： 服务部署在物理机
虚拟机模式： 为了充分利用物理机的计算资源，使用虚拟机方式部署服务
云原生模式： 应用部署在容器中

思考：微服务架构，服务拆分成千上万个服务，就需要非常多的容器来进行部署，那么这些容器怎么管理？
怎么横向扩容？
服务宕机了，怎么恢复，你是如何知道的？
版本更新，上线，更新容器后，线上业务如何不受影响？
监控容器？
调度问题？
安全问题？
window系统：海量的文件，如何管理？？资源管理器（管理文件：调度）

虚拟化： openstack
容器化： Kubernetes

5. 容器编排技术

解决问题：

• 怎么横向扩容
• 服务宕机了，怎么恢复，你是如何知道的？
• 版本更新，上线，更新容器后，线上业务如何不受影响？
• 如何监控容器
• 如何调度新创建的容器
• 数据安全问题
• …

以上问题，容器编排技术来说，一个指令，一个按钮就可以搞定一切。

5.1 docker-compose

Docker-compose组件可以批量的创建容器，管理容器，粗颗粒度。

非常轻量级容器编排技术，可以通过yaml文件方式，对容器进行批量管理，不能实现复杂容器编排

5.2 rancher

可视化的容器管理工具，v2版本提供对k8s兼容。中小型使用，性能非常差，不能实现复杂的容器编排。

5.3 Swarm

Swarm容器编排工具是docker公司自己的开发，但是docker公司都不使用，docker公司使用的kubernetes (k8s),阿里云切换为k8s

目前三大主流的容器平台Swarm, Mesos和Kubernetes具有不同的容器调度系统 ；

Swarm的特点是直接调度Docker容器，并且提供和标准Docker API一致的API。

每台服务器上都装有Docker并且开启了基于HTTP的DockerAPI。这个集群中有一个SwarmManager的管理者，用来管理集群中的容器资源。管理者的管理对象不是服务器层面而是集群层面的，也就是说通过Manager，我们只能笼统地向集群发出指令而不能具体到某台具体的服务器上要干什么（这也是Swarm的根本所在）。至于具体的管理实现方式，Manager向外暴露了一个HTTP接口，外部用户通过这个HTTP接口来实现对集群的管理。

5.4 Mesos

Mesos针对不同的运行框架采用相对独立的调度系统，其框架提供了Docker容器的原生支持。 Mesos并不负责调度而是负责委派授权，毕竟很多框架都已经实现了复杂的调度。

Mesos是Apache企业的开源项目，是一个资源管理，用来进行容器的管理。

5.5 borg

google研发一套容器编排技术，这套技术没有对外公开，强大，稳定。

5.6 Kubernetes

google研发一套容器编排技术，使用go开发。性能非常强大、稳定、通过指令、yaml编程方式管理容器，非常灵活。

Kubernetes则采用了Pod和Label这样的概念把容器组合成一个个的互相存在依赖关系的逻辑单元。相关容器被组合成Pod后被共同部署和调度，形成服务（Service）。这个是Kubernetes和Swarm，Mesos的主要区别。

Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器，那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。

Kubernetes基本结构：

• 1、master节点： 负责调度，存储集群状态（服务注册发现），提供统一API入口…,一个master对应一群node节点
• 2、node节点：node节点存储pod(pod内部封装容器的)，一个node节点理论上可以存储无数个pod,但是node节点存储pod的数量受限于硬件资源的限制，同时受限于pod内部服务运行所占用的资源

使用Kubernetes可以：

• 自动化容器的部署和复制
• 随时扩展或收缩容器规模
• 将容器组织成组，并且提供容器间的负载均衡
• 很容易地升级应用程序容器的新版本
• 提供容器弹性，如果容器失效就替换它，等等…