S********t 发帖数: 3431 | 1 Guice倒是开源的,别的DI方案也有。想请教下,市面上有没有这样的轮子,来解决
processing step之间的dependency,framework去schedule每一个step的异步执行?
举个例子,我要写一个后端rpc service,处理一个rpc request,产生这个rpc的
response,这个过程中我需要执行若干个步骤
1: input request, output A
2: input request, output B
3: input A, B, output C
4: input request, A, C; output D
5: input B, D output final response
每一个步骤内部的logic可能是一个blocking computation,也可能是一个async call
(disk io or network call)。有没有这样一个framework能够理解这样的dependency并
且最优化的schedule这5个step的async execution,比如1和2可以并行run。不知道开
源社区有没有这样的轮子? |
H****S 发帖数: 1359 | 2 这个应该是reactive programming的范畴。可以去看看rxjava或者akka stream。
call
【在 S********t 的大作中提到】 : Guice倒是开源的,别的DI方案也有。想请教下,市面上有没有这样的轮子,来解决 : processing step之间的dependency,framework去schedule每一个step的异步执行? : 举个例子,我要写一个后端rpc service,处理一个rpc request,产生这个rpc的 : response,这个过程中我需要执行若干个步骤 : 1: input request, output A : 2: input request, output B : 3: input A, B, output C : 4: input request, A, C; output D : 5: input B, D output final response : 每一个步骤内部的logic可能是一个blocking computation,也可能是一个async call
|
s*******m 发帖数: 58 | 3 why not use CompletableFuture?
Do not understand why DI is related. |
c*********e 发帖数: 16335 | 4 rxjava的异步,其实是 async + thread,不是node.js那样只有一个thread的async
【在 H****S 的大作中提到】 : 这个应该是reactive programming的范畴。可以去看看rxjava或者akka stream。 : : call
|
H****S 发帖数: 1359 | 5 如果只想要在当前thread上跑,可以直接subsribeOn immediate scheduler,否则用
trampoline scheduler在一个单一thread上run。rxjava的threading model是非常
flexible的。
【在 c*********e 的大作中提到】 : rxjava的异步,其实是 async + thread,不是node.js那样只有一个thread的async
|
c*********e 发帖数: 16335 | 6 如果只想要在当前thread上跑,那future.get()的时候,不会block这个thread吗?
【在 H****S 的大作中提到】 : 如果只想要在当前thread上跑,可以直接subsribeOn immediate scheduler,否则用 : trampoline scheduler在一个单一thread上run。rxjava的threading model是非常 : flexible的。
|
H****S 发帖数: 1359 | 7 你可以把scheduler想象成actor,所有的rx event都是这个actor的message。当你有一
个future的时候,把它转化成observable,这个observable可以attach到另外一个
observable上,就像搭乐高积木一样。future return以后的值直接传导到下一个
observable或者直接到subscriber。future.get是不是在一个thread上没有关系,因为
所有的event必须happen in order,就好像actor可以在一个multi threaded
dispatcher上,但是message processing还是要按顺序进行。
【在 c*********e 的大作中提到】 : 如果只想要在当前thread上跑,那future.get()的时候,不会block这个thread吗?
|
c*********e 发帖数: 16335 | 8 你的意思,是future.get()在另外一个thread上?
【在 H****S 的大作中提到】 : 你可以把scheduler想象成actor,所有的rx event都是这个actor的message。当你有一 : 个future的时候,把它转化成observable,这个observable可以attach到另外一个 : observable上,就像搭乐高积木一样。future return以后的值直接传导到下一个 : observable或者直接到subscriber。future.get是不是在一个thread上没有关系,因为 : 所有的event必须happen in order,就好像actor可以在一个multi threaded : dispatcher上,但是message processing还是要按顺序进行。
|
H****S 发帖数: 1359 | 9 根本没有future.get,future直接被register一个callback把值传给下个单元。rxjava
的好处是所有的callback aligned up as a stream,所以不用去担心callback hell的
问题。
【在 c*********e 的大作中提到】 : 你的意思,是future.get()在另外一个thread上?
|
c*********e 发帖数: 16335 | 10 future在的那个thread,在把值传给下个单元之前,在干啥子?
rxjava
【在 H****S 的大作中提到】 : 根本没有future.get,future直接被register一个callback把值传给下个单元。rxjava : 的好处是所有的callback aligned up as a stream,所以不用去担心callback hell的 : 问题。
|
|
|
x***4 发帖数: 1815 | 11 我觉得vertx比rxjava容易理解。不知道为什么vertx没有热起来。
【在 H****S 的大作中提到】 : 你可以把scheduler想象成actor,所有的rx event都是这个actor的message。当你有一 : 个future的时候,把它转化成observable,这个observable可以attach到另外一个 : observable上,就像搭乐高积木一样。future return以后的值直接传导到下一个 : observable或者直接到subscriber。future.get是不是在一个thread上没有关系,因为 : 所有的event必须happen in order,就好像actor可以在一个multi threaded : dispatcher上,但是message processing还是要按顺序进行。
|
H****S 发帖数: 1359 | 12 在计算future的body啊,取决于scheduler使用的是当前的thread还是另一个thread,
这个计算可以是同步或者是异步。
【在 c*********e 的大作中提到】 : future在的那个thread,在把值传给下个单元之前,在干啥子? : : rxjava
|
H****S 发帖数: 1359 | 13 容易理解不代表适用,我敢打赌actor比这两个都简单,但是actor一旦大规模使用,对
于维护简直就是一个灾难。
【在 x***4 的大作中提到】 : 我觉得vertx比rxjava容易理解。不知道为什么vertx没有热起来。
|
l*********s 发帖数: 5409 | 14 谢谢指点!
rxjava
【在 H****S 的大作中提到】 : 根本没有future.get,future直接被register一个callback把值传给下个单元。rxjava : 的好处是所有的callback aligned up as a stream,所以不用去担心callback hell的 : 问题。
|
s*******m 发帖数: 58 | 15 我很喜欢用actor, 能否说一下为什么“actor一旦大规模使用,对 |
H****S 发帖数: 1359 | 16 仅以akka actor为例:
1。它的message processing是untyped,所以你可以像actor传递任何marshallable
object,compiler不能帮你找出错误,如果你不小心发了个此actor无法handle的消息。
2。akka actor的context还可以evolve,意味着不同阶段它可能take完全不同的set of
messages,compiler更无法帮到你。
3。actor无法compose,你不能把复杂的logic分解成小块然后把它们类型安全的连结起
来。
4。actor还可以run remotely,这对于维护简直就是噩梦。当你的程序变得越来越大时
,任何的改动你都需要compiler给你带来一点信心。如果是actor的话,你基本上没有
任何信心来改动,尤其如果是别人的程序。
【在 s*******m 的大作中提到】 : 我很喜欢用actor, 能否说一下为什么“actor一旦大规模使用,对
|
s*******m 发帖数: 58 | 17 我没有用过akka actor, 谢谢你的经验之谈,如果我以后用到它会注意 |
H****S 发帖数: 1359 | 18 不客气,scalaz-actor在类型安全方面比akka要好,虽然还是没法compose。
【在 s*******m 的大作中提到】 : 我没有用过akka actor, 谢谢你的经验之谈,如果我以后用到它会注意
|
C******8 发帖数: 501 | |
c*********e 发帖数: 16335 | 20 你在写rpc? 怎么不直接写个restful web services呢?
call
【在 S********t 的大作中提到】 : Guice倒是开源的,别的DI方案也有。想请教下,市面上有没有这样的轮子,来解决 : processing step之间的dependency,framework去schedule每一个step的异步执行? : 举个例子,我要写一个后端rpc service,处理一个rpc request,产生这个rpc的 : response,这个过程中我需要执行若干个步骤 : 1: input request, output A : 2: input request, output B : 3: input A, B, output C : 4: input request, A, C; output D : 5: input B, D output final response : 每一个步骤内部的logic可能是一个blocking computation,也可能是一个async call
|
|
|
Y**G 发帖数: 1089 | 21 Amazon SWF不就是解决这种问题的吗?Any in large scale.
call
【在 S********t 的大作中提到】 : Guice倒是开源的,别的DI方案也有。想请教下,市面上有没有这样的轮子,来解决 : processing step之间的dependency,framework去schedule每一个step的异步执行? : 举个例子,我要写一个后端rpc service,处理一个rpc request,产生这个rpc的 : response,这个过程中我需要执行若干个步骤 : 1: input request, output A : 2: input request, output B : 3: input A, B, output C : 4: input request, A, C; output D : 5: input B, D output final response : 每一个步骤内部的logic可能是一个blocking computation,也可能是一个async call
|
S********t 发帖数: 3431 | |
S********t 发帖数: 3431 | |