小编Joh*_*xus的帖子

我已经阅读了一些用Kubernetes编写的书以及文档中有关无头服务的页面的几段内容。但是我仍然不确定它的真正作用以及为什么有人会使用它。是否有人对它有很好的了解，它能完成什么以及为什么有人会使用它？

我看了很多页面,或者不能按照他们的说法去做,因为他们不清楚和/或我的知识还不够.

我想跑:

luarocks install https://raw.githubusercontent.com/qassemoquab/stnbhwd/master/stnbhwd-scm-1.rockspec

这样我就可以使用GPU加速在一些图像上运行DenseCap.当我运行它时,我收到此错误:

$ luarocks install https://raw.githubusercontent.com/qassemoquab/stnbhwd/master/stnbhwd-scm-1.rockspec
Using https://raw.githubusercontent.com/qassemoquab/stnbhwd/master/stnbhwd-scm-1.rockspec... switching to 'build' mode
Cloning into 'stnbhwd'...
remote: Counting objects: 24, done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 24 (delta 0), reused 14 (delta 0), pack-reused 0
Receiving objects: 100% (24/24), 19.42 KiB | 0 bytes/s, done.
Checking connectivity... done.
cmake -E make_directory build && cd build && cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH="/home/tex/torch/install/bin/.." -DCMAKE_INSTALL_PREFIX="/home/tex/torch/install/lib/luarocks/rocks/stnbhwd/scm-1" && make

-- The C compiler identification is GNU 5.4.0
-- …

我该如何转换：

return this.subjects.entrySet()
            .stream()
            .collect(Collectors.toMap(e -> getArtistryCopy(e.getKey()), Map.Entry::getValue));

要返回 LinkedHashMap 而不是地图？

如果您需要知道，this.subjects是一个LinkedHashMap<AbstractArtistries, ArrayList<AbstractCommand>>. AbstractArtistry 和 command 是我制作的两个自定义对象。我需要维持秩序。

getArtistryCopy() 返回 AbstractArtistry 的副本（这是关键）。

根据此处的Azure ServiceBus 文档：

ServiceBusReceiver 类定义用于从 Azure 服务总线队列或主题订阅接收消息的高级接口。消息接收的两个主要通道是 receive()，用于发出单个消息请求，以及async for message in receiver:以持续的方式连续接收传入消息。

我一直在尝试使用async for message in receiver:建议在每次出现消息时触发函数，但我不确定如何正确执行，因为我几乎没有使用异步函数的经验。熟悉异步/服务总线的人可以解释一下代码应该如何格式化吗？

编辑：让我提供更多背景信息。我正在创建一个 python Flask 服务，在启动时，我需要它开始监听主题/订阅名称上的消息。每当它收到消息时，它都会执行一些代码，然后发回消息。那么...如何在启动时启动异步侦听器，并让它在触发时执行一些代码？它还应该能够以非阻塞的方式处理每条消息。因此，如果同时收到两条消息，则应同时处理两条消息。

注意：我无法使用 Azure Functions。

我目前正在致力于增强 gRPC 服务和客户端之间通信的稳健性和清晰度，特别是围绕操作降级的概念。在许多情况下，操作可能会部分成功或遇到客户应注意的非关键问题，而不必将这些问题视为彻底失败。

标准 gRPC 响应通常包括成功响应或错误，但对于成功但带有警告的操作存在灰色区域（例如，有关接近配额限制的警告、有关优化的信息性消息或不会停止操作的小问题） 。

是否有一个行业标准来解释我们如何构建 gRPC 响应，以跨服务标准化且可供客户操作的方式包含这些“降级”详细信息？

我建议的解决方案： 我正在考虑在 protobuf 定义中引入 DegradationDetail 消息，该消息可以封装操作期间遇到的任何降级的严重性和详细信息。下面是它的草图：

message DegradationDetail {
  string message = 1; // Human-readable message describing the degradation.
  DegradationSeverity severity = 2; // The severity of the degradation.
  repeated string affected_features = 3; // Specific features or components affected, if applicable.
}

enum DegradationSeverity {
  INFO = 0; // Informational message, operation successful.
  WARNING = 1; // Warning, operation successful but might require attention.
  ERROR = 2; // Error …