模块化分析平台·二#
---
创建日期: 2023-04-15
---
关于分析工具的模块化实现（并没有实现）
书接上回！
明明是要说“MicroService”的，却讲了一堆有的没的。
“MicroService” 实现#
先不考虑什么是“MicroService”，同时假设我们没有实现上的阻力（咱就啥都会）。 幻想一下“MicroService”风格的数据分析工具效果会是怎么样的。
先给出全部概念设计，后面再拆解分析。
首先，这是一个基于网页交互的平台。 基于网页的平台工具不是什么新鲜事了，自然是因为有不少的优势。
如果全都能实现的话， 一方面解决了入口问题，这个平台会是一个工具合集，打开浏览器，就能开始各种分析。 “下游”的客户也可以访问相同的入口，看到处理好的、有组织的结果，不会找不到查看工具或者数据，还能对结果进行交互，而不是静态的图片报告。
另一方面解决了部署问题，分析人员不需要安装特殊软件、运行环境，所有的依赖由后端平台解决。 基于网页技术的工具部署，可以快速在线让功能更新（或者让错误得到修复）不需要重新下载安装。
同时，因为是“浏览器-服务器”架构，数据处理都在服务器端。 如果每个地区架设独立的服务器，其它地区同事就可以在线协作、远程处理。 不需要传输高采样率的数据到本地再进行处理，访问的速度取决于网页交互速度。 （虽然好像网页交互也不是很快，而且分析模块要对 交互过程中的传输给用户浏览器的数据量 进行优化）
“MicroService”的核心之一就是要把不同的分析工具模块化， 因为不同部门需要定制自己的工具（使用自己喜欢的技术）。 各自实现的同时还能将其它模块输出作为输入，共同部分复用，减少重复开发。
从用户（分析人员）的角度，他们可以选择使用哪些工具组织他的分析工作。 每个模块会被不断地开发、更新，模块部署后，分析人员可以立刻用到最新模块带来新功能。
而对于历史的分析，希望能够回溯。 根据以往的经历，使用JupyterNotebook， 再执行的时候所依赖的库可能变化了，导致无法复现计算过程。 （主要原因是自己 库 开发得不专业啦） 所以希望能够把运行环境也包含在工具中。
容器（Docker）就是非常适合的工具来达成这些目标。
每个工具模块是独立的容器镜像（Image），有不同的版本信息。 默认获取最新的镜像，在要回溯的时候使用旧版。 容器镜像包含完整的运行环境，确保回溯正常。
当用户创建分析的时候，后端使用分析模块的镜像创建运行实例。 该实例为用户提供前端交互界面，并根据用户的输入进行分析。 分析结果包含内部模型以及与其它模块交流的外部模型，而分析的过程作为配置文件保存。
当回溯历史时，相应的镜像信息从配置中读取，并实例化，再从根据配置进行重新计算。
可以多个用户创建不同的分析，相同的分析也可以被多人回溯。 实例之间相互并不干扰。
每个实例负责自己的前端用户，前端关闭，实例也被关闭。 当有需要的时候，一个模块的结果还可以传递到下一个模块作为输入。
如此“MicroService”的分析平台就有了。
平台不仅让用户可以使用工具，还要将分析结果做结构化存储。 以便日后提供 跨项目对比、链接不同分析 的功能。
好像不是“MicroService”#
以上，不是挺好的愿景嘛，怎么就不是“MicroService”了？ 因为以我的理解，MicroService：
通常只是用于服务端处理API调用，并不会 提供前端内容、处理交互
每个微服务容器能处理许多用户需求，并且根据用量弹性扩展，不是单个容器为一个用户服务
在前一节描述的情况，分析流程分散在各个模块的容器中，一个用户会连接许多专享的容器实例。 虽然容器相较虚拟机轻便许多，可依然带着厚重的运行环境。 如果像我们那样每个容器都只实现一点功能，并发量必然受限，资源浪费，还增加了相互之间通信的成本。 （通信是一个很重要的事情，例如一个数据加载模块，读取了大量的数据，要如何传递给下游模块分析，毕竟不是在一个进程中）。
使用 MicroService的技术（容器） 来实现“MicroService”的，有种大炮打苍蝇的感觉，不如使用进程的方式来实现模块化。 当然容器方案有其好处，能够 打包运行环境、版本控制 以及 技术栈多样性。
难道就没有容器是提供前端同时又与之交互，并且每个容器是为单独用户服务的案例吗？ 我想是有的，比如Google Colab、MATLAB Online就应该是使用容器虚拟出了个人环境，将不同的用户隔离开。 但是这种情况，一个容器相当于一个非常丰富的应用。 而本来要用“MicroService”的目的就是为了让每个部门能选择各自喜欢的工具进行独立开发，而不是共同开发一个应用。
即使每个容器非常轻量（存储是写入时复制，说不定内存也有共用）， 在我们的描述中，一个模块的开发同时包含前端与后端，以及处理模块间的通信。 作为非专业的程序开发人员，只想关注分析逻辑、关心计算方法，最多写一些简单的界面代码。 现在要开始学习容器技术、网页技术、要去创建API服务，好难啊。 如果有能够自动封装前端的方法就好了；或者有人解决了前端的所有交互，我们只是实现API，让“MicroService”真正当个Service。
总之，相较于“MicroService”，我更愿意称之为“基于网页技术（或许以及容器技术）的模块化分析平台”。
来沾个边#
有没有什么解决方案（不一定要使用容器）能够成为“基于网页技术的模块化分析平台”呢？
MATLAB
集团有部署MATLAB，还可以从MathWorks得到非常丰富的支持。 （然而我们事业部没什么高级需求，都是简单的加减乘除）， MATLAB的解决方案一直都会是优先考虑。
不考虑其它部门协作，我们想解决的问题：
统一的分析、查看入口
由于数据量大，又想不同地区人员能远程支持，需要能远端处理数据
自定义工具，相互之间数据交流的问题，不想相同功能重复开发
MATLAB这些年图形界面程序开发主推的AppDesigner， 开发完成可以在桌面环境使用，也可以编译成WebApp部署到服务器上用浏览器打开。
一下不就解决了前两个问题？ 有同事想推但是也没推动，想用AppDesigner的人做的工具实在不好用。 我也觉得自定义交互上，MATLAB不容易。
WebApp的文件读写，其实是从本地上传到服务器，程序再读取的服务器上的内容。 而我们要处理的又是非常大量的数据，甚至分散在不同的系统中。 不能在应用中让用户选择文件资源管理器进行浏览（而这个又是当App作为桌面应用时必须的），否则用户可能会双倍时间等待文件读取。
意味着至少需要一个文件服务，让我们能从中选择远端要分析的数据。 不过我们的文件实在太多了，不同项目不说，通道还很多，同一个项目的采集还会保存到许多文件夹下，实在没有什么大一统的方法。
如果这个服务有了，在不同的WebApp中也还要去调用这个功能，因为WebApp之间相互独立。 MATLAB的WebApp服务器处理自动处理不同的会话，部署方便了，相应的想要修改让应用间通信几乎就不可能了吧。
Flutter
想着要怎么部署，为“MicroService”弄的“MicroFrontend”。
不想弄前端，以前开发的程序也多是桌面应用。 要构建网页应用啊，不想从 Vue.js/React 这种开始。 如果能够写桌面应用同时，也能部署在浏览器上，那不是也不错。 （等等，这不是你前面说的MATLAB WebApp吗？）
不想为了桌面和网页独立做交互，慢慢搜到了Flutter。 可以同一个项目编译成桌面、手机、浏览器程序， 跨平台编译、部署，太帅了！ 虽然是新的语言 Dart。 虽然分析工具的界面构建与交互逻辑，和消费应用App还是不太一样， 不能做到那么通用，最后并不会采用Flutter。
想想从 CSS+HTML+JS 到 jQuery，再到 Vue/React/Angular 这种，最后到自动编译成前端! 新技术让人兴奋，可是没到一定程度，实在追不动框架的变化。 以及看着过往努力被新工具替代，也是非常无奈、可笑。 （并不是我，我又不努力┑(￣Д ￣)┍）
MiroService x DAC
DAC是“Data Action Context”，也是上回提到的“模块功能”的实现。
既然每个节点可以连接起来，似乎也比较容易实现“MicroService”。 虽然到时候交互会非常的别扭。
最后，
还是想说，这些都是抽象相等的。
即使没有一个工具完成这些事情，我们的工作依然可以继续。 用已有的工具，导出数据交换，每个人就是“模块/容器”。 有工具固然是好，没有工具的话，其实重要的还是分析方法与业务逻辑本身。