微服务 vs NeuronStorm 一次微服务的实战真实感悟 简化通道化身为神经元玩法 减少微服务中通道代码占比 节省代码时长

最近在微服务的工程下面增加业务功能,设计涉及三个业务领域,也就是微服务的堆栈要处理多个工程代码,类似于【通道代码】,本身并不是业务代码,占的比例还不少!构想一个NeuronStorm,由平台完成通道的管理与维护,消灭通道代码,同时可视化编程

最近在微服务的工程下面增加业务功能,设计涉及三个业务领域,也就是微服务的堆栈要处理多个工程代码,类似于【通道代码】,本身并不是业务代码,占的比例还不少!构想一个NeuronStorm,由平台完成通道的管理与维护,消灭通道代码,同时可视化编程

最近在微服务的工程下面增加业务功能,设计涉及三个业务领域,也就是微服务的堆栈要处理webapi<—>Service<—->Agent<—>SDK<—->webapi<—–>bll<—->memcache,建立微服务通道花了一些时间,占了一定比例的开发时间与代码工作,而真正业务代码量是比较少。

微服务的堆栈要处理webapi<--->Service<---->Agent<--->SDK<---->webapi<----->bll<---->memcache,涉及多个工程

微服务的堆栈要处理webapi<—>Service<—->Agent<—>SDK<—->webapi<—–>bll<—->memcache,涉及多个工程

微服务中通道代码能否做一些处理,以节省没有必要的时间占用呢?这是开发过程中一直在思考的问题。我想有以下两方面可以考虑:

  1. 代码生成器,对于微服务中各工程的代码,通道代码可以抽成模板或通过架构手段变成可生成的。当然这种玩法并没有改变微服务在通道代码上面的冗余。这种方案相对比较保守。但是对于现有工程来讲,不涉及大的变化,是比较好实施的。
  2. NeuronStorm,这种方案的话,是将代码逻辑封装到一个处理单元中,Neuron并不用关心自己在哪个业务领域处理哪个机器上。由NeuronStorm统一调度,由业务人员自行配置。这种方案下,Cell之间的通道是基于NeuronStorm统一实现,所以将微服务中的通道代码全部消灭掉了。
NueronStorm中的Nueron单元共享NeuronStorm通道机制,省掉通道代码工作量

NueronStorm中的Nueron单元共享NeuronStorm通道机制,省掉通道代码工作量

NeuronStorm的最小逻辑单元为Neuron,可以理解为逻辑单元,不同的Neuron可组合成业务流,通过组织Neuron单元形成业务流,使得代码逻辑流可以可视化呈现。

复杂的NueronStorm逻辑流程图

复杂的NueronStorm逻辑流程图

NeuronStorm是一个可视化的编程平台,依据设想,基于NeuronStorm的程序,只需要集中在Neuron单元中编写业务逻辑,通道代码由NeuronStorm集群控制。NeuronStorm借鉴了Apache Storm的Bolt概念,注重于可视化编程。

目前NueronStorm处于概念阶段,github的存储库已经建立起来,有兴趣的可以加入进来。

https://github.com/Lancker/NeuronStorm

巧妙拆分bolt提升Storm集群吞吐量

此条目发表在未分类分类目录。将固定链接加入收藏夹。

发表评论

邮箱地址不会被公开。 必填项已用*标注