文章目录
（source：link）
（source：link）
云应用
云应用是一种在两个不同系统（客户端和服务器端）之间运行处理逻辑和数据存储的软件。有些处理工作在最终用户的本地硬件（例如台式机或移动设备）上进行，而有些处理工作则在远程服务器上进行。通常，云应用的优势之一就是大多数数据存储都位于远程服务器上。用户将通过网页浏览器或应用编程接口（API）与云应用进行交互。这些是云应用的基本原理，但客户端与服务器端之间要处理的内容以及对用户体验的改变却存在几种不同的形式。
软件即服务（SaaS）
软件即服务（Software as a Service，SaaS）是一种常见的云计算形式，可以为用户提供 Web 应用及所有的底层 IT 基础架构和平台。对于符合以下条件的企业或个人而言，SaaS 可能是理想的解决方案：
- 想避免维护基础架构、平台和软件的麻烦。
- 需要尽可能减少自定义。
- 青睐软件订阅模式。
SaaS 的示例包括一些面向客户的服务（如 Google Docs 和 Microsoft Office 365），以及一些提供人力资源软件、内容管理系统、客户关系管理工具和某些集成开发环境（IDE）的企业服务。
SaaS 运作模式
软件供应商通常选择 2 种常见部署模式中的 1 种或同时选择 2 种：
- 在其数据中心，或
- 通过公共云服务提供商（如 AWS、Azure 或 IBM 云）管理托管 SaaS 解决方案的云环境。
SaaS 应用利用多租户架构来隔离用户数据。软件更新、漏洞修复以及其他常规应用维护都是由 SaaS 提供商负责，用户通过网络浏览器与软件交互。SaaS 解决方案通常功能齐全，但有时通过应用编程接口（API）（如 REST 或 SOAP）融入自定义集成，以连接其他功能。
SaaS 的特性使提供商更容易向客户推出新功能。大多数 SaaS 应用都是预配置的即插即用产品，SaaS 提供商将管理这些应用背后的所有内容，包括：
- 硬件组件，例如网络、存储和数据中心服务器
- 平台，例如虚拟化、操作系统和中间件
- 各种软件要求，例如运行时、数据和应用本身
SaaS 应用在很大程度上依赖于订阅模式置备软件许可证。和永久许可证不同，该软件交付模式是将每个帐户与订阅进行关联，而后者则在一段时间内（通常是每年或每月）授予 SaaS 相应的访问权限。缴纳订阅费后，通常帐户会获得对产品文档和服务级别协议（SLA）规定的持续支持的访问权限，但有些 SaaS 提供商会收取额外的支持费用，才能进行源代码级别上的自定义代码更改。
中间件：
中间件是为应用提供通用服务和功能的软件。中间件可以帮助开发人员更高效地构建应用。它就相当于是应用、数据与用户之间的纽带。
中间件是企业应用集成的技术基础。越来越多的企业选择中间件，在复杂的 IT 环境中保持快速、经济高效的应用开发。中间件可以有力支持应用环境在高度分布式平台上平稳、一致地运行。
SaaS 供应商
部分 SaaS 公司和产品包括：
- SAP 的企业资源规划（ERP）软件
- Paychex 的人力资源软件
- CA Technology 的企业软件
- Atos 的 SaaS 消息传递解决方案
- Salesforce 的客户关系管理（CRM）软件
- Slack 的消息传递服务
- Microsoft Office 365
- Dropbox 的文件存储服务
基础架构即服务（IaaS）
基础架构即服务（Infrastructure as a Service，IaaS）意味着提供商可以通过公共云或私有云为用户管理基础架构（实际的服务器、网络、虚拟化和存储）。用户将通过 API 或控制面板来访问租用的基础架构。
- 用户：可以管理操作系统、应用和中间件等内容；可以让用户享受到本地计算资源的所有优势，而又不会有额外的开销。在 IaaS 模型中，用户负责处理应用、数据、操作系统、中间件和运行时。
- 提供商（例如 AWS 或 Microsoft Azure）：提供硬件、网络、硬盘驱动器、存储和服务器，并负责处理中断、维修及硬件问题。
在大多数情况下，IaaS 用户可通过应用编程接口（API）或控制面板来完全控制基础架构。作为最灵活的即服务型云模型，IaaS 使用户可以更轻松地扩展、升级和添加资源（例如云存储），而不必预测未来的需求并预先支付费用。
平台即服务（PaaS）
平台即服务（PaaS）是一种由第三方提供硬件和应用软件平台的云计算形式。PaaS 主要面向开发人员和程序员，它允许用户开发、运行和管理自己的应用，而无需构建和维护通常与该流程相关联的基础架构或平台。
大多数云服务提供基于 Kubernetes 的平台即服务，明确地讲，即平台即服务（PaaS）或基础架构即服务（IaaS）环境。这使得 Kubernetes 可以作为平台运行、扩展和管理基于容器的应用。
平台即服务（Platform as a Service，PaaS）会提供平台，用户可以在上面开发、运行和管理自己的应用，而无需构建和维护运行所需的基础架构或环境。因为 PaaS 会为外部服务提供商的用户提供相应的硬件和应用软件平台。这意味着用户将控制平台上"活着"存在的应用和数据，因此 PaaS 是开发人员和程序员的理想解决方案。例如，开发人员能以 PaaS 为基础创建一个新的应用，并将该应用与贵公司在用的 Oracle 数据库进行集成。
云平台就是一种 PaaS，其中包含了由阿里云、Microsoft Azure、Google Cloud、Amazon Web Services（AWS）和 IBM Cloud 所提供的服务。
Kubernetes（K8s）：
Kubernetes 是 Linux 容器编排的一个开源平台，最初是由 Google 工程师开发的。它通过将 Linux 主机上运行的容器组合到集群中并进行自动化管理，从而实现了应用开发、管理和扩展的自动化。部署和扩展容器化应用时所涉及的许多手动过程都会在后台处理好。
IaaS/PaaS/SaaS 的区别
即服务（aaS）一词通常是指由其他人管理的解决方案，这样就可以专注于一些重要的事务，例如自定义应用的迭代改进。
IaaS 表示将由提供商通过云为用户管理基础架构，包括实际的服务器、网络、虚拟化和存储。用户将通过 API 或控制面板来访问租用的基础架构。操作系统、应用和中间件等内容由用户管理，而提供商则提供硬件、网络、硬盘驱动器、存储和服务器，并负责处理中断、维修及硬件问题。
PaaS 是由外部服务提供商为用户提供相应的硬件和应用软件平台。由于用户可以自行处理实际的应用和数据，因此 PaaS 是开发人员和程序员的理想解决方案。PaaS 会为用户提供平台，使其可以在上面开发、运行和管理自己的应用，而无需构建和维护运行这些应用所需的基础架构或环境。
容器即服务（CaaS）
容器即服务（CaaS）是一款云服务，可帮助使用基于容器的抽象来管理和部署应用。CaaS 支持本地部署或云部署。
提供商会提供在其上部署和管理容器的框架或编排平台，而正是通过此编排，才得以实现关键 IT 功能的自动化。
对于要开发更安全且可扩展的容器化应用的开发人员而言，CaaS 尤为有用。用户只需购买他们想要的资源（调度功能、负载平衡等），从而节省资金并提高效率。
容器可以创建一致的环境，以便快速开发和交付可在任何地方运行的云原生应用。
在云计算服务范畴内，CaaS 被认为是基础架构即服务（IaaS）的一种子集，介于 IaaS 和平台即服务（PaaS）之间。
CaaS 的基本资源为容器，它是云原生应用和微服务的常见部署机制。此外，CaaS 还可以提高环境之间的可移植性，无论是混合环境还是多云环境。
云原生
无服务器架构
无服务器是一种云原生开发模型，可使开发人员专注构建和运行应用，而无需管理服务器。相反，这类常规任务被云提供商抽象出来，使开发人员能够比传统模型更快地将代码推送至生产环境。
无服务器方案中仍然有服务器，但它们已从应用开发中抽离了出来。云提供商负责置备、维护和扩展服务器基础架构等例行工作。开发人员可以简单地将代码打包到容器中进行部署。
部署之后，无服务器应用即可响应需求，并根据需要自动扩容。公共云提供商的无服务器产品通常通过一种事件驱动执行模型来按需计量。因此，当无服务器功能闲置时，不会产生费用。
无服务器计算产品通常分为两类，分别是后端即服务（BaaS）和功能即服务（FaaS）。
功能即服务（FaaS）
“功能即服务”（或称为 FaaS）是一种云计算服务，它允许开发人员以功能的形式来构建、计算、运行和管理这些应用包，无需维护自己的基础架构。
FaaS 是一种在无状态容器中运行的事件驱动型执行模型，这些功能将利用 FaaS 提供商的服务来管理服务器端逻辑和状态。FaaS 解决方案可通过主流公共云提供，并可在内部置备，这样就为企业 IT 应用开发新增了一些重要的功能。
FaaS 非常适合大数据量的交易、经常发生的工作负载，例如报表生成、图像处理或任何计划任务。常见的 FaaS 用例包括数据处理、IoT 服务、移动和 Web 应用。
FaaS 为开发人员提供了一种运行 Web 应用的抽象方式，可以在无需管理服务器的情况下响应事件。例如，上载文件可触发自定义代码，从而将文件转码为各种格式。
FaaS 基础架构通常是由服务提供商按需计量的，主要通过事件驱动型执行模型进行，因此它会随时待命，但不需要任何服务器进程在后台持续运行（这一点与平台即服务 （PaaS）不同）。
现代 PaaS 解决方案提供了无服务器功能（作为通用工作流的一部分），藉此开发人员可以实现应用的部署，从而模糊了 PaaS 和 FaaS 之间的界线。
实际上，整个应用将由以下解决方案混合而成：功能、微服务和长期运行的服务。
使用 FaaS 时，开发人员可以通过 API 调用无服务器应用，FaaS 提供商则通过 API 网关来处理 API。
API网关：
API 网关是位于客户端与后端服务集之间的 API 管理工具。
API 网关相当于反向代理，用于接受所有应用编程接口（API）调用、整合处理这些调用所需的各种服务，并返回相应的结果。
API 网关是 API 管理系统的一部分。API 网关会拦截所有传入的请求，然后通过 API 管理系统（该系统负责处理各种必要的功能）将其发送出去。
API 网关的工作因实施不同而异。一些常见的功能包括：身份验证、路由、速率限制、计费、监控、分析、策略、警报和安全防护。
API 是最常见的微服务通信方式之一。
云原生应用构建
云原生应用是独立的小规模松散耦合服务的集合，旨在提供备受认可的业务价值，例如快速融合用户反馈以实现持续改进。简而言之，通过云原生应用开发，可以加速构建新应用、优化现有应用并将这些应用全部组合在一起。其目标是以企业需要的速度满足应用用户的需求。
如何构建云原生应用？
- 自动化流程DevOps使开发和运维团队协同合作，让他们朝着共同目标努力并定期进行反馈。
- 容器提供理想的应用部署单元和独立的执行环境，为这些实践提供支持。凭借 DevOps 和容器，开发人员能够更加轻松地以松散耦合服务的形式（如微服务）来发布和更新应用，而不是等待大型版本的发布。
- 云原生开发注重架构的模块性、松散耦合及其服务的独立性。每个微服务实现一种业务能力，在自己的流程中运行，并通过应用编程接口（API）或消息传递进行通信。该通信可通过服务网层进行管理。
DevOps及CI/CD
单独归档
微服务与服务网格
微服务
微服务既是一种架构，也是构建软件的方法。在微服务中，应用被拆分成最小的组件，彼此独立。不同于将所有组件内置于一个架构中的传统单体式应用构建方法，在微服务架构中，所有部分相互独立，通过合作来完成同一个任务。其中的每一个组件或流程都是一个微服务。这种软件开发方法强调细粒度、轻量化，力求在多个应用中共享相似的流程。它是针对云原生模型优化应用开发的主要组件。
为什么要使用基于微服务的基础架构？
简单来说，微服务架构有助于更快地交付高质量的软件。使用微服务有助实现这一点，但也需要注意一些细节。仅仅将应用拆分成微服务是不够的，还必须对微服务进行管理和编排，处理微服务创建和修改的数据。
开发团队内的多名成员能以敏捷的方法同时在同一个产品上进行开发，从而快速为客户创造价值。
要想让微服务架构能够像正常运行的云应用一样工作，各个服务之间必须通过消息传递不断相互请求数据。通过在应用中构建一层**服务网格（service mesh）**可以简化服务间通信，但微服务架构可能还需要与传统应用及其他数据源进行集成。
服务网格
服务网格（例如开源项目 Istio）用于控制应用的不同部分之间如何共享数据。与用于管理此类通信的其他系统不同，服务网格内置于应用程序中的专用基础架构层。这个可见的基础架构层可以记录应用的不同部分是否能正常交互。因此，随着应用的不断发展，它在优化通信和避免停机方面就显得更加有用。
现代应用常以这种方式拆分，所有组件构成一个服务网络，每一个都分别执行特定的业务功能。要执行相应的功能，一项服务可能需要向其他几项服务请求数据。但如果有些服务（例如零售商的库存数据库）遇到请求超载会怎样呢？这就要靠服务网格了，它会将请求从一项服务路由到下一项，从而优化所有移动组件的协同工作方式。
微服务架构可让开发人员更改应用的服务，而无需全部重新部署。与其他架构的应用开发不同，每个微服务都是由小型团队来构建，他们可以灵活地选择自己的工具和编码语言。总体而言，微服务是独立构建的，它们之间彼此通信，出现故障也只是单独情况，而不会升级为整个应用的中断。
服务间的通信，令微服务成为可能。在没有服务网格层时，逻辑管理的通信可以编码到每个服务中，但随着通信变得越来越复杂，服务网格的价值也就愈发显著。对于以微服务架构构建的云原生应用而言，利用服务网格，可以将大量离散服务整合为一个功能应用。
在服务网格中，请求将通过所在基础架构层中的代理在微服务之间路由。正因如此，构成服务网格的各个代理有时也被称为"sidecar"（挎斗），这是因为它们与每个服务并行运行，而非在内部运行。总之，这些"sidecar"代理（与每项服务分离）构成了网格式网络。
sidecar 代理与微服务并肩协作，用于将请求路由给其他代理。这些 sidecar 共同构成了网格式网络。
如果没有服务网格，每项微服务都需要进行逻辑编码，才能管理服务间通信，这会导致开发人员无法专注于业务目标。同时，这也意味着通信故障难以诊断，因为管理服务间通信的逻辑隐藏在每项服务中。
API
应用编程接口（API）由一组用于集成应用软件和服务的工具、定义和协议组合而成。有了这类接口，无需不断构建新的连接基础架构，就能让自己的产品和服务与其他产品和服务进行通信。
简单对象访问协议（SOAP）和表述性状态传递（REST）是两种有助于简化 API 设计并优化实施结果的措施。随着 Web API 的不断普及，业界制定了 SOAP 来帮助标准化消息格式和请求。通过这种协议规范，能让不同环境中或以不同语言编写的应用更加轻松地相互通信。而 REST 则是一种架构模式。REST 依赖于比规定协议更易遵循的 6 大指导原则。因此，RESTful API 现在比 SOAP 更为普及。
API 有时被视为合同，而合同文本则代表了各方之间的协议：如果一方以特定方式发送远程请求，该协议规定了另一方的软件将如何做出响应。
容器与容器编排
容器化是指将软件代码和所需的所有组件（例如库、框架和其他依赖项）打包在一起，让它们隔离在自己的"容器"中。
Linux 容器技术能够让用户对应用及其整个运行时环境（包括全部所需文件）一起进行打包或隔离。从而让用户可以在不同环境（如开发、测试和生产等环境）之间轻松迁移应用，同时还可保留应用的全部功能。容器也是保障 IT 安全的一个重要组成部分。将安全性内置于容器管道，可以为用户的基础架构增添防护，从而保障容器的可靠性、可扩展性和信赖度。
容器可以为不同大小的工作负载和用例部署容器。容器可为用户的团队提供云原生开发模式所需的底层技术，使用户可以轻松进行 DevOps、CI/CD（持续集成与持续部署），甚至实现无服务器化。
基于容器的应用可跨高度分布式云架构工作。应用运行时中间件提供工具，帮助用户创建一个统一的开发、交付、集成和自动化环境。
此外，用户还可以在容器中部署集成技术，以便轻松调整应用和数据的连接方式。例如，通过 Apache Kafka 进行实时数据流处理。如果用户正在构建微服务基础架构，那对于每个微服务及连接这些微服务的服务网状网络来说，容器都是其理想部署单元。
Kubernetes 是一种可自动实施 Linux 容器操作的开源平台。它可以帮助用户省去应用容器化过程的许多手动部署和扩展操作。Kubernetes 可为用户提供一个便捷有效的平台，让用户可以在物理机或虚拟机集群上调用和运行容器。Kubernetes 架构将集群分为不同的组件，这些组件要协同工作来维护集群的预期状态。
参考资料
https://www.redhat.com/zh/topics/cloud-native-apps/what-are-cloud-applications
https://www.redhat.com/zh/topics/middleware
https://www.redhat.com/zh/topics/cloud-computing/what-is-saas
https://www.redhat.com/zh/topics/cloud-computing/what-is-iaas
https://www.redhat.com/zh/topics/cloud-computing/what-is-paas
https://www.redhat.com/zh/topics/cloud-native-apps/what-is-faas
https://www.redhat.com/zh/topics/cloud-computing/what-is-caas
https://www.redhat.com/zh/topics/api/what-does-an-api-gateway-do
https://www.redhat.com/zh/topics/api/what-are-application-programming-interfaces
https://www.redhat.com/zh/topics/containers
https://www.redhat.com/zh/topics/microservices/what-is-a-service-mesh