云原生与微服务的一些基本概念

云架构一张图

云原生：云原生是一种利用云计算环境的弹性、可扩展性和自动化特性，来构建、部署、运行和自动化管理容器化微服务化的应用程序的一系列工具，一句话讲就是 云上敏捷应用开发辅助工具集

微服务：微服务是一种将单个完整应用程序依据业务的服务进行拆分为单个可运行程序的过程，微小程序间通过接口相互传递信息，一句话讲就是 云上敏捷应用开发

抽象：在计算机领域，抽象是一种对服务消费者（消费者是指计算机程序或人类）隐藏具体细节的表征，使系统更通用，从而更容易理解。笔记本电脑的操作系统（OS）就是一个很好的例子。它抽象出了电脑工作的所有细节。你不需要知道关于 CPU、内存和程序处理方式的任何信息，只需操作操作系统，操作系统就会处理这些细节。所有这些细节都隐藏在操作系统的 "幕布 "或抽象层之后。

系统通常有多个抽象层。这大大简化了开发工作。在编程时，开发人员只需构建与特定抽象层兼容的组件，而不必担心所有底层的具体细节，因为这些细节可能是非常异构的。只要能与抽象层兼容，就能与系统兼容--不管底层是什么。

敏捷软件开发：其实通俗来讲，瀑布式开发就是一个后端一口气完成了所有的需求的开发，前端苦苦等待完成后端完成才可以进行自己的开发，最后一次性打包为可执行的程序。所谓敏捷开发，就是后端将一个大的需求进行拆分为小的需求，将一个小需求完成后立即编译成为可以运行的程序，前端可以立即测试结果，在得到最终反馈后调整代码符合期望的目标。

API网关：API网关和微服务有着紧密的联系，之前说到微服务是对应用服务的拆分，拆分后的程序必然要暴露很多的接口给外界，他们相互调用同时有一个统一的入口程序，在每次接口调用时都需要进行身份验证和授权操作，为了简化开发的复杂度，我们再提供一个程序专门用来接收用户发来的请求，并处理身份验证和授权问题，这就是所有所谓的微服务的api网关，他其实就是为了解决由微服务开发而引入的用户如何访问的该程序的问题的办法。当然还有其他问题需要解决，比如这么多的应用程序，一个一个管理太复杂，他们的配置文件如何统一管理的问题，还有服务a调用服务b，服务a如何知道b是否存活，他的地址又是多少，我又应该使用什么工具去调用，还有为了进一步提高程序的可用性，我如何进行服务监测，安全监测，流量监测问题，还有一个根本问题没有解决，这么多程序我难道要一个一个登录服务器自己手动配置环境后运行。

 API：应用程序编程接口，就是开发常说的接口，用于提供应用程序间发起http请求到web服务的访问入口。微服务程序也是基于api进行相互通信的。

裸金属机：
基础设施
裸金属机是指一台物理计算机，更具体地说是一台服务器，它有一个且只有一个操作系统。这种区别在现代计算中很重要，因为许多（如果不是大多数）服务器都是虚拟机。物理服务器通常是一台相当大的计算机，内置强大的硬件。在物理硬件上安装操作系统并直接运行应用程序（无需虚拟化）被称为在“裸金属机”上运行。

它解决的问题
将一个操作系统与一台物理计算机配对是计算的原始模式。物理计算机的所有资源都可直接供操作系统使用，并且不存在虚拟化层，因此在将操作系统指令转换为硬件时不存在人为延迟。

它有什么帮助
通过将计算机的所有计算资源专用于单个操作系统，您有可能为操作系统提供最佳性能。如果您需要运行必须以极快的速度访问硬件资源的工作负载，裸金属机可能是正确的解决方案。

在云原生应用程序的上下文中，我们通常会考虑扩展到大量并发事件的性能，这可以通过水平扩展（向资源池添加更多机器）来处理。但某些工作负载可能需要垂直扩展（为现有物理机添加更多功能）和/或极快的物理硬件响应，在这种情况下，裸金属机更适合。裸金属机还允许您调整物理硬件，甚至可能调整硬件驱动程序以帮助完成您的任务。

蓝绿部署：是一种在运行中的计算机系统上进行更新的策略，旨在最小化停机时间。运营者维护两个环境，分别称为“蓝色”和“绿色”。一个用于提供生产流量（所有用户当前使用的版本），而另一个用于更新。一旦在非活动（绿色）环境上完成测试，就会切换生产流量（通常通过负载均衡器进行）。请注意，蓝绿部署通常意味着同时切换包含许多服务的整个环境。有时，这个术语也会用于指系统中的个别服务，为了避免混淆，当涉及到系统中的个别组件时，更倾向于使用术语“零停机部署”。

解决的问题： 蓝绿部署允许在必须“锁定步调”更新的软件上进行最小停机时间。例如，对于由网站和需要更新的数据库组成的在线商店，但新版本的数据库与旧版本的网站不兼容，反之亦然，蓝绿部署是合适的。在这种情况下，两者需要同时更改。如果这在生产系统上完成，客户会注意到停机时间。

帮助之处： 蓝绿部署是一种适用于非云原生软件需要以最小停机时间更新的策略。然而，其使用通常是对遗留软件需要重新设计以便能够逐个更新组件的一种信号。

金丝雀部署：

金丝雀部署是一种从两个环境开始的部署策略：一个具有实时流量，另一个包含更新的代码但没有实时流量。流量逐渐从应用的原始版本转移到更新版本。它可以从移动 1% 的实时流量开始，然后是 10%、25%，依此类推，直到所有流量都通过更新版本运行。组织可以在生产中测试软件的新版本，获取反馈，诊断错误，并在必要时快速回滚到稳定版本。

“金丝雀”一词指的是“煤矿里的金丝雀”做法，将金丝雀鸟带入煤矿以保证矿工的安全。如果存在无味的有害气体，鸟就会死亡，矿工们知道他们必须迅速撤离。同样，如果更新的代码出现问题，实时流量将“疏散”回原始版本。

它解决的问题

无论测试策略多么彻底，在生产中总会发现一些错误。将 100% 的流量从应用程序的一个版本转移到另一个版本可能会导致影响更大的故障。

它有什么帮助

金丝雀部署允许组织在将大量流量转移到新版本之前了解新软件在现实场景中的行为方式。此策略使组织能够最大限度地减少停机时间，并在新部署出现问题时快速回滚。它还允许进行更深入的生产应用程序测试，而不会对整体用户体验产生重大影响。

 他和蓝绿部署的区别是一个整体迁移，一个是部分迁移

 

混沌工程（Chaos Engineering）是一种通过有意引入系统的随机性和不稳定性来测试和改善软件系统稳定性和可靠性的实践方法。通俗来说，混沌工程是为了找出系统中可能存在的问题并改进系统的表现，以便在真正面临压力和故障时能够更好地应对。

关键思想包括：

1. 有目的的引入故障： 混沌工程并非试图破坏系统，而是通过有计划地引入故障、延迟、网络中断等来模拟真实世界中可能发生的问题。

2. 观察系统响应： 通过监测和观察系统在面对这些故障时的表现，包括性能、稳定性和可恢复性等方面。

3. 改进系统设计： 基于观察结果，团队可以识别并改进系统中的弱点，提高系统对故障的容忍度和恢复能力。

4. 持续演练： 混沌工程是一个持续的实践，通过不断地引入故障并优化系统，确保系统能够在面对各种异常情况时保持稳定。

混沌工程的目标是使团队更好地了解其系统的弱点，从而提高系统的可靠性和健壮性。这有助于在生产环境中更好地应对真实世界中的故障和压力。

 

云计算
基础设施
基本的
云计算通过互联网按需提供CPU、网络和磁盘功能等计算资源，允许用户在远程物理位置访问和使用计算能力。我们通常区分私有云和公共云，具体取决于云基础设施是专门供组织使用还是为开放公共服务共享。

它解决的问题
传统上，组织在尝试扩展计算能力时面临两个主要挑战。他们可以购买、支持和设计（新）设施来托管其物理服务器和网络，也可以扩展和维护现有的设施。云计算允许组织外包一些计算需求，从而解决了这一挑战。

它有什么帮助
云提供商允许组织按需租用计算资源并按使用付费，从而带来两个主要好处。首先，组织可以专注于他们的产品或服务，而无需等待、规划和在新的物理基础设施上花费资源。其次，他们可以根据需要简单地按需扩展。云计算允许组织根据需要采用尽可能多或尽可能少的基础设施。

 

 

云原生安全

云原生安全是一种将安全性构建到云原生应用程序中的方法。它确保安全性成为从开发到生产的整个应用程序生命周期的一部分。云原生安全力求确保与传统安全模型相同的标准，同时适应云原生环境的特殊性，即快速的代码更改和高度短暂的基础设施。云原生安全与DevSecOps实践高度相关。

它解决的问题

传统的安全模型是基于许多不再有效的假设而构建的。云原生应用程序变化频繁，使用大量开源工具和库，通常在供应商控制的基础设施中运行，并且会受到快速基础设施变化的影响。代码审查、较长的质量保证周期、基于主机的漏洞扫描和最后一刻的安全审查无法与云原生应用程序一起扩展。

它有什么帮助

云原生安全引入了一种新的工作方式，通过从传统安全模型迁移到发布周期的每个步骤都涉及安全的模型来保护应用程序。手动审核和检查很大程度上被自动扫描所取代。快速代码发布管道与在编译代码之前扫描代码漏洞的工具集成。开源库是从可信来源提取的，并监控漏洞。云原生安全模型并没有减缓变化，而是通过频繁更新易受攻击的组件或确保定期更换基础设施来拥抱变化。

 

云原生技术

云原生技术，也称为云原生堆栈，是用于构建云原生应用程序的技术。这些技术使组织能够在公共云、私有云和混合云等现代动态环境中构建和运行可扩展的应用程序，同时充分利用云计算的优势。它们是从头开始设计的，旨在利用云计算的功能，而容器、服务网格、微服务和不可变基础设施就是这种方法的例证。

它解决的问题

云原生堆栈有许多不同的技术类别，可解决各种挑战。如果您查看CNCF 云原生景观，您会看到它涉及多少不同的领域。但在较高层面上，它们解决了一组主要挑战：传统 IT 运营模式的缺点。挑战包括创建可扩展、容错、自我修复应用程序的困难，以及资源利用效率低下等。

它有什么帮助

虽然每种技术都解决一个非常具体的问题，但作为一个整体，云原生技术可以实现弹性、可管理和可观察的松散耦合系统。与强大的自动化相结合，工程师能够以最少的劳力频繁且可预测地进行高影响力的更改。使用云原生堆栈更容易实现云原生系统的理想特性。

 

集群是一组为实现共同目标而协同工作的计算机或应用程序。在云原生计算的背景下，该术语最常应用于Kubernetes。Kubernetes 集群是一组在自己的容器中运行的服务（或工作负载），通常在不同的机器上。通过网络连接的所有这些容器化服务的集合代表一个集群。

它解决的问题
在单台计算机上运行的软件会出现单点故障——如果该计算机崩溃，或者有人意外拔掉电源线，那么某些关键业务系统可能会离线。这就是为什么现代软件通常构建为分布式应用程序，并分组为集群。

它有什么帮助
集群、分布式应用程序跨多台机器运行，消除了单点故障。但构建分布式系统确实很难。事实上，它本身就是一门计算机科学学科。对全球系统的需求和多年的反复试验导致了一种新型技术堆栈的开发： 云原生技术。这些新技术是使分布式系统的操作和创建变得更容易的构建

 

容器编排

容器编排是指在动态环境中管理和自动化容器化应用程序的生命周期。它通过容器编排器（在大多数情况下是Kubernetes）执行，该编排器支持部署、（自动）扩展、自动修复和监控。编排是一个比喻：编排工具像音乐指挥一样指挥容器，确保每个容器（或音乐家）做它应该做的事情。

它解决的问题

大规模管理微服务、安全性和网络通信——以及一般的分布式系统——手动管理即使不是不可能，也是很困难的。容器编排允许用户自动执行所有这些管理任务。

它有什么帮助

容器编排工具允许用户确定系统的状态。首先，他们声明它应该是什么样子（例如，x 个容器、y 个 pod 等）。然后，编排工具将自动监视基础设施，并在其状态偏离声明的状态时进行纠正（例如，如果容器崩溃，则启动一个新容器）。这种自动化简化了许多工程团队原本高度手动且复杂的操作任务，包括配置、部署、扩展（向上和向下）、网络、负载平衡和其他活动。

 

容器化是将应用程序及其依赖项捆绑到容器映像中的过程。容器构建过程需要遵守开放容器计划(OCI) 标准。只要输出是符合此标准的容器镜像，使用哪种容器化工具并不重要。

它解决的问题
在容器流行之前，组织依靠虚拟机 (VM) 在单个裸机上编排多个应用程序。虚拟机比容器大得多，并且需要虚拟机管理程序才能运行。由于这些较大的虚拟机模板的存储、备份和传输，创建虚拟机模板的速度也很慢。此外，虚拟机可能会遭受配置漂移的影响，这违反了不变性原则。

它有什么帮助
容器映像是轻量级的（与传统虚拟机不同），并且容器化过程需要一个包含依赖项列表的文件。该文件可以进行版本控制，构建过程可以自动化，从而使组织能够专注于其他优先事项，同时自动化过程负责构建。容器映像由与其确切内容和配置相关联的唯一标识符存储。当容器被调度和重新调度时，它们总是重置为初始状态，从而消除了配置漂移。

 

容器是一个正在运行的进程，具有由计算机操作系统管理的资源和功能限制。容器进程可用的文件被打包为容器镜像。容器在同一台机器上彼此相邻地运行，但通常操作系统会阻止单独的容器进程相互交互。

它解决的问题

在容器可用之前，需要单独的机器来运行应用程序。每台机器都需要自己的操作系统，该操作系统需要 CPU、内存和磁盘空间，所有这些都是为了单个应用程序的运行。此外，操作系统的维护、升级和启动也是另一个重要的辛苦来源。

它有什么帮助

容器共享相同的操作系统及其机器资源，分散操作系统的资源开销并创建物理机的高效利用。此功能之所以可能，是因为容器之间的交互通常受到限制。这使得更多的应用程序可以在同一台物理机器上运行。

然而，也有一些限制。由于容器共享相同的操作系统，因此可以认为进程的安全性低于替代方案。容器还需要对共享资源进行限制。为了保证资源，管理员必须约束和限制内存和CPU的使用，以免其他应用程序性能不佳。

 

持续交付，通常缩写为 CD，是一组实践，其中代码更改自动部署到验收环境中（或者，在持续部署的情况下，部署到生产环境中）。CD 至关重要的是，它包括确保软件在部署之前经过充分测试的程序，并提供了一种在必要时回滚更改的方法。持续集成（CI）是实现持续交付的第一步（即，在测试和部署之前必须干净地合并更改）。

它解决的问题

大规模部署可靠的更新会成为一个问题。理想情况下，我们会更频繁地部署，以便为最终用户提供更好的价值。然而，手动执行每次更改都会导致高昂的交易成本。从历史上看，为了避免这些成本，组织发布的频率较低，同时部署更多变更，并增加了出现问题的风险。

它有什么帮助

CD 策略创建了一条完全自动化的生产路径，使用各种部署策略（例如金丝雀或蓝绿发布）来测试和部署软件。这使得开发人员可以频繁部署代码，让他们放心新版本已经过测试。通常，基于主干的开发用于 CD 策略，而不是功能分支或拉取请求。

 

持续部署（通常缩写为 CD）比持续交付更进一步， 将完成的软件直接部署到生产中。持续部署 (CD) 与持续集成(CI)齐头并进，通常称为 CI/CD。CI 流程测试对给定应用程序的更改是否有效，CD 流程自动将代码更改部署到组织的环境中，从测试到生产。

它解决的问题
发布新的软件版本可能是一个劳动密集型且容易出错的过程。组织通常只想不经常这样做，以避免生产事故并减少工程师在正常工作时间之外需要的时间。传统的软件部署模型使组织陷入恶性循环，发布软件的过程无法满足组织对稳定性和功能速度的需求。

它有什么帮助
通过自动化发布周期并迫使组织更频繁地发布到生产环境，CD 所做的事情就像 CI 为开发团队和运营团队所做的那样。具体来说，它迫使运营团队将生产部署中痛苦且容易出错的部分自动化，从而降低总体风险。它还使组织能够更好地接受和适应生产变化，从而带来更高的稳定性

 

持续集成，通常缩写为 CI，是尽可能定期集成代码更改的实践。CI 是持续交付(CD)的先决条件。传统上，CI 流程从代码更改提交到源代码控制系统（Git、Mercurial 或 Subversion）时开始，并以准备好由 CD 系统使用的经过测试的工件结束。

它解决的问题 

软件系统通常庞大且复杂，需要众多开发人员维护和更新。这些开发人员在系统的不同部分并行工作，可能会做出相互冲突的更改并无意中破坏彼此的工作。此外，由于多个开发人员在同一个项目上工作，每个开发人员都需要重复测试和计算代码质量等日常任务，从而浪费时间。

它有什么帮助

每当开发人员提交更改时，CI 软件都会自动检查代码更改是否完全合并。使用 CI 服务器来运行代码质量检查、测试甚至部署是一种几乎无处不在的做法。因此，它成为团队内部质量控制的具体实施。CI 允许软件团队将每个代码提交转变为具体的失败或可行的候选版本

 

 

数据中心是专门用于容纳计算机（通常是服务器）的建筑物或设施。这些数据中心往往连接到高速互联网线路，尤其是在专注于云计算时。数据中心所在的建筑物配备了即使在不利事件期间也能维持服务的设备，包括在停电期间提供电力的发电机和使发热计算机保持凉爽的强大空调。

它解决的问题

在 20 世纪 90 年代末数据中心盛行之前，主要是执行特定任务的个人计算机或供个人用来完成工作的计算机。

但计算机的资源（磁盘、RAM 和 CPU）是有限的。这意味着在它们上运行的应用程序具有相同的硬约束，限制了它可以运行的应用程序类型。在数据中心出现之前，应用程序的规模受到其运行的计算机容量的限制。但如果您考虑像 Gmail 或 Netflix 这样的大规模应用程序（应用程序，而不是您手机或计算机上的用户界面），那么这些应用程序需要的计算能力是任何一台计算机都无法提供的。这就是数据中心发挥作用的地方。

它有什么帮助

通过连接各种服务器，用户可以创建一个功能类似于“超级计算机”的分布式系统。因为我们捆绑了多台机器的功能，所以我们现在可以运行更大的应用程序或处理更强大的计算任务。数据中心为我们日常使用的大多数应用程序提供支持。

公共云是向客户出租容量的数据中心。在过去的几年里，我们看到了从企业拥有的数据中心到云的转变。

 

DevOps 是一种方法，团队拥有从应用程序开发到生产运营的整个流程，因此称为 DevOps。它不仅仅是实施一套技术，还需要文化和流程的彻底转变。DevOps 需要一组工程师来处理小型组件（而不是整个功能），从而减少交接——这是常见的错误来源。

它解决的问题

传统上，在具有紧密耦合的 整体应用程序的复杂组织中，工作通常分散在多个组之间。这导致了多次交接和较长的交付时间。每次组件或更新准备就绪时，它都会被放入下一个团队的队列中。由于个人只参与项目的一小部分，因此这种方法导致缺乏所有权。他们的目标是将工作交给下一个小组，而不是向客户提供正确的功能——这显然是优先事项的不一致。

当代码最终投入生产时，它经历了如此多的开发人员，在如此多的队列中等待，如果代码不起作用，就很难追踪问题的根源。DevOps 颠覆了这种方法。

它有什么帮助 

让一个团队负责应用程序的整个生命周期，可以最大限度地减少交接，降低部署到生产中的风险，提高代码质量，因为团队还负责代码在生产中的执行方式，并由于更多的自主权和所有权而提高了员工满意度。

 

DevSecOps 一词是指开发、运营和安全责任的文化合并。它扩展了DevOps方法，将安全优先事项纳入其中，并且对开发人员和操作工作流程的干扰最小甚至没有干扰。与 DevOps 一样，DevSecOps 是一种文化转变，由所采用的技术推动，具有独特的采用方法。

它解决的问题

DevOps 实践包括持续集成、持续交付和持续部署，并加速应用程序开发和发布周期。不幸的是，无法充分代表所有组织利益相关者的自动化发布流程可能会加剧现有问题。不考虑安全需求而快速发布新软件的流程可能会降低组织的安全状况。

它有什么帮助

DevSecOps 专注于打破团队孤岛并促进创建安全、自动化的工作流程。在选择安全应用程序时，组织必须利用自动化 CI/CD 工作流程和为开发人员提供支持的策略实施。目标不是成为阻止者，而是执行安全策略，同时为用户提供有关如何推进项目的准确信息。如果实施得当，组织将获得更好的团队沟通并减少安全事故和相关成本。

 

分布式应用程序是一种功能被分解为多个较小的独立部分的应用程序。分布式应用程序通常由单独的微服务组成 ，这些微服务处理更广泛的应用程序中的不同问题。在云原生环境中，各个组件通常作为集群上的容器运行。

它解决的问题

在一台计算机上运行的应用程序代表单点故障 - 如果该计算机出现故障，应用程序将变得不可用。分布式应用程序通常与单体应用程序进行对比。单体应用程序可能更难扩展，因为各个组件无法独立扩展。随着开发人员的成长，它们还可能成为开发人员速度的拖累，因为更多的开发人员需要在不一定具有明确定义的边界的共享代码库上工作。

它有什么帮助

当将应用程序拆分为不同的部分并在多个地方运行它们时，整个系统可以容忍更多的故障。它还允许应用程序利用单个应用程序实例不可用的缩放功能，即水平缩放的能力。然而，这确实是有代价的：增加了复杂性和运营开销——您现在正在运行大量应用程序组件而不是一个应用程序。

 

分布式系统是通过网络连接的自主计算元素的集合，在用户看来是一个单一的连贯系统。一般称为节点，这些组件可以是硬件设备（例如计算机、手机）或软件进程。节点经过编程以实现共同目标，并且为了进行协作，它们通过网络交换消息。

它解决的问题

如今，许多现代应用程序都非常庞大，需要超级计算机才能运行。想想 Gmail 或 Netflix。没有一台计算机的功能足以承载整个应用程序。通过连接多台计算机，计算能力几乎变得无限。如果没有分布式计算，我们今天依赖的许多应用程序将无法实现。

传统上，系统会垂直扩展。这时您需要向单个计算机添加更多 CPU 或内存。垂直扩展非常耗时，需要停机，并且很快就会达到极限。

它有什么帮助

分布式系统允许水平扩展（例如，在需要时向系统添加更多节点）。这可以自动化，允许系统处理工作负载或资源消耗的突然增加。

非分布式系统面临失败的风险，因为如果一台机器出现故障，整个系统就会出现故障。分布式系统可以设计成这样，即使某些机器出现故障，整个系统仍然可以继续工作以产生相同的结果。

 

eBPF，即扩展伯克利数据包过滤器，是一种允许小型沙盒程序或脚本在 Linux 系统的内核空间中运行的技术，而无需更改内核的源代码或加载 Linux 内核模块。

Linux系统有两个空间：内核空间和用户空间。内核代表操作系统的核心，是唯一可以无限制访问硬件的部分。

应用程序驻留在用户空间，当它们需要更高的权限时，它们会向内核发送请求。对于需要更大灵活性的应用程序，例如直接硬件访问，可以通过所谓的“Linux 内核模块”方法来扩展内核。这种方法扩展了内核的默认功能，允许应用程序更深入地访问底层组件。然而，这种方法也带来了安全风险，这使得 eBPF 成为一个有吸引力的替代方案。

它解决的问题

通常，应用程序在用户空间中运行，如果应用程序需要内核的某些权限（例如，访问某些硬件），它会通过所谓的“系统调用”向内核请求它。
在大多数情况下，这种方法效果很好。然而，在某些情况下，开发人员需要更灵活地进行低级系统访问。可观察性、安全性和网络功能就是很好的例子。为了实现这一点，我们可以使用 Linux 内核模块，在不修改内核源代码的情况下扩展内核基础。虽然使用 Linux 内核模块有好处，但它也带来了安全风险。因为它们在内核空间内运行，所以 Linux 内核模块可能会导致内核崩溃，当内核崩溃时，整个机器也会崩溃。此外，内核模块具有提升的权限并可以直接访问系统资源。如果没有得到适当的保护，攻击者就可以利用这些漏洞。

它有什么帮助

eBPF 为执行用户定义的程序提供了比 Linux 内核模块更受控制和包含的环境。它在内核内的沙盒环境中运行，提供隔离并降低风险。如果 eBPF 程序中的漏洞或缺陷被利用，其影响通常仅限于沙盒环境。此外，在eBPF程序开始在内核中运行之前，它必须通过一些验证。验证器组件检查 eBPF 程序是否存在潜在的安全违规，例如越界内存访问、无限循环和未经授权的内核函数。这样，它可以确保程序不会进入无限循环并导致内核崩溃。这些安全控制使 eBPF 成为在 Linux 内核中运行应用程序比 Linux 内核模块更安全的选择。

 

边缘计算是一种分布式系统方法，它将一些存储和计算能力从主数据中心转移到数据源。收集的数据在本地计算（例如，在工厂车间、商店或整个城市），而不是发送到集中式数据中心进行处理和分析。这些本地处理单元或设备代表系统的边缘，而数据中心是系统的中心。然后，在边缘计算的输出被发送回主数据中心以进行进一步处理。边缘计算的示例包括手腕小工具或分析流量的计算机。

它解决的问题

在过去的十年中，我们看到边缘设备（例如手机、智能手表或传感器）的数量不断增加。在某些情况下，实时数据处理不仅是可有可无的，而且至关重要。想想自动驾驶汽车。现在想象一下，来自汽车传感器的数据必须传输到数据中心进行处理，然后再发送回车辆，以便车辆能够做出适当的反应。固有的网络延迟可能是致命的。虽然这是一个极端的例子，但大多数用户不想使用无法提供即时反馈的智能设备。

它有什么帮助

如上所述，为了使边缘设备有用，它们必须至少在本地进行部分处理和分析，以向用户提供近乎实时的反馈。这是通过将一些存储和处理资源从数据中心转移到数据生成地：边缘设备来实现的。已处理和未处理的数据随后被发送到数据中心进行进一步处理和存储。简而言之，效率和速度是边缘计算的主要驱动力。

 

事件流是一种软件将事件数据从一个应用程序发送到另一个应用程序以持续传达它们正在执行的操作的方法。想象一个服务向所有其他服务广播它所做的一切。服务进行的每个活动都称为事件，因此称为事件流。例如，纳斯达克每秒都会更新股票和商品定价。如果您有一个监控一组特定股票的应用程序，您可能希望近乎实时地接收该信息。雅虎！Finance 提供了一个API，可以从 NASDAQ 获取数据并将信息（或事件）从其应用程序发送（或流式传输）到订阅它的任何应用程序。发送的数据以及该数据（股票价格）的变化是事件，而将它们传递到应用程序的过程是事件流。

它解决的问题

传统上，雅虎！财务部门将使用单个 TCP 请求。这将非常低效，因为它需要为每个事件创建连接。随着数据本质上变得更加实时，扩展此类解决方案变得效率低下。打开一次连接并允许事件流动是实时收集的理想选择。生成的数据量呈指数级增长，数据状态不断变化。开发人员和用户需要能够近乎实时地查看这些数据。

它有什么帮助

事件流允许将数据更改从源传送到接收者。该服务不是等待服务请求信息，而是连续流式传输其所有事件（或活动）。它不关心信息会发生什么。它只是做它需要做的事情并广播它，从而完全独立于任何其他服务。

 

事件驱动架构是一种促进事件的创建、处理和消费的软件架构。事件是应用程序状态的任何更改。例如，在乘车共享应用程序上叫车就代表一个事件。此架构创建了一种结构，在该结构中，事件可以从其来源（请求乘车的应用程序）正确路由到所需的接收者（附近可用司机的应用程序）。

它解决的问题
随着越来越多的数据变得实时，寻找可靠的方法来确保捕获事件并将其路由到必须处理事件请求的适当服务变得越来越具有挑战性。处理事件的传统方法通常无法保证消息被正确路由或实际发送或接收。随着应用程序开始扩展，编排事件变得更具挑战性。

它有什么帮助
事件驱动的架构为所有事件建立了一个中心枢纽（例如，Kafka）。然后，您定义事件生产者（源）和消费者（接收者），中央事件中心保证事件流。这种架构确保服务保持解耦，并且事件正确地从生产者路由到消费者。生产者通常通过 HTTP 协议获取传入事件，然后路由事件信息。

 

功能即服务 (FaaS) 是一种无服务器 云计算 服务 ，允许执行代码来响应事件，而无需维护通常与构建和启动微服务应用程序相关的复杂基础设施。使用 FaaS，用户仅管理功能和数据，而云提供商则管理应用程序。这使得开发人员可以在代码不运行时获得他们需要的功能，而无需支付服务费用。

它解决的问题
在传统的本地场景中，企业管理和维护自己的数据中心。企业必须投资服务器、存储、软件和其他技术，并可能雇用 IT 员工或承包商来购买、管理和升级所有设备和许可证。数据中心的建设必须能够满足高峰需求，即使工作负载下降并且这些资源闲置时也是如此。相反，如果业务增长很快，IT 部门可能很难跟上。在标准基础设施即服务 (IaaS)云计算模型下，用户预先购买容量单位，这意味着您需要向公共云提供商支付始终在线的服务器组件来运行您的应用程序。用户有责任在需求高时扩大服务器容量，并在不再需要该容量时缩小服务器容量。即使应用程序未被使用，运行应用程序所需的云基础设施也会处于活动状态。

它有什么帮助
FaaS 为开发人员提供了运行 Web 应用程序以响应事件的抽象，而无需管理服务器。例如，上传文件可能会触发将文件转码为各种格式的自定义代码。FaaS 基础设施将自动扩展代码以适应大量使用，开发人员无需花费任何时间或资源来构建代码以实现可扩展性。计费仅基于计算时间，这意味着企业无需在功能不使用时付费。

 

水平扩展是一种通过添加更多节点而不是向单个节点添加更多计算资源来增加系统容量的技术 （后者称为垂直扩展）。假设我们有一个 4GB RAM 的系统，想要将其容量增加到 16GB RAM，水平扩展意味着通过添加 4 x 4GB RAM 而不是切换到 16GB RAM 系统来实现。

此方法通过添加新实例或节点来增强应用程序的性能，以更好地分配工作负载。简单来说，它的目的是减少服务器的负载，而不是扩展单个服务器的容量。

它解决的问题

随着应用程序的需求增长超出该应用程序实例的当前容量，我们需要找到一种方法来扩展系统（增加容量）。我们可以向系统添加更多节点（水平扩展），也可以向现有节点添加更多计算资源（垂直扩展）。

它有什么帮助

水平扩展允许应用程序扩展到底层集群提供的任何限制。通过向系统添加更多实例，应用程序可以处理更多数量的请求。如果单个节点每秒可以处理 1,000 个请求，则每个额外的节点应该使请求总数每秒增加大约 1,000 个请求。这允许应用程序同时执行更多工作，而无需特别增加任何节点的容量

 

在数学或计算机科学中，幂等性描述了一种总是导致相同结果的操作，无论执行多少次。如果参数相同，多次执行幂等操作不会产生额外效果。在分布式系统和网络通信中，幂等性非常重要，特别是在面对网络不稳定、消息丢失或重复发送等情况时。保持操作的幂等性可以确保系统在面对这些不确定性的情况下，最终达到一致的状态，而不会因为重复执行操作而导致意外结果。

 

基础设施即服务（IaaS）是一种云计算服务模型 ，以即用即付的模式按需提供物理或虚拟化计算、存储和网络资源。云提供商拥有并运营硬件和软件，可供消费者在公共、私有或混合云部署中使用。

它解决的问题

在传统的本地设置中，组织经常难以有效地使用计算资源。数据中心的建设必须满足潜在的峰值需求，即使只需要 1% 的时间。在需求较低期间，这些计算资源处于空闲状态。而且，如果工作负载超出预期需求，则处理该工作负载的计算资源就会短缺。缺乏可扩展性会导致成本增加和资源使用效率低下。

它有什么帮助

借助 IaaS，组织可以避免为其应用程序购买和维护计算和数据中心空间。按需基础设施使他们能够根据需要租用计算资源并推迟大量资本支出（CAPEX），同时赋予他们扩大或缩小规模的灵活性。

IaaS 降低了试验或尝试新应用程序的前期成本，并提供了快速部署基础设施的设施。云提供商是开发或测试环境的绝佳选择，可以帮助开发人员进行实验和创新。

 

不可变基础设施是指一旦部署就无法更改的计算基础设施，包括虚拟机、容器和网络设备。这可以通过自动化流程强制覆盖未经授权的更改，或者通过系统阻止第一次更改来实现。容器是不可变基础设施的良好示例，因为对容器的持久更改只能通过创建容器的新版本或重新创建现有容器来实现。

通过防止或识别未经授权的更改，不可变基础设施使得更容易识别和缓解安全风险。操作这样的系统变得更加简单，因为管理员可以对其进行假设。毕竟，他们知道没有人犯下错误或进行了未经沟通的更改。不可变基础设施与基础设施即代码紧密相关，其中用于创建基础设施的所有自动化都存储在版本控制中（例如 Git）。这种不可变性和版本控制的结合意味着系统的每个经过授权的更改都有持久的审计日志。

 

 

基础设施即代码是将基础设施的定义存储为一个或多个文件的做法。这取代了通常通过 shell 脚本或其他配置工具手动配置基础设施即服务的传统模型。

它解决的问题
以云原生方式构建应用程序需要基础设施是一次性且可复制的。它还需要以自动化和可重复的方式按需扩展，可能无需人工干预。手动配置无法满足云原生应用的响应能力和规模要求。手动基础设施更改不可重复，很快就会达到规模限制，并引入错误配置错误。

它有什么帮助
通过将服务器、负载均衡器和子网等数据中心资源表示为代码，它允许基础设施团队拥有所有配置的单一事实来源，并允许他们在CI / CD管道中管理其数据中心，实现版本控制和部署策略。

 

Ingress 是一组规则，有助于管理从外部到集群中运行的容器或一组容器的互联网流量。它由两个元素组成：入口资源和入口控制器。入口资源是一个配置文件，与其他清单文件一起存在，并允许管理员配置外部流量路由。入口控制器是一种 Web 服务器技术，它根据入口资源中的配置实际执行流量的路由。

它解决的问题

云原生 Web 应用程序由多种服务组成，通常，这些服务需要可通过互联网访问，以便用户使用浏览器进行访问。为了使用户在使用Kubernetes运行此应用程序时可以访问这些服务，我们需要将每个应用程序服务公开给外界。最直接的方法是使用 Kubernetes 负载均衡器服务。创建这样的 Kubernetes 负载均衡器服务会在底层基础设施上产生一个新组件。这不仅引入了新的成本和管理开销，而且每个新创建的负载均衡器都有自己的外部 IP 地址。这会导致糟糕的用户体验，因为作为用户，我们不想浏览不同的 URL 来访问应用程序。

它有什么帮助

Ingress 资源允许您配置如何平衡流量并将其路由到应用程序的服务。入口控制器是一个 Web 服务器，它允许通过 URL ( www.example-url.com ) 实现单个入口点，并根据不同的 URL 路径 ( www.example-url.com/path)进行实际路由和平衡。Ingress 控制器是在集群内运行并解释 Ingress 资源中定义的规则的组件。由运行 Web 应用程序的集群运营商从 Nginx、Traefik、HAProxy 等一组可能的技术中选择特定的 Ingress 控制器。因此，现在，如果应用程序由多个服务组成，用户可以使用以下方式访问它：单个 URL。这消除了基础设施级别上对大量单独负载均衡器的需求，并简化了每个服务的防火墙和负载均衡器规则的配置。通过集中流量路由和处理配置，Ingress 提供简化的可扩展性、优化资源利用率、降低成本并提高集群中运行的应用程序的整体可管理性。

 

Kubernetes，通常缩写为 K8s，是一个开源容器编排器。它自动化了现代基础设施上容器化应用程序的生命周期，充当“数据中心操作系统”，跨分布式系统管理应用程序。

Kubernetes在集群中的节点之间调度容器，捆绑多个基础设施资源（例如负载均衡器、持久存储等）来运行容器化应用程序。

Kubernetes 支持自动化和可扩展性，允许用户以可重复的方式以声明方式部署应用程序（见下文）。Kubernetes 可通过其API进行扩展，允许经验丰富的 Kubernetes 从业者根据自己的需求利用其自动化功能。

它解决的问题

基础设施自动化和声明式配置管理长期以来一直是重要的概念，但随着云计算的普及，它们变得更加紧迫。随着对计算资源的需求增加，组织需要用更少的工程师提供更多的操作能力，需要新技术和工作方法来满足这一需求。

它有什么帮助

与传统的基础设施即代码工具类似，Kubernetes 有助于自动化，但具有使用容器的优势。容器比虚拟机或物理机更能抵抗配置漂移。

此外，Kubernetes 以声明方式工作，这意味着操作员不是指导机器如何做某事，而是描述（通常作为清单文件（例如 YAML））基础设施应该是什么样子。然后，Kubernetes 负责“如何”。这使得 Kubernetes 与基础设施即代码极其兼容。

Kubernetes 还可以自我修复。集群的实际状态将始终与操作员期望的状态匹配。如果 Kubernetes 检测到与清单文件中描述的内容存在偏差，Kubernetes 控制器就会启动并修复它。虽然 Kubernetes 使用的基础设施可能会不断变化，但 Kubernetes 会不断自动适应变化并确保其与所需状态匹配。676

 

松散耦合架构是一种架构风格，其中应用程序的各个组件彼此独立构建（与紧密耦合架构相反的范例）。每个组件（有时称为微服务）都是为了以可由任意数量的其他服务使用的方式执行特定功能而构建的。这种模式的实现速度通常比紧密耦合架构慢，但具有许多优点，特别是随着应用程序的扩展。

松散耦合的应用程序允许团队独立开发功能、部署和扩展，从而使组织能够快速迭代各个组件。应用程序开发速度更快，团队可以围绕他们的能力构建，专注于他们的特定应用程序。

 

微服务架构是一种将应用程序分解为单独的独立（微）服务的架构方法，每个服务专注于特定的功能。这些服务紧密配合，对最终用户来说就像一个实体。以Netflix为例。它的界面允许您访问、搜索和预览视频。这些功能可能由较小的服务提供支持，每个服务处理一种功能，例如身份验证、搜索和在浏览器中运行预览。

这种架构方法使开发人员能够比紧密耦合的新功能或更新功能更快地推出新功能或更新功能，例如在整体应用程序中（更多内容见下文）。

它解决的问题

应用程序由不同的部分组成，每个部分负责特定的功能。对特定功能的需求不一定会随着对其他​​应用程序部分的需求而增加或减少。回到我们的 Netflix 示例。假设在一场大规模的营销活动之后，Netflix 的注册人数大幅上升，但流媒体在当天凌晨基本保持稳定。
注册人数的激增需要更多的注册容量。传统上（单一方法），整个应用程序必须进行扩展以适应增长——资源的利用效率非常低。

单体架构还使开发人员很容易陷入设计陷阱。由于所有代码都位于一处，因此更容易使代码紧密耦合，但更难执行关注点分离原则。单体应用通常还要求开发人员在部署任何更改之前了解整个代码库。微服务架构是对这些挑战的回应。

它有什么帮助

将功能分离到不同的微服务中使它们更容易独立部署、更新和扩展。它还允许不同的团队同时处理较大应用程序的一小部分，而不会无意中对应用程序的其余部分产生负面影响。虽然微服务架构解决了许多问题，但它也产生了运营开销——您需要部署和跟踪的内容按数量级增加。许多云原生技术旨在使微服务更易于部署和管理。

 

单体应用程序包含单个可部署程序中的所有功能。这通常是制作申请时最简单、最容易的起点。然而，一旦应用程序变得越来越复杂，整体架构就会变得难以维护。随着越来越多的开发人员在同一代码库上工作，发生冲突的更改的可能性以及开发人员之间的人际沟通需求也会增加。

它解决的问题
将应用程序转移到微服务会增加其运营开销 - 有更多的东西需要测试、部署和保持运行。在产品生命周期的早期，推迟这种复杂性并构建整体应用程序直到确定产品成功可能是有利的。

它有什么帮助
精心设计的整体架构可以通过最简单的方式启动和运行应用程序来维护精益原则。当单体应用程序的业务价值被证明是成功的时，就可以将其分解为微服务。在证明其价值之前构建基于微服务的应用程序可能会过早地花费工程精力。如果应用程序没有产生任何价值，那么这些努力就被浪费了。

 

多租户（或多租户）是指为多个租户提供服务的单个软件安装。租户是一个用户、应用程序或一组利用软件在自己的数据集上运行的用户/应用程序。这些租户不共享数据（除非业主明确指示），甚至可能不知道彼此。

租户可以小到一个具有单一登录 ID 的独立用户（例如个人生产力软件），也可以大到拥有数千个登录 ID 的整个公司，每个登录 ID 都有自己的权限，但以多种方式相互关联。多租户软件示例包括 Google Mail、Google Docs、Microsoft Office 365、Salesforce CRM 和 Dropbox，以及更多被归类为完全或部分多租户软件的软件。

它解决的问题

如果没有多租户，每个租户都需要安装专用的软件。这增加了资源利用率和维护工作，最终增加了软件成本。

它有什么帮助

多租户软件为每个租户提供一个隔离的环境（工作数据、设置、凭据列表等），同时为多个租户提供服务。从租户的角度来看，每个租户都有其专用的软件安装，尽管实际上它们都共享一个。这是通过在服务器上运行软件并允许租户通过接口和/或API （另请参阅客户端-服务器架构）通过网络连接到该软件来实现的。使用多租户软件，租户可以共享一个安装的资源，而不会相互影响，或者仅以预定义和受控的方式共享。软件提供商方面节省的资源可以转移给租户，从而显着降低用户的软件成本（再次考虑基于网络的电子邮件或文档编辑器）。

PaaS概念就是基于多租户的，比如我在一个后台管理网站上配置了一个单位下的所有部门，他们是相互可见的，但有新的单位需要使用该软件时，增加租户即可，无需重新在部署一套软件

 

相互 TLS (mTLS) 是一种用于对两个服务之间发送的消息进行身份验证和加密的技术。相互 TLS 是标准传输层安全(TLS) 协议，但不是仅验证一个连接的身份，而是验证双方。

它解决的问题
微服务通过网络进行通信，就像您的 WiFi 网络一样，通过该网络传输的通信可能会被黑客攻击。mTLS 确保未经授权的一方无法监听或冒充合法请求。

它有什么帮助
mTLS 确保客户端和服务器之间的双向流量安全且可信，为登录网络或应用程序的用户提供额外的安全层。它还验证与不遵循登录过程的客户端设备（例如物联网 (IoT) 设备）的连接。mTLS 可以防止路径攻击、欺骗攻击、撞库攻击、暴力攻击等攻击。

 

节点是与其他计算机或节点协同工作以完成常见任务的计算机。以您的笔记本电脑、调制解调器和打印机为例。它们都通过您的 WiFi 网络连接进行通信和协作，每个代表一个节点。在云计算中，节点可以是物理计算机、虚拟计算机（称为VM），甚至是容器。

它解决的问题
虽然应用程序可以（而且许多应用程序确实）在一台机器上运行，但这存在一些风险。即底层系统的故障将破坏应用程序。为了解决这个问题，开发人员开始创建分布式应用程序，其中每个进程都在自己的节点上运行。因此，节点作为组的一部分运行应用程序或进程，形成节点集群或组，这些节点一起工作以实现共同目标。

它有什么帮助
节点为您提供了可以分配给集群的独特计算单元（内存、CPU、网络）。在云原生平台或应用程序中，节点代表可以执行工作的单个单元。理想情况下，各个节点是无差别的，因为特定类型的任何一个节点都与相同类型的任何其他节点无法区分。

 

可观察性是一个系统属性，它定义了系统可以生成可操作的见解的程度。它允许用户从这些外部输出了解系统的状态并采取（纠正）措施。

计算机系统是通过观察低级信号（例如CPU时间、内存、磁盘空间）以及更高级别和业务信号（包括API响应时间、错误、每秒事务数等）来测量的。这些可观察的系统是被观察（或监控）的通过专门的工具，即所谓的可观察性工具。可以在云原生景观的可观察性部分查看这些工具的列表。

可观察的系统为其操作员提供有意义的、可操作的数据，使他们能够实现有利的结果（更快的事件响应，提高开发人员的生产力）并减少辛苦和停机时间。

因此，系统的可观察性将显着影响其运营和开发成本。

 

在Kubernetes环境中，Pod 充当最基本的可部署单元。它代表了部署和管理容器化应用程序的重要构建块。每个 Pod 包含一个应用程序实例，并且可以容纳一个或多个容器。Kubernetes 将 Pod 作为更大部署的一部分进行管理，并可以根据需要垂直或水平扩展 Pod。

它解决的问题

虽然容器通常充当运行和控制特定工作负载的独立单元，但在某些情况下，容器需要以紧密耦合的方式进行交互和控制。

如果对这些紧密相关的容器中的每一个进行单独管理，就会导致管理任务冗余。例如，操作员必须重复确定相关容器的放置位置，以确保它们保持在一起。而且这些相关容器的生命周期虽然需要同步，但只能单独管理。

它有什么帮助

Pod 将紧密相连的容器捆绑成一个单元，从而显着简化了容器操作。例如，辅助容器通常与主容器一起使用，以添加附加功能或设置全局配置。示例包括向主容器注入和应用基本设置的容器、 处理主容器的网络流量路由的sidecar （容器）（请参阅服务网格）或与每个容器结合收集日志的容器。

内存和 CPU 分配可以在 Pod 级别上定义，允许内部容器以灵活的方式共享资源，也可以在每个容器上定义。

 

策略即代码是一种将策略定义存储为机器可读和可处理形式的一个或多个文件的做法。这取代了传统模型，其中策略以人类可读的形式记录在单独的文档中。

它解决的问题
构建应用程序和基础设施通常受到组织定义的许多策略的限制，例如禁止在源代码中存储机密、使用超级用户权限运行容器或在特定地理区域之外存储某些数据的安全策略。对于开发人员和审核人员来说，根据记录的策略手动检查应用程序和基础设施是非常耗费人力且容易出错的。手动流程无法满足云原生应用的响应能力和规模要求。

它有什么帮助
通过代码描述策略可以实现可重复性并减少错误（与手动完成不同）。策略即代码的另一个优点是代码可以由版本控制系统（例如 Git）进行管理。Git 创建更改日志历史记录，当某些内容未按预期工作时，该历史记录特别有用。它允许用户确定谁进行了更改并恢复到以前的版本。

 

可移植性是一种软件特性，是一种可重用性形式，有助于避免“锁定”到某些操作环境，例如云提供商、操作系统或供应商。

传统上，软件通常是针对特定环境（例如 AWS 或 Linux）构建的。另一方面，便携式软件可以在不同的操作环境中运行，无需进行重大返工。如果应用程序适应新环境所需的努力在合理的范围内，则该应用程序被认为是可移植的。“移植”一词的意思是修改软件并使其能够在不同的计算机系统上工作。

 

从云原生的角度来看，可靠性是指系统对故障的响应能力。如果我们有一个分布式系统，能够在基础设施发生变化和单个组件发生故障时继续工作，那么它就是可靠的。另一方面，如果它很容易出现故障，并且需要操作人员手动干预以保持其运行，那么它是不可靠的。云原生应用程序的目标是构建本质上可靠的系统。

 

 

基于角色的访问控制 (RBAC) 是一种安全方法，根据用户在团队或大型组织中的角色来管理用户对系统、网络或资源的访问。RBAC 使 IT 管理员能够确定具有特定工作职能的所有用户的必要访问级别，并为这些用户分配具有预定义权限集的角色。组织利用 RBAC 为其员工提供适合其角色和职责的不同级别的访问权限。

它解决的问题

RBAC 解决了控制团队成员和应用程序可以访问的资源以及他们可以执行的操作的挑战，特别是随着应用程序和团队成员数量的增加。管理员必须确保每个用户对其需要访问的资源拥有正确的权限。如果没有结构化的访问控制机制，这项任务可能会变得麻烦且容易出错。

它有什么帮助

RBAC 使 IT 团队能够轻松地同时管理组中所有用户的权限，或通过分配或删除角色来快速调整单个用户的访问级别。这可以保护敏感数据，并确保员工只能访问信息并执行其工作职责所需的操作。总体而言，RBAC 增强了访问管理、增强了安全性并提高了组织内的运营效率。

 

一般来说，运行时执行一个软件。它是底层操作系统的抽象，它将程序的命令转换为操作系统的相应操作。

在云原生的语境中，运行时一般指的是容器运行时。容器运行时专门实现了开放容器计划规范，以确保不同容器编排技术的处理一致。

它解决的问题

如果没有容器运行时的抽象，应用程序将不得不处理每个操作系统的所有机制，从而增加了运行应用程序的复杂性。

它有什么帮助

容器运行时是 Kubernetes 等容器编排器的必要组件。它们处理容器生命周期，主要做三件事。首先，它定义了如何指定容器映像以及运行时如何检索它们。其次，它们处理这些镜像的解包、分层、安装和执行方式。此外，运行时管理硬件资源，负责所有这些操作系统级操作。其中包括资源分配和隔离。
随着时间的推移，不同的容器运行时产品不断发展，最终形成了 OCI 规范，该规范成为容器运行时的标准。

引入此标准允许最终用户将任何符合 OCI 的运行时与任何符合 OCI 的容器编排器（如 Kubernetes）结合起来。

 

可扩展性是指系统可以增长的程度。这就是提高执行系统应该执行的任何操作的能力。例如，Kubernetes 集群通过增加或减少容器化应用程序的数量来进行扩展，但这种可扩展性取决于几个因素。它有多少个节点，每个节点可以处理多少个容器，控制平面可以支持多少记录和操作？

可扩展的系统可以轻松添加更多容量。我们区分两种缩放方法。一方面，水平缩放会添加更多节点来处理增加的负载。相比之下，在垂直扩展中，单个节点变得更强大，可以执行更多事务（例如，通过向单个机器添加更多内存或CPU）。可扩展的系统能够轻松更改并满足用户需求。

 

安全混沌工程（Security Chaos Engineering 或 SCE）是基于混沌工程的一种方法。SCE在分布式系统上进行积极的安全实验，以增强系统抵御动荡和恶意条件的能力，并通过科学方法循环（包括稳态、假设、持续验证、经验教训和缓解实施）来达到这一目的。

解决的问题
站点可靠性工程师（SRE）和网络安全工程师的主要任务是尽快恢复服务，以实现零停机和最小化业务影响的目标。SRE和网络安全工程师既处理故障前的情况，也处理故障后的情况。大多数安全问题很难快速发现和修补，影响应用程序或系统功能。此外，在开发阶段通常难以发现安全事件。

帮助之处
安全混沌工程基于可观察性和网络安全弹性实践。它旨在揭示“未知的未知”，增强系统的信心，提高网络安全弹性并改进可观察性。

工程团队将逐步改进对复杂基础架构、平台和分布式系统中安全问题的理解。SCE提高整个产品的网络安全弹性，揭示隐藏的安全问题，暴露传统的盲点，并使团队为关键边缘案例做好准备。这种方法帮助SRE、DevOps和DevSecOps工程师在系统中建立信心，提高网络安全弹性并改进可观察性。

 

自愈系统能够从某些类型的故障中恢复，无需任何人为干预。它有一个“收敛”或“控制”循环，可以主动查看系统的实际状态并将其与操作员最初期望的状态进行比较。如果存在差异（例如，运行的应用程序实例比期望的少），它将采取纠正措施（例如，启动新实例）。

 

无服务器是一种云原生开发模型，允许开发人员构建和运行应用程序而无需管理服务器。虽然服务器仍然存在于无服务器范例中，但它们是从应用程序开发过程中抽象出来的。云提供商负责配置、维护和扩展服务器基础设施的日常工作。开发者可以方便地将代码打包到容器中进行部署。部署后，无服务器应用程序会响应需求并根据需要自动扩展和缩减。公共云提供商的无服务器产品通常通过事件驱动的执行模型按需计量。因此，当无服务器功能处于空闲状态时，没有相关成本。

它解决的问题

在标准基础设施即服务 (IaaS) 云计算模型下，用户预先购买容量单位，这意味着您需要向公共云提供商支付始终在线的服务器组件来运行您的应用程序。用户有责任在需求高时扩大服务器容量，并在不再需要该容量时缩小服务器容量。即使应用程序未使用，运行应用程序所需的云基础设施仍保持活动状态。

它有什么帮助

与传统方法相比，无服务器架构仅在需要时启动应用程序。当事件触发应用程序代码运行时，公共云提供商会动态地为该代码分配资源。当代码执行完毕后，用户停止付款。除了成本和效率优势之外，无服务器还使开发人员摆脱了与应用程序扩展和服务器配置相关的日常和琐碎任务。通过无服务器，管理操作系统和文件系统、安全补丁、负载平衡、容量管理、扩展、日志记录和监控等日常任务都被卸载到云服务提供商。

 

请注意，在 IT 中，服务具有多重含义。在此定义中，我们将重点关注更传统的定义：微服务中的服务。服务与微服务有何不同或是否不同是微妙的，不同的人可能有不同的看法。对于高级定义，我们将它们视为相同。请参阅微服务定义。

 

服务发现是查找构成服务的各个实例的过程。服务发现工具跟踪组成服务的各个节点或端点。

它解决的问题
云原生架构是动态且流动的，这意味着它们在不断变化。容器化应用程序在其生命周期中可能会多次启动和停止。每次发生这种情况时，它都会有一个新地址，任何想要找到它的应用程序都需要一个工具来提供新的位置信息。

它有什么帮助
服务发现跟踪网络内的应用程序，以便它们可以在需要时找到彼此。它提供了一个查找并可能识别各个服务的公共场所。服务发现引擎是类似数据库的工具，用于存储有关存在哪些服务以及如何找到它们的信息。

 

在微服务世界中，应用程序被分解为多个通过网络进行通信的较小服务。就像您的 WiFi 网络一样，计算机网络本质上不可靠、容易被黑客攻击，而且速度通常很慢。服务网格通过管理服务之间的流量（即通信）并在所有服务中统一添加可靠性、可观察性和安全功能来解决这一系列新的挑战。

它解决的问题

迁移到微服务架构后，工程师现在正在处理数百个甚至可能数千个单独的服务，所有这些服务都需要通信。这意味着大量流量在网络上来回传输。最重要的是，各个应用程序可能需要加密通信以支持监管要求，为运营团队提供通用指标，或提供对流量的详细洞察以帮助诊断问题。如果构建到单独的应用程序中，这些功能中的每一项都会导致团队之间的摩擦并减慢新功能的开发速度。

它有什么帮助

服务网格在集群中的所有服务中统一添加可靠性、可观察性和安全功能，而无需更改代码。在服务网格出现之前，该功能必须编码到每个服务中，从而成为错误和技术债务的潜在来源。

 

 

 

在微服务世界中，应用程序被分解为多个通过网络进行通信的较小服务。就像您的 WiFi 网络一样，计算机网络本质上不可靠、容易被黑客攻击，而且速度通常很慢。服务网格通过管理服务之间的流量（即通信）并在所有服务中统一添加可靠性、可观察性和安全功能来解决这一系列新的挑战。

它解决的问题

迁移到微服务架构后，工程师现在正在处理数百个甚至可能数千个单独的服务，所有这些服务都需要通信。这意味着大量流量在网络上来回传输。最重要的是，各个应用程序可能需要加密通信以支持监管要求，为运营团队提供通用指标，或提供对流量的详细洞察以帮助诊断问题。如果构建到单独的应用程序中，这些功能中的每一项都会导致团队之间的摩擦并减慢新功能的开发速度。

它有什么帮助

服务网格在集群中的所有服务中统一添加可靠性、可观察性和安全功能，而无需更改代码。在服务网格出现之前，该功能必须编码到每个服务中，从而成为错误和技术债务的潜在来源。

 

 

 

Shift Left 中的 Left 指的是软件开发生命周期的早期阶段，将生命周期视为从左到右执行阶段的一条线。左移是在软件开发生命周期的早期而不是最后实施测试、安全或其他开发实践的做法。

虽然最初用于指早期测试的过程，但 Shift Left 现在也可以应用于软件开发和DevOps的其他方面，例如安全性和部署。

它解决的问题

如果在开发周期后期或部署后发现安全问题、错误和软件缺陷，特别是当软件已经部署到生产中时，修复起来可能会更加困难和昂贵。

它有什么帮助

通过采用左移思维进行软件开发，团队可以在整个开发生命周期中实施测试和安全性。由于测试和安全的责任由整个开发团队共同承担——从软件工程师到质量保证再到运营——每个人都在确保应用程序的稳定性和安全性方面发挥着作用。

此外，左移可以实现持续改进，并遵循敏捷而非瀑布式的开发方法。团队可以进行小的迭代改进并尽早发现问题。这种方法允许工程师早在设计和架构阶段就采用安全和安全开发实践。在整个开发周期中进行测试可以减少软件发布前测试所需的时间。

许多软件工具和 SaaS 解决方案有助于改变这些做法。然而，左移也可以通过团队内改进流程和文化变革来实施。

 

服务代理拦截发送到给定服务或来自该服务的流量，对其应用一些逻辑，然后将该流量转发到另一个服务。它实质上充当一个“中间人”，收集有关网络流量的信息并/或对其应用规则。

解决的问题
为了跟踪服务之间的通信（即网络流量）并可能对其进行转换或重定向，我们需要收集数据。传统上，启用数据收集和网络流量管理的代码嵌入在每个应用程序中。

它如何帮助
服务代理允许我们“外部化”此功能。它不再需要存在于应用程序内，而是现在嵌入到平台层（您的应用程序运行的地方）。

作为服务之间的守门员，代理提供了有关正在发生的通信类型的见解。基于它们的见解，它们确定要将特定请求发送到何处，甚至可能完全拒绝该请求。

代理收集关键数据，管理路由（在服务之间均匀分配流量或在某些服务故障时重新路由），加密连接，并缓存内容（减少资源消耗）

 

站点可靠性工程或 SRE 是一门结合了运营和软件工程的学科。后者特别适用于基础设施和运营问题。这意味着，站点可靠性工程师不是构建产品功能，而是构建系统来运行应用程序。与DevOps有相似之处，但 DevOps 专注于将代码投入生产，而 SRE 可确保生产中运行的代码正常工作。

它解决的问题
确保应用程序可靠运行需要多种功能，从性能监控、警报、调试到故障排除。如果没有这些，系统操作员只能对问题做出反应，而不是主动努力避免问题——停机只是时间问题。

它有什么帮助
SRE 方法通过不断改进底层系统，最大限度地减少软件开发过程的成本、时间和精力。该系统持续测量和监控基础设施和应用程序组件。当出现问题时，系统会向站点可靠性工程师指示何时、何地以及如何修复它。这种方法有助于通过自动化操作任务来创建高度可扩展且可靠的软件系统。

 

当我们谈到有状态（和无状态）应用程序时，状态是指应用程序需要存储才能按设计运行的任何数据。例如，任何记住您的购物车的在线商店都是有状态的应用程序。

如今，我们使用的大多数应用程序至少部分是有状态的。但在云原生环境中，有状态应用程序是一个挑战。这是因为云原生应用程序非常动态。它们可以放大和缩小、重新启动和移动，但仍然需要能够访问它们的状态。

因此，有状态应用程序需要某种可从任何地方访问的存储，例如数据库。

 

无状态应用程序处理请求就好像每个请求都是第一次发送的请求一样。该应用程序不会“记住”以前的交互或用户会话数据。来自先前交互的数据被称为状态，并且由于该数据不存储在任何地方，因此这些应用程序是无状态的。下面是一个示例：当您使用搜索引擎时，如果搜索中断（例如，窗口关闭），这些搜索结果就会丢失。你需要从头开始。

另一方面，在考虑先前交互的同时处理请求的应用程序称为有状态应用程序。

 

紧耦合架构是一种架构风格，其中许多应用程序组件是相互依赖的（与松散耦合架构相反的范例）。这意味着一个组件的更改可能会影响其他组件。它通常比松散耦合的架构风格更容易实现，但可能会使系统更容易遭受级联故障。它们还往往需要协调地推出组件，这可能会拖累开发人员的生产力。

紧耦合的应用程序架构是一种相当传统的应用程序构建方式。虽然不一定与微服务开发的所有最佳实践一致，但它们在特定情况下可能很有用。它们往往实现起来更快、更简单，并且与整体应用程序非常相似，它们可以加快初始开发周期。

 

传输层安全 (TLS) 是一种旨在提高网络通信安全性的协议。它确保通过互联网发送的数据的安全传输，避免可能的数据监控和/或更改。该协议广泛应用于消息传递、电子邮件等应用中。

它解决的问题
如果没有 TLS，浏览习惯、电子邮件通信、在线聊天和电话会议等敏感信息在传输过程中很容易被他人追踪和修改。使服务器和客户端应用程序支持 TLS 可确保它们之间传输的数据经过加密且第三方无法查看。

它有什么帮助
TLS 使用编码技术的组合，在通过网络传输数据时提供安全性。TLS 允许客户端应用程序和服务器（例如 Web 浏览器和银行站点）之间的加密连接。它还允许客户端应用程序主动识别它们正在调用的服务器，从而降低客户端与欺诈站点通信的风险。这可确保第三方无法查看和监控使用 TLS 的应用程序之间传输的数据，从而保护信用卡号、密码、位置等敏感和私人信息。

 

垂直扩展，也称为“向上和向下扩展”，是一种通过随着工作负载的增加向各个节点添加 CPU 和内存来增加系统容量的技术。假设您有一台 4GB RAM 的计算机，想要将其容量增加到 16GB RAM，垂直扩展意味着切换到 16GB RAM 系统。（请参阅水平缩放以了解不同的缩放方法。）

它解决的问题
随着应用程序的需求增长超出该应用程序实例的当前容量，我们需要找到一种方法来扩展系统（增加容量）。我们可以向现有节点添加更多计算资源（垂直扩展），也可以向系统添加更多节点（水平扩展）。 可扩展性有助于提高竞争力、效率、声誉和质量。

它有什么帮助
垂直缩放允许您在不更改应用程序代码的情况下调整服务器的大小。这与水平扩展形成鲜明对比，水平扩展中应用程序必须可复制才能扩展，可能需要代码更新。垂直扩展通过添加计算资源来增加现有应用程序的容量，从而允许应用程序处理更多请求并同时执行更多工作

 

虚拟机 (VM) 是不绑定到特定硬件的计算机及其操作系统。虚拟机依靠虚拟化将一台物理计算机分割成多台虚拟计算机。这种分离使组织和基础设施提供商能够轻松创建和销毁虚拟机，而不会影响底层硬件。

它解决的问题

当裸机机器绑定到单一操作系统时，机器资源的利用程度会受到一定程度的限制。此外，当操作系统绑定到单个物理机时，其可用性直接与该硬件相关。如果物理机由于维护或硬件故障而离线，操作系统也会离线。

它有什么帮助

通过消除操作系统和单个物理机之间的直接关系，您可以解决裸机机的几个问题：配置时间、硬件利用率和弹性。

由于无需购买、安装或配置新硬件来支持它，因此新计算机的配置时间显着缩短。通过将多个虚拟机放置在一台物理机上，虚拟机允许您更好地使用现有的物理硬件资源。虚拟机不受特定物理机的束缚，也比物理机更具弹性。当物理机需要离线时，可以将其上运行的虚拟机移至另一台机器，几乎不需要停机时间

 

在云原生计算的背景下，虚拟化是指使用物理计算机（有时称为服务器）并允许其运行多个独立操作系统的过程。这些独立的操作系统及其专用计算资源（CPU、内存和网络）称为虚拟机或 VM。当我们谈论虚拟机时，我们谈论的是软件定义的计算机。外观和行为类似于真实计算机但与其他虚拟机共享硬件的东西。 云计算主要由虚拟化技术提供支持。例如，您可以从 AWS 租用一台“计算机”——该计算机实际上是一台虚拟机。

它解决的问题
虚拟化解决了许多问题，包括通过允许更多应用程序在同一台物理机上运行，​​同时为了安全而相互隔离来提高物理硬件的使用率。

它有什么帮助
在虚拟机上运行的应用程序并不知道它们正在共享物理计算机。虚拟化还允许数据中心的用户在几分钟内启动一台新的“计算机”（也称为虚拟机），而无需担心向数据中心添加新计算机的物理限制。

 

零信任架构规定了一种完全消除信任的 IT 系统设计和实施方法。核心原则是“永不信任，始终验证”，设备或系统本身在与系统的其他组件通信时，始终在这样做之前验证自己。在当今的许多网络中，在企业网络内，内部的系统和设备可以自由地相互通信，因为它们位于企业网络周边的可信边界内。零信任架构采用相反的方法，尽管在网络边界内，但系统内的组件在进行任何通信之前首先必须通过验证。

它解决的问题

在传统的基于信任的方法中，系统和设备存在于企业网络边界内，假设因为存在信任，所以就不存在问题。然而，零信任架构认识到信任是一个漏洞。如果攻击者获得了对受信任设备的访问权限，根据对该设备的信任和访问级别，系统现在很容易受到攻击，因为攻击者位于“受信任”网络边界内，并且能够在整个系统中横向移动。在零信任架构中，信任被消除，因此减少了攻击面，因为攻击者现在被迫在进一步遍历整个系统之前进行验证。

它有什么帮助

采用零信任架构的主要好处是提高安全性并减少攻击面。现在，从公司系统中删除信任会增加安全门的数量和强度，攻击者必须通过这些安全门才能访问系统的其他区域。