金鱼哥RHCA回忆录:CL210描述OPENSTACK控制平面--通过API描述服务访问+通过MQ描述服务通信

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 第二章 描述OPENSTACK控制平面--通过API描述服务访问+通过MQ描述服务通信
🎹 个人简介:大家好,我是 金鱼哥,CSDN运维领域新星创作者,华为云·云享专家,阿里云社区·专家博主
📚个人资质: CCNA、HCNP、CSNA(网络分析师),软考初级、中级网络工程师、RHCSA、RHCE、RHCA、RHCI、ITIL😜
💬格言:努力不一定成功,但要想成功就必须努力🔥

🎈支持我:可点赞👍、可收藏⭐️、可留言📝


🧾通过API描述服务访问

📜身份服务目录

服务目录是Keystone体系结构的一个关键元素。它提供了可以被API客户端动态发现的端点url列表,并提供了可以通过令牌访问的服务端点。如果没有服务目录,API客户端将不知道APl请求应该使用哪个URL。openstack catalog show命令显示服务的目录信息。服务名作为命令的命令名传递。例如,要查看Nova compute的服务目录数据,可以使用以下命令:

(undercloud) [stack@director ~]$ openstack catalog show nova

+-----------+---------------------------------------------+
| Field     | Value                                       |
+-----------+---------------------------------------------+
| endpoints | regionOne                                   | # url的区域。
|           |   internal: http://172.25.249.202:8774/v2.1 |
|           | regionOne                                   |
|           |   public: https://172.25.249.201:13774/v2.1 |   #API客户机请求可以通过其访问Nova计算服务的内部、公共和管理url列表。
|           | regionOne                                   |
|           |   admin: http://172.25.249.202:8774/v2.1    |
|           |                                             |
| id        | eade3c9269134a528a15f598ca70421b            |
| name      | nova                                        | # 面向用户的服务名。
| type      | compute                                     | # OpenStack注册类型,如镜像服务和对象存储。
+-----------+---------------------------------------------+

📜端点

端点是API客户端用来访问OpenStack服务的URL。每个服务都有一个或多个端点。端点URL有三种类型:管理、公共和内部。管理URL只能由需要对服务端点进行管理访问的人使用。内部URL被服务用来在网络上相互通信,该网络是没有计量的或免费的带宽费用。公共URL的设计意图是让来自公共网络的最终用户使用。

要列出所有服务及其端点,使用openstack catalog list命令作为admin用户。

(undercloud) [stack@director ~]$ openstack catalog list
+------------------+-------------------------+---------------------------------------------------------------------------------+
| Name             | Type                    | Endpoints                                                                       |
+------------------+-------------------------+---------------------------------------------------------------------------------+
| placement        | placement               | regionOne                                                                       |
|                  |                         |   public: https://172.25.249.201:13778/placement                                |
|                  |                         | regionOne                                                                       |
|                  |                         |   internal: http://172.25.249.202:8778/placement                                |
|                  |                         | regionOne                                                                       |
|                  |                         |   admin: http://172.25.249.202:8778/placement                                   |
|                  |                         |                                                                                 |
| heat-cfn         | cloudformation          | regionOne                                                                       |
|                  |                         |   internal: http://172.25.249.202:8000/v1/f50fbd0341134b97a5a735cca5d6255c      |
|                  |                         | regionOne                                                                       |
|                  |                         |   public: https://172.25.249.201:13800/v1/f50fbd0341134b97a5a735cca5d6255c      |
|                  |                         | regionOne                                                                       |
|                  |                         |   admin: http://172.25.249.202:8000/v1/f50fbd0341134b97a5a735cca5d6255c         |
|                  |                         |                                                                                 |
| zaqar-websocket  | messaging-websocket     | regionOne                                                                       |
|                  |                         |   public: wss://172.25.249.201:9000                                             |
|                  |                         | regionOne                                                                       |
|                  |                         |   admin: ws://172.25.249.202:9000                                               |
|                  |                         | regionOne                                                                       |
|                  |                         |   internal: ws://172.25.249.202:9000
………

要列出所有端点的ID、区域、服务名称和服务类型,请使用openstack endpoint list命令。

(undercloud) [stack@director ~]$ openstack endpoint list
+----------------------------------+-----------+------------------+-------------------------+---------+-----------+----------------------------------------------------+
| ID                               | Region    | Service Name     | Service Type            | Enabled | Interface | URL                                                |
+----------------------------------+-----------+------------------+-------------------------+---------+-----------+----------------------------------------------------+
| 0428dfac8f2c4c73a773e8ea8c283a97 | regionOne | heat-cfn         | cloudformation          | True    | internal  | http://172.25.249.202:8000/v1/%(tenant_id)s        |
| 0805e9f0df6241bcac52a40c5d745fe2 | regionOne | heat             | orchestration           | True    | admin     | http://172.25.249.202:8004/v1/%(tenant_id)s        |
| 0e7057a4823c48b793a5a455fdfbcfe1 | regionOne | glance           | image                   | True    | internal  | http://172.25.249.202:9292                         |
| 0ec1b29d2ebe45678336281710f5003e | regionOne | ironic           | baremetal               | True    | public    | https://172.25.249.201:13385                       |
| 152496ecc2a342ce9d3f558c1ba2519c | regionOne | heat-cfn         | cloudformation          | True    | public    | https://172.25.249.201:13800/v1/%(tenant_id)s      |
| 160aa5d2ebc449ffbf2e9d2b1f7beb8c | regionOne | keystone         | identity                | True    | public    | https://172.25.249.201:13000                       |
…………

📜故障排除API通信

正确的目录和端点配置对于OpenStack环境的有效运行至关重要。导致故障排除的常见问题是不匹配的端点和用户身份验证。在BZ-1404324中记录了一个已知的问题,即计划的令牌刷新作业对于大型部署不够有效,我们将在下面的指导练习中查看修复方法。当问题出现时,您可以采取措施进行调查并找到解决问题的方法。下面是故障排除步骤列表:

使用curl命令来检索服务目录,确保身份验证凭据和令牌是适当的。
在这里插入图片描述

检查/var/log/containers/keystone/keystone。日志文件为[Errno 111]连接拒绝错误。这表示存在连接到服务端点的问题。
在这里插入图片描述

在对端点进行故障排除时,每个服务都应该检查APl日志。例如,如果操作员不能检索到Glance镜像数据,就需要检查/var/log/containers/glance/api.log可以提供有用的信息。查询文件中的DiscoveryFailure。
在这里插入图片描述

在openstack catalog show 命令(或任何openstack命令)中包含 --debug选项,以查看来自客户机的HTTP请求和来自端点的响应。这个示例显示了ldentity端点的请求和响应,然后是令牌的请求和响应,然后是获取端点信息的命令。为了可读性,这里对JSON有效负载进行了格式化。

在这里插入图片描述

(其余详见课本)


🧾通过MESSAGE BROKER描述服务通信

📜RabbitMQ概述

OpenStack软件提供了一组服务,涵盖了与私有云解决方案相关的所有功能。这些服务本身是由几个组件构建的,允许灵活和可伸缩的配置。OpenStack服务的后端基于两个功能:用于持久性的数据库和支持每个服务组件之间通信的消息代理。任何支持AMQP的消息代理解决方案都可以用作后端。Red Hat在其OpenStack产品中包括RabbitMQ作为消息代理,因为它提供了用于设置高级配置的企业级特性。


📑常见的RabbitMQ术语和定义

Broker:它提供一种传输服务,它的角色就是维护一条从生产者到消费者的路线,保证数据能按照指定的方式进行传输,

Exchange:消息交换机,它指定消息按什么规则,路由到哪个队列。

Queue:消息的载体,每个消息都会被投到一个或多个队列。

Binding:绑定,它的作用就是把exchange和queue按照路由规则绑定起来.

Routing Key:路由关键字,exchange根据这个关键字进行消息投递。

vhost:虚拟主机,一个broker里可以有多个vhost,用作不同用户的权限分离。

Producer:消息生产者,就是投递消息的程序.

Consumer:消息消费者,就是接受消息的程序.

Channel:消息通道,在客户端的每个连接里,可建立多个channel.


消息代理在生产者和消费者应用程序之间发送和接收消息,RabbitMQ在内部使用交换器和队列以及它们之间的绑定来执行这种通信。当应用程序生成要发送给一个或多个使用者应用程序的消息时,它将该消息放在绑定了一个或多个队列的交换器上。交换器将消息路由到相关队列。使用者订阅队列以接收生产者的消息。路由基于传输消息中包含的路由密钥。


📜Message Broker交换概念

交换器与队列的交互基于消息中包含的路由键与相关交换器上与队列关联的绑定键之间的匹配。根据这两个元素的使用,RabbitMQ中有几种交换类型。

Direct Exchange

直接匹配,通过Exchange名称+RountingKey来发送与接收消息。

Topic Exchange

主题匹配订阅,这里的主题指的是RoutingKey,RoutingKey可以采用通配符,如:*或#,RoutingKey命名采用。来分隔多个词,只有消息这将队列绑定到该路由器且指定RoutingKey符合匹配规则时才能收到消息。

Fanout Exchange

广播订阅,向所有的消费者发布消息,但是只有消费者将队列绑定到该路由器才能收到消息,忽略Routing Key。

Headers Exchange

消息头订阅,消息发布前,为消息定义一个或多个键值对的消息头,然后消费者接收消息同时需要定义类似的键值对请求头:(如:x-mactch=all或者x_match=any),只有请求头与消息头匹配,才能接收消息,忽略RoutingKey。


📑OpenStack中的message broker(消息代理)模式结构

交换器、队列和绑定以模式组合在一起,以实现应用程序之间和应用程序内的通信。以下示例描述了一些常见的编程配置,在对message broker通信进行故障排除时可能会遇到这些配置。
在这里插入图片描述

图2.1:工作队列将消息分发给工作使用者


即使不使用交换器,队列对于将工作分发给多个使用者进程也是有用的。图2.1中的工作队列设计以先到先服务的方式分发请求。单个消息只使用一次,这与Fanout Exchange不同,Fanout Exchange将消息复制到多个队列,以便所有使用者接收相同的消息。只要处理了每个请求消息,发布者并不关心哪个worker处理了它。

在这里插入图片描述

图2.2:交换器和队列使用绑定来建立路由连接


独特的任务通常必须路由到能够处理请求的特定使用者应用程序。通过在交换器和队列之间创建绑定,交换器可以理解消息键,并将它们与特定的命名队列关联起来。在图2.2中,taskC_create消息将被路由到名为taskC_queue的队列。

在这里插入图片描述

图2.3:使用用户指定的模式匹配交换路由主题消息


交换路由可以是显式的,使用消息中指定的主题元数据上的模式匹配过滤器。通过在路由模式中使用通配符,可以同时将消息发送到一个或多个队列。在图2.3中,只有compute_tasks会路由到名为compute_tasks的队列,但是所有任务,包括compute,都会路由到名为all_tasks的队列。


📑使用消息队列实现RPC(Remote Procedure Call远程过程调用)

单个信息队列是发布者到使用者的单向通信。为了实现请求和响应通信,模拟通用RPC协议编程,需要使用一个共享的已命名队列来交付响应。

在这里插入图片描述

图2.4:RPC调用是使用预先设置的RPC响应直接交换来实现的


当流程需要对请求进行应答时,它将发布一条消息,其中包括接收方用于响应的已命名队列。然后,请求进程订阅该队列,并继续轮询响应,直到收到响应。服务器端的主题使用者工作人员处理原始请求,然后实例化发布者来创建响应


📑oslo消息传递库

在过去,开发OpenStack组件的开发人员需要一些AMQP的知识来执行RPC操作。这推动了对消息传递后端RPC通用接口的需求,从而产生了Oslo消息传递库。oslo.messaging。rpc APl允许开发人员在不需要任何AMQP知识的情况下进行组件集成,并且额外的抽象层允许在将来添加非AMQP后端。


📑配置和日志文件

下面的列表描述了RabbitMQ配置和日志文件。激活配置文件位于RabbitMQ容器内,不再直接访问控制器节点。日志文件位于控制器节点本身。


/etc/rabbitmq/enabled_plugins

包含已启用插件的列表。


/etc/rabbitmq/rabbitmq-env.conf

RabbitMQ启动脚本的默认设置。


/etc/rabbitmq/rabbitmq.config

提供标准的Erlang配置文件,允许配置RabbitMQ核心应用程序、Erlang服务和RabbitMQ插件


/var/log/containers/rabbitmq/rabbit@controller0.log

包含运行时事件的日志。


📑通过消息传递进行服务通信的故障排查

OpenStack服务遵循组件体系结构。服务的功能被划分为不同的组件,每个组件使用message broker与其他组件通信。为了对OpenStack服务的问题进行故障排除,理解请求在服务的不同组件之间移动时所遵循的工作流是很重要的。通常,OpenStack服务体系结构提供一个独特的组件,以使每个服务的API可用。例如,Cinder块存储服务由Cinder api服务管理。API组件是其服务的组件体系结构的其他部分的入口点。当试图隔离一个服务的问题时,首先检查它的APl提供者。

验证API组件之后,如果日志文件中没有出现错误,请确认其余组件可以无问题地通信。任何与RabbitMQ消息代理相关的错误,或其在相关服务配置文件中的配置,都应该出现在服务日志文件。对于Cinder块存储服务,在Cinder API服务通过Cinder API处理了请求之后,该请求由Cinder_volume和Cinder_scheduler进程处理。这些组件负责使用RabbitMQ消息代理来通信自身,以便在最可行的存储后端位置创建卷。Cinder块存储服务组件(例如Cinder -scheduler)不能与意外崩溃的RabbitMQ后端正常运行。通过检查组件相关的日志来调试问题,例如/var/log/cinder/scheduler.log和/var/log/containers/cinder/scheduler.log基于Systemd单元的服务和基于Docker容器的服务的日志。然后,检查作为RabbitMQ消息代理客户端的组件是否存在问题。当一个组件由于RabbitMQ相关问题而崩溃时,通常是由于授权或加密的错误配置造成的。这些错误存在于相关的配置文件中,例如/etc/ cinder/cinder.conf,但是有时候,对于Cinder组件来说,崩溃发生的原因不是RabbitMQ,比如不可用的Cinder块存储服务。


📑rabbitmqctl命令

因为OpenStack现在已经被容器化了,所以所有的RabbitMQ命令都必须从容器本身内部执行。属性使用的典型命令列表如下rabbitmqctl命令。

使用report命令显示RabbitMQ守护进程当前状态的摘要,包括交换和队列的数量和类型。
在这里插入图片描述

使用列表用户命令列出RabbitMQ用户。

在这里插入图片描述

使用list_exchanges命令和rabbitmqctl来显示RabbitMQ守护进程上默认的已确认的交换。

在这里插入图片描述

使用list_queues命令列出可用队列及其属性。

在这里插入图片描述

使用list_consumer命令列出所有消费者及其订阅的队列。

在这里插入图片描述


📑RABBITMQ跟踪消息

RabbitMQ有一个内置的函数来跟踪所有的消息,称为Firehose跟踪器。当启用时,所有进入系统的消息将复制到amq.rabbitmq.trace交换。如果您创建了一个队列,则可以使用这些消息进行分析。跟踪会增加系统的负载,因此请确保在调查完成时禁用跟踪。

使用rabbitmqctl trace_on和rabbitmqctl trace_off命令启用和禁用跟踪。

下面的消息是用户创建实例的结果。它是协调各种服务以执行所需工作所需的众多服务之一。下面的消息的路由键为publish.nova和conductor容器的请求头中。这是请求创建finance-server2实例的Nova Conductor服务。

消息中包含了很多信息,但是对于故障诊断,有一些关键字段非常有用。

  • 可以使用 _context_request_id值搜索与此请求相关的消息。
  • _reply_q值定义请求者将在其中接受响应的队列。

在消息中,您可以看到满足此请求所需的所有服务的端点,以及与实例相关的信息,如密钥对和风格。

在这里插入图片描述

(其余详见课本)


📜课本练习

RabbitMQ中启用跟踪,然后在实例部署期间监视选定的组件。

[student@workstation ~]$ lab controlplane-message  setup 
Setting up workstation for lab exercise work:

 • Verifying project: finance..................................  SUCCESS
 • Creating user env file: developer1-finance-rc...............  SUCCESS
 • Creating keypair: example-keypair...........................  SUCCESS
 . Creating flavor: default....................................  SUCCESS
 . Creating image: rhel7.......................................  SUCCESS
 . Creating internal network: finance-network1.................  SUCCESS
 . Creating subnet: finance-subnet1............................ SUCCESS
 . Creating external network: provider-datacentre..............  SUCCESS
 . Creating router: finance-router1............................  SUCCESS
 . Creating security group: default............................  SUCCESS
 . Downloading trace consumer script: .........................  SUCCESS

📑使用docker exec和rabbitmqctl命令在RabbitMQ中创建跟踪程序用户,密码为redhat

以下是课本外另一种方式

[root@controller0 ~]# docker exec -it rabbitmq-bundle-docker-0 /bin/bash
()[root@controller0 /]# rabbitmqctl add_user tracer redhat
Creating user "tracer"
()[root@controller0 /]# rabbitmqctl list_users
Listing users
tracer    []
guest    [administrator]
()[root@controller0 /]# exit
exit

[root@controller0 ~]# docker exec -t rabbitmq-bundle-docker-0 rabbitmqctl list_users
Listing users
tracer    []
guest    [administrator]

📑tracer用户的权限配置。使用通配符语法将所有资源分配给配置、写入和读取的三个权限中的每一个。

[root@controller0 ~]# docker exec -t rabbitmq-bundle-docker-0 rabbitmqctl set_permissions tracer ".*" ".*" ".*"
Setting permissions for user "tracer" in vhost "/"
[root@controller0 ~]# docker exec -t rabbitmq-bundle-docker-0 rabbitmqctl list_user_permissions tracer
Listing permissions for user "tracer"
/    .*    .*    .*

📑使用docker exec和rabbitmqctl trace_on命令在RabbitMQ中启用跟踪。

[root@controller0 ~]# docker exec -t rabbitmq-bundle-docker-0 rabbitmqctl trace_on
Starting tracing for vhost "/"

📑确定RabbitMQ监听的接口。RabbitMQ的默认端口是5672

[root@controller0 ~]# netstat -lntup | grep :5672
tcp        0      0 172.24.1.1:5672         0.0.0.0:*       LISTEN      13456/beam.smp

📑提供了一个使用来自amq.rabbitmq.trace交换的python脚本。

使用-u和-p选项指定跟踪程序用户和密码。使用-t选项提供前一步中的目标IP地址。将输出重定向到/tmp/rabbit.trace进行分析。

[root@controller0 ~]# ./rmq_trace.py -u tracer -p redhat -t 172.24.1.1 > /tmp/rabbit.trace

📑部署实例

[student@workstation ~(developer1-finance)]$ openstack server create --image rhel7 --flavor default --security-group default --key-name example-keypair --nic net-id=finance-network1 finance-server2 --wait
+-----------------------------+------------------------------------------------------------------+
| Field                       | Value                                                            |
+-----------------------------+------------------------------------------------------------------+
| OS-DCF:diskConfig           | MANUAL                                                           |
| OS-EXT-AZ:availability_zone | nova                                                             |
| OS-EXT-STS:power_state      | Running                                                          |
| OS-EXT-STS:task_state       | None                                                             |
| OS-EXT-STS:vm_state         | active                                                           |
| OS-SRV-USG:launched_at      | 2020-10-17T05:36:36.000000                                       |
| OS-SRV-USG:terminated_at    | None                                                             |
| accessIPv4                  |                                                                  |
| accessIPv6                  |                                                                  |
| addresses                   | finance-network1=192.168.1.10                                    |
| adminPass                   | m5UDoUjDarCU                                                     |
| config_drive                |                                                                  |
| created                     | 2020-10-17T05:31:19Z                                             |
| flavor                      | default (e04380ed-b027-4a72-a697-4307bc014b6c)                   |
| hostId                      | c439f7c83de10e6a305fc9bc9caefdef52c9f503e4aa5733eae8573c         |
| id                          | 65cb9f1a-61e0-48b7-bf0c-0ea4889d8923                             |
| image                       | rhel7 (6b0128a9-4481-4ceb-b34e-ffe92e0dcfdd)                     |
| key_name                    | example-keypair                                                  |
| name                        | finance-server2                                                  |
| progress                    | 0                                                                |
| project_id                  | 3c003f65d8d64914a053f178fbbf953c                                 |
| properties                  |                                                                  |
| security_groups             | name='default'                                                   |
| status                      | ACTIVE                                                           |
| updated                     | 2020-10-17T05:36:36Z                                             |
| user_id                     | e4035d555f6b88cf42ca4cacb9fa9999dca9787392222d2eb0875e4e34e6d76f |
| volumes_attached            |                                                                  |
+-----------------------------+------------------------------------------------------------------+

📑取消rmq_trace.py命令。使用docker exec和rabbitmqctl命令禁用跟踪。

[root@controller0 ~]# docker exec -t rabbitmq-bundle-docker-0 rabbitmqctl trace_off
Stopping tracing for vhost "/"

📑在/tmp/rabbit.trace日志文件中搜索finance-server2。

第一个结果的路由键为publish.nova和conductor。整个消息是JSON格式的,但是为了可读性,可以使用echo '' | jq . 命令对子部分进行重新格式化。下面的小节展示了实例风格。


💡总结

RHCA认证需要经历5门的学习与考试,还是需要花不少时间去学习与备考的,好好加油,可以噶🤪。

以上就是【金鱼哥】对 第二章 描述OPENSTACK控制平面--通过API描述服务访问+通过MQ描述服务通信 的简述和讲解。希望能对看到此文章的小伙伴有所帮助。

💾 红帽认证专栏系列:
RHCSA专栏: 戏说 RHCSA 认证
RHCE专栏: 戏说 RHCE 认证
此文章收录在RHCA专栏: RHCA 回忆录

如果这篇【文章】有帮助到你,希望可以给【金鱼哥】点个赞👍,创作不易,相比官方的陈述,我更喜欢用【通俗易懂】的文笔去讲解每一个知识点。

如果有对【运维技术】感兴趣,也欢迎关注❤️❤️❤️ 【金鱼哥】❤️❤️❤️,我将会给你带来巨大的【收获与惊喜】💕💕!

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
相关文章
|
30天前
|
存储 消息中间件 安全
JUC组件实战:实现RRPC(Java与硬件通过MQTT的同步通信)
【10月更文挑战第9天】本文介绍了如何利用JUC组件实现Java服务与硬件通过MQTT的同步通信(RRPC)。通过模拟MQTT通信流程,使用`LinkedBlockingQueue`作为消息队列,详细讲解了消息发送、接收及响应的同步处理机制,包括任务超时处理和内存泄漏的预防措施。文中还提供了具体的类设计和方法实现,帮助理解同步通信的内部工作原理。
JUC组件实战:实现RRPC(Java与硬件通过MQTT的同步通信)
|
26天前
|
编解码 中间件 API
API实现跨平台访问的方式
【10月更文挑战第16天】API实现跨平台访问的方式
43 2
|
1月前
|
开发框架 .NET API
Windows Forms应用程序中集成一个ASP.NET API服务
Windows Forms应用程序中集成一个ASP.NET API服务
90 9
|
1月前
|
Kubernetes 安全 Cloud Native
云上攻防-云原生篇&K8s安全-Kubelet未授权访问、API Server未授权访问
本文介绍了云原生环境下Kubernetes集群的安全问题及攻击方法。首先概述了云环境下的新型攻击路径,如通过虚拟机攻击云管理平台、容器逃逸控制宿主机等。接着详细解释了Kubernetes集群架构,并列举了常见组件的默认端口及其安全隐患。文章通过具体案例演示了API Server 8080和6443端口未授权访问的攻击过程,以及Kubelet 10250端口未授权访问的利用方法,展示了如何通过这些漏洞实现权限提升和横向渗透。
145 0
云上攻防-云原生篇&K8s安全-Kubelet未授权访问、API Server未授权访问
|
2月前
|
人工智能 Serverless API
一键服务化:从魔搭开源模型到OpenAI API服务
在多样化大模型的背后,OpenAI得益于在领域的先发优势,其API接口今天也成为了业界的一个事实标准。
一键服务化:从魔搭开源模型到OpenAI API服务
|
2月前
|
API iOS开发 开发者
Snapchat API 访问:Objective-C 实现示例
Snapchat API 访问:Objective-C 实现示例
|
2月前
|
Go API 开发者
深入探讨:使用Go语言构建高性能RESTful API服务
在本文中,我们将探索Go语言在构建高效、可靠的RESTful API服务中的独特优势。通过实际案例分析,我们将展示Go如何通过其并发模型、简洁的语法和内置的http包,成为现代后端服务开发的有力工具。
|
2月前
|
消息中间件 Kafka 数据安全/隐私保护
RabbitMQ异步通信详解
RabbitMQ异步通信详解
90 16
|
3月前
|
API Java Python
API的神秘面纱:从零开始构建你的RESTful服务
【8月更文挑战第31天】在现代网络应用开发中,RESTful API已成为数据交互的标准。本文通过比较流行的技术栈(如Node.js、Python的Django和Flask、Java的Spring Boot)及其框架,帮助你理解构建RESTful API的关键差异,涵盖性能、可扩展性、开发效率、社区支持、安全性和维护性等方面,并提供示例代码和最佳实践,指导你选择最适合项目需求的工具,构建高效、安全且易维护的API服务。
57 0
|
3月前
|
Java 缓存 数据库连接
揭秘!Struts 2性能翻倍的秘诀:不可思议的优化技巧大公开
【8月更文挑战第31天】《Struts 2性能优化技巧》介绍了提升Struts 2 Web应用响应速度的关键策略,包括减少配置开销、优化Action处理、合理使用拦截器、精简标签库使用、改进数据访问方式、利用缓存机制以及浏览器与网络层面的优化。通过实施这些技巧,如懒加载配置、异步请求处理、高效数据库连接管理和启用GZIP压缩等,可显著提高应用性能,为用户提供更快的体验。性能优化需根据实际场景持续调整。
72 0