小编cod*_*yzu的帖子

我们用C#开发.NET Enterprise软件.我们正在寻求改进我们的版本控制系统.我之前使用过mercurial并且一直在我们公司进行实验.但是,由于我们开发企业产品,因此我们非常关注可重用的组件或模块.我一直在尝试使用mercurial的子repos来管理组件和依赖,但是遇到了一些困难.以下是源代码管理/依赖关系管理的基本要求:

1. 可重复使用的组件
   1. 按源共享(用于调试)
   2. 依赖于第三方二进制文件和其他可重用组件
   3. 可以在消费产品的背景下开发并承诺源控制
2. 依赖
   1. 产品依赖于第三方二进制文件和其他可重用组件
   2. 依赖关系有自己的依赖关系
   3. 应通知开发人员依赖项中的版本冲突

这是我一直在使用的mercurial结构:

可重用的组件:

SHARED1_SLN-+-docs
            |
            +-libs----NLOG
            |
            +-misc----KEY
            |
            +-src-----SHARED1-+-proj1
            |                 +-proj2
            |
            +-tools---NANT

第二个可重用的组件,消耗第一个:

SHARED2_SLN-+-docs
            |
            +-libs--+-SHARED1-+-proj1
            |       |         +-proj2
            |       |
            |       +-NLOG
            |
            +-misc----KEY
            |
            +-src-----SHARED2-+-proj3
            |                 +-proj4
            |
            +-tools---NANT            

消耗两种组分的产品:

PROD_SLN----+-docs
            |
            +-libs--+-SHARED1-+-proj1
            |       |         +-proj2
            |       |
            |       +-SHARED2-+-proj3
            |       |         +-proj4
            |       |
            |       +-NLOG
            |
            +-misc----KEY
            |
            +-src-----prod----+-proj5
            |                 +-proj6
            |
            +-tools---NANT

笔记

1. Repos在CAPS中
2. 假设所有儿童回购都是子项目
3. 第三方(二进制)库和内部(源)组件都是位于libs文件夹中的子库
4. 第三方库保存在单独的mercurial repos中,以便消费项目可以引用特定版本的库(即旧项目可以引用NLog v1.0,而较新的项目可以引用NLog v2.0).
5. 所有Visual Studio .csproj文件都在第4级(proj*文件夹),允许相关引用依赖项(即../../../libs/NLog/NLog.dll用于所有引用NLog的Visual Studio项目) …

我们使用REST 服务 API从 PubSub 订阅中提取消息。准备好接受服务的消息被确认，而其他消息则在稍后的执行周期中未被确认而需要接受服务。

在执行周期中，我们使用和向服务 REST API发送单个请求。pullreturnImmediately=truemaxMessages=100

在测试时，我们遇到了这样的情况：每个执行周期仅返回 3 条“旧”消息。新发布的消息从未包含在 的请求中pull。我们通过监控 Stackdriver 监控中的未送达消息来验证新消息是否已成功到达订阅。

• REST API是否pull不包含所有未传递的消息？
• 它会忽略该maxMessages参数吗？
• 应如何使用 REST API 读取所有消息（最多指定的最大值）？

笔记：

pull我们通过向API 发送 2 个并行请求并合并结果来解决该问题。我们找到了此处讨论的解决方法（需要并行请求）。

2018 年 2 月 22 日更新

我在我们的博客上写了一篇文章，解释了为什么我们强制使用 PubSub 服务 REST API。

建筑学：

我们有一个使用 2 个 pubsub 主题/订阅对的架构：

• 主题T1由 cronjob 定期触发（例如每 5 分钟）。订阅S1是我们云功能的触发器。
• 主题T2充当由我们的服务之一发布的后台作业的队列。云函数在每次执行时都会读取订阅S2，以便为排队的后台作业提供服务。

这使我们能够控制后台作业的服务频率，而与它们何时添加到队列无关。

云函数（由 触发）通过PullS1读取消息。它决定哪些后台作业已准备就绪，并在成功为作业提供服务后，确认相关消息。未准备好或失败的作业不会被确认以便稍后提供服务。S2

问题：

我们在使用google 的官方Node.js pubusb 客户端时遇到问题：

1. 有时 ACK 消息会重新出现（似乎无限次）。我们验证了消息在 ACK 截止日期之前得到了确认，并ack()通过调查日志来确保我们正在调用。
2. 有时在第一次执行后（重新部署函数后），后续执行永远不会收到新消息。我们可以通过验证S2stackdriver 中未确认的消息计数或通过重新部署该函数并查看得到服务的消息来验证消息是否在订阅中排队。

我们认为这是 google 的 node.js pubsub 客户端的问题。云功能文档明确指出不启动后台活动。然而，查看 Node.js pubsub 客户端源代码，它显然使用超时在后台提供确认服务。

google的node.js pubsub客户端与google云功能不兼容吗？Google建议仅在客户端库不存在或不能满足其他需求时才访问服务 API。在云功能中运行客户端是否是“其他需求”，要求我们使用服务 API 编写自己的客户端？

尝试的解决方法：

作为一种“解决方法”，我们尝试延迟 cloudfunction 的执行结束，以允许 node.js pubsub 客户端中的任何“后台”进程完成，但这并不能始终消除我们的问题。pubsub 客户端似乎对云函数不友好，并且无法从云函数执行之间的停止中恢复。

2018 年 2 月 22 日更新

我在我们的博客上写了一篇文章，详细描述了我们为什么 …