前面介绍了Laxcus分布式操作系统的体系结构、分布式应用软件的组成要素，以及终端和边缘端编程的入口函数、抽象方法、注意事项，今天来介绍编写云端应用软件的规则和注意事项，这是Laxcus分布式编程最重要的部分，相比终端和边缘端要复杂，咱们先从几个基本的概念讲起。
一、阶段和阶段命名
一个云端应用软件由多个不同工作属性的应用组件组成。它的运行，是应用组件不断分裂和聚合，直到最后输出结果的过程。在这个执行过程中，系统需要为应用组件分配大量各种类型的节点，出于安全原因，应用组件会被置于节点的容器里运行，为应用组件分配CPU、内存、硬盘、网络等资源，同时系统还要实时监视和控制它们的IO行为和处理范围，以及随时定位找到它们。在Laxcus分布式操作系统的分布环境里，需要一个标记符来识别应用组件和节点、应用组件和容器的对应关系，这是系统为应用组件分配资源之前的必须手段，提供这项功能的，就是“阶段”。阶段是一个抽象概念，开发者们可以把它理解为Laxcus分布式操作系统为云端应用软件定义的一个分布处理步骤。
如果把“阶段”用计算机程序可以理解的方式表达出来，对应到应用组件上，就是“阶段命名”。这是一组字符串，一个标准的阶段命名是下面这个样子：
To:{2A97516C354B68848CDBD8F54A226A0A55B21ED138E207AD6C5CBB9C00AA5AEA}/Benchmark.Sort.Geon
这组字符串的内容含义是：
<1> To：阶段命名，也是Laxcus分布式操作系统的保留关键字。To阶段命名对应Work节点和Work节点上的To阶段容器。
<2>2A97516C354B68848CDBD8F54A226A0A55B21ED138E207AD6C5CBB9C00AA5AEA，用户的SHA256数字签名，对应明文“demo”。如果用户手工输入阶段命名，也可以写成：To:{demo}/Benchmark.Sort.Geon，系统都能正常识别。
<3> Benchmark，分布式应用软件的名称，它由开发者定义，通过这个命名，系统在部署和运行云端应用软件的时候，会把它和其它云端应用软件进行区别。
<4> Sort：分布式应用软件的根命名，也是由开发者定义。它对应云端应用软件的应用组件，如果一个分布式应用软件包里有多组应用组件时，根命名将实现相互区别。
<5> Geon：分布式应用软件的子命名，同样由开发者定义,用于迭代处理。比如开发者需要在一个阶段，对计算工作进行多次但内容不同的持续处理，子命名将提供名称识别。
二、引导程序
很多Laxcus分布式应用软件在启动时，需要录入一些参数，这类似于C语言和Java语言main函数中的形参变量，引导程序的也是提供这项能力，允许用户输入各种参数。引导程序的形参变量基于阶段，变量类型和数量根据开发者的需要自由定义。用户发布分布式应用软件时，引导程序会被部署到用户的桌面环境里。运行时，系统为它提供图形界面和字符界面两种录入方式。
开发者的引导程序需要从“GuideTask”类派生，这个类包含下图中的抽象方法：
上述方法中，最重要的是“markup”和“create”，markup方法负责产生录入参数集，create方法根据用户输入的录入参数集生成分布计算命令。目前的分布计算命令有“Conduct”、“Contact”，“Establish”三种。
三、分布式计算模型的种类
目前Laxcus分布式操作系统上，针对不同的业务需求，有三套分布式计算模型，基于这些分布式计算模型开发的应用软件，都属于云端应用软件，它们是：Conduct模型、Contact模型、Establish模型，它们背后都有一套基础算法支撑，以下分别介绍。
- Conduct模型
Conduct模型主要用于大规模、超大规模的分布式存储和分布式计算业务。它的优势是对大型应用业务友好，缺点是计算、迭代、关联层次多，分布式应用软件编写复杂。但是很多的大型计算业务，比如基因测序、气象预报、病毒样本分析、新型航空航天器的设计试验，普遍都采用Conduct模型业设计开发。在某位用户的计算报告中，其公司基于Conduct模型设计开发的高通量药物测序筛选软件，在1600个英特尔X86至强和飞腾2000异构服务器支持下，在3015分钟时间内，实现了568万个化物分子与寨卡病毒蛋白的测序和对接工作。而此前的最好记录是8235分钟，这次升级使整体计算效率提高了一倍以上。
- Contact模型
Contact模型主要用于中等规模或者小规模的分布式存储和分布式计算业务，相比Conduct模型，它的应用开发工作比较简单。因为分布处理阶段少，同等规模的应用业务，处理效率也优于Conduct模型。比如传统中间件使用的EJB或者CORBA的业务，WEB的后端业务，以及近几年兴起的云原生业务，都可以使用Contact模型来实现。这些业务的普遍特点是计算规模小，并发量大，这时如果采用Contact模型是最佳选择。
- Establish模型
Establish模型对标的是ETL业务，主要有数据重组、数据清洗、数据混淆、数据加密加扰等工作，它在Laxcus分布式体系里的作用，是提高数据安全性，辅助Conduct和Contact模型，增强分布数据检索效率，减少分布式计算时间，在有限时间和空间里让更多人使用共享的计算机集群资源。目前一些通用型的ETL数据业务，已经规范和流程化。这类固定的ETL处理，在Laxcus分布式操作系统里，通过系统命令，或者购买第三方应用软件的方式来解决，基本不需要用户重复开发。某些个性化的ETL业务，如果有一定的市场空间，也欢迎开发者们来开发它们，我们将提供辅助的市场营销推广工作，帮助开发者们打开市场。
四、分布式计算模型的运行流程和抽象方法
分布式应用组件的设计和开发都必须基于分布式计算模型，这样编写的应用组件才能被系统识别、部署、运行。分布式计算模型的抽象方法，和C语言、Java语言的main函数，以及前面提到的引导程序一样，是系统运行分布式应用组件的起点，另外也是输出的终点。系统需要在启动前根据阶段命名找到分布式应用组件，为分布式应用组件分配系统资源，向分布式应用组件输入参数，或者不输入，然后启动分布式应用组件。因为抽象方法是系统定义而没有实现具体作用的方法，它需要开发者继承超类和实现它们。
以下将介绍分布式计算模型的运行流程和入口方法。
（1）Conduct模型运行流程
在Laxcus分布式计算体系里，Conduct模型有5个阶段，分别是：Init、Balance、From、To、Put，对应Call、Data、Work、Front节点。它的运行流程是：先从图形窗口或者命令行窗口启动，用户向引导程序输入参数。引导程序得到全部参数后，负责生成Conduct分布式命令，然后被系统通过网络投递到Call节点。在Call节点，系统将根据阶段命名，从Init容器找到对应的Init阶段应用组件，然后启动运行它。Conduct模型给Init阶段规定的工作是检查计算机集群的可用资源并初始化它们。这个过程中，如果发现资源不足或者参数错误等情况，会弹出异常，通过网络反馈回调用者。如果一切符合要求，Init应用组件将根据引导程序的输入参数和自身业务逻辑，生成新的分布指令，提交给系统，由系统先后分发给Data节点的From容器，和Work节点To容器上执行。在From、To阶段之间，Call节点Balance阶段应用组件负责每次计算结束后的资源和数据平衡分配工作，然后再次生成新的分布式指令，分发给下个阶段的应用组件去处理。资源和数据平衡工作在所有分布式计算上都非常重要，它保证了每次的计算工作，所有节点都能平均分到相同的工作载荷，避免出现水桶短板现象，实现计算工作的最大化处理和最少时间输出。之前说，Laxcus分布式计算体系中的某些阶段支持迭代执行，在Conduct模型里，支持迭代执行的是From、To、Balance阶段。这些迭代工作将根据业务需要持续进行，直到最后完成，把计算结果输出到Front节点。Front节点收到反馈数据，将根据调用者的来源，显示在字符窗口、图形窗口、第三方应用的插件界面，或者提交给边缘端调用接口，实现一次完整的Conduct分布式计算工作。
（2）Conduct模型抽象方法
开发基于Conduct模型的分布式应用组件，必须在5个系统基础类上派生，分别是：InitTask、BalanceTask、FromTask、ToTask、PutTask。其中InitTask抽象方法是“Init”，BalanceTask的抽象方法是“admix”，FromTask的抽象方法是“divide、effuse、flushTo”，ToTask的抽象方法是“effuse、flushTo”，用于执行计算工作的“ToEvaluateTask”的抽象方法是“evaluate、assemble”，用于数据处理的“ToGenerateTask”的抽象方法是“divide”，ToEvaluateTask和ToGenerateTask都是从ToTask派生。PutTask从LocalTask派生，它的抽象方法是“display”。
（3）Contact模型运行流程
在Laxcus分布式计算体系里， Contact模型有4个阶段，分别是：Fork、Merge、Distant、Near，对应Call、Work、Front节点。Contact模型可以视为一个简化版的Conduct模型，它有和Conduct模型类似的运行流程和处理机制，只是因为面向中小规模和频繁发生的计算业务，减少一个中间阶段，减少了迭代频率，以此来实现更快的计算，更短的计算用时。
同Conduct模型一样，Contact模型也是从图形窗口或者命令行窗口启动，通过引导程序输入参数，根据参数生成Contact命令，投递给Call节点。在Call节点，系统根据Contact阶段命名，首先找到Fork容器，从中再找到对应的Fork应用组件，Front应用组件根据Contact携带的参数，检查系统资源和参数正确性，初始化计算机集群资源，生成新的分布指令，分散到Distant阶段运行。Distant阶段位于Work节点，在Work节点，Distant阶段除了按照业务需求，执行分布式计算工作，也可以执行大小不等的数据存储处理。每次Distant阶段应用组件执行完成，会把结果反馈给Call节点。当Call节点收到所有Distant应用组件的反馈结果后，Merge阶段应用组件会被启动，它同Conduct阶段的Balance应用组件一样，除了需要根据业务需求，对上次Distant计算结果进行合并和重组处理，还要为下一次的计算工作平均分配计算机集群资源和数据资源，然后交给Distant处理。这种处理工作会交叉反复进行，直到最后完成，把结果输出反馈给Front节点。和Conduct模型一样，在Contact模型，Near阶段的应用组件会在Front节点启动，处理来自Call节点的反馈结果，根据调用者来源，把反馈结果再次处理，显示在字符界面、图形窗口、第三方的插件窗口，或者转发给边缘端的调用接口上，完成一次完整的Contact计算工作。
（4）Contact模型抽象方法
开发基于Contact模型的分布式应用组件，必须在4个系统基础类上派生，分别是：ForkTask、MergeTask、DistantTask、NearTask。ForkTask抽象方法是“Fork”，MergeTask的抽象方法是“next”，DistantTask的抽象方法是“effuse、flushTo”，用于计算工作的“DistantEvaluateTask”的抽象方法是“evaluate、assemble”，用于数据处理的“DistanceGenerateTask”的抽象方法是“process”，DistantEvaluateTask、DistanceGenerateTask都是从DistantTask派生。NearTask也是从LocalTask派生，它的抽象方法同样是“display”。
（5）Establish模型
在Laxcus分布式计算体系里，Establish有六个阶段，分别是：Issue、Assign、Scan、Rise、Sift、End，对应Call、Data、Build、Front节点。与上面两个模型不同的是，Establish模型对标ETL业务，它的业务重心不在计算工作，而是面向数据的筛选和重组工作，将同质数据或者异质数据按照业务逻辑进行聚合，减少数据集合中的冗余数据，增加安全性，增强检索能力，提高大规模、超大规模分布式计算过程中无益的资源消耗，从而实现更高效的数据计算处理。
在工作流程上，Establish和Conduct、Contact模型一致，首先从引导程序中获得初始参数，然后生成Establish命令，投递到Call节点。Call节点的Issue应用组件被启动，检查计算机集群资源和参数正确性之后，生成新的指令，投递到关联的Data节点。在Laxcus分布式计算体系里，Data节点主要负责数据存储工作，所以Establish首先要通过Data节点的Scan应用组件，找到关联的数据对象。每个DataL节点的关联数据，会被Scan应用组件生成一个数据映射列表，表明这些数据在这个Data节点的分布情况，然后反馈给Call节点。收到来自全部Scan应用组件的反馈结果后，Call节点的Assign应用组件会被启动，它将分析Scan应用组件提供的数据映射列表，然后根据业务需求，生成一组新的数据资源分布图谱和对应的分布指令，投递到BUILD节点，交给BUILD节点的Sift应用组件去执行ETL处理工作。Sift应用组件将解释Establish命令中的业务需求，按照Assign提供的数据资源分布图谱，通过网络获得实体数据，在本地进行ETL业务的数据处理工作。处理完成后，再次生成新的数据映射列表，反馈给Call节点。在Sift、Assign之间，这些工作可以迭代进行，也就是说，它们可以持续任意多次进行，直到最后完成全部ETL处理工作。这时Assign再次生成新的数据资源分布图谱，交给Data节点的Rise阶段去处理。Rise阶段应用组件根据Assign阶段提供的数据资源分布图谱，从BUILD节点取回已经被Sift应用组件ETL处理过的新数据，保存到本地，并把存取结果反馈给Call节点。Call节点收到全部Rise处理报告后，将它们原样反馈给Front节点，通过Front节点的End阶段应用组件，根据调用者的来源，显示在字符界面、图形窗口、第三方应用的插件，或者转发给边缘端的调用接口，完成一次完整的Establish的ETL处理工作。
（6）Establish模型抽象方法
开发基于Establish模型的分布式应用组件，必须在6个系统基础类上派生，分别是：IssueTask、AssignTask、ScanTask、SiftTask、RiseTask、EndTask。IssueTask抽象方法是“create”，AssignTask的抽象方法有“Scan、Sift、Rise”，ScanTask的抽象方法有“analyse、analyseTo”，SiftTask的抽象方法有“implement、implementTo”、RiseTask的抽象方法有“convert、convertTo”，EndTask也源自LocalTask派生，它的抽象方法同样是“display”。
五、脚本、打包、发布
开发者完成云端应用组件开发工作，部署到Laxcus集群上运行，这中间还需要继续完成三项工作：脚本制作、打包、发布。在Laxcus分布操作系统上，脚本制作有规定的样式，内容采用XML格式，使用UTF8编码（注意必须是UTF8），以文件形式打包进应用组件里。应用组件在部署和运行时候，这些脚本会被系统从软件包中提取出来解析，生成映射关系，保存到分布式环境里，方便系统随机定位、检索、启动分布式应用组件。目前的软件打包分为两种：打包云端应用软件和打包客户端应用软件。打包云端应用软件，是将一个分布式计算模型的不同阶段的应用组件合并到一起；打包客户端应用软件，是将图形桌面的客户端程序文件合并到一起，云端应用软件，可以打进客户端软件包，也可以不打包。如果打包进来，云端应用软件就能通过客户端软件发布；如果不打包进来，用户需要通过系统命令或者相关工具单独发布的云端应用软件包。
（1）引导程序脚本
一个标准的引导程序脚本内容如下，其中标签是关键字，标签中的内容用户编写，这些信息会出现客户端软件界面，同时也被系统识别和分发，保存到不同节点。
（2）云端应用组件脚本
一个标准的云端应用组件脚本内容如下。标签中为关键字，与引导程序脚本相同的是，都有“ware”标签组，不同的是，应用组件脚本用“task”标签组取代“guide”标签组，同时开头还需要指定当前应用组件对应阶段，截图中的是“<phase> Init </phase>”。
（3）打包云端应用组件
系统提供打包应用组件的工具，打开桌面上的“分布式组件”，移到“应用”菜单，点击“编写分布计算应用脚本文件”，将呈现如下显示，开发者在对话窗口输入参数后，单击“导出脚本”按纽，系统将生成以“.script”后缀的脚本文件，脚本文件将在下一步根据开发者录入的内容，生成一个云端应用软件包。
（4）生成云端应用软件包
还是使用桌面上的“分布式组件”，移到“应用”菜单，点击“生成分布计算应用包”，将呈现如下显示。点击“选择脚本文件”按纽，从磁盘上选中之前生成的脚本文件，然后点击“保存到”按纽，系统将读取脚本文件中的组件路径，将磁盘上全部应用组件打包在一起，做为一个云端应用软件，保存到磁盘上。
（5）发布云端应用软件包
依然是使用桌面上的“分布式组件”，移到“应用”菜单，点击“发布分布计算应用软件包”，将呈现如下显示。点击“选择分布式应用”按纽，从磁盘上找到之前已经生成的云端应用软件包，点击“确认”按纽，系统将把这个应用软件部署到云端。部署过程是由系统完成的，不需要用户参与，无论部署成功或者失败，系统都会反馈到“分布式组件”提示用户。如果只需要在本地部署，那么就选中“只在本地部署”，这个软件将不会部署到云端。另外，用户也可以使用命令来部署一个云端应用软件，效果如接下图所示。
至此，云端分布式应用软件的全部工作介绍完毕。如有疑问，请登录Laxcus官方网站留言，或者加入我们的微信技术讨论群了解更多技术细节，欢迎你的加入！