引言
在当今快节奏的数字世界中，企业需要能够快速适应不断变化的市场需求和技术进步。应用微服务和 API 架构已成为实现敏捷性、模块化和可扩展性的关键策略。
什么是微服务？
微服务是一种软件开发方法，将应用程序分解为松散耦合、独立部署的小型服务。每个微服务都有自己的明确定义的目的，并负责应用程序的特定功能。
使用微服务架构具有以下优点：
- 敏捷性： 微服务可以独立开发和部署，使团队能够快速响应业务需求。
- 模块化： 微服务可以单独维护和更新，从而实现更简单的代码管理。
- 可扩展性： 微服务可以按需扩展，从而可以轻松应对变化的工作负载。
什么是 API？
API（应用程序编程接口）是一组协议和标准，允许应用程序之间相互交互。API 提供了一种定义应用程序如何共享数据和功能的方法。
在微服务架构中，API 对于以下方面至关重要：
- 服务发现： API 允许微服务发现和连接到彼此。
- 数据交换： API 提供了一种结构化的方式在微服务之间交换数据。
- 功能访问： API 允许外部应用程序访问微服务的特定功能。
微服务和 API 的协同作用
微服务和 API 一起工作，为应用程序架构提供了强大的基础。微服务提供应用程序的模块化和可扩展性，而 API 提供服务之间的通信和互操作性。
这种协同作用使企业能够：
- 快速开发和部署新功能。
- 在不影响其他服务的的情况下独立扩展或缩减服务。
- 轻松集成第三方服务和应用程序。
构建微服务和 API 架构
构建有效的微服务和 API 架构需要仔细规划和执行。以下是一些关键步骤：
- 确定业务领域： 将应用程序分解为明确定义的业务领域，每个领域都有其自己的微服务。
- 设计 API： 定义将用于在微服务之间交换数据和功能的 API。
- 实现微服务： 构建独立于其他微服务的微服务。
- 集成 API： 将 API 集成到微服务中，以实现服务发现和数据交换。
- 部署和监控： 部署微服务和 API，并监控其性能和可用性。
最佳实践
以下来管理其应用程序的各个方面，包括驾驶员匹配和支付。
结论
微服务和 API 已成为构建敏捷、模块化和可扩展的应用程序的关键。通过遵循最佳实践并利用适当的技术，企业可以利用这些架构来提高开发速度、提高效率并满足不断变化的业务需求。
云原生相关知识？
云原生技术使企业/组织能够在公共、私有和混合云等现代动态环境中，构建和运行可扩展的应用程序。容器、服务网格、微服务、不可变基础设施和声明式 API 就是这种方法的例证。
这些技术支持具有弹性、可管理和可观察的松散耦合系统。结合强大的自动化，它们使工程师能够以最少的工作频繁且可预测地进行高影响力的更改。
云原生包含哪些技术？
云原生技术以微服务、DevOps、容器、多云业务管理为代表，目前已经成为了加速企业数字化业务高效创新、实现企业数字化转型的最佳技术支撑。
微服务实现了软件的模块化、组件化、共享化，实现了开发团队的独立化、小型化和协同化，为数 字化应用研发创新更敏捷、更高效打下了坚实的基础。
DevOps 实现了软件研运过程标准统一，强化应用研发运营全周期的管理、打破部门壁垒，从应用 需求到生产运维的全流程改进和优化，结合统一工具链，实现文化、流程、工具的一致性，提升数 字化应用创新整体协同效率，提升软件交付效率。
容器技术实现了应用与资源的解耦和应用交付件的标准化，有效解决了异构环境的部署一致性问 题，促进了资源的标准化，为面向应用的服务化、自动化提供了基础。标准容器化的打包方式实现 了真正的应用可移植性，不再受限于特定的基础架构环境。
多云业务管理实现在私有云模式、混合云模式、多云模式下应用的部署、跨云迁移、应用运维和治 理，满足企业多样化 IT 资源需求，同时避免企业被云服务商绑定，实现自主可控。多云业务管理 同时可实现云端+边缘设备的应用一体化交付和管理。
云原生景观图
云原生景观图
截图只是部分，网络搜索会有完整景观图。
微服务架构的优缺点
微服务架构的优缺点具体如下：
优点：服务的独立部署：每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低；服务的快速启动：拆分之后服务启动的速度必然要比拆分之前快很多，因为依赖的库少了，代码量也少了。
更加适合敏捷开发：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布；职责专一，由专门的团队负责专门的服务：业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。
服务可以动态按需扩容：当某个服务的访问量较大时，我们只需要将这个服务扩容即可；代码的复用：每个服务都提供RESTAPI，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。
缺点：分布式部署，调用的复杂性高：单体应用的时候，所有模块之前的调用都是在本地进行的，在微服务中，每个模块都是独立部署的，通过HTTP来进行通信，这当中会产生很多问题，比如网络问题、容错问题、调用关系等。
测试的难度提升：服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了。这里要强调一点，就是API文档的管理尤为重要。
运维难度的提升：在采用传统的单体应用时，我们可能只需要关注一个Tomcat的集群、一个 MySQL的集群就可以了，但这在微服务架构下是行不通的。当业务增加时，服务也将越来越多，服务的部署、监控将变得非常复杂，这个时候对于运维的要求就高了。
微服务架构
是一项在云中围绕业务领域组件来创建和部署应用和服务的新技术，由MartinFowler于2012年提出。微服务架构构建的工具是Seneca，基本思想在于创建的应用可独立地进行开发、管理和加速，在分散的组件中使用微服务云架构和平台，使服务等功能的交付变得更加简单。
微服务架构现状
微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。但大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中，微服务被认为是未来的方向。通过将应用和服务分解成更小的、松散耦合的组件，它们可以更加容易升级和扩展，理论上是这样。
「微服务架构」部署NGINX Plus作为API网关，第1部分 - NGINX
了解着名的Nginx服务器（微服务必不可少的东西）如何用作API网关。 现代应用程序体系结构的核心是HTTP API。 HTTP使应用程序能够快速构建并轻松维护。 无论应用程序的规模如何，HTTP API都提供了一个通用接口，从单用途微服务到无所不包的整体。 通过使用HTTP，支持超大规模Internet属性的Web应用程序交付的进步也可用于提供可靠和高性能的API交付。 有关API网关对微服务应用程序重要性的精彩介绍，请参阅我们博客上的构建微服务：使用API网关。 作为领先的高性能，轻量级反向代理和负载均衡器，NGINX Plus具有处理API流量所需的高级HTTP处理功能。 这使得NGINX Plus成为构建API网关的理想平台。 在这篇博文中，我们描述了许多常见的API网关用例，并展示了如何配置NGINX Plus以便以高效，可扩展且易于维护的方式处理它们。 我们描述了一个完整的配置，它可以构成生产部署的基础。 注意：除非另有说明，否则本文中的所有信息均适用于NGINX Plus和NGINX开源。 API网关的主要功能是为多个API提供单一，一致的入口点，无论它们在后端如何实现或部署。 并非所有API都是微服务应用程序。 我们的API网关需要管理现有的API，单块和正在部分过渡到微服务的应用程序。 在这篇博文中，我们引用了一个假设的库存管理API，即“仓库API”。 我们使用示例配置代码来说明不同的用例。 Warehouse API是一个RESTful API，它使用JSON请求并生成JSON响应。 但是，当部署为API网关时，使用JSON不是NGINX Plus的限制或要求; NGINX Plus与API本身使用的架构风格和数据格式无关。 Warehouse API实现为离散微服务的集合，并作为单个API发布。 库存和定价资源作为单独的服务实施，并部署到不同的后端。 所以API的路径结构是： 例如，要查询当前仓库库存，客户端应用程序会向/ api / warehouse / inventory发出HTTP GET请求。 使用NGINX Plus作为API网关的一个优点是，它可以执行该角色，同时充当现有HTTP流量的反向代理，负载平衡器和Web服务器。 如果NGINX Plus已经是应用程序交付堆栈的一部分，那么通常不需要部署单独的API网关。 但是，API网关所期望的某些默认行为与基于浏览器的流量的预期不同。 出于这个原因，我们将API网关配置与基于浏览器的流量的任何现有（或未来）配置分开。 为实现这种分离，我们创建了一个支持多用途NGINX Plus实例的配置布局，并为通过CI / CD管道自动配置部署提供了便利的结构。 / etc / nginx下的结果目录结构如下所示。 所有API网关配置的目录和文件名都以api_为前缀。 这些文件和目录中的每一个都启用API网关的不同特性和功能，并在下面详细说明。 所有NGINX配置都以主配置文件开头。 要读入API网关配置，我们在的http块中添加一个指令，该指令引用包含网关配置的文件api_（下面的第28行）。 请注意，默认的文件使用include伪指令从conf.d子目录中引入基于浏览器的HTTP配置（第29行）。 本博文广泛使用include指令来提高可读性并实现配置某些部分的自动化。 api_文件定义了将NGINX Plus公开为客户端的API网关的虚拟服务器。 此配置公开API网关在单个入口点（第13行）发布的所有API，受第16到21行配置的TLS保护。 请注意，此配置纯粹是HTTPS - 没有明文HTTP侦听器。 我们希望API客户端知道正确的入口点并默认进行HTTPS连接。 此配置是静态的 - 各个API及其后端服务的详细信息在第24行的include伪指令引用的文件中指定。 第27到30行处理日志记录默认值和错误处理，并在响应中讨论错误部分如下。 一些API可以在单个后端实现，但是出于弹性或负载平衡的原因，我们通常期望存在多个API。 使用微服务API，我们为每个服务定义单独的后端;它们一起作为完整的API。 在这里，我们的Warehouse API被部署为两个独立的服务，每个服务都有多个后端。 API网关发布的所有API的所有后端API服务都在api_中定义。 这里我们在每个块中使用多个IP地址 - 端口对来指示API代码的部署位置，但也可以使用主机名。 NGINX Plus订户还可以利用动态DNS负载平衡，自动将新后端添加到运行时配置中。 配置的这一部分首先定义Warehouse API的有效URI，然后定义用于处理对Warehouse API的请求的公共策略。 Warehouse API定义了许多块。 NGINX Plus具有高效灵活的系统，可将请求URI与配置的一部分进行匹配。 通常，请求由最具体的路径前缀匹配，并且位置指令的顺序并不重要。 这里，在第3行和第8行，我们定义了两个路径前缀。 在每种情况下，$ upstream变量都设置为上游块的名称，该上游块分别代表库存和定价服务的后端API服务。 此配置的目标是将API定义与管理API交付方式的策略分开。 为此，我们最小化了API定义部分中显示的配置。 在为每个位置确定适当的上游组之后，我们停止处理并使用指令来查找API的策略（第10行）。 使用重写指令将处理移至API策略部分 重写指令的结果是NGINX Plus搜索匹配以/ _warehouse开头的URI的位置块。 第15行的位置块使用=修饰符执行完全匹配，从而加快处理速度。 在这个阶段，我们的政策部分非常简单。 位置块本身标记为第16行，这意味着客户端无法直接向它发出请求。 重新定义$ api_name变量以匹配API的名称，以便它在日志文件中正确显示。 最后，请求被代理到API定义部分中指定的上游组，使用$ request_uri变量 - 其中包含原始请求URI，未经修改。 API定义有两种方法 - 广泛而精确。 每种API最合适的方法取决于API的安全要求以及后端服务是否需要处理无效的URI。 在warehouse_api_中，我们通过在第3行和第8行定义URI前缀来使用Warehouse API的广泛方法。 这意味着以任一前缀开头的任何URI都代理到相应的后端服务。 使用基于前缀的位置匹配，对以下URI的API请求都是有效的： 如果唯一的考虑是将每个请求代理到正确的后端服务，则广泛的方法提供最快的处理和最紧凑的配置。 另一方面，精确的方法使API网关能够通过显式定义每个可用API资源的URI路径来理解API的完整URI空间。 采用精确的方法，Warehouse API的以下配置使用精确匹配（=）和正则表达式（〜）的组合来定义每个URI。 此配置更详细，但更准确地描述了后端服务实现的资源。 这具有保护后端服务免于格式错误的客户端请求的优点，代价是正常表达式匹配的一些小额外开销。 有了这个配置，NGINX Plus接受一些URI并拒绝其他URI无效：使用精确的API定义，现有的API文档格式可以驱动API网关的配置。 可以从OpenAPI规范（以前称为Swagger）自动化NGINX Plus API定义。 此博客文章的Gists中提供了用于此目的的示例脚本。 随着API的发展，有时会发生需要更新客户端的重大更改。 一个这样的示例是重命名或移动API资源。 与Web浏览器不同，API网关无法向其客户端发送命名新位置的重定向（代码301）。 幸运的是，当修改API客户端不切实际时，我们可以动态地重写客户端请求。 在下面的示例中，我们可以在第3行看到定价服务以前是作为库存服务的一部分实现的：rewrite指令将对旧定价资源的请求转换为新的定价服务。 动态重写URI意味着当我们最终在第26行代理请求时，我们不能再使用$ request_uri变量（正如我们在warehouse_api_的第21行所做的那样）。 这意味着我们需要在API定义部分的第9行和第14行使用稍微不同的重写指令，以便在处理切换到策略部分时保留URI。 HTTP API和基于浏览器的流量之间的主要区别之一是如何将错误传达给客户端。 当NGINX Plus作为API网关部署时，我们将其配置为以最适合API客户端的方式返回错误。 顶级API网关配置包括一个定义如何处理错误响应的部分。 第27行的指令指定当请求与任何API定义都不匹配时，NGINX Plus会返回错误而不是默认错误。 此（可选）行为要求API客户端仅向API文档中包含的有效URI发出请求，并防止未经授权的客户端发现通过API网关发布的API的URI结构。 第28行指的是后端服务本身产生的错误。 未处理的异常可能包含我们不希望发送到客户端的堆栈跟踪或其他敏感数据。 此配置通过向客户端发送标准化错误来进一步提供保护。 完整的错误响应列表在第29行的include伪指令引用的单独配置文件中定义，其前几行如下所示。 如果首选不同的错误格式，并且通过更改第30行上的default_type值以匹配，则可以修改此文件。 您还可以在每个API的策略部分中使用单独的include指令来定义一组覆盖默认值的错误响应。 有了这种配置，客户端对无效URI的请求就会收到以下响应。 在没有某种形式的身份验证的情况下发布API以保护它们是不常见的。 NGINX Plus提供了几种保护API和验证API客户端的方法。 有关基于IP地址的访问控制列表（ACL），数字证书身份验证和HTTP基本身份验证的信息，请参阅文档。 在这里，我们专注于API特定的身份验证方法。 API密钥身份验证 API密钥是客户端和API网关已知的共享密钥。 它们本质上是作为长期凭证发布给API客户端的长而复杂的密码。 创建API密钥很简单 - 只需编码一个随机数，如本例所示。 在顶级API网关配置文件api_的第6行，我们包含一个名为api_的文件，其中包含每个API客户端的API密钥，由客户端名称或其他描述标识。 API密钥在块中定义。 map指令有两个参数。 第一个定义了API密钥的位置，在本例中是在$ http_apikey变量中捕获的客户端请求的apikey HTTP头。 第二个参数创建一个新变量（$ api_client_name）并将其设置为第一个参数与键匹配的行上的第二个参数的值。 例如，当客户端提供API密钥7B5zIqmRGXmrJTFmKa99vcit时，$ api_client_name变量设置为client_one。 此变量可用于检查经过身份验证的客户端，并包含在日志条目中以进行更详细的审核。 地图块的格式很简单，易于集成到自动化工作流程中，从现有的凭证存储生成api_文件。 API密钥身份验证由每个API的策略部分强制执行。 客户端应在apikey HTTP头中显示其API密钥。 如果此标头丢失或为空（第20行），我们发送401响应以告知客户端需要进行身份验证。 第23行处理API键与地图块中的任何键都不匹配的情况 - 在这种情况下，api_第2行的默认参数将$ api_client_name设置为空字符串 - 我们发送403响应告诉身份验证失败的客户端。 有了这个配置，Warehouse API现在可以实现API密钥身份验证。 JWT身份验证 JSON Web令牌（JWT）越来越多地用于API身份验证。 原生JWT支持是NGINX Plus独有的，可以在我们的博客上验证JWT，如使用JWT和NGINX Plus验证API客户端中所述。 本系列的第一篇博客详细介绍了将NGINX Plus部署为API网关的完整解决方案。 可以从我们的GitHub Gist仓库查看和下载此博客中讨论的完整文件集。 本系列的下一篇博客将探讨更高级的用例，以保护后端服务免受恶意或行为不端的客户端的攻击。 原文：本文：讨论：请加入知识星球或者小红圈【首席架构师圈】
若对本页面资源感兴趣，请点击下方或右方图片，注册登录后
搜索本页相关的【资源名】【软件名】【功能词】或有关的关键词，即可找到您想要的资源
如有其他疑问，请咨询右下角【在线客服】，谢谢支持！
发表评论