z****e
发帖数: 54598 | 1 需要汇总数据，所以用vert.x比较容易解决这个需求
其他server的话，汇总数据要自己写，bus要自己建，vert.x自己就有bus
可以直接用
然后latency这个需求，这个用异步可以很容易解决
看看rxjava的subscribe，把你需要callback的部分放到subscribe中去就好了
这样一旦建模完成就可以callback回来，然后你要怎么弄就怎么弄了
唯一的问题是这两个刚做出来没多久，可以参考的文档不多
不过本身你这个需求就比较另类，没有太多的轮子可以直接用
所以如果不怕文档少的话，就放手做吧
spark用起来比vertx麻烦不少，而且spark主要是建模容易
跟hdfs等数据源的接口比较容易做
如果你是自己建模的话，不用spark也没啥大不了的
做吧
N |
|
z****e
发帖数: 54598 | 2 vert.x其实就是object或者说是verticle层面的封装
这样你就不用像fp一样搞什么immutable了
轻松容易许多，当然你要搞也可以，只是木有必要
记住这句话
"Vert.x guarantees that a particular verticle instance is never executed by
more than one thread concurrently."
http://vertx.io/manual.html#concurrency |
|
z****e
发帖数: 54598 | 3 举个例子
class A
A有个对象是a
如果你啥都没做的话
那么这个a并不是线程安全的
为了线程安全，人们想出了各种方法
比如一种线程安全的机制就是lock
但是lock会带来各种狗血问题，比如死锁
而另外一种机制就是immutable
每个thread访问时候，拷贝一份副本就是了
但是这也会带来各种问题，而且不利于理解
fp的狂徒居然发疯了一样要求人们接受什么都是常量的想法
神经病
然后spring什么则是不做控制，你自己要留意
这样就加重了你写代码时候的负担，等于什么都没有做
然后node干脆就干掉多线程，用单线程来做
多线程启动多个process，但是这样的话
你自己要去管理process，以发挥最大机能
尤其是多个cpu多个core的环境下，也麻烦
然后ejb说我可以保证每个instance，一次只会被一个thread所访问
就木有问题，但是这样并发量大的时候，有些操作会导致thread堵塞
就是同步操作，所以ejb并没有很好滴address大并发的问题
虽然提出的构想和目标很美好，但是实现的手段不够好
很多人还是选择了spring那些
但是有了异步之后，大量block的操作... 阅读全帖 |
|
|
z****e
发帖数: 54598 | 5 另外，只有node才需要ipc
其它框架都是itc
这就是为啥node很傻逼
像单线程一样编程是目的
但是你真把所有东西都做成单线程的话
那个thread挂了咋办捏？
哪怕是一个不小心，被阿三程序员写段代码blocked了
你不一样很苦逼？
当然这个问题哪怕是弄成itc一样存在
但是至少至少，其它启动的threads会在一定程度上抵消这个问题
我猜测这就是为啥在大多数报告里面，node总是会有丢包的问题
可能就是那个线程出了问题，把所有鸡蛋全部放在一个篮子里
自然会出问题，vert.x说，我按照cpu有多少个core来建threads
一个dual core的cpu，vert.x就启两个threads，如果是两个这种cpus
就起2*2=4个threads，这样万一其中一个thread被blocked，一样不会挂，对不对？
当然blocked在异步编程中是错误的，而且同一个process下处理communication
比起多个processes下处理，那是要强太多了，不同process之间做c，那很苦逼的好不好
得调用第三方工具，各种狗血问题，所以你还是用node的思维来看其他多线程... 阅读全帖 |
|
z****e
发帖数: 54598 | 6 vert.x heavy在哪里？总共就10多m的一个东西
为啥很难scale？
只要做到stateless，scale都很容易，几乎都是线性scale
哪怕ejb都可以很容易做到线性scale
vert.x天生就是stateless的东西
所谓scale难都是一些无聊的人为了吹嘘自己的本领而编造出来的
做过以后就不以为然的 |
|
z****e
发帖数: 54598 | 7 其他框架根本不需要多process，去哪里来的ipc问题？
node的ipc放在其他框架就是itc，而且vert.x天生就有一个bus予以解决
node还要自己倒腾第三方工具予以解决，只有node需要倒腾第三方工具解决并发问题
其他都不用，哪怕是akka都是自己搞定，所谓ipc就是一个集成的问题
单机系统还需要集成的只有单线程，其他都不用，自己能搞定
这个完全是一个名词上的混淆，根本不是什么优势，是大大滴劣势
至于io快，纯粹胡说八道，vert.x vs node.js的报告到处都是
自己试试就知道node有多烂了，你还是没试过，凭想象来指责其他框架的问题 |
|
z****e
发帖数: 54598 | 8 我没说很容易
如果用node就不那么容易，尤其是当process多了之后
就很恶心
用vert.x就相对简单，因为这种情况在预料之中，有现成的文档予以解决
而且不同情况不一样
有些场景比如游戏就很难
但是大多数尤其是web，就相对简单很多
node在单机上的多process都需要第三方软件介入
这是非常滑稽可笑的，就是对这些东西了解了之后
才会觉得它烂，而不是像宗教一样，除了说好和坏以外，连一个合理的理由都说不出来
估计你没搞过其他的框架，我怀疑你甚至连vert.x可以直接用js都不知道
当然灌水嘛，不用太认真 |
|
z****e
发帖数: 54598 | 9 另外，只有node才需要ipc
其它框架都是itc
这就是为啥node很傻逼
像单线程一样编程是目的
但是你真把所有东西都做成单线程的话
那个thread挂了咋办捏？
哪怕是一个不小心，被阿三程序员写段代码blocked了
你不一样很苦逼？
当然这个问题哪怕是弄成itc一样存在
但是至少至少，其它启动的threads会在一定程度上抵消这个问题
我猜测这就是为啥在大多数报告里面，node总是会有丢包的问题
可能就是那个线程出了问题，把所有鸡蛋全部放在一个篮子里
自然会出问题，vert.x说，我按照cpu有多少个core来建threads
一个dual core的cpu，vert.x就启两个threads，如果是两个这种cpus
就起2*2=4个threads，这样万一其中一个thread被blocked，一样不会挂，对不对？
当然blocked在异步编程中是错误的，而且同一个process下处理communication
比起多个processes下处理，那是要强太多了，不同process之间做c，那很苦逼的好不好
得调用第三方工具，各种狗血问题，所以你还是用node的思维来看其他多线程... 阅读全帖 |
|
z****e
发帖数: 54598 | 10 vert.x heavy在哪里？总共就10多m的一个东西
为啥很难scale？
只要做到stateless，scale都很容易，几乎都是线性scale
哪怕ejb都可以很容易做到线性scale
vert.x天生就是stateless的东西
所谓scale难都是一些无聊的人为了吹嘘自己的本领而编造出来的
做过以后就不以为然的 |
|
z****e
发帖数: 54598 | 11 其他框架根本不需要多process，去哪里来的ipc问题？
node的ipc放在其他框架就是itc，而且vert.x天生就有一个bus予以解决
node还要自己倒腾第三方工具予以解决，只有node需要倒腾第三方工具解决并发问题
其他都不用，哪怕是akka都是自己搞定，所谓ipc就是一个集成的问题
单机系统还需要集成的只有单线程，其他都不用，自己能搞定
这个完全是一个名词上的混淆，根本不是什么优势，是大大滴劣势
至于io快，纯粹胡说八道，vert.x vs node.js的报告到处都是
自己试试就知道node有多烂了，你还是没试过，凭想象来指责其他框架的问题 |
|
z****e
发帖数: 54598 | 12 我没说很容易
如果用node就不那么容易，尤其是当process多了之后
就很恶心
用vert.x就相对简单，因为这种情况在预料之中，有现成的文档予以解决
而且不同情况不一样
有些场景比如游戏就很难
但是大多数尤其是web，就相对简单很多
node在单机上的多process都需要第三方软件介入
这是非常滑稽可笑的，就是对这些东西了解了之后
才会觉得它烂，而不是像宗教一样，除了说好和坏以外，连一个合理的理由都说不出来
估计你没搞过其他的框架，我怀疑你甚至连vert.x可以直接用js都不知道
当然灌水嘛，不用太认真 |
|
z****e
发帖数: 54598 | 13 俺不负责滴预测一次
只要l家有组用了vert.x
就会蜂拥而至，vert.x和java8不冲突
还有rxjava，netflix已经在用了 |
|
z****e
发帖数: 54598 | 14 俺不负责滴预测一次
只要l家有组用了vert.x
就会蜂拥而至，vert.x和java8不冲突
还有rxjava，netflix已经在用了 |
|
z****e
发帖数: 54598 | 15 用了node又被推翻那这个显然不是什么方便阿三搬运那么简单
否则一开始就不会上node
简单粗暴不是错，错在server不可能永远简单粗暴下去
该解决的问题迟早要解决
play真难用，vert.x容易得多
vert.x既没有play那么复杂，又有node的简单粗暴
人总是在吃到各种亏之后才会记住教训
JAVA8
。。 |
|
z****e
发帖数: 54598 | 16 用scala那几个id的平均水平最高
不管是骂还是捧，只要是认真写过scala的，水平都在
那种写过hello world就自诩用过scala的不算
明显胜过其他那些，也就是scala那几个能解释清楚为什么要这么做
这些概念啥意思，也明白java到底是怎么回事
能够比较自如滴交流，其他的，很多不懂怎么回事，容易鸡同鸭讲
我说的是平均水平，用scala那几个出来说，我写过java
我信，但是如果是其他的，那未必是真的，多数是吹牛
scala好就好在，对于各种features可以自由选择
而不用换个feature就换个语言，这种做纯粹脑子进水
因为语法要背半天，看来以后要专注于扯蛋scala了
对于学习scala，我的心得是最好先把java学清楚，不要跳过java
否则你会死得很惨的，举个例子，比如case class
这里面一堆东西，比如case class有get方法
如果你工作中用过java，应该知道怎么用
其次case class是singleton，你用过spring的话，这个就不会陌生了
还有自动实现了equals&hashcode，这两个也常用
但是这两个是初学者经常出问题的... 阅读全帖 |
|
z****e
发帖数: 54598 | 17 用vert.x写会更容易
单纯搬运数据脚本无问题
但是一旦涉及数据处理，脚本就吃不消了
而且脚本也有很多种，ruby什么一样能做，也都是脚本
你看vert.x的helloworld例子里面，哪个代码最少？
不是js，也不是scala那些，是groovy，连import都给你省了
http://vertx.io/ |
|
z****e
发帖数: 54598 | 18 嘿嘿，vert.x v3就可以直接从客户端往bus里面塞msg
vert.x真是牛逼神器 |
|
|
z****e
发帖数: 54598 | 20 因为message broker并不是什么特别难的东西
jms随便用，除非你要用到streaming
这个时候storm什么可以顶上，不过你绝大多数时候用不到
我用的是vert.x自带的broker，等vert.x 3出来之后，可以对接客户端的message
这样就不用额外搞一个了 |
|
z****e
发帖数: 54598 | 21 server side最简单粗暴的就是vert.x
尤其是适合各种游戏的server
比如棋牌乐，你用process蛋疼到死
用vert.x就很容易，直接启thread对于每一局的话
搞定 |
|
z****e
发帖数: 54598 | 22 abi以后不会是问题了
但是这个向后或者向前兼容来得有些太迟了
vert.x现在的scala api就面临着这种问题
因为无法兼容，导致每次升级，scala部分代码都需要大量重构
每次都是其他语言都做好了，都开始测试了
就看scala在那边磨磨蹭蹭，要等很久才会好，因为工作量甚大
而且即便如此，main team都觉得会偏离core code
因为大多数语言的api都是一层wrapper，而scala不是
有很多工作几乎是重构了整个设计
但是好在scala可以直接用java的api，所以也还好就是了
现在vert.x v3主要的工作就是在scala上，其他基本上都做得差不多了 |
|
z****e
发帖数: 54598 | 23 real-time你要自己处理threads，最好用thread pool，几乎必需自己动手写
你建模必需把server side考虑进去，尤其是想做大型的mmorpg
c++ or java，很多国内私服都是用java写的，java可以，但是是core java
卡牌，棋牌这种回合制的可以用vert.x，但是还是需要自己启动并管理部分thread
node不合适，process太耗资源，akka又太复杂
vert.x主要问题是会的人少，招来的小弟不一定能顶用
动作类指啥？
游戏server开发难度要大过web很多 |
|
z****e
发帖数: 54598 | 24 可以预见的是，随着接口的定义成型，这个接口的定义会越来越复杂
因为现实的复杂度是比较高的，导致很难用一些简单的接口来搞定所有问题
所以不停滴加接口，加各种函数定义，最后所有人都在这堆规则中游泳
如果这些规则是公开的标准，还凑合，如果是scope=company
下面的人很快就会造反，跳槽的会变多，因为这样等于把自身技术生命绑定到公司这艘
船上
都不是傻子，谁都会自己的前途着想，做螺丝钉没有太多人愿意
interface/protocol这些东西并不是特别好用
举个最简单的例子
比如你写了一个module，或者叫verticle/actor in vert.x/akka
是一个组件，你要plugin到这个系统中去
那么比较愚蠢的方式就是找个脚本
用container.deploy("module name");
同时当然你也需要定义好interface/protocol，让别人去impl这些interface
这种方式部署，因为这种方式要重新编译，很麻烦，不灵活
比较聪明的方式是找个config，写成
或者json
module:... 阅读全帖 |
|
z****e
发帖数: 54598 | 25 spring是jee的子集了现在
spring重点对付多线程管理
如何通过di解耦
这是原理，但是用起来很傻瓜
ejb本质也是一个多线程的框架
这些所有的多线程的框架目的无非一个
就是让你不再对付多线程
我之前写过vert.x跟其它方式的对比
你可以看看，目前我觉得做得最好的是vert.x
其它都不行，有硬伤，当然spring的这种做法是开创性的
巨人的肩膀，spring就是那个巨人
spring跟fp的多线程有点接近，很多idea是共通的
ejb跟脚本node那些比较像，ejb pool起来其实就是worker了 |
|
z****e
发帖数: 54598 | 26 vert.x比play容易很多
当然做web的话，vert.x稍微等等
等3出来之后再搞，官方有官方的web plugin |
|
z****e
发帖数: 54598 | 27 go和vert.x又不是一个东西
用go做太过于底层了
没吃那么饱
vert.x随便一个java的lib下下来就可以用了
用go写到明年去
go vs c差不多make sense |
|
z****e
发帖数: 54598 | 28 rhcloud
随便搞
这个你自己google一下就有
不明白有啥难的
除非你自己不懂linux和ssh这些
至于后台db可靠不可靠
这个不是cloud的问题
是你自己的db选择的问题
paas压根不管这事
你这个怀疑很无厘头
paas就是一个虚拟的linux
剩下的你用啥软件，跟这个平台稳定性有关
rhcloud主要是没有persistence，如果你怕，就用compute engine吧
vert.x也不管你用啥db，你用db纯粹是db的事
还有就是vert.x等异步服务器需要你小心一下，表block
这些东西压根不会扯到一块去，你问得也是够无厘头得 |
|
z****e
发帖数: 54598 | 29 我用vert.x+android studio
搞定了一大块东西，甚至web我都准备丢到vert.x上去
等v3出来，另外还弄了个swift/xcode |
|
z****e
发帖数: 54598 | 30 当然可以，但是要注意，vert.x用的是jython，而不是cpython
所以版本会略微老一点，不过这个应该无所谓，反正写python的人也不是那么懂
多数都是看了几个hello world就开始写的，用message的话
要用python的人做一个server起来，要理解网络协议和web service这些
嘿嘿，我看难度不小，写脚本的人一般不太懂这些东西
vert.x可以帮你搞掂这些外行，让他们很快滴fit in |
|
z****e
发帖数: 54598 | 31 postgresql -> 同步
mongo -> 异步
node -> 异步
php, tomcat -> 同步
vert.x -> 异步＋同步(worker)
node也有worker，但是很麻烦，比较折腾
同步搭配同步的，异步搭配异步的
如果你换着搭配，就会有冲突
mongo是不太容易做join，但是比你搞异步的postgresql可能要简单点
如果你坚持node的话，用vert.x这些都不是问题，意料之中 |
|
z****e
发帖数: 54598 | 32 用什么j2ee啊
用upd或者tcp
直接上java socket
java做一层socket的lib，用vert.x去监听
vert.x对于常用的网络协议都有现成的类库，直接用
主要是swift需要找一个udp/tcp的类库 |
|
z****e
发帖数: 54598 | 33 如果你一定要用j2ee的components，最简单的是restful web service
如果你有选择可以不用，那就是tomcat, spring, jersey这些，这些也是j2ee
轻量级的j2ee，或者叫非正规的j2ee components
正规的开源重量级的j2ee就是wildfly(jboss)，做法跟weblogic什么一样
如果可以选择不用j2ee，那就用vert.x，直接走tcp协议，比http高效
如果时效要求再高一点，就走udp，游戏一般是udp，vert.x搞这些没问题
ios那边，如果是udp/tcp协议，用我前面发的那个类库，你确定是udp还是tcp之后
只需要拷贝2个文件就好了，如果是http协议以及web service的话
需要parse xml，json这些，就用cocoa2009给你讲的那个类库
另外，apple跟ibm已经联手了，估计websphere那边早就有类似的东西了
如果用了websphere的话，直接问问他们的工程师，也许会有惊喜 |
|
z****e
发帖数: 54598 | 34 可能hdfs也值得带走吧
hbase就算了吧，不太想用
postgre+cassandra+flink
应该可以满足绝大多数需要了
flink可以替换掉yarn, spark, storm & hdmr
cassandra，postgre可以替换掉hbase，mongo
剩下的交给vert.x
酱紫大概用4-5个框架，就可以解决几乎所有目前已知需求
sql/db, nosql/batch, streaming, script, web, web service, thread pool etc.
如果将来有一个vert.x based & flink-like system
而非akka based systems(spark&flink)
那就是一个终极解决方案，要有人这么搞就太好了
话说nosql真麻烦啊
一般db的话，一个jdbc就搞掂了，顶多说异步的话，需要启一个worker
但是nosql还要折腾mr，yarn, spark, flink这些，麻烦不少 |
|
z****e
发帖数: 54598 | 35
干，你的需求难道除了核心算法以外其他都没有了吗？
当时洋洋洒洒列了一大堆，我说的意思是这些东西用个合适的轮子
就是半个小时就搞定的事，哪里需要那么多东西还整合来整合去
所以其实那个项目除了核心算法以外其他都是苦力活
木有太大吸引力，算法部分另说
因为算法部分不是vert.x的长项，它也不是设计来做这个的
vert.x属于infra的一部分，算法处理可以通过spark等来搞
比较合理的方式是直接扩充mllib，而非自己搞一个，要学会合作
而不是自己单干，协作远比单干难，如果无法跟现有eco协作的话
项目是没有前途的，所以现在都在hadoop上往上加
hadoop本身跟java又有很深的渊源
从os->java->hadoop->spark你看到这里面的依赖关系没有？
这才是发展，而不是动不动革命掉，重新搞，一个国家不能这么搞
一个软件同样不能随便这样搞
另外我做了的东西不会公开的，github上有太多人用真名
我自己还有不少东西在上面，有些是直接卖钱的app，可不是什么tools
所以如果你真的有一天遇到了这个项目，那恭喜我自己，成功了
我也希望你能看到 |
|
z****e
发帖数: 54598 | 36 akka最头疼的就是树状结构
到最后actors越来越多，自己都有些迷失了
虽然理论上可以复用actor，但是大部分时候都是各自写各自的
vert.x就是扁平的网状结构，每一个verticle都是平等的
随时可以通过verticles的组合来形成你的需求处理链
而且msg的发送是通过bus来发送的，不像actor那样，跟每个actor绑定
这就增加了代码的复用的可能性，而且akka一旦有一个actor挂了
整个处理逻辑就over了，但是vert.x可以随时拔插进verticles，就比较方便 |
|
c****e
发帖数: 46 | 37 vert.x 3 官方的定位是这样的“Vert.x is a tool-kit for building reactive
applications on the JVM”
vertx可以用来实现async web service， 但是不仅仅能做web service.
之所以和akka比，是因为他们都能解决thread带来的问题，都能让application
reactive. |
|
z****e
发帖数: 54598 | 38 你在说什么呀，这两个一点都不冲突，你用spark是用来处理nosql那些data的
vert.x根本就不是主攻这一块，虽然理论上可以用vert.x来替换akka
但是这个就算做了，也跟用户无关，那是spark这些写轮子的人的事
你难道学个spark还去倒腾akka？你没搞错吧？
我觉得你在编造很多东西，很多东西一看就觉得不make sense |
|
c****e
发帖数: 46 | 39 看这里：http://vert-x3.github.io/docs/
底层的例子已经很全了。
可能视点不一样的原因，我倒是觉得java正是吸引人的地方。
vert.x 3其他语言api都能从java api 用code gen产生，明确java一等公民地位。
这个的最大好处是极有可能被enterprise接受。 |
|
z****e
发帖数: 54598 | 40
我怀疑它根本没有看过vert.x
它说它用过vert.x，我很怀疑啊
用过的话，犯这么低级错误，有些不可思议啊 |
|
z****e
发帖数: 54598 | 41
msg就是event的一种，如果非要纠结的话
vert.x也有bus
还有就是，vert.x可不仅仅是event，还有thread |
|
z****e
发帖数: 54598 | 42 另外我写数据并不经过spark
直接vert.x->c*，spark主要负责读出数据做分析
如果单纯的crud，根本不过spark
包括查询，也不过spark，用cql
所以对于spark的需求仅仅限于ml部分
这样数据量大就不是完全spark的东西了
很大一部分分流给了vert.x去做，比如使用storm
就不需要介入spark的streaming
可能这也是为什么我可以放弃掉hadoop的原因
yarn更是早就放弃了 |
|
z*******3
发帖数: 13709 | 43 顺便说一下，run 什么来submit jobs这种属于手动
这种东西完全可以自动化起来
cloud一天到晚忙活的就是自动化这些东西
所以cloud开发经常用python这些东西
因为wrapper容易做
但是一般运行时候，这种东西尽量做成自动化操作
就是service，楼主的思路很正确
一般通过run什么script来提交的，这种要么就是开发时候用
因为测试时候直接run比较容易搞，大部分qa都有自己的脚本
但是prod.一般都是自动化，所以一般需要看programmatically blablabla
这个如果多做点vert.x的项目，就很容易想到
因为vert.x的verticles的安装，就是run script和programmatically两种方式
一般测试用前者，prod.用后者
楼主可以搜索一下programmatically run spark jobs，可以看到很多人在问类似的问题
然后前面其他人推荐的jobserver也是一个solution |
|
z*******3
发帖数: 13709 | 44 vert.x就是actor
只不过文档不会像akka那样，到处都是含混晦涩的概念
immutable，state，actor满天飞
vert.x的文档几乎没出现过这些概念，虽然用的是同样的model |
|
z*******3
发帖数: 13709 | 45 akka和hadoop给我的感觉就像当年的ejb一样复杂难懂
各种乱七八糟的概念满天飞，好像很fashion，其实也就是那么一回事
相比之下，vert.x，c*的哲学我很喜欢
不跟你扯概念，扯理论，从最简单的入手，慢慢作难起来
还有就是hadoop是一个很大的eco，应该具体问题具体分析
hadoop mapreduce就已经被取代了，虽然over yarn还是很多人用
但是这个就犹如隔靴扰痒痒，很不爽的说
其实很多frameworks都太复杂了，包括akka
一些很简单的概念，被说得复杂异常
从历史上看，simplicity always wins
更不要说新生代的东西，更加兼容
就比如ap可以tune成cp，反过来就不行，那显然ap系统前景广阔
同样的，vert.x可以当akka&node用，反过来就不行
这就是区别，简单是一回事，兼容性是另外一回事
一般这两个方面同时占据上风的话，后面就很容易想了
其他的，gradle对于maven也是如此，android studio就用了gradle，而非maven
简单不仅仅是对于用户是种需求，对于开发人员同样也是需求 |
|
z*******3
发帖数: 13709 | 46 属于学校
尤其是在学校做出来的东西
基本上都会被学校所claim
因为idea是学校的，老板也算是学校的
除非老板辞职走人后再搞，让学校这个project流产
否则只要在学校搞出来，学校就会claim版权
个人想claim这个版权，最好等毕业之后再release
不过一般这种都要等你这个玩意大红大紫之后学校才会去claim
而且学校在你成功之前，会有很多connections帮忙你成功
比如学校会组织校友来看你做的东西，然后撮合你们，一方给钱，一方搞技术酱紫
最后学校从中抽成，等毕业之后再release的话，就未必能有这些机会
最后，如果是公派的留学生，国家也会claim版权
还有就是在职人员做出来的话，公司也有可能claim版权
简单说就是谁给钱，发工资，你做出来的东西，就有可能被雇主所claim
公派留学生的国家，在职人员的公司，学校的老板，这都是给钱发工资的entity
所以他们如果claim，也很正常
tim fox的vert.x就是被vmware和red hat所争夺
因为vm ware雇他的时候，他做出了vert.x |
|
z*******3
发帖数: 13709 | 47
先区分是不是reactive
reactive最快最有效率，来一个就处理一个
vert.x的是rxjava，天生就是reactive
akka和storm需要通过插件来改成reactive
flink的streaming目前是window&trigger，并不是reactive的
也不是最快的，但是比spark的microbatch要强一点点
跟不改reactive的storm类似
spark的是microbatch
如果要做成reactive的话
第一步改成getSeed.subscribe(datasource)
然后datasource.publish之后，就自动启动这一套逻辑
akka就可以publish，vert.x就可以subscribe akka |
|
c*********e
发帖数: 16335 | 48 不得不说，你是vert.x的托。看看vert.x网站上用它的几个公司，groupon, hulu, rbs
, red hat
都会超过8个 |
|
|
z****e
发帖数: 54598 | 50 比起这些新技术来说，刷题可能是一种更为可行的方式
至少有章可循，对于nosql这些东西的了解和学习
你需要对db，网络，分布式这些一顿恶补才行
big data更是涉及很恶心的数学，从线性代数开始卷进去
我不认为你可以很快上手，从另外一方面说
这些东西迟早会进入企业，所以你也不用特别的担心
可以从建议你boss用一些新的工具入手
比如vert.x，vert.x懂了之后，基本上我觉得多线程的模式
常见的工具的hello world这些应该就不怕了
当然后续还有很长的路要走，至少你可以抬脚往前走了 |
|
