云原生_数字企业的云原生架构

图1说明了CNCF提供的云原生参考架构。每层都有自己的专用云原生软件堆栈，其中许多由CNCF控制。

基础设施层

基础结构层代表实际的计算资源。这些计算资源可以通过使用一组在本地数据中心联网的裸机来组成。如果数字企业已经在基于虚拟机管理程序的虚拟化技术（例如VMware，OpenStack和CloudStack）的支持下运行了私有云，则可以通过使用一组在同一虚拟网络中连接并工作的虚拟机来组成基础架构层。企业也可以使用由Google，Microsoft和Amazon等公共云提供商提供的虚拟基础架构。或者可以通过组合私有云和公共云计算资源来成为混合云。

供应层

供应层涵盖了主机管理活动，例如安装和设置操作系统。它具有一组DevOps（维护）和管理（软件更新，安全补丁等）活动。像CoreOS和RancherOS这样的操作系统是运行容器化环境的专用主机操作系统。

运行时层

运行时层主要由容器运行时组成。容器运行时接口（CRI）允许插入不同的容器时间实现。Docker是广泛使用的容器运行时、可以使用CRI-O（与开放容器倡议兼容的运行时）或rkt容器运行时，也可以在CRI支持下插入基于虚拟机监控程序的容器运行时（例如Frakti）。

容器网络接口（CNI）使API可以插入不同的容器网络运行时实现。CNI带有内置网络插件，例如BRIDGE，VLAN，IPVLAN，DHCP，LookBack等。此外，它还允许来自第三方来源（例如Weave，Calco，Cilium，Flannel，WMWare和NSX）的容器网络插件。所有网络运行时都实现CNI的规范。

图2-容器网络接口（CNI）

Docker不实现CNI，它具有自己的实现，称为容器网络模型（CNM），它仅可与Docker容器运行时一起使用。

容器存储接口（CSI）提供了将容器编排平台连接到持久存储插件的通用标准。借助CSI，存储供应商可以编写符合单个规范的插件，并且可以在许多业务流程平台上使用。CSI的主要功能是动态配置和停用卷，从主机节点进行卷的连接和分离以及从主机节点进行卷的安装和卸载。

编排与管理层

容器编排器可帮助管理跨多个容器主机的大量容器化应用程序部署。Cloud Foundry，Mesos，Nomad和Kubernetes是在云原生空间中使用的流行容器编排器。容器调度，配置，启动和发现；系统监视，跟踪和崩溃恢复；声明式系统配置；路由，负载平衡和策略实施是这些编排器管理的一些常用功能。

这些基本编排器可用于创建更高级别的编排器，例如服务网格和无服务器平台。Istio，Linkerd和OpenPaaS是在Kubernetes编排器之上创建的一些服务网格平台。

应用定义/部署层

应用程序定义层定义应用程序组成，特定于应用程序的配置，部署属性，映像存储库，连续集成/连续交付等。云原生应用程序开发人员主要参与该层的功能。

云原生数字企业的参考架构

云原生应用程序都是关于动态性的。微服务架构（MSA）对于实现敏捷性至关重要。为了获得MSA的好处（例如，更快地开发，测试和部署，并且更容易理解和维护），这些微服务需要与不同的SaaS端点，旧版应用程序和其他微服务集成，以执行定义的业务功能。为了符合业务需求，需要组合和集成多个微服务，并将它们公开为业务API。这些API应该得到保护，管理，观察和货币化。API主导的集成平台与云原生技术相结合对于数字企业至关重要。

图3-云原生数字企业的参考架构

基础设施

该层表示与我们在云原生参考架构中讨论的功能相同的功能。容器编排平台/作为服务平台

该层还表示与我们在云原生参考架构中讨论的功能相同的功能。Cloud Foundry，Mesos，Nomad，Kubernetes，Istio，Linkerd和OpenPaaS是当前行业领先的容器编排平台的一些示例。Knative，AWS Lambda，Azure函数，Google函数，Oracle函数是作为服务平台（FaaS）的函数的一些示例。

微服务和无服务器组件

将一个复杂的问题分解为一组较小的问题将更易于解决问题，并且在开发，测试，部署，扩展和更新过程中也更加容易。这个较小的问题可以实现为微服务或无服务器功能。每个微服务或无服务器功能都是由较小的团队开发的，可以自由选择合适的技术。数字企业可以拥有内部或云编排平台来部署这些基于MSA的应用程序。一些云提供商在这些编排平台之上提供PaaS，企业可以按需付费模式使用它们。如果企业使用无服务器功能，则建议使用由知名云提供商提供的FaaS平台。云锁定可能是使用FaaS平台的不利因素，但它可能取决于您企业的策略。

集装箱镜像

“十二要素应用程序”定义了一种开发和部署可伸缩应用程序的方法，其中许多非常适合MSA。

定义和实现微服务后，应将它们与所有依赖项捆绑在一起，并作为容器映像运送。特定于环境的配置应在外部定义，并在运行时注入到容器中。这些容器映像应存储在注册表中，其他开发人员以及运行时环境都可以在其中注册并从这些映像中创建容器。

图4-容器映像创建

将应用程序作为容器镜像进行运输的主要好处之一是通用包装模型，该模型得到所有云提供商的支持，并且具有不变性。一旦构建了容器镜像，就可以确保在创建容器"运行时"时满足所有必需的依赖关系。它有助于维护从开发人员机器到生产服务器的一致性。每个发行版都应创建具有正确版本控制的新容器映像。这些版本可以用作容器镜像标签。

容器运行时

图5-容器（运行时）

除了容器镜像随附的所有应用程序依赖性之外，容器运行时还需要与某些特定于环境的属性（例如配置，证书和凭据）相关联。这些属性可以在开发人员，测试和生产环境中更改。因此，这些属性不应烧入容器镜像中，而应与容器运行时关联。

图6-与容器的配置，凭证和证书关联

可扩展性，负载均衡和服务发现

与基于虚拟机管理程序的虚拟机实例相比，容器运行时的开销最小。由于容器属性和MSA最佳实践的结合，这些容器可以非常快速地扩展。向外扩展时，应使用适当的负载均衡器控制将入口流量路由到每个容器。每个应用程序都应具有通过适当的负载均衡器绑定到服务名称。

图7-扩展，负载平衡和服务名称解析

健康检查和自动修复

业务流程平台的一个重要功能是对每个容器进行运行状况探针检查，并在出现问题时能够自动修复。可以在容器生命周期的多个级别中进行运行状况检查。

容器启动时，某些应用程序需要执行一些初始化任务。容器编排平台应该能够监视这些初始化任务的进度，并在接受任何工作负载之前通告任务已经成功的完成。这些类型的运行状况检查探针称为启动探针。

容器启动后，容器协调器将进行运行状况检查，以确认应用程序已准备好接受工作负载，然后通知负载均衡器将传入流量路由到容器。在某些情况下，由于某些临时负载高峰，正在运行的应用程序可能会变得不健康。在这种情况下，协调器可以从运行状况检查探针检测到应用程序的运行状况，并通知负载均衡器跳过进一步的流量路由。这有助于恢复受影响的容器。当它恢复时，再通过负载均衡器打开流量路由。

有时，应用程序可能无法从不正常的情况中完全恢复，或者可能出现致命错误。在这种情况下，协调器应该能够通过运行状况检查探针来识别情况，并用新的容器替换错误的容器。这些健康检查探针称为活动探针。

图8-容器运行状况检查探针

自动缩放

自动缩放是完成可扩展架构的关键功能。部署为容器的单个微服务应能够根据负载峰值来扩容和缩容。运行不必要的容器会浪费计算资源，并且容器数量少会导致服务停机。

容器协调器可以监视这些负载峰值，并能够删除不必要的容器或添加其他容器以执行扩容和缩容操作。CPU使用率，内存使用率和运行中请求计数（负载均衡器路由队列）是众所周知的负载峰值监视因素，可帮助计算扩容和缩容决策。一些协调器使用高级自动缩放算法，该算法可以预测将来的负载峰值并尽早进行扩展以避免服务中断。

图9-自动缩放

部署和回滚

MSA经常发布版本，并且这些版本需要无缝地投入生产。众所周知，即使我们进行了彻底的测试，有时由于某些后来发现的错误，我们仍需要回滚到稳定状态。为了减轻这种情况，我们应该有不同的部署策略。以下部署策略有助于使部署和回滚的停机时间为零。

滚动部署

Ramped（也称为滚动更新）是可以在零停机时间内实现的最简单的部署策略。在此，通过一个接一个地替换容器直到推出所有容器来实现新版本（例如，下图版本2）。

图10-强化的部署策略

蓝绿部署

蓝色/绿色部署策略使用完全相同数量的容器来部署版本2（绿色）和版本1（蓝色）。经过一段时间运行测试后，新版本流量在负载均衡器级别从版本1切换到版本2。

图11-蓝色/绿色部署策略

金丝雀部署

金丝雀部署会逐渐将生产流量从版本1转移到版本2。最初，一小部分流量会路由到新版本。当缺乏测试或对新版本的稳定性缺乏信心时，通常使用Canary。

图12-Canary部署策略

A / B测试

A / B测试部署会在特定条件下将一部分用户路由到新版本（功能）。此部署策略用于测试给定功能的转换，仅推出转换最多的版本。

图13-A / B测试部署策略

影子部署

Shadow部署策略可以同时运行版本1和2，并分叉版本1的传入请求，并将它们也发送到版本2，而不会影响生产流量。这是一个相当复杂的部署策略，主要用于测试新功能上的生产负载。当达到所需的稳定性和性能时，可以推出该应用程序的新版本。

图14-影子部署策略

组成/整合/政策执行

微服务是细粒度的，并且被开发为较小的逻辑组件，以使系统更加敏捷和可扩展。并非从最终用户的角度设计微服务，在这种情况下，用户确实需要根据业务需求访问系统。要将系统功能公开为业务API，这些微服务需要与不同的SaaS端点，旧版应用程序和其他微服务集成，以执行定义的业务功能。

每个企业已经有某种系统。引入新的业务功能时，有必要与这些旧系统集成。这些集成通常由企业服务总线（ESB）功能支持，例如路由，转换，业务流程，聚合和弹性模式。

但是，总的来说，ESB是一个整体系统，与MSA不太匹配。另外，在MSA中，可以通过使用集成微服务来实现集成。这些集成微服务可以具有代码库实现方法或配置驱动的方法。注重集成的特定编程语言和框架通过提供必要的抽象和库，有助于基于代码的方法。对于配置方法，可以使用现代的对微服务友好的轻量级ESB运行时，称为微集成器。

微服务将API公开给其他微服务使用，以完成给定的业务功能。这些单独的微服务需要聚合以满足用户需求。可以在另一个微服务中完成此聚合，以向消费者公开有意义的API。这些API应该得到保护，管理，观察和货币化。这需要具有策略执行力的治理模型。这是API网关很重要的地方。

API网关

API网关可用作API治理的策略实施点，同时与控制和管理平面组件（例如生命周期管理，流量控制，策略控制以及身份和访问管理）同步工作。以下是API网关的主要功能；

身份验证和安全性

尽管微服务主要关注业务逻辑，但是身份验证和安全性也可以在服务级别上实现。但是它会重复功能并增加可维护性问题。MSA的一个主要优点是对服务实现的异构语言支持。API网关跨所有微服务强制执行标准身份验证和安全性。

API速率限制

负载处理能力因微服务而异。一些微服务超载可能会导致应用程序无响应，并且很难从这种情况中恢复。API网关仅允许可以在每个微服务中处理的请求，并且它控制超出限制的请求。

动态API发现和路由

应用程序经历了一系列不同的生命周期阶段。这些生命周期可能因企业而异。开发，测试，登台和生产是常见的生命周期阶段。这些有时称为环境。在开发阶段，开发人员需要发现其他微服务以进行相互通信。除了可发现性之外，这些相互通信的链接应该在不同的环境中工作，而无需进行任何更改。动态发现和动态路由应该是API网关中的关键功能。

API负载平衡和故障转移

为了使微服务高度可用或可扩展，我们需要在部署中运行两个或多个相同的微服务。在这种情况下，API网关可以处理负载平衡或故障转移功能。

API调整

API网关可以根据API使用者的性质优化API响应。例如，如果API使用者是移动设备，那么与Web使用者相比，我们可以精简响应的某些内容以优化带宽使用。

API组成

尤其是当我们向外部方公开API时，我们可能需要聚合多个微服务响应并创建单个复合API响应。API网关在这些类型的边缘组合中起着重要作用。

API中介和转换

相同的微服务可能需要支持新的微服务消费者以及旧有消费者。在这种情况下，API网关中的中介和消息转换非常有用。

响应缓存

在某些情况下，响应缓存可能会很方便，而不是期望后端处理每个请求。API网关在这种要求中非常有用。

API网关部署模式

与MSA保持一致，可以通过三种主要的API网关部署模式来实现API治理。

• 集中/共享的API网关




• 私有Jet API网关




• Sidecar API网关

  
  

集中/共享网关

集中式API网关是一种完善的流行部署模式。API网关的共享群集处理所有API请求。这些请求可以是内部和外部API调用。API网关集群可以水平扩展，并且负载分布在所有API网关容器中。

图15-集中式/共享API网关

在此部署中，API网关在微服务间通信中添加了一个额外的跃点。同一网关集群可用于管理外部API和内部API，或者可具有专用的API网关层来管理外部流量。

私有Jet 网关

在这种模式下，每个单独的微服务都有一个专用的API网关。这提供了最大的安全性，并保证了API执行的资源分配。可以将单个私人喷气机API网关连接到相同类型的微服务集群。负载平衡，故障转移功能将是必需的，并且自然适合这种情况。

图16-Private Jet API网关

私人jet API网关本身可以独立扩展。与集中式API网关类似，此模式还增加了微服务间通信中的一个网络跃点。

Sidecar网关

Hetrogeneos服务是MSA的主要优势之一。可以根据好处以不同的语言实现微服务。API网关可以作为辅助工具连接到微服务，然后可以从API网关的所有功能中受益。

图17-Sidecar API网关

Sidecar模式减少了集中式和私有Jet 网关模式中所需的其他外部网络跃点，同时使本地网络呼叫进行通信。

Sidecar在服务网格架构模式中大量使用。将所有服务之间的通信事务（例如发现，可靠的交付，路由，故障转移，负载平衡等）嵌入mesh sidecar中，将使开发人员可以自由地专注于业务功能。

您可以在需要使用服务网格体系结构的时间和位置使用sidecar API网关模式。

多合一网关

图18-网关融合

技术正在发展，所有类型的网关（例如API网关，入口网关，服务网格网关和微集成器）都合并为一个单一的多合一网关。

但是，即使这些网关合并为一个网关概念，根据使用情况和要求，在某些情况下，最好还是使用多个网关来拥有干净且可伸缩的体系结构。

控制和管理平面

API网关是策略执行的拦截点，可捕获统计信息，指标并进行分析以了解API的行为方式。在当今的数字经济中，管理这些API是必不可少的。控制和管理平面应提供API管理功能。

设计与生命周期管理

API设计是软件开发生命周期（SDLC）中非常重要的阶段。设计阶段有助于在实施之前（API优先设计）收集开发人员反馈。OpenAPI（Swagger）是定义API设计的通用行业标准。部署原型API，提供对API的早期访问，创建模拟API实现并获得早期反馈是设计和生命周期管理所提供的一些功能。

控制访问并加强安全性

通过API公开业务功能时，安全性至关重要。这不仅涉及身份验证和授权，还涵盖了保护攻击，敏感数据泄漏，撤消入侵API，由于未付款而阻止订阅，威胁防护，漫游器检测，令牌欺诈检测等的策略。可以通过使用来保护API OAuth2.0，OIDC，基本身份验证，API密钥和相互TLS。控制和管理平面可用于定义这些安全策略。

管理和扩展API流量

API管理使用户可以控制到后端业务服务的流量。API配额和峰值抑制功能有助于保护后端系统免于受到适当的限制和管理。控制和管理平面应该能够定义这些策略，并通过API网关在数据计划中实施它们。

可观察性

与整体架构不同，审计和跟踪在诸如MSA之类的分散式架构中是难题。拥有必要的拦截器来收集指标，统计信息和数据至关重要。控制和管理平面应具有功能强大的分析工具和引擎，以分析这些收集的指标，统计信息和数据，以生成商业智能报告。通过将这些报告与已定义的业务计划结合起来，可以利用它们来通过业务功能获利。

开发者门户

在外部可访问的自助服务开发人员门户中列出这些API也很重要，在该门户中，应用程序开发人员或API用户可以轻松发现这些API并将它们与定义明确的业务计划一起使用。开发人员的经验是采用和成功使用API的关键，拥有反馈机制（例如客户评分和论坛）对于开发人员门户至关重要。

业务洞察报告

要成为成功的数字企业，重要的是收集数据，分析这些API的行为并获得有意义的业务见解。全面的可观察性和业务洞察力报告系统在这里起着重要作用。这些仪表板和报告可供业务和运营负责人使用，以获取其数字业务的360度视图。

GitOps

持续集成和持续部署对于实现敏捷性至关重要。GitOps是一种向云原生应用程序实施持续部署的方法。它结合了Git和连续部署工具的功能，并在操作基础架构时提供了以开发人员为中心的体验。

Git存储库保留给定环境（开发，测试，阶段，产品等）中基础结构的所有声明式部署描述，并且连续部署工具使该过程自动化以使环境与存储库中描述的状态匹配。在不幸的事件中，可以通过参考Git修订版很容易回滚到工作状态。

在GitOps中，通常，您可以有两个Git存储库，一个用于保存应用程序代码修订，另一个用于跟踪部署的声明性描述。

图19-GitOps

通过为应用程序源代码推送事件配置Git触发器，构建管道可以根据应用程序需求启动已配置的管道步骤。第一步可能是构建并推送相关的容器图像。另一个步骤可能是创建声明性部署描述符，然后提交并推送到单独的部署Git存储库。

如果您有许多部署环境，那么每个环境都可以有单独的Git分支。在完成环境测试之后，我们可以通过合并到相关的Git分支来升级到更高的环境（例如，从stage到prod）。在这种模式下，如果要部署新应用程序或更新现有应用程序，则只需要更新存储库即可；自动化过程将处理其他所有问题。

结论

数字企业通过数字化转型过程中整个价值链的数字化，使各个行业的公司能够将其业务能力作为API进行集成和公开。这些API应该得到保护，管理，观察和货币化。由API主导的集成平台对于数字企业无论是从新开始还是现有应用开始都是必不可少的。

云原生应用程序都是关于动态性的。微服务架构（MSA）对于实现敏捷性至关重要。容器和业务流程平台等云原生技术对于成功实现微服务和部署至关重要。API网关通过执行在控制和管理平面中定义的策略来发挥关键作用。

自助服务开发人员门户对于构建有效的API生态系统很重要。仪表板和报告可帮助业务和运营获得其数字业务的360度视图。

将云原生技术与API主导的集成平台相结合，可以为数字企业提供有效的架构，从而通过拥有自动化，生产或运营以及服务来提高生产力。

参考链接：

1. https://github.com/wso2/reference-architecture/blob/master/reference-cloud-native-architecture-digital-enterprise.md




2. https://thenewstack.io/deployment-strategies/




3. https://medium.com/@lakwarus/micro-api-gateway-58cce43f2d7d




4. https://12factor.net/




5. https://www.gitops.tech/




6. https://www.infoq.com/articles/cloud-native-architecture/