【架构设计】现代软件交付中的灵活性与可靠性———云原生与不可变基础设施（微服务/容器化/持续交付，计算/存储/网络）

【架构设计】现代软件交付中的灵活性与可靠性———云原生与不可变基础设施（微服务/容器化/持续交付，计算/存储/网络）

1、云原生与基础设施的关系

定义：

• 云原生：云原生是一种设计和运行应用程序的方法，充分利用云计算的灵活性和可扩展性。它通常涉及**微服务架构、容器化、持续交付（CI/CD）**和动态编排等概念。
• 基础设施：基础设施指的是支持云原生应用程序运行的物理或虚拟资源，包括服务器、存储、网络设备、操作系统等。

云原生依赖于基础设施

• 资源需求： 云原生应用程序需要底层基础设施来提供计算、存储和网络资源，以支持其运行的需求。
• 容器化支持： 云原生应用通常使用容器化技术（如Docker），依赖基础设施来提供容器运行时环境。
• 自动化管理： 基础设施需要支持自动化和动态配置，以满足云原生应用的弹性需求。工具如Kubernetes帮助管理和调度容器化应用。

基础设施影响云原生

• 基础设施即代码：许多云原生实践采用“基础设施即代码”的理念，通过代码管理和配置基础设施，确保其灵活性和可重复性。
• 弹性和可扩展性：基础设施必须支持云原生应用的弹性设计，允许应用根据负载自动扩展或缩减。
• 网络架构：云原生对基础设施的网络配置提出了要求，要求具备高效的服务发现、负载均衡和安全策略，以确保微服务之间的通信顺畅。

共同演进

• 合作发展：随着技术的发展，云原生和基础设施的理念和工具不断演进，相互影响。例如，基础设施的虚拟化技术（如虚拟机和容器）推动了云原生应用的广泛采用。
• 生态系统的整合：现代云原生平台通常集成了多个基础设施组件，通过微服务和API实现相互连接，使软件开发和运维更为高效。

现代形态

• 基础设施即服务，或者IaaS ，是一种云计算服务模型，它提供物理 或虚拟 的计算、存储和网络资源，使用按需按量的计费模式。 云提供商拥有和管理软件和硬件设施，可供消费者在公共、私有或混合云部署和使用。
• 云原生基础设施是指在云计算环境下构建和运行应用程序所需的基础设施。它包括计算、存储、网络等资源，以及容器、编排、自动化等工具，旨在支持应用程序的快速部署、扩展和管理。云原生基础设施通常具有弹性、可伸缩、可靠性高等特点，能够更好地适应动态变化的业务需求。
• 现代的云计算架构
  IaaS（基础设施，虚拟化，计算存储网络）
  PaaS（平台，dns，cnd，容器，数据库）
• 现代云原生基础设施
  1.一切皆为资源：将所有关于应用运维的对象抽象成几类运维资源，并对于不同的运维资源抽象不同的状态机、进行不同的生命周期编排和数据关系查询等
  2.一切皆可编排：可以将所有可执行的代码抽象成不同类型的执行动作，同时将执行动作编排成为流水线
  3.依赖解耦，能力下沉：交付的稳定性是以容器作为不可变基础设施，让应用程序和运行环境解耦。
  4.弹性伸缩，韧性可靠：弹性伸缩可以让系统流量高峰的时候对应用进行扩容，同时当系统流量低峰的时候可以对应用进行缩容，减少资源浪费
  5.观察追踪，自动运维：可观测性由日志、指标和追踪来构建，在云原生中，可观测性十分重要，我们通过可观测性分析在面向终态的执行中出现了什么异常，以便在特殊情况下快速介入。

参考资料：1 云原生基础设施,2 云原生基础设施，1, 2，3

2、云原生的概念（灵活性）

为什么叫云原生

• 云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。
• 云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心； Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

云原生的发展史

• 云原生的发展
  2013年，Pivotal公司的Matt Stine于首次提出云原生（CloudNative）的概念
  2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：微服务、自敏捷架构、基于API协作、扛脆弱性；
  2015年，云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；
  2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；
  2017年，Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。
  2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。

• 云原生基础设施的发展
  2013年：Docker 发布，引领了从虚拟机到容器的转变。
  2014年：Kubernetes 发布，为容器编排设立了标准。
  2015年：CNCF 成立，为云原生技术提供了组织支持。
  2017年：Kubernetes 成为容器编排领域的事实标准，云原生技术迎来了快速发展。
  2018年：Kubernetes从CNCF中毕业，Istio 1.0发布。
  2019年：云原生技术达到顶峰。CNCF 毕业了 8 个项目，增加了173个会员（增长50%）。涌现了大量云原生相关的开源项目，比如阿里的OAM、华为Volcano、微软Dapr。市场上涌现大量云原生公司，云原生市场一片欣欣向荣。

• 总结，符合云原生架构的应用程序应该是：
  1、采用开源堆栈（K8S+Docker）进行容器化，
  2、基于微服务架构提高灵活性和可维护性，
  3、借助敏捷方法、DevOps支持持续迭代和运维自动化，
  4、利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

软件设计的目标

• 软件设计有两个关键目标：高内聚、低耦合。
  围绕这2个核心目标，又提出了单一职责、开闭原则、里氏替换、依赖导致、接口隔离、最少知识等设计原则。
  软件工程师一直都在为这两个目标而努力奋斗，以求把软件编写得更加清晰、更加健壮、更加易于扩展和维护。

• 纵观近二十年的科技互联网发展历程，大的趋势是技术下沉。
  特别是近些年，随着云计算的发展和普及，基础设施越来越厚实，业务开发变得越来越容易，也越来越没有技术含量，而之前困扰小团队的性能、负载、安全性、扩展性问题都不复存在，这不禁让互联网行业的大叔们噤若寒蝉，仿佛分分钟就要被卷入历史洪流而万劫不复。

• 如果说PC时代的基础设施是控件库，互联网时代的基础实施是云，那AI时代基础设施是什么。

参考资料： 111-云原生, 2-k8s 教程, 3-容器技术, 4 pod和容器, 5 pod和容器, 6 pod和容器, 7 云原生发展史, 8 云原生的定义

3、云原生 = 微服务+容器化+持续交付（容器化）

微服务

• 跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分，大概意思是组织架构决定产品形态。
• 微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞。
• 本地部署的传统应用有些是单体(巨石)应用，或者强依赖，而基于微服务架构的云原生应用，纵向划分服务，模块化更合理。

容器化：

• Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于LXC技术实现的，容器化为微服务提供实施保障，起到应用隔离作用。
• K8S是容器编排系统，用于容器管理，容器间的负载均衡，谷歌开源的，Docker和K8S都采用Go编写。

持续交付：

• Dev+Ops，就是开发和运维合体，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。
• 持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。
• 本地部署的传统应用可能需要停机更新，而云原生应用应该始终是最新的，需要支持频繁变更，持续交付，蓝绿部署。
• 本地部署的传统应用通常人肉部署手工运维，而云原生应用这一切都是自动化的。

上云的优势

• 本地部署的传统应用无法动态扩展，往往需要冗余资源以抵抗流量高峰，而云原生应用利用云的弹性自动伸缩，通过共享降本增效。
• 本地部署的传统应用对网络资源，比如ip、端口等有依赖，甚至是硬编码，而云原生应用对网络和存储都没有这种限制。
• 本地部署的传统应用通常依赖系统环境，而云原生应用不会硬连接到任何系统环境，而是依赖抽象的基础架构，从而获得良好移植性。

4、基础设施的概念（可靠性）

可变的服务器部署

• 在可变的服务器部署模式中，通过 Terraform 创建出所需的虚拟机以及其它基础设施资源，然后通过配置管理工具 Ansible 对已经存在的服务器资源进行应用相关的配置和部署。
• 随着业务的需求增加，需要对服务器操作系统进行更新，或对部署的应用进行频繁的升级。这种情况下，可变的服务器部署模式所带来的挑战和风险是我们无法预估的。
• 在真实的用户场景里，运行的应用程序与操作系统、或第三方软件资源存在各种各样复杂的依赖。当给操作系统打补丁，亦或升级应用程序所依赖的软件包时，可能会出现应用程序无法正常启动、DNS 解析异常、网络不可达、性能下降等现象，这些异常可能是无法预测的，甚至是我们无法控制的。
• 即使应用程序更新成功，一旦线上环境产生不可预知的严重 Bug ，需要将应用程序回滚时，由于可变的服务器部署的不确定性，回滚的过程对于运维人员仍然是一项挑战。
• 当线上环境负载过高时，在可变的服务器部署模式下，响应也会显得不够高效。按照上述流程，需要创建新的虚拟机资源，再运行配置管理工具去部署该版本的应用。整个过程比较耗时，也较容易出错。

不可变的服务器部署

• 不可变基础设施指的是一旦部署就无法变更的计算机基础设施 （例如虚拟机、容器、网络设备）。 具体实现方式可以是通过自动化进程覆写所有未经授权的变更，也可以通过某个系统从一开始就不允许变更。 容器是不可变基础设施的一个很好的例子，因为如果想要持久变更容器，只能通过创建新版本的容器或从其镜像重新创建同样的容器。
• 相对于可变的服务器部署模式，不可变的服务器部署模式要求服务器在部署完成之后，后续每次做部署变更时，不再对现存的服务器做任何更新或升级。
• 不可变的服务器部署模式下，我们将会基于基础的虚拟机镜像，创建新的虚拟机，为该虚拟机安装所需软件包，部署应用程序所需要的新的代码和配置。最后将该虚拟机打包成一个新的虚拟机应用镜像。
• 每次部署应用时，基于以上过程创建出来的应用镜像，创建新的服务器，在这个过程中，我们不会去改动当前环境中运行的基础设施资源。
• 同时在整个过程中，出现任何错误，我们将直接退出。待问题解决之后，基于以上过程重新打包镜像。如果一切顺利，待虚拟机启动成功，再将线上环境流量切换到该新虚拟机上，随后销毁掉的虚拟机。这样就完成了一次部署变更。
• 如果线上流量较高，需要横向扩展虚拟机数量时，只需将上述已经打包好的应用镜像部署成新的虚拟机，作为额外资源加入到线上集群即可。整个响应过程十分迅速且可靠。

参考资料：
1-github-基础设施
2-使用 Terraform 通过 Packer 自定义映像创建 Azure 虚拟机规模集
3-Terraform 介绍
4-同github
5-云原生基础设施有哪些
6-不可变基础设施

5 使用 Packer、Ansible 和 Terraform 构建不可变的基础设施（镜像化）

可以理解为，Packer 和 Terraform 都是公有云开放给用户的API接口，按照用户自己的方式编写代码，实现基础设施的快速构建。

不可变基础设施-镜像

• 在容器编排领域，Kubernetes 已成为事实上的标准，而容器镜像 (Docker Image) 作为容器技术栈中最关键的创新之一，极大的推动了企业内部 Devops 运动的进程。
• 容器镜像所具有的轻量性、便携性、分层机制和内核共享机制真正意义上实现了 “Build once, run anywhere”。
  这种不可变的基础设施 (Immutable Infrastruture) 高度保持了开发、测试和生产环境的一致性。因为镜像的易移植、易复制的特性，也给运维带来了很大的弹性和灵活性。
• 对于还无法容器化，只能部署在虚拟机里的传统应用，是否也能构建像容器镜像这样不可变的的基础设施？

虚拟机镜像打包 Packer

• Packer 是一款出色的开源镜像打包工具。它的 builder 支持主要的公有云和私有云平台，以及常见的虚拟化类型。此外，Packer 提供的 provisioner 涵盖了主流的配置管理工具，如 Ansible、Puppet、Chef、Windows Shell 和 Linux Shell 等。
• 在不可变服务器的应用场景中，Packer 能够自动创建虚拟机，并利用 Ansible provisioner 从中央制品仓库下载软件包，部署所需的额外依赖以及相关配置。最终，它将这些配置打包成虚拟机镜像，并回收该虚拟机的资源，将镜像上传至云平台中。

配置管理及安全加密 Ansible

• Ansible 是一款简单的，易上手的开源配置管理工具。它能简化软件的安装部署，作为配置管理能提供灵活的模版渲染引擎以及针对敏感信息的加密。

基础设施的创建和编排 Terraform

• Terraform 作为开源的基础设施资源编排工具，能覆盖主流的云平台，非常适用于多云的环境。能提供灵活的部署选择，并能根据用户需求开发可插拔式的、自定义的 provider。
• Terraform是由HashiCorp公司在2014年左右推出的开源资源编排工具， 目前几乎所有的主流云服务商都支持Terraform，包括阿里云、腾讯云、华为云、AWS、Azure、百度云、火山引擎等等。遵循 IaC （基础设施即代码）的理念，编写 Terraform 特定语法的 DSL 配置文件即可轻松部署上百家云厂商的服务。
• HashiCorp 目前总共有八款主打产品，囊括了从开发 (Packer, Vagrant)、部署 (Terraform)、安全 (Boundary, Vault)、网络 (Consul)、应用 (Nomad, Waypoint)等各个环节。
• 将云资源、服务或者操作步骤以代码的形式定义在模板中，借助编排引擎，实现资源的自动化管理，这就是基础设施即代码（Infrastructure as Code，简称IaC），也是资源编排最高效的实现模式。
• 然而，多种云编排服务带来的是高昂的学习成本、低效的代码复用率和复杂的多云协同工作流程。每一种服务仅限于管理自家的单一云平台上，无法满足对多个云平台，多种层级（如IaaS，PaaS）资源的统一管理，比如AWS CloudFormation。如何解决如上问题，是否可以使用统一的编排工具，共用一套语法实现对多云的统一管理呢？所以这个时候就诞生Terraform，来解决这些问题。

镜像的打包效率

• 相对于可变服务器部署模式，由于打包虚拟机镜像过程较为耗时，在一定程度上会加长整个部署的时间。
• 因为镜像里包含了应用程序所需要的代码和配置，每一次配置更新或者代码更新需要重新打包镜像时，可以考虑把配置和代码从镜像中分离出来提高打包效率。
• 将镜像分层管理，分为基础操作系统镜像和应用镜像。基础操作系统镜像中包含软件运行所需要的基本环境以及相关依赖（Python、C#、 第三方工具或者相关依赖包等）。
• 这样在构建应用镜像时只安装与应用相关的代码和配置，不必再重新安装基础镜像中存在的基础软件包、配置，缩短了应用镜像的打包时间。
• 将配置迁移至配置管理服务，应用程序启动时从该配置服务中动态获取配置信息，避免每次因为配置文件更新需要重新打包镜像。