问题标签 [system-design]

您将如何以编程方式设计一个“黑网”，其中可以进行点对点数据交换（文件传输、聊天等），但播种者/发送者的匿名性要么完全隐藏，要么至少所有参与者都有“合理性”可否认性”，这意味着他们对系统交易或活动的确切参与和/或知识无法在任何合理怀疑之外得到证明？

我们有两个系统，其中系统 A 向系统 B 发送数据。要求每个系统都可以独立于另一个系统运行，并且如果另一个系统宕机，任何一个系统都不会崩溃。问题是在满足解耦要求的同时，系统 A 与系统 B 进行通信的最佳方式是什么。

系统 B 当前有一个进程轮询 db 表中的数据并处理已插入的任何新行。

一种建议的设计是系统 A 只需将数据插入到系统 b 的 db 表中，并让系统 B 通过现有进程处理新行。问题是这个解决方案是否满足两个系统解耦的要求？数据库是否被认为是系统 B 的一部分，可能变得不可用并导致系统 A 崩溃？

另一种解决方案是系统 A 将数据放入 MQ 队列，并有一个进程从 MQ 中读取，然后插入到系统 B 的数据库中。但这只是额外的开销吗？最终，MQ 队列是否比 db 表更容错？

我有一个简单的分布式系统模型，它是由各种工作项的多个生产者和消费者组成的异构网络，以及许多可以以不同速率处理这些工作项的计算节点。连接节点的弧线引入了延迟和带宽限制。

我正在寻找的是一些实用工具，我可以将模型描述为（作为 DSL，或使用图形编辑器），以及用于处理的工作项的统计分布，然后可以对我的模型进行分析（分析或通过模拟）并告诉我有关吞吐量统计的信息（例如平均吞吐量、超出某些响应时间阈值的频率等）。这样的工具存在吗？

我正在设计一个 WCF 服务，它将返回描述系统中一个人的对象列表。

记录数量真的很大，而且我有一些属性，比如人的性别。使用两个值（男性和女性）创建一个名为 Sex 的新枚举（它是一种复杂类型并消耗更多带宽），还是使用 bool IsMale 之类的原始类型更好？

我想知道是否有人对这个问题有一些见解。

一点背景：

我们一直在使用 Rails 从旧的 dBase 和基于 Visual Basic 的系统迁移，以构建内部公司 IntrAnet，它可以处理标签打印、库存控制、运输等 - 基本上是一个 ERP

困境

现在我们需要替换一个用 Java 完成的面向客户的旧网站，该网站将连接到我们的内部系统供客户使用。我们希望能够从我们的内部系统中提取库存、下订单、帐户报表等信息，并将其实时公开。原因是我们在网站上接受订单，通过传真和电话，有时我们有预约。因此，有时（非常罕见）即使是我们旧 Java 网站上库存更新的短暂延迟也会导致我们延期交货，因为我们在半小时内将同一商品卖给了 2 位客户。它通常会在一天内修复，但我们希望将来避免这种情况。

实际问题

有人对如何以更好的方式完成此任务有任何建议吗？

以下是我看到的三个选项：

a) 在 Web 服务器上构建一个单独的 Rails 应用程序，它将连接到我们内部应用程序连接到的同一个数据库。

• +++ 优点：实时数据 - 与我们的内部应用程序看到的相同，即实时创建订单，库存立即耗尽

• --- 缺点：潜在的安全风险、代码重复——即我需要复制所有处理订单的控制器、模型、视图等。

b) 在 Web 服务器上构建一个单独的 Rails 应用程序，它将连接到与我们内部应用程序不同的数据库。

• +++ 优点：更少的安全风险。
• --- 缺点：同步网络数据库和内部数据库（或使用像 REST-API 之类的网络服务）的额外工作，处理库存耗尽和订单创建的额外代码，代码重复 - 即我需要复制所有控制器，处理订单的模型、视图等。

c) 向网络公开内部应用程序

• +++ 优点：消除了上面的所有问题。这是非常“干燥”的方法。
• --- 缺点：更多的安全问题。更复杂的登录系统 - 一种用于 Web，另一种用于使用 LDAP 的内部用户。

那么有什么想法吗？有人有类似的问题要解决吗？请记住，我们公司的资源有限 - 即一位致力于此的开发人员。所以这必须是那些“正确”和“聪明”的解决方案之一，而不是“在这个解决方案上投入金钱/人员/资源”。

谢谢你。

我们有一个 Web 应用程序 (ASP)，其中包含工作流，供管理层将工作分配给个人。问题是在签出工作之前。在晚上/晚上/清晨，操作人员很少，因此如果其他关键工作远离计算机执行（从货架上为机械师获取工具），则可能不会密切关注工作的管理队列。因此，我们有一个功能需求，即创建一个程序，以在工作区的监视器或电视屏幕上不断刷新显示新的未分配工作。

我的问题：部署架构是否有任何推荐的最佳实践？Web 与桌面胖客户端应用程序？

网站：

Pro - 保持架构一致

缺点 - 控制盒子可能很困难我们采取了额外的措施来确保盒子不会被劫持到其他站点，控制有限的登录、其他安全和计算机资源

桌面厚客户端：

缺点 - 现在需要同时支持 Web 和客户端应用程序。需要将两个实例部署到两个位置

优点 - 盒子的安全性和限制使用很简单。无需应用安全登录，因此 PE 等功能可以在需要时恢复应用。

我正在构建一个 Web 应用程序来管理基于不同参数（例如 JobCode、State、Customer、Product 等）的指令。我为每个这样的参数分配了大约 20 个填充字段。字段的显示名称可能因一个项目而异。（多种实现）。

有些项目可能不会使用所有 20 个字段，而只说 5-6 个字段...

现在，我的一位同事建议我自定义存储过程以返回并接受项目所需列名的字段，并让 SP 使用实际列名进行查找。他还建议动态构建控件。

我想为所有 20 个字段提供静态控件，并使用必要的字段名称填充标签，并使用字段名称“Filler1”、“Filler2”与 SP 交互。这也意味着我们需要使非必需的控件不可见......

作为更有经验的用户……你能列举出两者的优缺点吗……

谢谢

来自Alan J. Perlis的编程警句：

22. 好的系统不能有弱的命令语言。

这是什么意思？什么是这个原则的好例子？

我在哪里可以了解有关如何实现符合此标准的命令语言的更多信息？

SQL 中实体-属性-值数据库设计的主要缺点似乎都与能够高效快速地查询和报告数据有关。由于这些问题以及几乎所有应用程序的查询/报告的共性，我阅读的有关该主题的大多数信息都警告不要实施 EAV。

我目前正在设计一个系统，其中一个实体的字段在设计/编译时是未知的，并且由系统的最终用户定义。EAV 似乎很适合这个要求，但由于我读到的问题，我在实施它时犹豫不决，因为这个系统也有一些非常繁重的报告要求。我想我已经想出了解决这个问题的方法，但想向 SO 社区提出这个问题。

鉴于典型的规范化数据库 (OLTP) 并不总是运行报告的最佳选择，一个好的做法似乎是拥有一个“报告”数据库 (OLAP)，将规范化数据库中的数据复制到该数据库中，并对其进行广泛索引，并且可能非规范化以便于查询。是否可以使用相同的想法来解决 EAV 设计的缺点？

我看到的主要缺点是将数据从 EAV 数据库传输到报告的复杂性增加，因为您可能最终不得不更改报告数据库中的表，因为在 EAV 数据库中定义了新字段。但这几乎是不可能的，而且对于 EAV 设计所赋予的更大灵活性而言，这似乎是一个可以接受的折衷方案。如果我使用非 SQL 数据存储（即 CouchDB 或类似数据）作为主要数据存储，也会存在此缺点，因为所有标准报告工具都期望 SQL 后端进行查询。

如果您有一个单独的报告数据库进行查询，EAV 系统的问题是否大部分都消失了？

编辑：感谢到目前为止的评论。关于我正在研究的系统的重要事情之一是我实际上只是在谈论将 EAV 用于其中一个实体，而不是系统中的所有内容。

该系统的整个要点是能够从多个不同的来源提取数据，这些来源事先不知道，并对数据进行处理以得出一些关于特定实体的“最知名”数据。因此，我处理的每个“字段”都是多值的，我还需要跟踪每个“字段”的历史记录。对此的规范化设计最终是每个字段 1 个表，这使得查询它无论如何都是痛苦的。

这是我正在查看的表模式和示例数据（显然与我正在研究的内容有所不同，但我认为它很好地说明了这一点）：

EAV 表

报告表

标准化设计

此处的“信心”字段是使用 SQL 无法轻松表达（如果有的话）的逻辑生成的，因此除了插入新值之外，我最常见的操作是为所有字段提取有关一个人的所有数据，以便我可以生成记录报告表。这在 EAV 模型中实际上更容易，因为我可以执行单个查询。在规范化设计中，我最终不得不对每个字段进行 1 次查询，以避免大量笛卡尔积将它们连接在一起。

我希望这个问题不会太开放，但我只需要朝着正确的方向轻推！

我目前正在构建一个在线会计系统——这个想法是用户可以注册、登录、然后创建客户、生成发票和其他文件，并最终打印/通过电子邮件发送这些文件。

我是一名 Java 程序员，但不幸的是在 Web 项目及其设计概念方面没有太多经验......

这就是我到目前为止所得到的——一个加载 Spring 的 Tomcat Web 服务器。Spring 处理我的 DAO 和业务逻辑所需的类。Tomcat 为包含构成网站的页面的 JSP 提供服务。为了使其具有交互性，我在页面中使用了 JavaScript（jQuery 及其 AJAX 调用）来发送和接收 JSON 数据（这是通过发布到在我的一个类中调用 handleAction() 方法的页面来完成的）。

我的问题是，我是否以正确的方式处理这个项目？我是否使用了正确的工具和方法？我知道实际上有无数种方法可以处理任何项目，但我真的很想得到关于久经考验的方法、一般实践等方面的反馈。

提前致谢！

尚德尔