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 | |
