前言
过去七年，我们设计开发了 Laxcus 大数据管理系统。在设计这套产品前，市场上虽然已经有多种数据产品，却没有一家能够提供一套功能完整、适合各行业使用的通用大数据软件，这是我们设计这套系统的初衷。更重要的原因是，随着大数据应用的快速发展，存储计算规模越来越大，以及需求多样性的增加，导致数据处理过程更加复杂和缓慢。如何解决这个问题，在保证效能的前提下，改变大数据应用现状？针对软硬件性能特点，采用架构/功能一体化设计，增加内聚，减少调用层次和处理流程，改进人机界面，提高分布效能，无疑是一个很好的解决思路。但是这个方案也因为体系化和集成化设计的缘故，需要涉及多个技术领域，在当时的技术条件下，设计这种级别的复杂系统，当中有许多不确定因素，在实践中面临着巨大的研发风险。这些风险归纳起来，主要包括以下几个方面：
对硬件成本和运营成本的考量。
分布环境下，系统稳定性和可靠性的问题。
数据业务和处理规模可扩展性、可承载能力、适用性的问题。
软硬件冗错和处理的问题。
系统安全的问题。
人机接口的设计，包括简化开发、管理、操作流程的问题。
软硬件结合和多平台兼容的问题。
各个子系统整合和设计指标平衡的问题。
在此后七年时间里，经过我们持续研发和版本升级，上述问题已经全部解决，目前 Laxcus 大数据管理系统的主要特征是：
系统总体设计成松耦合架构，在此框架下实现数据业务的可定制、可扩展。
网络通信采用二进制协议，来提高数据传输和处理效率。
依托多集群并行和弱中心管理为基础，实现超大规模、可伸缩的数据存储和计算。
引入自适应机制，使集群具备自组织自管理能力，包括数据处理和软硬件故障管理。
底层数据采用混合存储方案，支持 OLTP 和 OLAP 业务两种业务模式，实现数据即时存取。
数据处理融入 SQL 思想，兼容数据库，满足高并发和高可靠性两种需求。
全新设计的分布算法，保证数据处理流程的简捷高效。
组件化编程，结合容器管理，来减少数据业务的开发和维护难度。
体系化安全策略，将安全管理纳入系统每一个环节。
使用类自然语句命令操纵集群，覆盖全部数据处理和管理工作。
支持全球已知字符集，满足不同国家地区的用户语言使用习惯。
Laxcus 大数据管理系统运行在普通硬件设备上，操作系统涵盖 Linux/Windows，硬件平台包括 X86、ARM、POWER PC、NVIDIA。以下将以2.6版本为基础，结合之前版本，来介绍 Laxcus 大数据管理系统主要的设计、技术、实现，以及发展过程。
图1 Laxcus 大数据管理系统架构。
系统架构
Laxcus 大数据管理系统被设计成松耦合架构。这个松耦合架构可以理解成：为适应复杂分布网络环境，被临时组织起来的工作模型。在这个架构下，所有硬件的设备和软件的模块，以及其上运行的数据处理工作，都被视为一项服务。它们在获得授权许可的条件下，可以自由的加入和退出，以离散、独立、弱依赖的形态存在。其中少量故障不影响系统的整体运行，从而使系统具备极强的稳定性、可靠性、可伸缩、冗余容错的能力。
角色设计和定位
Laxcus 大数据管理系统建立在计算机和网络基础上，通过网络连接管理大量的计算机，形成计算机集群，来组织和实施大规模的数据并行存储和计算工作，这是 Laxcus 大数据管理系统的基本形态。同时，由于计算机集群固有的不稳定特性，需要特别强调软件对分布资源可随机增减的适应性，来弥补计算机集群不稳定造成的损失。这种运行过程中动态波动和需要瞬时感知的特点，完全不同与传统的集中处理模式。这个特点衍生出一系列的新变化，促使我们重新审视产品需要面对的目标和业务需求，并衍生出不同的设计。
以节点为单位的计算集群
在 Laxcus 大数据管理系统的设计里，节点是计算机集群的基本单位。相较与物理性质的计算机来说，节点是一个逻辑概念的单位。以一台实体计算机为例，在它上面可以部署最少一个节点，也可以部署多个节点，共享一台计算机的资源，甚至可以组成一个微型的计算机集群。按照工作属性划分，节点分为四种类型：前端节点、网关节点、工作节点、管理节点。前端节点负责发起任务请求和显示数据处理结果，类似我们通常所说的“客户端”。网关节点将 Laxcus 集群分成内外彼此隔绝的两个部分，它处于“边界”位置。对外，它接受来自前端节点的任务请求；对内，它将前端节点的任务请求转发给集群内部的工作节点处理，同时对外部网部屏蔽集群内部拓扑结构，起着“反向代理服务器和防火墙”的安全作用。在集群的内部运行着工作节点和管理节点。工作节点承接网关节点的任务请求，负责组织和实施具体的数据处理工作。当数据处理工作完成后，将结果返回给边界节点。管理节点在集群里是一个“维护者”的角色，它没有任何实质的数据处理任务，只起到管理和控制集群的作用，包括对下属的网关节点和工作节点的检测和协调。在 Laxcus 集群里，前端节点的部署和维护由是用户来实施，没有特别明确的要求。被大量部署的是工作节点，以及少量的网关节点，和一个管理节点。 Laxcus 大数据管理系统将它们组织起来，来完成许多大规模的数据存储和计算工作。这些大型数据处理工作的工作量，通常是一台或几台计算机不能完成，或者短时间内不能完成的。
超大规模集群
在 Laxcus 大数据管理系统的语义规范里，“域”被定义为计算机集群的单位。在一个计算机集群里，管理节点处于核心地位，负责监督、维护整个集群的运行，它的作用非常重要。管理节点实质也是一台计算机，也受到自身 CPU、内存、网络接口等硬件性能的限制，随着集群内计算机数量的增加，它的管理负荷也在随之升高。因为有这样的限制，在实际部署时，一个集群内的计算机数量是不可能无限增加的。根据我们对多套硬件和数据应用的组合测试显示，当一个集群内的节点数量达到3000至8000这个范围时，会出现管理峰值，超过这个范围，稳定性会大打折扣。但是在实际使用中，用户对数据存储和计算需求总是在持续增加的，这样就产生一个矛盾：如何在保证集群稳定运行的情况下，仍然能够满足用户更大规模存储数据和计算数据需要？多域并行集群就成为这样的一个选择。
Laxcus 的多域并行集群是对现有单域集群的升级和改进。通过把原来多个孤立运行的集群连接起来，在这些集群之上，建立更高一层的管理模型，形成一个两级的管理架构。这个两级架构的集群，在 Laxcus 中被称为“主域集群”，原来的集群成为它下属的子集群，这个集群被称为“子域集群”。子域集群接受主域集群的管理，实时向主域集群汇报自己的运行状态。按照 Laxcus 对集群的设计定义，子域集群需要集中在一个物理环境里，主域集群允许跨地域分散存在。就是说，如果 A 子域集群的机房在北京，B 子域集群的机房在广州，天津机房是 C 主域集群，只要它们之间能够通过网络进行通信，就可以在天津的 C 主域集群管理下协同工作。
通过这样的组合，集群的节点数量获得巨大的提升，极大地拓展了数据存储、计算范围，满足了当前包括未来一段时间内数据处理业务的需要。在跨域测试中，主域集群管理下的计算机节点数量可以达到百万级的规模，数据的存储和计算能力可以达到EB量级。
多用户共享
Laxcus 是多用户系统，支持任意数量的用户同时使用计算机集群。用户通过远程登录的方式接入系统。区分用户身份的唯一标识是账号，账号由用户名和密码组成。在一个系统里，用户名是唯一的，一旦建立不可修改，但允许修改密码。建立账号，包括后续的账号管理工作由系统管理员或者拥有管理员权限的用户来实施。用户在获得管理员的授权后，就拥了建立、管理、操纵数据的权力，可以在自己的数据空间里，执行写入、更新、删除、计算、查询等一系列操作。从这一点来说，用户与数据的关系，更接近博客、推特等网络应用，而与关系数据库中的用户、数据的定义有所区别。在逻辑空间里，系统中的每一个用户和用户持有的数据都是独立的，彼此不存在关联，也不会发生冲突。为了充分发挥多集群并行处理能力，实施大规模并行处理工作，在权限许可的条件下，Laxcus 允许一个账号同时从多个地址登录，执行各种数据操作。
低成本的硬件设备
大数据系统运行依赖于计算机集群。部署计算机集群，需要大量的计算机，以及连接它们网络通信设备，这对所有运营大数据的企业和机构来说，都是一笔庞大的开支。而大数据分布处理和“以多胜强”的特点，更强调运用软件技术和算法所带来的效能，对硬件设备本身并没有太多的要求。所以，低价、性能稳定的硬件设备成为首选。 具备这样特点的硬件设备，目前有很多选择，典型如 PC 架构的 X86 系统，还有移动架构的 ARM 系列，Laxcus 都实现了支持。
实际上，但是无论上述哪款系列的计算机，在稳定性和可靠性上都不能和专业服务器相比，发生故障和宕机的可能性比服务器要大得多。针对这个情况，Laxcus 采用了一个简单的办法：冗余和去中心化，来解决这个问题。实现这项功能的要求是 Laxcus 具备实时的节点感知能力，当集群内任何一个节点发生故障，都能很快被 Laxcus 捕获到。在确认故障节点失效后， Laxcus 将执行“隔离”方案，将故障节点从集群中排除，然后从集群中寻找一个新的备用节点，或者通知其它同类型的节点，来分担故障节点的工作。排除故障的处理过程，都会同步通知给集群的维护管理人员。在执行数据处理工作时， Laxcus 要确保每个节点是正常且有效的，才执行数据处理工作。 这项措施简单且有效，在多次故障和修复过程中，都验证了这个结论。
弱中心化管理
在 Laxcus 集群里，大量计算机被用来执行数据处理工作，管理节点做为集群的核心，起着监督和协调的作用。如果管理节点的工作内容过多或者复杂，势必将增加管理计算机的工作负荷，降低处理效率，延长处理时间，不能对下级节点的请求及时做出反馈，减弱对集群的监督和协调作用。在此前的几个运行环境，上述情况都分别发生过，是造成系统稳定性变差，影响集群正常运行的重要原因。所以，进一步分散管理节点的工作内容，减少计算开销，降低工作负荷，是提高集群稳定性的主要办法。“弱中心化”思想即由此衍生而来。
鉴于此前的教训，通过对1.x版本的运行统计和评估，在2.0版本中，管理节点的工作被压缩到只有两项内容：监听节点心跳、记录节点元数据。这两项工作由子节点上传，管理节点负责汇总和分析，网络通信量极少，内容简单，计算量非常少，并且只有计算内存里存储和执行，不存在计算瓶颈和计算压力，管理节点的工作负荷因此大幅度减少，从而提高了集群的稳定性。目前因为管理节点问题造成的故障已经基本消失。
负载自适应机制
截止到目前，Laxcus 已经部署到很多应用场景中。这些系统在运营过程中，我们通常不限制用户发出的命令数量，这种忽略经常导致集群的某个节点涌现大量的计算任务，发生超载现象。例如在此前的一次例行检测时，就发现有一个计算节点并行着8000多个计算任务。面对如此庞大的计算压力，如果任由这些现象持续下去而不加以控制，计算机宕机现象随时可能发生。
在1.x版本中，负载控制是由管理节点来监视和协调控制的。在实地运行中显示，这种处理方式虽然达到了协同节点工作和平衡集群负载的目的，但是也存在很多隐忧，主要体现以下几个方面：
每个节点的负载情况都被反馈到管理节点上，增加了管理节点的数据存储量和计算量，不利于管理节点的弱中心化管理。
负载的平衡和分配调度依赖于网络通信，当发生大面积超载时，往往也意味着网络中存在大量数据传输，这时的通信成功率会直线下降。实际上为了保证通信成功，就需要进一步加大了管理节点通信量和工作负担，这种情况对管理节点稳定运行有巨大影响。
负载控制要求实时处理，如果管理节点汇聚了大量任务请求，很难做到实时处理，延时将不可避免发生。同时下属的节点收不到命令，超载会持续下去，宕机的可能性大幅增加。
整套过载处理机制过于复杂，管理成本颇高，不符合简单化的设计原则。
鉴于以上问题，2.x版本的负载控制，取消了以管理节点为中心的协同处理方式，改为分散到每个节点的自适应调节。这样，当节点在执行计算任务的时候，也监视自己的运行负载。如果发生超载现象，可以立即做出反应，停止分配新的计算任务，或者根据运行任务的权重和资源占用比率，有选择地要求某些任务进入暂停、休眠状态，以达到即时发现即时处理，降低运行负载的目的。原来管理节点承担的平衡运行负载的工作，交给网关节点来协调解决。新的负载处理方式避免了上述1.x版本的问题，同时简化了负载管理的处理流程，提高了运行系统的稳定性。
命名
在 Laxcus 体系里，命名是一组由文字和数字组成的有意义的字符串，是网络设备、分布目录、任务接口、数字数据资源等各种实体资源抽象化的表示，被应用到所有与数据处理有关的环节上。通过命名，系统在运行过程中，屏蔽了许多裸露环节，简化了分布计算方法和计算流程，使复杂的网络运行环境变得简单，同时减少和避免了因为网络拓扑和数据分散可能导致的错误和漏洞。命名只在系统运行过程中产生，被存储到内存里，在节点之间分发，随时间和节点的变动同步发生变化。每个命名在系统中都是唯一的，不允许出现重叠现象。因为命名只应用于系统内部环境，所以它对用户是透明的，注册用户和系统管理员不必在意，也无需了解它的使用、执行情况。
设计命名，对简化系统架构设计，提高系统稳定性、保障系统安全有重要作用。
全语种字符
在2.6版本之前，Laxcus 大数据管理系统只支持中文和英文两种语言的输入和处理。但是随着全球范围内用户的增加，根据用户语言习惯，提供和支持本地字符集，来满足全球用户使用本地文字输入参数和操纵数据处理工作，就显得非常迫切了。所以，2.6版本的一项主要改进工作就是支持全球已知主流字符，在 Laxcus 平台实现各种语言文字的统一输入和处理。
这个修改工作包括两个部分：可视化部分和非可视化部分。可视化部分由 UI 界面和各种字符命令组成，它为用户提供直观的文字输入和显示。非可视化部分承接可视接口的输入，并把数据处理工作贯穿 Laxcus 分布处理的所有层面，最终进入存储层保存。
目前，Laxcus 大数据管理系统已经完整支持不同语言用户在同一个平台的输入和输出，系统会正确识别这些文字，不会产生乱码问题和导致运行错误。
节点的分类
按照设计定义，Laxcus 集群被分为内部和外部两个网络环境。内部网络由集群的所有权人负责实施和管理，为保证集群能够有效可靠运行，需要遵守一系列的集群部署和管理规定。外部网络是用户负责范围，用户可以通过互联网或者 VPN 的方式，远程登录进入集群，通过交互命令传达到集群上，执行数据操作。这样一个布局，可以理解为集群层面的客户机/服务器结构。另外，如果集群没有对外服务的业务，也可以把整个集群部署在内网里，成为一个纯粹的 Intranet 集群。
由于集群这些特点，我们在选择目标硬件设备时，利用集群多节点冗余的属性，和以此为基础研发的分布管理和容纠错技术，使 PC 级的硬件也能很好地运行高端硬件设备才能完成的数据处理工作，并且在价格费用、并行处理规模、可扩展性方面，远超高端设备。这为降低用户运营成本和提高工作效率开辟一条新的通道。
如前所述，节点是 Laxcus 集群的基本单位，由前端节点、网关节点、工作节点、管理节点4类节点组成。理论上，一台物理计算机上可以部署任意多个节点，包括组成一个小型的集群。从节点的工作性质来看，它具有双重身份，即是服务器又是客户机。当它做为服务器使用时，它接受其它节点的命令请求和执行数据处理；当处于客户机状态时，又可以向其它节点发送命令。软件层面上，节点实质是操作系统下的一个进程，在后台运行，通过网络与外界保持联系。在 Laxcus 2.0 版本中，节点共设计有4类11种节点。对每一种节点，我们都详细规定了它的工作内容和处理范围，以下将逐一进行介绍。
图2 Laxcus 大数据集群拓扑结构
Top 节点
Top 是管理节点，在 Laxcus 集群的二级管理构架中，是整个集群的核心，必须保证绝对存在。集群中的其它节点都是 Top 节点的下属节点。按照 Laxcus 集群管理规定，这些节点的工作，必须在 Top 节点启动后启动，在 Top 节点停止前停止。因为 Top 的顶级管理节点身份，它节点只负责最关键的数据资源管理工作，包括用户账号的建立、删除、查询，用户操作权限的授权和回收，数据库资源的分配、释放、检查。Top 有两个直接的下属节点：Home、Aid，Top 要接受它们的注册，以及监测它们的运行状态。由于 Top 节点在集群中的重要性，它的故障将造成整个集群的管理混乱，所以在实际部署时，要求一个 Top 节点在运行的同时，还应该有最少一个 Top 备用节点。为了区分这两类节点，在 Laxcus 集群管理规定里，我们把接受和执行业务处理中的 Top 节点称为 Master 节点，备用的 Top 节点称为 Monitor 节点。Monitor 节点的工作，除了监视 Master 节点运行外，还会同步备份它的数据资源和运行记录。当 Master 节点发生故障失效后，Monitor 节点将启动故障切换过程，接手它的全部管理工作。如果有多个 Monitor 节点，它们会通过协商的方式，在它们中间推举一个 Monitor 节点成为新的 Master 节点。新的 Master 节点会要求原来的下属节点重新注册它的下面，来保证集群继续有效运行，同时新 Master 节点还把故障和切换过程通知集群管理员，由管理员来负责后续的故障计算机检查、维修工作。
因为 Top 节点只负责数据资源管理，以及与 Home、Aid 节点保持少量的通信，所以通常情况下，它的工作负荷很轻。
Home 节点
Home 是管理节点，在 Laxcus 集群二级管理架构中，它是子域集群的核心。对上，向 Top 节点注册，和接受 Top 节点的管理；对下，接受下属节点的注册，以及监督和协调它们的运行。在 Laxcus 集群里，工作节点全部运行在 Home 节点下面，并且弱中心化管理思想也主要体现在 Home 节点上。运行过程中，它只负责两项工作：追踪工作节点运行状态，收集和分析工作节点元数据。这些工作的数据量和产生的计算量都很小，不会对 Home 节点正常运行构成影响。与 Top 节点一样，Home 也要求有一个 Master 节点和最少一个 Monitor 节点。当 Master 节点发生故障时，Monitor 节点可以接替 Master 节点的工作。
Archive 节点
Archive 节点是工作节点，注册到 Top 节点下面，为用户的分布任务组件提供存储、管理、转发服务。在实际使用时，Top 会把它重定向给关联的 Home 节点，再经过 Home 节点结合自己的数据资源进行判断后，分派给自己的下属节点，让它们与 Archive 节点进行数据交互。与 Archive 节点进行直接数据交互的节点有 Data、Work、Build、Call 四种节点，它们将根据自己的业务需要，请求关联的分布任务组件，并把分布任务组件下载下来，部署在自己的节点上，为用户提供分布数据处理。同时，每一个与 Archive 节点执行过成功交互的节点，Archive 节点会记录下它们的信息，当有新的分布任务组件上传后，Archive 节点会把这些新的分布组件，同步推送给这些节点，使得用户在发布分布任务组件后，集群可以立即部署和生效，省却了用户的等待时间。
按照上述流程介绍，实质上，Archive 节点是跨子域集群存在的，我们为 Archive 节点设计了一个 Top/Home/Home 下属节点的三层定向机制，每个 Archive 节点可以为整个集群提供分布任务组件服务，而不必拘泥于某个子域集群的限制。管理员也可以按照自己的需要，设置规则，为不同的用户选择合适的发布空间，提高了管理灵活性。
Log 节点
Log 节点是工作节点，注册到 Home 节点下面。为本集群的其它节点保存它们的日志数据，并提供格式化的日志检索服务。这样的工作内容使得 Log 节点成为 Laxcus 集群里最简单的一个节点。对于上传的日志，Log 节点将根据每个节点的类型和地址，在磁盘上分别建立目录和文件，然后按照时间的格式排列保存下来。在 Laxcus 集群里，各节点上传的日志内容，通常是它们的工作流程和运行错误，这些信息为分布状态下的数据追踪和分析、程序调试、快速定位和判断节点运行故障提供了重要的依据。所以 Log 节点的工作虽然简单，但是非常重要，这也是为什么要单独把日志单独保存并且列为一类节点的原因。
Data节点
Data 节点是工作节点，注册到 Home 节点下面，提供基于磁盘和内存的数据存取服务。在 Laxcus 集群里，Data节点保存着整个集群的数据，是所有数据处理的源头。为了保证正确的数据处理，我们在 Data 节点上，为数据处理设计了一系列的可靠性保证，包括数据完整性、一致性要求，以及各种数据纠错和冗余能力。这些元素的加入，使得 Data 节点的复杂性，远高于集群中的其它节点，它在集群中的重要性，也仅次于 Top、Home 节点。
另外 Data 节点与其它节点不同的是，Data 节点具有“级别”概念，在运行时，被分为主节点（Prime Site）和从节点（Slave Site）两种类型。它们的区别在于，主节点具有“读写”能力，可以执行全部数据操作，包括添加、删除、更新、检索。从节点只拥有“读”的能力，即数据检索操作。这个特点在实际应用中是非常重要的，它为 Laxcus 集群的许多初始指标，如数据冗余、平衡计算、并行处理，提供了基本的保证，成为了 Laxcus 集群实施大规模数据处理的必要条件。
Work 节点
Work 节点是工作节点，注册到 Home 节点下面，提供数据计算服务。在 Laxcus 集群中，Work节点承接来自Data节点的数据，大量重要性高、计算量大的数据处理工作都发生在 Work 节点上，这使得 Work 节点在整个 Laxcus 集群中，成为工作负荷最重的节点，也因此成为体现数据处理效率最关键的一环。
为了获得更高的数据处理效率，在 Laxcus 2.0中，Work 节点通常会把有限的硬件资源集中起来，采用任务队列的手段和快进快出的原则，来解决几个最重要的数据计算工作，从而避免因为无谓的任务空耗硬件资源，而其它需要作业的任务又不能获得工作许可的问题。使得 Work 节点在应对大规模数据处理时，能够充分利用硬件资源，来加快数据计算速度，同时也提高了数据处理效率。
Build 节点
Build 节点是工作节点，注册到 Home 节点，提供 ETL 服务。ETL 是的提取、转换、装载（extract、transform、load）的简称，这个名词很好地描述了一种数据处理过程，是当前许多商业数据应用和互联网数据处理业务的重要组成部分，可以理解为数据计算的前奏和加速器。ETL的核心要旨是把各种数据，按照各自不同的需求，经过重新组织整理后，形成新的数据。这些新的数据，将成为后续数据计算的必要材料。
在许多业务处理中，我们通常是采用 ETL 的方式，把一些数据组合工作从数据计算过程中分离出来，做成一个独立的单元，提前完成，来供后面的数据计算使用，以达到简化数据计算流程的目的。实际上，这种简化的数据计算工作，在很多大规模数据处理业务中使用时，不止是简化了数据处理流程，往往还获得了更高的处理效率。
Call 节点
Call 节点是网关节点，注册到 Home 节点下，提供分布数据管理和任务调度服务。在 Laxcus 集群中，Call节点是一个“中间人”的角色，起到类似路由器的作用。对内，它收集 Data、Work、Build 节点的元数据，并把这些元数据按照各种要求重新组合，保存在内存里。对外，它只接受 Front 节点的注册和命令请求，同时具有对外屏蔽了集群内部拓扑结构的作用，防止可能由外部发起的网络攻击，即使因此发生宕机现象，也可以做到尽量避免波及到集群内部其它节点。当收到 Front 节点的命令后，它将按照命令的要求，为 Front 节点筛选集群内部的数据资源，和定位目标节点。在目标节点完成数据处理后，Call 节点把数据结果返回给 Front 节点，从而完成一次数据处理工作。
与 Archive 节点一样，Call 节点也是可以跨越多个子域集群的。至于是否需要跨越，则由注册的 Front 节点来决定。当 Front 节点需要的数据分别存在于多个子域集群时，那么 Call 节点将自动发生跨越子域集群行为。
Aid 节点
Aid 节点是网关节点，注册到 Top 节点下面，提供账号和账号资源的管理服务。Aid 节点唯一的服务对象是 Front 节点，所有类型的 Front 节点都要首先注册到 Aid 节点下面，才能获得进入集群和操纵数据的权力。Front 节点发出的每一道命令，当通过 Aid 节点审核后，才能交给 Call 节点并转发到集群内部。与 Call 节点一样，Aid 节点也对 Front 节点屏蔽内部网络环境，避免可能的网络攻击行为影响到内部集群运行。Aid 节点这种布局和处理方式，具有分解数据业务负荷和保证集群安全的双重作用。
在 Laxcus 2.0版本中，Aid 节点新增加事务处理能力，这样命令在获得核准前，为了防止命令之间可能存在的事务冲突，Aid 节点给每个命令都增加了事务检查环节。
Front 节点
Front 节点是 Laxcus 集群唯一的前端节点，由用户操作和使用，被要求注册到 Aid 节点下面，为用户提供进入集群和操作集群数据的能力。当 Front 节点成功注册到 Aid 节点后，Front 节点会向 Aid 节点请求关联的 Call 节点地址，然后主动与它们建立联系，来获得执行命令的能力。
在 Laxcus 集群里，Front 节点被分为三种类型：字符界面的控制台、图形界面的终端、没有操作界面的驱动程序。前两种被用户直接使用，分别针对了 Linux 和 Windows 用户的使用习惯。用户在窗口上输入命令后，通过 Aid、Call 这两道网关节点的审查，被发往集群内部处理。后一种是嵌入到其它软件中使用（如 Apache、Tomcat 这类 Web 软件），命令由这些开放接口传递过来，经过 Aid、Call 节点审查通过，发往集群内部处理。Front 节点运行过程中，显示的语言默认与操作系统自动匹配，用户不用做任何设置。
三类 Front 节点允许同时并行存在，每一类又可以同时并发多组命令，所有命令都在 Aid 节点管理下，各自执行自己的数据处理工作，不会发生冲突。至于命令最大并发数，则由集群管理员分配，Aid 节点负责执行。
图3 Front 控制台字符界面
图4 Front 终端图形界面
Watch 节点
Watch 是工作节点，可以选择注册到 Top 或者 Home 节点下面，提供监视主域集群或者子域集群的服务。在 Laxcus 集群里，Watch 节点是唯一完全由集群管理员操纵的节点，它也是 Laxcus 集群另一种拥有图形操作界面的节点，为集群管理员提供可视化的管理工作。集群管理员通过 Watch 节点，能够实时追踪和检查所有节点、所有用户的当前状态。当集群中的节点需要通知管理员，或者感知、捕获到运行故障时，也会通过网络传递给 Watch 节点，Watch 节点将以文字、图像、声音的方式，提醒管理员加予关注，或者要求管理员去排除已经发生的故障。
图5 Watch 节点图形界面
松耦合架构
做为 Laxcus 大数据管理系统最重要的组成部分， Laxcus 架构设计经历了从紧耦合到松耦合的过程。在0.x版本里，我们采用了紧耦合架构。紧耦合架构如下图所示，它的本质是一个客户机/服务器模型，采用同步工作模式。客户机发起请求给服务器，服务器收到，根据请求做出应答，然后反馈给客户机。这种架构最典型的应用就是我们每天都用到的WEB服务。它的优点是简单，设计容易、开发周期短、能够快速投入部署和应用。在 Laxcus 集群的早期运行中，这些特点都得到有力的验证。
图6 紧耦合架构
情况在以后出现了变化。随着 Laxcus 集群规模的不断扩大，业务量的不断增加，尤其是数据计算量、计算时间成倍数的增长后，紧耦合架构渐渐不堪重负，缺点开始不断暴露出来，主要集中在以下几个方面：
无法支持大规模的计算业务。因为大数据业务对计算机资源占比普遍很大，导致多任务并行能力有限。根据我们在一台 Pentium IV 2.G + 4G 的机器上做的测试，当并行任务量达到100左右的时候，计算机已经发生超载现象。
无法限制任务载荷，管理设计难度大。由此导致计算机不能控制超载现象，而超载对硬件伤害非常大，会严重降低计算机稳定运行能力和使用寿命。
网络资源消耗大。紧耦合的本质是同步操作，而同步操作在数据的发送后和返回前，有很大一段时间是空闲的。这种空闲状态下的网络占用，是对网络资源的极大浪费，尤其当使用TCP通信时。
安全控制力度差。因为服务器直接暴露给客户机，容易引发网络攻击行为。
程序代码之间关联度过高，不利于模块化和抽象化处理。
以上现象最终导致系统稳定性变差。
鉴于以上问题，我们重新考虑了系统架构设计，并最终决定将紧耦合架构改为松耦合架构。新架构是原来的客户机/服务器模型之间，加入一层代理服务器（Agent），即把 CS 模型改为 CAS 模型，同时把同步处理模式改为异步处理模式。在新的架构下，客户机的角色不变，代理服务器承担起与客户机通信，和对客户机的识别判断工作，服务器位于代理服务器后面，对客户机来说不可见，它只负责数据处理工作。
在设计松耦合架构的同时，结合新增加的代理服务器这个角色，我们又设计了一套名为：“Invoke/Produce”的任务调度模型。它针对数据处理工作实施异步的抽象化处理和分组分级管理。原来的数据处理和业务逻辑套用这套机制后，程序代码基本不用修改，转移到CAS模型上运行就可以了。
图7 松耦合架构
松耦合架构设计和代码修改完成后，我们在原来的集群上，和紧耦合架构做了各种对比测试。其结果是不仅解决了紧耦合架构上存在的所有问题，而且其中很多技术指标还超出了我们的预估，主要表现以下一些方面：
多任务并行处理能力获得极大提升。同样是上述的数据处理，紧耦合架构只能支持最大约100多个并行，在松耦合架构上增加到10倍。
同步实现了负载自适应机制，避免了超载现象。
对运行任务实现了随机调度和随机控制，进一步避免了持续超载现象。
基本杜绝了网络攻击行为。由于代理服务器的隔绝和筛查作用，同时结合其它安全管理手段，外部攻击在代理服务器处就被识别和过滤掉了，保护了后面的服务器不受影响。
Invoke/Produce 机制改进了程序的模块化和抽象化，有利实现更复杂的数据处理。
异步处理减少了网络资源消耗和操作关联。
综合以上措施，它们共同增强了系统稳定性。
以下我们用一张表格，来对两种架构的性能和特点做个比较总结：
| 紧耦合架构 | 松耦合架构 | |
|---|---|---|
| 工作方式 | 同步 | 异步 |
| 业务逻辑关系 | 集中控制 | 分散控制 |
| 代码关联依赖 | 强 | 弱 |
| 设计开发难度 | 容易 | 复杂 |
| 响应能力 | 快 | 略低于紧耦合架构 |
| 时效表现 | 实时 | 延时 |
| 适用范围 | 简单计算 | 复杂计算 |
| 安全表现 | 弱 | 强 |
| 应用领域 | 小规模并行处理环境 | 大规模、超大规模并行处理环境 |
| 系统稳定性 | 弱 | 强 |
表1 紧耦合/松耦合性能对比
网络通信
Laxcus 大数据管理系统网络建立在 TCP/IP 网络之上。从1.x版本开始，同时支持 IPv4 和 IPv6 两种网络地址。网络通信是 Laxcus 体系里最基础和重要的一环，为了能够利用有限的网络资源，获得最大化的使用效率，我们根据大数据网络环境的特点，设计了一套专属网络通信协议，以及在此协议基础上实现的多套网络通信方案，它们共同组成了 Laxcus 集群的网络通信基础。本章将以 TCP/IP 协议为起点，介绍与网络通信有关的各个组成部分。
FIXP 协议
Laxcus 采用 FIXP 协议通信。FIXP 协议全称是“自由信息交换协议（Free Information eXchange Protocol）”协议。这是一套建立在 TCP/IP 协议之上的应用层二进制通信协议。二进制字序采用小头编码（Little Endian）。协议具有平台独立、上下文无关、结构简单、数据尺寸小等特点。
协议结构
如图8所示，协议结构布局按排列顺序由三部分组成：命令、消息、数据实体。命令分为两种：请求和应答，命令的作用是说明本次通信的基本属性。每次通信由发起方发送请求命令，受理方返回应答命令。消息在命令之后出现，消息在一次通信协议中允许出现任意多个，消息中携带本次通信需要的多类附属信息。消息之间是衔接的，彼此无分隔标记，通过消息头中的标记长度加以区别。在最后面是数据实体部分，数据实体包含本次通信所要传递的内容。这些内容可以是任意格式的，如音频、图像、数据库数据、各种元数据等。数据实体是一个可选部分，是否存在会在消息中注明。比如通信发起方通常是不需要传递数据实体的。
图8 FIXP 协议结构
命令结构
如图9，命令是一个56位（7字节）的数字序列。第一个8位的标识的作用是区分当前是请求命令或者应答命令。之后的协议版本号占用16位，协议版本号是可变的，不同的协议版本号代表不同的协议格式，在应用中分别有不同的解释。目前协议的最新版本号是256(0x100)。 命令的主要区别在第24至40位，请求命令需要提供两个8位的主命令和从命令，说明本次操作的作用目标，应答命令返回一个16位的应答码，确认本次请求是接受、还是因为其它原因拒绝。最后是16位的消息成员数，理论上，一次 FIXP 通信最多可以携带65535个消息。
图9 命令（请求/应答）结构
消息结构
如图10，消息是一个不定长的数据结构，由键、类型、参数长度、参数组成。键占用16位，每个键都有一个固定的定义，键理论上有65536个，目前已经使用了大约100个。类型占用4位，说明后续的参数属性，包括布尔、短整数、整型、长整型，单浮点、双浮点、二进制数组、字符串、压缩二进制数组、压缩字符串。参数长度是一个12位的值，参数的实际尺寸由参数长度说明。需要特别指出的是，数值型参数具有字长压缩能力，例如一个整型数0x20，按照计算机字长标准需要占用4个字节，但是实际尺寸只有1个字节。这时参数长度会说明为1，忽略前面3个0。如本章开篇所述，数值型参数遵循小字头格式（Little Endian）。
图10 消息结构
通信方案
我们在 FIXP 协议基础上提供了四种通信方案。这些通信方案将根据所在环境条件和任务的不同需求，实现有区别的通信，以达到节约网络流量，降低运行负载，提高计算效率的目的。
TCP 通信
TCP 通信建立在 TCP/IP 协议的 TCP 堆栈之上，主要用来处理持续性高的、流量大的数据传输。如数据块的分发，以及 Diffuse/Converge 分布计算传递的数据等。在 Laxcus 集群中，它们是主要的通信流量，占用了大量的网络带宽，严重的时候会发生网络阻塞，影响到集群正常运行。为了避免这种现象，TCP 通信会受到流量控制机制的限制，通过采用降低数据传输流量的办法，腾出一部分网络带宽，来保证其它通信业务的数据传输和集群的稳定运行。
UDP 通信
UDP 通信建立在 TCP/IP 协议的 UDP 堆栈之上，主要针对于非持续、可靠性不高、流量小的数据传输。在 Laxcus 集群中，基于 UDP 传输的 FIXP 协议包，数据尺寸普遍介于20至300字节之间，小于一个 IP 包的最大传输单元（MTU），其中以网络监控包为主，测试节点状态的心跳包是最常用一种。目前 UDP 通信是 Laxcus 集群使用频率最高的通信方案。
KEEP UDP 通信
UDP 的优点在于对计算机的资源占用率低，缺点是数据通信不稳定，存在丢包现象。TCP 恰恰相反，可以提供稳定的数据通信通道，但是对 TCP/IP 堆栈的资源占用率高。在 Laxcus 集群里，存在着大量即需要保持稳定通信，又希望采用 UDP 的网络通信业务。如何在拥有二者优点的情况下又避免它们的缺点，答案就是“KEEP UDP（可持续的包通信）”。KEEP UDP 是我们在 TCP 和 UDP 之间，为 Laxcus 集群网络通信设计的一种过渡方案，通过在 UDP 基础上模拟 TCP 通信过程，为 UDP 数据提供稳定的通信保证。这个方案的实质就是将原来在 TCP/IP 堆栈上进行的包的分组和重组的工作，转移到 Laxcus 控制的工作线程上去执行。在减轻 TCP/IP 堆栈压力的同时，还能够根据当时需求，自由定义一些对包的特殊规则。目前 KEEP UDP 主要用来执行 RPC 处理和传输网络日志，这些都是数据流量不大但是要求可靠传输的通信业务。
RPC 通信
RPC（远程进程调用）的出现由来以久，是一种非常优秀的网络通信方案，至今仍在被广泛使用。它通过隐藏网络两端通信的方式，使网络上两台计算机之间进行的网络调用类似本地 API 调用的过程。这样就极大地简化了开发者对网络编程的难度，提高了工作效率，减少了出错的机会。
Laxcus 包含了对 RPC 的实现，它的通信建立在 TCP 和 KEEP UDP 通信基础之上，通过在本地嵌入接口和对开发者屏蔽网络流程，实现 RPC 调用处理。目前 Laxcus 集群里许多复杂的、安全度高的网络通信都是采用 RPC 方案执行。
通信检测
集群运行过程中，发生的很多故障都与网络和网络设备有关。根据统计，这些故障大致包括：线路损坏、插口松动、电磁影响、网络阻塞、网络设备损坏。其中有些是硬件故障，有些是暂时性的网络故障。判断故障的有效手段是通过发送 ICMP 包来检测网络可达。这项测试可以由单机处理，必要时需要多个节点对一个地址共同测试，然后汇总测试结果得出答案。系统将判断故障是暂时性的网络问题或是不可恢复的物理故障。如果问题严重，将报告给系统管理员，通过人工处理来解决故障问题。通信检测在所有节点都会执行，是体现集群弱中心化和自维持能力的必要手段。
通信服务器
通信服务器是节点管理下的一个工作模块，采用 FIXP 协议通信。通信服务器在启动时分别绑定 TCP/UDP 两个模式的监听套接字（SOCKET），套接字参数在配置文件中定义。根据系统的规定，工作节点的套接字地址在启动时由系统随机选择，管理节点的套接字必须有固定的 IP 地址和端口。因为只有管理节点的地址固定，工作节点才能够在网络上找到管理节点。通信服务器不主动发起通信工作，只接收外部发来的命令。在收到命令后，分派给下属的任务线程完成具体的任务处理。通信服务器还承担网络通信安全的职能，确保通信过程中，网络两端传输的数据是正确和可信任的。通信服务器的安全管理是一个可选项，是否使用由用户决定，在配置文件中设置。
全局时间
在网络通信过程中，为了能够辨别各节点之间数据处理的先后顺序，需要一个统一的参数来标识它们当时所处的位置。这个参数被称为全局时间，也称为主时钟或者时间轴。全局时间以集群中 Top Master 状态节点的操作系统时间为标准，其它所有节点必须遵从这个时间定义，与 Top Master 节点保持一致。全局时间在节点启动时向所属上级管理节点申请和获取，在本地操作系统上设置，误差要求不超过1秒。全局时间目前已经使用在网络日志、网络计算，以及主块冲突、数据冗灾处理中。
流量控制
在造成集群运行不稳定的因素中，有相当大一部分原因是网络传输流量过大所致，如果可以控制每项数据业务的通信流量，让它们以公平和合理的速率传输数据，对于改善集群运行的不稳定状况，将有很大促进作用。Laxcus 采用“等/停传输机制”来控制每项工作的网络传输速率，这是一项 TCP/IP 应用层的技术，是“Invoke/Produce”任务调度模型的一部分，具有实时判断网络流量和错误重传的能力。可以根据当时的网络状况，选择合适的传输速率去传输数据，如果丢包率增加，表明当前网络负载过重，就会延迟数据发送间隔。流量控制对上层是透明的，不用对它做任何管理控制措施。目前 Laxcus 集群所有数据处理业务中，网络通信都默认使用“等/停传输机制”。根据我们对各种数据流量的检测显示，当网络通信启用“等/停传输机制”后，网络传输速率是未启用前的70% - 84%左右，但是网络在面对重负载的数据通信时，它的适应能力增强了。所以，总体而言，这对提高系统稳定性是有利的。