Python 全栈系列190 全栈能力组建进展梳理

说明

从数据处理的应用角度，梳理一下目前全栈能力的情况。

内容

简单的分为四部分：

• 1 存储
• 2 处理
• 3 (调度)机制
• 4 监控/管理

1 存储【保持使用】

这部分我觉得已经ok了 $\star \star \star \star \star$

从持续改进或者服务的角度上，数据必须进行持久化。我们甚至希望在使用数的时候，并不需要特别的关心他们来自哪里，去向何处。

目前主要的数据库，我已经通过：

• 1 Docker方式快速部署
• 2 构建了副本集
• 3 使用微服务代理进行访问
• 4 使用句柄工具集成操作

总体上，对于数据处理过程中的配置、统计信息等元数据，以及准表格数据本身(listofdict)，我是建立在十亿级以上设计和测试的。

当然，分布式的构建，理论上数据量级可以很大。从实际的角度，我一个十台主机的算网(30~50万)应该可以处理几百亿级的数据，而我至少可以轻松管理十个算网。所以我觉得目前数据的存储已经不是我最主要关心的部分。

当然，后续还是有不少需要改进的地方。比较确定的是使用Redis构建消息队列，这会大幅增加数据处理的运转效率。类似于CPU的二级缓存了。

另外，可变性比较大的是图库。对于neo4j的吞吐(冷库快速搭建以及在线更新)和功能(用户权限）已经有过成功的实践，但是对于函数(链)依赖、智能问答、知识推理方面还没有实践。可能最近最想做的是路由选择：对于任意控制的主机，访问指定主机服务时选择路径。至少可分为：local, lan 和 wan三种方式，在worker启动时自动query一条较好的路线。

2 处理【稳步推进】

这部分有了实质进展，基本上确定了 $\star \star \star$

关于如何可靠、高效、灵活的构建函数体系来处理数据是一个灵魂话题，过去其实已经探索了很多形式。现在应该算摸索到一个可实现的方式，对应于原来的：

• 1 FuncChain / RuleChain : 总之是一种类似链式（本质上是网）的流水线式规则执行方式
• 2 TinyEngine/ SCLC / RuleEngine : 是对规则结果(根据层级)进行协调，输出期望结果的方式

简单来说，如何做的又快又稳(感知与变换)，以及做的清晰准确(判断与决策)。

原来的形式没整好，很难在设计理念与工程实践结合在一起；现在应该可以借助微服务体系，以及前端技术实用化了。

从运维的角度上，处理大约还需要nginx的负载均衡来实现服务端更好的并行化，不过这属于运维部分的内容了，之前实现过，后续再调试一下就好。

顺带查了一下，参考。高可用的负载均衡服务。

3 机制【保持使用】

关键的机制已经在使用 $\star \star \star \star$

机制是为了让我们的操作从大的方向上具有统一性，从而不必在一些无谓的操作上浪费时间。

• 1 【命名机制】：采用内、外的三级命名方式，应该是足够清晰的（其实是从六爻收到了启发）

• 2 【元数据与数据】：使用mymeta集群存储元数据，其他的单机或者集群是放业务数据的。

• 3 【任务机制】：分为标准任务机制与简易任务机制。前者是一种完善的任务管理，后者是为了容纳单条数据的多次处理，以及简化操作。任务还定义了状态 0,1,2,3

• 4 【数据处理机制】：这里特别指外层的任务处理机制，函数链对应于数据处理中的逻辑步。某种程度上，这个是外层，而函数链是内层。数据处理定义了步骤和状态码：初始化0、数据连通测试成功与失败1,2、数据有无3,4、数据合规5,6、逻辑处理7,8、缓存处理9,10、交付处理11,12（7个步骤也符合易的原则）。除0外，奇数为正常，偶数为错误。这个机制其实完成了和外部的IO握手。

• 5 【板材机制】：是在函数链内部的机制，包含了数据校验、尽力交付等细节。

• 6 【嗅探/处理】：一个任务的处理总是分为这两个节拍，一步去读取数据并将结果更新在数据库里，另一步去数据库读取元数据，根据元数据进行数据的IO和处理。

应该还有一些机制，暂时想不起来了(所以定期梳理还是很有必要)

4 监控/管理【极速推进】

这部分是将资源进行整合调用，是技术的终点。 $\star \star$

这两天比较满意的是，我终于可以使用前端的js表格和数据库无缝交互了。这点得感谢tabulator让我基本上可以猜猜查查，在比较短的时间完成对接；也感谢datatables，让我明白不是"早就对"的道理，及时放手，及时改错。

后端使用上的问题就是过于抽象了，难道每个小任务我都要ssh,切入镜像然后打开ipython之类的吗？ 更何况有很多项目的代码，版本啥的，真的记不住。

前端可以方便的看(监控）,必要的话修改一些字段，如果一定要去往哪个项目，也可以提供元信息，以及跳转代码。 这块对我现在节约时间方面的帮助会非常大。以下梳理一下几个方向：

• 1 开发、调试
• 2 分析：数据查探
• 3 手工协同工作
• 4 运维：项目运行进度、启停服务

基础是我可以非常便捷的和数据库做交互，这样人机(后端服务机)之间就有了一个桥梁。这里需要增加一个机制：注册制。对Server和Worker都需要进行注册，信息会保留在数据库中。因为目前我的服务和处理程序都是以Worker部署的，而且我有一个超级服务24030，可以代为转达Docker命令，所以是切实可行的。

每个Server和Worker都可以分身，都具有状态（类似任务的0,1,2,3) 。在用户设置到服务响应会有一段时间，这个在Portal中会有一个视图去负责管理。所以大体上，Portal会接受用户的请求，然后送到数据库(Want To Be)。

所以可以看到一张表，这张表上有所有服务的名字，描述，当前运行状态（包括分身数）等。允许用户加入一些定制的参数，然后将用户的设置传到后台，改变后将状态返回前端。

1 开发、调试

信息汇聚

前端会有专栏汇聚项目信息，通过这个地方可以查阅已有的文档，可以跳往私有的gitlab，访问代码；也可以跳往项目所在的jupyter进行交互式调试；也可以给出跳往对应主机并打开docker bash的命令。

同时这里也可以关联到对应的项目运行统计数据。这样就会使得开发在使用（逻辑）上是高度规整的，实际的项目存放或者不规范的地方都可以在前端得到修正。

简化调试

在采用了APIFunc(现在的函数链）之后，有一个额外的好处：各部处理和API的形式是一致的。这意味着在前端可以输入数据，然后可以交互式的看到这条数据在流中的变化。从而快速的发现程序中的错误。

函数与参数变更

一个流就是一个制程，在前端页面发现的参数或者函数问题，可以将文本贴在对应位置，同步到数据库。由前端触发制程的修改，而这些都可以完全用字符表达，及时刷新。

2 分析：数据查探

这块主要是因为前端表格和数据库可以直接互通，设置好一些模式和筛选参数，前端可以很快看到数据库里的内容。这部分实际上耗很多时间，数据库会记住用户的偏好，可以更快的让用户迅速找到想看的数据。

3 手工协同工作

这部分的工作本来也是非常耗时的。通过交互式表格，可以约束协同者的合法输入，可以为模型打标更新等进行协同。

当然，将APIFunc进行分布的协同开发也是非常重要的一部分功能。

4 运维：项目运行进度、启停服务

这里会涉及到对项目进行跟踪、统计和消息发送。

其实还会收集主机的资源使用情况，并对请求进行主动的负载均衡。

管理各类服务的定义，运行，分身数等。