|
g*****g
发帖数: 34805 | 2 RxJava is just a way to replace Future, it has nothing to do with
concurrency model. You can use vert.x along with it. |
|
|
z****e
发帖数: 54598 | 4 你应该不会这么急着上吧？
再等等吧，现在主要问题是scala那边需要大量重构代码
不兼容java的api，其他语言都能兼容，制作组不想写太多scala代码
但是目前看，没有特别好的方法，因为v2的scala刚写完没多久
又要再写一遍，如果你实在想搞
单独用rxjava，vert.x只是一个简单的网络listener而已
自己写一个也不难，还有一个worker
理解了rxjava的idea，其实剩下的无非是实现verticle的interface的问题
这两个整合好像没有那么难吧？以前hibernate，struts什么比这个恶心多了 |
|
z****e
发帖数: 54598 | 5 observer, listener这个在swing时代就有了
再早vc，smark什么叉叉什么不知道
但是估计也有，jms的subscriber还是后来的事了
属于21个patterns里面不怎么为人所用的一个
除了jms和swing这种，现在做的无非是一些infra
以后其他人用了可以不用再重复造这个轮子罢了
没啥大不了的，用点脑子，自己做一个出来也不是什么难事
关键是一堆蠢货明明知道有callback hell，还能把代码写成那样
那绝对是奇芭，vert.x v3当rxjava出来之后，马上adopt
然后所有代码重构，这就是正确的态度
v2->v3是一个非常大的跨越，如果不是对原理特别熟悉的话
强烈建议等v3出来之后再搞，另外不用node的原因也很简单
因为多线程，社交网站各个thread之间可以隔离，但是我的需求可不是这么一回事
不同的thread之间需要交流，在内存中就要communicate
share objects几乎是必需的，如果存到persistence上去再回来
都不知道猴年马月了，估计差评一堆了，redis也慢，也不方便
web还是太简单了 |
|
z*******3
发帖数: 13709 | 6 eventbus部分我看他们并没有做什么改动
基本上还是原来那个，但是v2时代没有什么eventbus相关的产品吧？
v3也不过才做出第一个c++的客户端，其他的都没有看到
听说他们想做ios和android的客户端，但是目前这个优先级还比较低
还没有看到有谁打算去实现，只是tim等人的一个设想而已
如果你已经做了或者用了什么，你可以试试看，应该不会有太大问题
但是不确定，eventbus这一块对于用户来说是透明的，所以参考资料不是很多
如果想通信的话，可以直接用udp或者tcp或者http跟vert.x通信
用verticle伺候就好了，不需要直接塞入eventbus |
|
c*******9
发帖数: 9032 | 7 虽然这是不同的东西。play 2 对web应用支持多，但很多东西mobile用不上。vert.x更
底层对web支持少（和akka比，但akka比较复杂） |
|
z****e
发帖数: 54598 | 8 我用vertx,目前x3除了语言还限于那四个以外，没遇到其它问题，各种协议支持得很好
，play主要搞http，没啥意思，挺浪费的，node是单线程，app建模不合适，go没有线
程，虽然底层也是，但是不能自己操作，也不合适，app并发经常需要用到线程
：虽然这是不同的东西。play 2 对web应用支持多，但很多东西mobile用不上。vert.x
更底层对web支持少（和akka比，但akka比较复杂） |
|
z****e
发帖数: 54598 | 9
对于mobile部分，是的
java做的model可以在android和vert.x上复用 |
|
d*******r
发帖数: 3299 | 10 据我的理解
Node 那个 cluster 是本机多进程使用
Vert.x 那个是分布式的 over message bus |
|
|
l**********n
发帖数: 8443 | 12 nodejs + message queue 就相当于vert.x了吧。 |
|
z****e
发帖数: 54598 | 13
关于performance的问题
vert.x的google group很活跃
我鼓励你直接去挑战他们
tim fox很吃这一套
当然要给出源代码和具体的setups
而不是嘴巴上说，别人无法重现过程和结果，这个毫无意义 |
|
z****e
发帖数: 54598 | 14 jxcore那个测试明显有问题
把最开始的反应时间当作所有的benchmark
10runs算个p啊，应该10^3以上才make sense
还有就是很明显代码，setups什么都没给
鬼知道他怎么测的，当别人要求用multiple threading测试的时候
作者居然不知道有multiple threading的设置，那搞p啊
说明根本没用过，因为对于socket的控制，tcp允许多个socket同时listen同一个port
但是udp不允许你这么干，所以还是需要在socket的verticle上做点设置才行
而对于http来说，我相信这个设置很重要，所以tim fox解释说是setup的问题
但是原作者根本没看懂这里面会有什么问题，这个太不可信了
anyway，这个测试很容易做，你自己试试就知道了
只要源代码和具体的setup给出来，自己跑最有说服力
相比之下techempower的源代码，setups都放在github上
你自己随时可以重现他们的测试，这个非常的有说服力
期待vert.x回到techempower的比武中去 |
|
z****e
发帖数: 54598 | 15
我不觉得你知道，你说过好几次vert.x，无一例外都是错的 |
|
|
z****e
发帖数: 54598 | 17
我觉得vert.x的文档更出彩
不过他们的code里面有大量的注释
直接看javadoc其实就能看懂了 |
|
c*******9
发帖数: 9032 | 18 如果是http web为主的项目，Vert.x3 和sevlet开发难易程度差不多吧， 能代替多少
struts＋spring＋hibernate的功能？ |
|
|
c*******9
发帖数: 9032 | 20 Vert.x 和nosql 有什么关系？
要说服组里的人采用新东西不容易。 |
|
z****e
发帖数: 54598 | 21 所以我个人认为，技术革新已经逐步转移到了netflix这家公司上去
rxjava这种神奇的东西，不是google之类的做出来的
反而是netflix在搞，而且netflix很喜欢优化aws
做各种傻瓜化折腾aws的工具，我相信用不了多久
netflix的这些傻瓜化的工具会逐步流行开来
rxjava的接口什么比较标准，scala的很多东西就不那么标准
就这个差别，本质上原理是一样的
vert.x在rxjava的基础之上做了pump那些，不过我还没怎么用过
不确定这个到底怎么搞，只是听以前做scala的人提起，说大并发时候需要这个东西 |
|
z****e
发帖数: 54598 | 22
应该要等明年了
python lang support那个法国佬在忙着写网站
和vert.x awesome的test cases
年底之前比较可能加上去的语言是极为小众的ceylon
其他都要继续等了，你可以主动申请去试试
他们好像会提供tutor，因为新语言支持都是通过cod gen来生成 |
|
s***o
发帖数: 2191 | 23 老赵理解错了，Tim Fox是在发牢骚。有可能是red hat 内部的JEE五毛诸如Arun
Guupta之流在搞vert.x的小动作 |
|
f*********t
发帖数: 17 | 24 if using fiber why still sticking to Vert.x than use dropwizard
which is much simpler and more familiar to most |
|
z****e
发帖数: 54598 | 25
是啊，这些东西都略微heavy了一点
而且不够灵活
比如udp，nosql，支持就不好了
udp怎么看都需要netty系的产品，比如netty, vert.x这些
nosql怎么看也都不怎么需要orm |
|
|
z****e
发帖数: 54598 | 27
你只有一个java，一个jdk
无论是vert.x还是spring都依赖这个jdk
spring只需要有jre就行，jdk就包含有jre
跟java版本不兼容有什么关系？ |
|
g*******o
发帖数: 156 | 28 vert.x3的document上都没有scala的例子，搜了一下github也发现都是WIP.
是不是离正式支持还差不少？ |
|
z****e
发帖数: 54598 | 29
这个只是没有官方的support而已
你要用scala，只要在jvm上都可以用
直接用scala调用java的api就是了
vert.x的api总共就那么点东西，5分钟就看完了
剩下就看你怎么用了
而且你用go做还不如用scala实现一下，然后反馈给他们的community
这样你名利可以双收，写在简历上也好看，是contributor
有些module做得好的话
还可以包装成api给其他语言community用
用go的话，就算你想public，社区也要自己培养
而且go上现在可没有js engine这些东西，连jvm都没完全实现
你何必呢？而且集成只能是web service |
|
t**r
发帖数: 3428 | 30 vert.x 就那么点东西：verticles, event bus. http server/client, tcp server/
client
没了。
真的很好学。
到底有多有用，还在摸索 |
|
t**r
发帖数: 3428 | 31 vert.x 就那么点东西：verticles, event bus. http server/client, tcp server/
client
没了。
真的很好学。
到底有多有用，还在摸索 |
|
d******e
发帖数: 2265 | 32 现在ms，netflixyou自己的技术战，也有很多跟风的。
akka明显是可以做micro services。需要的那些都有。而且akka即使不做成
microservice就一个jvm。也解决了micoservice的很多问题。
vert.x貌似也是做这个的利器，呼唤赵老师。 |
|
d******e
发帖数: 2265 | 33 vert.x有client cide load balancing和service discovery嘛？ |
|
d*******r
发帖数: 3299 | 34 zhaoce你要是再 Netflix 推广vert.x实战成功了，那板上肯定一堆跳坑的 :D |
|
z****e
发帖数: 54598 | 35
谁有没有任何关系
这不是general的需求
不因为某家公司或者某个框架有而改变
实际上vert.x现在的module已经有些多了
所以拆成core, base, full这几个
all or nothing是不对滴 |
|
z****e
发帖数: 54598 | 36
对，所以vert.x启动的core的thread数量相对少
一般一个core by default就启动一个thread，叫做eventloop
这也是优势之一 |
|
d*******r
发帖数: 3299 | 37 vert.x 宣传部长看完开心了，召唤 zhaoce 来布道 :D |
|
z****e
发帖数: 54598 | 38 关键用vert.x做startup的话
你将来要iteration，比如从js -> java
就会变得很容易很自然，但是如果你要是想从一个pure js system
切换到java，那就只有web service这一套路可以走了
那就很麻烦了，系统往往要大了之后才会看出问题来
大多数大系统之所以死掉，都是因为不可维护
所以才发明了oo，而且是java这种强oo
不是因为java写hello world有多好
而是因为pure oop对于大项目来说至关重要，否则会挂
有些猴子素质比较高的公司，比如google，靠code review
但是大多数公司不可能花时间给你搞什么code review
一般code review就是3-5分钟搞定，谁无聊在那边开会啊？
一般code review看看有啥问题，连争辩都懒得争辩，直接改都改完了
也就是几分钟的事 |
|
s***o
发帖数: 2191 | 39 老赵你要找几个应用vert.x大获成功的real world use cases来show off一下，推广效
果才会好。 |
|
d******e
发帖数: 2265 | 40 上午花点时间看了vert.x web的code.主要要扒点代码下来。
感觉还是太简单了。重型应用时能被play拉出三条街。
所以，玩大的还是都上play Akka。
另外急需各种轮子。反倒用在数据pipeline时大多数情况下都足够了。 |
|
l**********n
发帖数: 8443 | 41 看了下vert.x, 很简单啊，就是event bus, 多线程太复杂了，event loop就简单多了
，timer, stream都容易掌握。 |
|
l**********n
发帖数: 8443 | 42 android复杂多了，光support library就七八个，vert.x, node什么的其实很简单 |
|
T******7
发帖数: 1419 | 43 zhaoce,请问vert.x能代替spring么？ |
|
W***o
发帖数: 6519 | 44 最近看了一下vert.x 试着玩了一下udp，感觉不错。但是感觉Go的udp更好用一些，而
且concurrency是强项 |
|
z****e
发帖数: 54598 | 45 不要为了udp而udp
我用udp是不怕丢包
之前跟dumbcoder讨论过为啥要用udp
不要为了装逼去用udp
一般的web还是去用http吧
json简单太多，干活足够
udp我直接一个byte一个byte处理
这种太过于底层，不要没事找事，而且不安全，也不稳定
我用udp基本上是把安全，稳定什么全部丢掉，以保证速度
在任何时候只在乎最后一帧的数据，之前数据全部作废
记得以前打星际，联机，第一件事就是把tcp改成udp，以保证速度
但是这个绝对不apply到很多领域，比如website
还有如果是钱的交易，我一定会上tcp，而且极有可能上https
另外就是vert.x在一些领域优势很明显，比如android上代码的复用
app和server可以直接重用同样的代码 |
|
z****e
发帖数: 54598 | 46 thread vs event
如果想要快，就用event，你要很清楚自己在做什么
另外不要让引擎拖了后退，js等脚本引擎很慢
jvm（hotspot）等要快不少
go，quasar本质上都还是thread pool
只不过是lightweight thread pool
tomcat，jetty，undertow这些是heavyweight thread pool
看你托管在什么层次上了，这种怎样都会慢
因为本质上还是thread pool嘛，就像是自动档
要想快，就用手动档
因为33ms这个高压线压着，不得不牺牲所有的其它东西
比如稳定性，安全这些，没办法了，所以用了udp和event
但是涉及到钱的部分，那肯定还是tcp了，这个时候可以用thread
所以需要一个能够在不同模式中自由切换的工具
vert.x很好滴address了这个问题，它什么都支持
而且给了我足够多的选择，我讨厌别人替我做选择
因为我总发现别人选的比我糟糕，所以还是不听别人的比较好 |
|
w***g
发帖数: 5958 | 47 vert.x基本上就是java版的node.js |
|
|
O***b
发帖数: 104 | 49 对我来说就是个在线游戏引擎
话说vert.x的话题都见不到zhaoce了，真是不胜唏嘘 |
|
d*******r
发帖数: 3299 | 50 那就还是没人用vert.x了, Node.js 和 Go 用的人多了去了...
光说好，但是没人用也难忽悠大家跳坑呀 |
|
