微型与单片服务器架构

我们当前正在开发我们的新产品/项目，它是针对某些特定工业/服务企业的客户端-服务器应用程序。我们正在构建一个服务器（仅C语言和Linux），该服务器在带有Java前端的TCP之上运行自定义协议。我们大约有20％的人员从事编码工作，并且面临着必须在微型或单核内核体系结构之间进行选择的情况。

我知道Micro vs. Monolithic通常与内核体系结构有关，但是我们专门讨论服务器。

为什么要使用自定义服务器而不是现有服务器？

• 我们的UI需求非常重要且非常动态，因此基于Web / Web浏览器的解决方案不合适。
• 统计处理在客户端非常重要，因此，浏览器也无济于事。（当然，我们可以在服务器端进行处理，然后将处理后的数据传递给客户端，但这将意味着服务器上的大量负载和客户端资源的浪费）。
• 此外，利用至少三种技术（JS / HTML / CSS）来管理单个事件，就可以像在沙漠风暴中扫除房屋一样获得整个体验-您扫除n次，灰尘积聚n + 1次。

微型和整体服务器呢？你在说什么？

考虑以下（假设的）客户端请求：

request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010

收到此类请求后，服务器通常会这样做（为简单起见，我们忽略了诸如线程和派生之类的并发技术）：

• 解析请求字符串
• 确定动作（HistoricDataSets LIMIT Year (2010)在我们的例子中为Fetch ）
• 与持久层（在我们的示例中为Oracle）交互并获取数据。

• 根据协议格式化数据。例如：

  response-id：123
  成功：true
  响应文本：DataSets

• 用这样格式化的数据响应客户端。

这就是我们所说的单片服务器（类似于单片内核，其中所有OS工作都在内核空间中完成）。

再次考虑到相同的请求，这一次是服务器（我们为简单起见，我们仅假设共享内存为IPC）：

• 将请求放入Parser进程的共享内存
• 在Parser解析字符串，确定任务和指示Executioner执行任务的过程。
• 在Executioner然后将数据传递到Fomatter方法，该方法中，数据格式化为一个协议串后，返回到服务器。
• 服务器将其分派给客户端（响应）。

当然，相反的Parser，Executioner而且Formatter它可能是一个单一的，而是独立的进程。这就是我们所说的微型服务器（类似于微型内核，几乎不需要做任何事情）。服务器实际上只是在侦听和响应，而所有步骤都由不同的进程来处理。

选哪一个？我们感到困惑！尽管已经尝试和测试了单片服务器（大多数HTTP-Web服务器？），并且易于编程，并且可以很好地处理并发性。表面上看，微型服务器看起来很快速，并且符合UNIX的一个程序可以完成一项任务的原则，但是开发却很复杂，尤其是。注意并发。

问题
-每种方法的利弊是什么（可能是）？
-什么时候使用？（也可以将其解释为一个普遍的问题：何时使用IPC？）
-如果选择了Micro kernel，那么哪些功能需要成为核心服务器的一部分，而没有呢？

相似/相关问题

• 巨大的整体应用的危险
• 外部Vs嵌入式浏览器（切向）
• 将Monolithic应用程序转换为多线程（切线）的建议

• 我们的潜在客户可以分为两类：
  • 大型：每分钟大约1,700-2,000个请求
  • 小型：每分钟大约650-700个请求
• 可以假设每个请求周期（请求和后续响应）的数据量是正态分布的，平均数约为1.20 MB，最坏的情况约为250-300 MB。
• 该产品概念相对较新，但具有影响核心运营的能力，因此我们希望客户预算仅在部署后一定时间（9-12个月）后才具有灵活性，这限制了客户愿意使用的硬件数量。提交，特别是 小的。
• 每个客户都有自己的客户端-服务器堆栈。服务器将在由客户团队管理的客户硬件上运行，而客户将部署在职能员工的计算机上
• 客户端和服务器应用程序都必须进行远程更新
• PUSH如果产品点击，可能非常需要服务器的实时服务！

与选择背后的核心理论相比，经济学有时会提出更为关键的答案。最重要的是，如果您正在寻找“浩如烟海”的东西，那么您的应用程序需要真正艰难的部署-您自己发明的轮子数量越少越好。如果可以，我不在乎它是单块的还是微型的。如果不是，我也不会在乎！

确实，基于常规网页的应用程序可能不适合您-但您需要更广泛地了解一下，可以使用现成的东西，后来发展出自己的出路，看看是否可以用某种方式替换该元素。更好。这样，您不仅可以节省第一件事的时间，而且您还可以提高对现实生活中真正重要内容的理解。这里是您可能会考虑的一些提示。

1. 如果您确实需要非常高的可伸缩性，请考虑您的服务器将如何划分任务而不是尽可能快地搅乱数字。最终，即使intel使地球上最快的处理器和客户准备付款，您也将承受一台服务器无法真正承担的负担！因此，请求路由和负载平衡比协议本身的效率更为重要。

2. HTTP仍然是最好的-如果您需要扩展。（如果使用负载均衡器，也可以轻松购买）。定制协议需要定制安排。

3. HTTP并不意味着您根本不需要抛出HTML和Java脚本。甚至不意味着您需要使用常规的Apache服务器和Web浏览器。您可以在两个自定义客户端和AOL服务器或lighthttpd之类的元素之间使用HTTP，如果通信不是大量数据传输，则可以将它们用作库。您还可以将SOAP与gSOAP之类的工具包一起使用。

4. 即使HTTP绝对不合适，也可以考虑使用BEEP之类的东西，它可以帮助您提高效率。或者，存在许多已证明的RPC，RMI机制。

5. 尝试看看您可以通过在后端进行并行处理来最大程度地完成工作，并且仅在工作完成后才查询服务器。如果这行得通，那么会有类似MPI的框架，或者还有许多其他的分布式计算工具套件可能会有所帮助。

6. 最后，虽然我可能无法知道确切的需求，但是如果您需要两者，则可能需要分发大量数据或进行大量计算-仍然存在一些核心架构效率低下的问题。

对我来说，创建一个新的协议，而不是创建一个新的服务器框架，是一个双重实验，您不应该一起做。如果您的赌注如此之高，那么首先，您实际上应该尝试尝试使用现有工具，以了解到目前为止所做工作的局限性-只有这样，您才知道真正的挑战。

在分布式系统的研究中，已经完成了许多工作，而不仅仅是Web应用程序。因此，您应该对此进行研究。

地盘

对我来说这似乎很有学问。坦率地说，我发现第二种方法是一样的。这是您应该去的范围：

1. 解析请求
2. 处理请求

基于请求参数选择的请求处理程序应封装处理请求的所有方面。处理程序是否实际上在您的数据存储上执行查询，以及是否使用标准格式返回数据与上一层无关。事实上，它可能会做到这一点，但是对它进行假设没有任何价值。

1. 整体内核比Microkernel早得多。在Unix中使用。而微内核的想法出现在1980年代末。

2. 具有Monolithic内核的os的示例是UNIX，LINUX， 而具有Microkernel的os 的示例是QNX，L4，HURD，最初是Mach（不是mac os x），后来将转换为混合内核，即使MINIX也不是纯内核，因为设备驱动程序是编译为内核的一部分。

3. 整体内核比微内核快。而第一个微内核Mach比Monolithic内核慢50％，而L4等较新版本仅比Monolithic内核慢2％或4％。

4. 整体内核通常很笨重。而Pure Monolithic内核的尺寸必须很小，甚至必须适合处理器一级缓存（第一代微内核）。

5. Monolithic内核设备中的驱动程序驻留在内核空间中。而在Microkernel中，设备驱动程序驻留在用户空间中。

6. 由于设备驱动程序驻留在内核空间中，因此使单块内核的安全性不如微内核。（驱动程序中的故障可能会导致崩溃），而微内核比某些军事设备中使用的单片内核更安全。

7. 整体内核使用信号和套接字来确保IPC，而微内核方法则使用消息队列。1代微内核无法很好地实现IPC，因此在上下文切换时速度很慢。

8. 向单片系统添加新功能意味着重新编译整个内核， 而您可以添加新功能或补丁而无需重新编译。