虚拟实验室架构演进

<p>[TOC]</p> <h2>前言</h2> <p>虚拟实验室的核心业务是</p> <ol> <li>颗粒生产人员通过实验编辑器产生实验文件，这些实验文件通过验收后将会发布到服务端。</li> <li>播放器端加载编好的实验文件，播放实验。</li> </ol> <p>在架构演进的过程中，是由于多个方面的业务变化</p> <ol> <li>应用端功能的演进，单个应用的功能越来也复杂</li> <li>应用端的数量的演进，比如播放器衍化成VR播放器，PAD播放器等</li> <li>颗粒数量的演化，从物理到化学和生物等，颗粒的数量越来越多，这会导致实验器材的数量越来越多。</li> <li>实验颗粒使用流程的演化，从离线使用到从云端下载使用，再根据用户权限下载</li> </ol> <p>因为颗粒是通过编辑器编辑出来的，所以虚拟实验室的核心开发任务是应用端的功能的开发和实验器材的开发，由于器材本身含有3D模型资源，每个器材的大小约有5M，而每个颗粒通常使用的器材很少，而且颗粒之间存在器材是共用的，这里有个核心的架构决策是器材要按需下载。</p> <p>另一个需要解决的核心问题是应用功能的发布和器材的发布同步问题，通常器材会依赖应用端的功能。</p> <h2>预立项阶段架构</h2> <p>这个阶段应用端有：实验编辑器、 这个期间几乎没有架构，所有的资源和代码都放在U3D工程中。 这个期间主要的问题引擎计算的输入来源于器材的属性，输出也需要更新到器材的属性，整个过程都要在器材逻辑里处理，很容易出问题。</p> <p>重要的架构决策有：</p> <ol> <li>通过在器材属性上打标签的方式，使用一个中间层在器材和引擎之间的数据交换，简化了器材的开发。</li> </ol> <h2>正式立项阶段【架构1.0】</h2> <p>这个阶段应用端有：实验编辑器、实验播放器 重要的架构决策有：</p> <ol> <li>所有的器材存放在管理平台上【现在称为旧管理平台】，器材的元数据有状态【测试，发布，上线等】，版本号，最低播放器版本。应用端根据自身的播放器版本号取最新的器材版本。</li> <li>一个器材对应一个dll和资源AB包，一个器材包含有dll和资源AB包，应用端通过动态加载器材的dll和反射调用。</li> <li>应用端和器材的共用逻辑，抽出一个叫做CommonBase的组件包，这个组件包也存放在管理平台上用于热更新。</li> <li>应用程序先更新CommonBase的dll【下载并替换到xx_Data/Managed目录重启】，再更新器材。</li> <li>颗粒存储在NDR1.0上。</li> </ol> <h2>接入3D能力平台阶段【架构2.0】</h2> <p>这个阶段应用端依然是：实验编辑器、实验播放器 重要的架构决策有：</p> <ol> <li>所有的器材都要使用Lua语言开发，3D能力平台认为使用Lua开发器材可以节约人力成本；</li> <li>将实验表现、实验交互、实验引擎明确区分开来，由Lua脚本做数据的转发和业务处理；</li> <li>为了适应交互适配不同的外设，需要对交互单独抽象，并接入3D能力平台的外设交互组件；</li> <li>原来器材里的dll统一换成了lua脚本；</li> <li>实验表现、交互、引擎等通用类的dll都放在管理平台上热更；</li> <li>实验表现相关的资源也都统一打成AB包，放在管理平台上用于更新；</li> </ol> <p>附：接入3D能力平台是公司的强制要求，但那个时候3D能力平台不成熟，它对项目的好处是提供了一个长时间重构的机会，让项目有时间吧架构调整地合理。它的坏处是项目没有选择的权利，引入Lua后带来很多性能问题，以及C#程序员和Lua程序员沟通和协作上的问题。</p> <h2>产品化阶段【架构2.1】</h2> <p>这个阶段要推出面向市场的产品，主要是TOB的产品 主要使用流程是用户登录后，进入实验大厅，显示颗粒资源列表，选择实验颗粒进入播放场景。 应用端有：101实验室【3D播放器前身】，101实验考试【VR播放器前身】、编辑器【内部使用】</p> <p>重要的架构决策有：</p> <ol> <li>101实验室和101实验考试需要接入用户登录模块【UC】</li> <li>实验颗粒存储在NDR2.0的私有库上</li> <li>应用端查询颗粒不能直接与NDR通信，需要通过一个网关做权限控制</li> <li>开发了实验步骤判定组件，用于VR实操实验的评分</li> <li>101实验室接入视频播放组件，用于播放视频</li> <li>101实操考试开发对应的服务端用于存储用户的实操数据。</li> </ol> <h2>接入新管理平台阶段【架构2.2】</h2> <p>与上个阶段相比，这个阶段的主要变化是使用新的管理平台。 应用端有：101实验室【3D播放器前身】，101实验考试【VR播放器前身】、编辑器【内部使用】</p> <p>旧管理平台的缺点有：</p> <ol> <li>器材状态太少，缺少开发自测转态</li> <li>器材缺少依赖信息，比如火柴盒业务会依赖火柴</li> <li>器材的资源和脚本合在一个包中，只有脚本更新，资源没有更新的时候依赖下载量比较大。</li> <li>存在多个应用的情况下，应用用最低播放器版本获取器材很难做到应用和器材的独立发布。</li> </ol> <p>重要的架构决策有：</p> <ol> <li> <p>管理平台明确区分器材、资源和组件，组件有区分核心组件和业务组件，核心组件所有应用不能缺少，业务组件按需下载。</p> </li> <li> <p>器材根据最低依赖的播放组件版本和引擎组件版本来取最新版本，播放组件是个虚拟的概念，应用端所有使用的公共组件合并成一个播放组件包。引擎组件也是个虚拟的概念，它由所有的实验引擎，实验表现组件，实验交互组件合并成。这样的好处是引擎组件和播放组件可单独更新，减少彼此的依赖。</p> </li> <li>新管理平台上支持实验药品，药品可在管理平台上配置【可由学研老师配置】</li> </ol>