本文，我们将尝试深入了解uniGUI HyperServer。 可以将HyperServer所有功能分成三类：
- HyperServer和稳定性
- HyperServer和可扩展性
- HyperServer和远程部署
HyperServer和稳定性
HyperServer是一种新的服务器技术，专门用于从根本上提高uniGUI应用程序的可伸缩性和稳定性。那么，为什么我们需要HyperServer？
为了首先回答这个问题，让我们先回顾一下，一个传统的uniGUI应用程序的运行过程。一个传统的uniGUI应用程序，是由编译器生成二进制文件，该二进制文件通常是DLL或可执行文件。一旦将二进制文件加载到进程内存空间，该二进制文件就会充当服务器。它将无限期运行，直到由系统操作员手动卸载，或者由于程序错误而导致应用程序崩溃，被操作系统中止运行。在理想条件下，人们总是期望应用程序服务器二进制文件无限期地保留在内存中并提供强大而稳定的功能服务。
传统应用程序模型的另一个特征是由单个进程负责创建，保存和提供所有会话。它类似于将所有鸡蛋放在一个篮子里。在这种情况下，会话是鸡蛋，应用程序服务器是篮子。这个模型有几个缺点，最明显的问题是，一旦Web应用程序服务器终止或重新启动，所有活动会话都将被丢弃。另一个可能严重影响应用程序稳定性的问题是应用程序代码中的bug。此类bug可能导致严重的内存泄漏和其他问题，最终可能导致内存损坏和Web应用程序服务器崩溃。这个问题，那怕是微小的内存泄漏问题，因累积也会影响服务器运行。由于在传统模型中，应用服务器注定会无限期地运行，即使小问题也会随着时间的推移变得致命。当然，对于隐藏的bug，内存泄漏，指针问题和开发人员可能看不到的其他问题的应用程序来说，这种情况是真实存在的。如果将遗留的应用程序代码从桌面VCL应用程序移植到uniGUI，则可能难以检测和修复某些此类问题。
毋庸置疑，根据通用设计模式开发，同时对内存问题，泄漏和bug进行了充分测试与修正，经过这种方式开发的应用程序能够在传统的单进程应用程序模型中无限运行，uniGUI应用服务器非常稳定和健壮是有目共睹的，众所周知，许多开发人员开发的uniGUI应用程序的稳定性几乎没有问题。但是，也必须强调，尽管单一过程模型对于传统的uniGUI应用程序可以被认为是稳定的，但是对于可伸缩性而言不能说两者相同。考虑到稳定性，开发人员面临的主要问题是他们可能面临许多级别的软件缺陷，这些缺陷可能难以检测，修复或找到解决方法。让我们看一下这些缺陷的列表：
- 当前项目代码中的错误。
- 从旧项目移植的遗留代码中的错误。
- 第三方库中的错误。
- 编译器错误。
- Delphi标准库中的错误（RTL，VCL，DB等）
上面的一些bug来源可能非常罕见，比如编译器错误和Delphi库错误，我们不能否认它们的存在。在上述bug中，最常见的错误是直接存在于项目代码中的错误，但只有可能导致内存泄漏，内存损坏或代码死锁的错误对服务器应用程序最有害。Delphi应用程序的本地特性使它们容易受到内存问题的影响，并且在所有这些问题都解决之前，不能实现完全稳定的应用程序。软件开发团队（尤其是大型团队）面临的最大问题是，他们无法始终确保生成相同质量的代码，并且每个新版本都没有缺陷。即使是长时间的压力测试也可能不足以检测，隔离和修复以及隐藏的代码缺陷。
为了解决上述问题，我们需要一个新的服务器模型，它可以更好地容忍带有错误的应用程序代码。这里的主要技巧是增加代码在生产环境中的生存机会，即使它还没有为黄金时段做好准备。 HyperServer旨在提高存在此类条件时的稳定性。 HyperServer通过实现不同的机制来实现这一目标：内部负载平衡和节点回收。负载平衡将在节点之间分配整体服务器负载。节点回收将通过基于预定义规则回收节点，从而减少他们的生命周期。回收将确保节点仅在一段时间内驻留在进程内存空间中。与将应用程序服务器进程无限期地保存在内存中的经典模型不同。
必须要说的是，在这个意义上，HyperServer不应被视为有缺陷代码的解决方案，也不应被视为处理内存问题的工具。 HyperServer既不会修复您的应用程序错误，也不会为它们提供解决方法。
HyperServer和可扩展性
Web应用程序最大的问题之一是它们能够扩展，uniGUI应用程序也是如此。事实上，可扩展性可能是uniGUI应用程序的一个更大的问题，因为uniGUI会话是有状态的并且将所有状态信息保存在进程内存中。我们可以说使用单个进程来服务所有会话的经典应用程序模型可以扩展到几百个会话。这并不意味着您不能在经典模型中拥有数千个会话。从理论上讲，只要您的服务器具有足够的资源且您的应用程序设计具有固有的可扩展性，经典模型中的会话数量就没有上限。这里的问题是，在一个篮子里放1000个鸡蛋是否安全？显然，答案是否定的。然而，如果我们在10个篮子中分配1,000个鸡蛋，每个鸡蛋包含100个鸡蛋，那么每个人似乎都同意。这就是HyperServer诞生的出处。 HyperServer在内部将您的应用程序划分为多个节点，并在这些节点之间分配会话。由于每个节点都是一个单独的进程，因此其会话与其他节点中的会话隔离。因此，Node中的任何问题都只能影响该节点及其会话。
鸡蛋和篮子问题不是与传统单进程应用程序服务器模型相关的唯一问题。另一个问题是在同一进程中保留大量会话可能会导致其他问题。一个问题是uniGUI应用程序是高度多线程的应用程序，当然它需要使用锁来同步某些操作。随着会话数量的增加，这种锁可能会变成瓶颈。虽然在uniGUI中我们尝试尽可能少地使用锁，但它们是不可避免的。在RTL代码和其他涉及的第三方库中也可能出现代码锁。
HyperServer不仅可以管理同一服务器内的节点集群，还可以扩展为管理多个服务器上的多个节点集群。这意味着您将能够在服务器场上运行uniGUI应用程序。这将为使用uniGUI和Delphi开发的Web应用程序添加新的维度。
HyperServer和远程部署
HyperServer为uniGUI框架添加的另一个令人兴奋的新功能是能够远程部署应用程序的新版本，而无需停止服务器。因此HyperServer不仅仅具有稳定性和可扩展性，它还涉及到应用程序服务器运行的连续性和可用性。在传统的单一过程中，uniGUI应用程序更新应用程序相对困难。首先，需要跟踪出流量较低且活动会话很少的时间点，然后，需要关闭服务器，这意味着将丢弃所有活动会话，这时候，你可能需要通知用户，从应用中注销并等待更新完成。
针对以上常见的场景，使用HyperServer可以远程上传新版本的应用程序，其余工作将由HyperServer完成。 HyperServer将逐步更新节点，所有新会话将重定向到运行新版本应用程序的节点，旧版本的节点将在其所有会话都注销后被丢弃并清除。