定义云原生Word下载.docx
《定义云原生Word下载.docx》由会员分享，可在线阅读，更多相关《定义云原生Word下载.docx（18页珍藏版）》请在冰豆网上搜索。
经验
Netflix公司
拥有600多种生产服务。
每天部署一百次。
优步
拥有1,000多种生产服务。
每周部署数千次。
微信
在生产中有3,000多种服务。
每天部署1,000次。
如表格所示，Netflix，Uber和微信构建了由数百个独立微服务组成的系统。
这种架构风格使他们能够快速响应市场状况。
他们可以实时更新复杂应用程序中的一个小模块，并根据需要分别缩放这些小模块。
云原生的速度和敏捷性来自多种因素。
最重要的是云基础架构。
图1-3中显示的五个基础支柱为云原生系统提供了支撑。
图1-3云原生基础支撑
云
云原生系统充分利用了云服务模型。
这些系统旨在动态，虚拟化的云环境中蓬勃发展，广泛使用了平台即服务（PaaS）计算基础架构和托管服务。
他们将基础架构视为可以自由地进行只需几分钟即可配置，并通过自动化按需调整大小，缩放，移动或销毁。
在传统的数据中心中，服务被视为Pets：
一台物理机，具有有意义的名称，并且需要维护。
您可以通过向同一台计算机添加更多资源来进行扩展（向上扩展）。
如果服务器故障，则可以将其恢复健康。
如果服务器不可用，那么所有用户都会受到影响。
Cattle的服务模式是不同的。
您将每个实例配置为虚拟机或容器。
它们是相同的，并分配了系统标识符，例如Service-01，Service-02等。
您可以通过创建更多相同的实例来进行扩展。
当一个实例不可用时，用户也不会受到影响。
Cattle模型包含了不可变基础设施。
服务不能修复或修改。
如果服务失败或需要更新，则将其销毁并置备新的服务-所有这些都通过自动化完成。
云原生系统采用Cattle服务模型。
服务会随着基础设施的伸缩而继续运行，而不需要关心运行服务的计算机设备。
Azure云平台通过自动伸缩、自我修复和监控功能支持这种高度弹性的基础设施。
现代设计的一些问题
您将如何设计云原生应用程序？
您的架构是什么样的？
您将遵循哪些原则，模式和最佳实践？
哪些基础架构和运营问题很重要？
十二要素应用
十二要素应用程序是构建基于云的应用程序的一种广泛接受的方法。
它描述了开发人员遵循的一组原则和实践，便于构建针对现代云环境优化的应用程序。
特别注意跨环境和声明式自动化的可移植性。
十二要素尽管适用于基于Web的应用程序，但许多从业人员都将“十二要素”视为构建云原生应用程序的坚实基础。
基于这些原则构建的系统可以快速部署和扩展、添加功能，以对市场变化做出快速反应。
下表重点介绍了“十二要素”方法：
要素
说明
1
代码库
每个微服务的单个代码库，存储在其自己的存储库中。
通过版本控制进行跟踪，它可以部署到多个环境（测试、生产）。
2
依懒关系
每个微服务都隔离并打包自己的依赖项，在不影响整个系统的情况下进行更改。
3
配置
配置信息从微服务中移出，并通过代码外部的配置管理工具进行外部化。
使用正确的配置，相同的部署可以跨环境传播。
4
后端服务
辅助资源（数据存储，缓存，消息代理）应通过可寻址的URL公开。
这样做会将资源与应用程序解耦，从可以进行替换。
5
构建，发布，运行
每个发行版本都必须在构建、发布和运行阶段之间严格分离。
每个版本都应标有唯一的ID，并支持回滚功能。
6
进程
每个微服务都应在与其他正在运行的服务隔离并在自己进程中执行。
将所需状态外部化到后端服务，例如分布式缓存或数据存储。
7
端口绑定
每个微服务都应该是独立的，其接口和功能应在其自己的端口上公开。
这样做可以与其他微服务隔离。
8
并发
服务可以通过大量小的相同进程（副本）进行扩展，而不是在可用的功能最强大的计算机上扩展单体大型实例。
9
可处置性
服务实例应该是可处置的，以便于快速启动进行横向扩展，并支持关闭服务实例，系统仍然保持正确状态。
Docker容器与协调器本质上包含了这一要求。
10
开发/生产环境相同性
保持整个应用程序生命周期中的各个环境尽可能相似，避免走捷径。
在这里，容器的采用在促进相同的执行环境方面做出了巨大贡献。
11
日志
将微服务生成的日志视为事件流。
使用事件聚合器对其进行处理，并将数据传播到数据挖掘/日志管理工具，例如AzureMonitor或Splunk，并最终进行长期归档。
12
管理流程
将管理任务作为一次性过程运行。
任务可以包括数据清理和提取报表分析。
执行这些任务的工具应从生产环境中调用，但应与应用程序分开。
《
BeyondtheTwelve-FactorApp》这本书中，作者凯文·
霍夫曼（KevinHoffman）详细介绍了最初的12个要素（于2011年编写）。
此外，他讨论了反映当今现代云应用程序设计的三个其他要素。
新要素
13
API优先
使一切成为服务。
假设您的代码将被前端客户端，网关或其他服务使用。
14
遥测
在工作站上，您可以深入了解应用程序及其行为。
在云中，您不需要。
确保您的设计包括监控，特定域和运行状况/系统数据的收集。
15
认证/授权
从一开始就实现身份认证。
可以考虑公共云中的RBAC（基于角色的访问控制）功能。
关键设计的一些注意事项
除了十二要素方法提供的指导之外，在构建分布式系统时还必须做出几个关键的设计决策。
通讯问题
前端客户端应用程序将如何与后端核心服务通信？
您可以直接交流吗？
或者，您是否可以使用具备灵活性、控制性和安全性的网关外观抽象化后端服务？
后端核心服务将如何相互通信？
您是否允许直接HTTP调用导致耦合，并影响性能和敏捷性？
还是可以考虑通过队列和主题技术解耦消息传递？
弹性问题
微服务架构将您的系统从进程内通信转移到进程外网络通信。
在分布式体系结构中，当服务B不响应来自服务A的网络请求时会发生什么？
或者，当服务C暂时不可用并且其他调用它的服务被阻止时会发生什么？
分布式数据问题
根据设计，每个微服务都封装自己的数据，并通过其公共接口公开操作。
如果是这样，您如何查询数据或实现跨多个服务的事务？
身分识别问题
您的服务将如何识别谁在访问它以及他们拥有哪些权限？
微服务
云原生系统包含微服务，这是一种用于构建现代应用程序的流行架构风格。
微服务是作为一组分布式的小型独立服务而构建的，它们通过共享结构进行交互，它们具有以下特征：
∙它们各自在更大的领域上下文中实现特定的业务功能。
∙每个都是自主开发的，可以独立部署。
∙每个组件都是独立的，封装了自己的数据存储技术（SQL，NoSQL）和编程平台。
∙每个服务都在自己的进程中运行，并使用标准通信协议（例如HTTP/HTTPS，WebSocket或AMQP）与其他进程通信。
∙它们一起组成一个应用程序。
图1-4将单体应用程序方法与微服务方法进行了对比。
请注意，单体应用程序整体结构是由分层架构组成的，该架构在单个进程中执行。
它通常消费一个关系数据库。
但是，微服务方法将功能分离到包含逻辑和数据的独立服务中。
每个微服务都托管自己的数据存储。
图1-4单体方法与微服务方法
为什么选择微服务？
微服务具备敏捷性。
我们将一个单体构建的电子商务应用程序与带有微服务的电子商务应用程序进行了比较。
在示例中，我们看到了一些明显的好处：
∙
每个微服务都有一个自治的生命周期，可以独立发展并频繁部署。
您不必等待季度发布才能部署新功能或更新。
您可以更新复杂应用程序的一小部分区域，从而减少破坏整个系统的风险。
∙每个微服务都可以独立扩展。
无需将整个应用程序扩展为一个个单元，而仅扩展那些需要更多处理能力或网络带宽的服务。
这种细粒度的扩展方法可以更好地控制系统，并有助于在扩展部分系统（而非全部）时降低总体成本。
开发微服务
可以使用任何现代开发平台来创建微服务。
Microsoft.NETCore平台是一个很好的选择。
它是免费和开源的，具有许多内置功能，可以简化微服务开发。
.NETCore是跨平台的。
可以在Windows，macOS和大多数Linux版本上构建和运行应用程序。
.NETCore的性能很高，与Node.js和其他竞争平台相比得分很高。
有趣的是，TechEmpower在许多Web应用程序平台和框架中进行了广泛的性能基准测试。
.NETCore在前10名中得分最高，远高于Node.js和其他竞争平台。
.NETCore由Microsoft和.NET社区在GitHub上维护。
容器
如今，很自然地会听到任何有关云原生的对话中提到的容器一词。
在《CloudNativePatterns》一书中，作者CorneliaDavis指出：
“容器是云原生软件的强力支撑者。
”CloudNativeComputingFoundation（云原生计算基金会）将微服务容器化作为其Cloud-NativeTrailMap的第一步-为企业开始其云原生之旅的指南。
容器化微服务既简单又直接。
代码，其依赖项和运行时被打包到一个称为容器镜像的二进制文件中。
镜像存储在容器注册表中，容器注册表充当镜像的存储库。
注册表可以位于开发计算机，数据中心或公共云中。
Docker本身通过DockerHub维护一个公共注册表。
Azure云具有容器注册表，可将容器镜像存储在运行镜像的云应用程序附近。
在需要时，将镜像转换为运行的容器实例。
容器实例可在装有容器运行时引擎的任何计算机上运行。
您可以根据需要，部署任意数量的容器化服务实例。
图1-5显示了三种不同的微服务，每个微服务都在自己的容器中，并且在单个主机上运行。
图1-5容器主机上运行多个容器
注意每个容器是如何维护自己的依赖关系和运行时，这可能会有所不同。
在这里，我们看到在同一主机上运行的Product微服务的不同版本。
每个容器共享基础主机操作系统，内存和处理器的一部分，但彼此隔离。
容器模型很好地包含了十二要素中的“依赖关系”原则。
要素2指定“每个微服务隔离并打包其自己的依赖关系，在不影响整个系统的情况下接受更改。
”
容器同时支持Linux和Windows工作负载。
Azure开放地包含了两者。
有趣的是，已经成为Azure中最受欢迎的操作系统是Linux，而不是WindowsServer。
尽管有多家容器供应商，但Docker占据了最大的市场份额。
该公司一直在推动软件容器的发展。
Docker已经成为打包、部署和运行云原生应
升级会员 