z*******3
发帖数: 13709 | 1
哈哈哈，真不容易啊，总算稍微有点懂了的样子
话说再superficial能比你说的那两个路边理论superficial？
undertow是一个最新的servlet容器，你是不是不能很准确滴理解这句话？
实际上undertow的结构跟vert.x很像，两个都实现了blocking & non-blocking的功能
两个都基于netty的实现，两个都是red hat的产品
实际上不管是blocking还是non-blocking
最后殊途同归，最后还是需要混用，你可以用nio来对付req
但是最后还是需要blocking的部分，因为总有那么些需求是blocking的
不管你用的是worker还是ejb，其本质都还是传统的thread pool
blocking部分用thread pool做优化就不用说了
而且就算是event，也还是用捆绑cores数量的thread pool
看到了吗？thread pool啊，前面的人都在讨论thread pool
前面都在讨论thread pool，你在说什么？
然后说说undertow和vert.x
undertow和vert.x的差异仅仅是标... 阅读全帖 |
|
z****e
发帖数: 54598 | 2
vert.x因为在建设3，所以tim fox要求撤下
马上就回去了，下半年估计就会放上去了
上面也写出来了，outdated version
spray— Removed at request of maintainer - outdated version
vertx — Removed at request of maintainer - outdated version
两年前vert.x可有指标都是top 1
http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&te
同窗的undertow的理念跟vert.x是一样的
都是那批人做的，看看undertow在什么位置
vert.x应该比undertow更强悍，因为不需要兼容j2ee标准
undertow是j2ee，spring那个，spring本身不是web server
不管这事，放在里面有些不伦不类 |
|
z****e
发帖数: 54598 | 3
学vert.x，你可以接触各种东西，这是server side
如果你想扩展你对于app的知识，建议直接上swift
所以swift + vert.x
你懂了vert.x之后，我觉得什么node, akka之类的，都不难
因为本来很多东西就是互相抄的，等真用了再补足剩下的不迟
这个面就广了，你还能明白rxjava, streaming, nosql这些
vert.x对这些新兴的东西支持非常好，官方直接发布包教你怎么搞
swift的话，用xcode来搞，听说apple秋季打算放出大招
在app上搞广告拦截，如果这个真的搞出来了
android跟ios的差距会进一步拉大
因为本来android的体验就不如ios，如果没有了广告，那后果不堪设想
google几乎不可能限制android上的广告投放，狗就靠这个活着的了 |
|
z****e
发帖数: 54598 | 4
once again
不是网站的后端，是所有东西的后端
包括socket, streaming这些
甚至还有file system
如果你现在还认为这个东西只能做website的话
那就太凹凸了
另外，front end的东西一直都在变，这个很正常
但是back end的东西，20年前的java，10年前的spring
都在被大面积使用中，你没写过企业软件，这个是硬伤
java的大部分东西都是一层一层往上累积
跟front end三十年河东三十年河西不是一回事
back end从java开始，每次新潮流涌现
都会从中抽取几个做得特别好的留下来
然后寻找其他部分的互补，目前看
back end几乎所有部分都被很好滴填补上了
要说还有什么没有，那就是各个domain自身的scripts还比较缺乏
比如r，很多领域都缺少r这样的脚本
而将来jvm和vert.x统一backend之后
需要做的就是在这个基础之上，作出各种脚本引擎来
实际上vert.x已经朝着这个目标大幅迈进了
os->jvm->vert.x->scripts，这个就是一个进步
跟website的一天到晚就做http还有web... 阅读全帖 |
|
z****e
发帖数: 54598 | 5
vert.x首先要有netty
vert.x的tim fox的导师就是netty的那个韩国人trustin lee
就是它跳槽到red hat之后，在trustin指导下作出的vert.x
10年前连netty都不存在，trustin刚毕业不过两年
去哪里来的vert.x？ |
|
w***g
发帖数: 5958 | 6 我看赵策这么desperate，顺便帮他做下广告。我自己感兴趣的是DPDK。
这个benchmark里DPDK 服务器 + 传统客户端能做到192K req/s，
（我重复出来是210K req/s)
比C++/vert.x传统服务器高差不多一倍。但是其实DPDK服务器是没用足的，
客户端是bottleneck。如果用多台客户机，DPDK吞吐量能进一步提高。
我在相同的硬件上试了DPDK 服务器 + DPDK 客户端，吞吐量能做到
500K req/s。也就是vert.x的5.5倍。这个5.5倍只是HTTP短消息的开销，
如果业务逻辑加上去，速度提升就不会那么明显。vert.x相对别的
框架的提高也是同理。一般app应该连vert.x的性能都不需要的。 |
|
l**********n
发帖数: 8443 | 7 【 以下文字转载自 Military 讨论区 】
发信人: zhaoce (米高蜥蜴), 信区: Military
标 题: java之后，人类就已经不再意计算机语言了
发信站: BBS 未名空间站 (Mon Jan 25 19:13:08 2016, 美东)
你可以说计算机语言已死
或者说是一个夕阳产业了
就是人类已经发现了这个领域的最优解
就不再继续折腾了，你只需要学会人类定义好的规则就好了
计算机语言这个领域已经没有什么难题需要人类去解决了
java之前，人们之所以搞计算机语言
是因为觉得机器的对话方式，跟人类对话方式有比较大的差异
所以人类可能看不懂机器在执行什么，比如01001011110101010
给你这么一串，你滴不懂这个是啥意思
但是java之后，基本上人能看懂了
所以满足了这个目的之后，还在折腾计算机语言的
不是脑子有屎就是目光短浅，人家解决过的问题
你解决了干嘛？就犹如数学上的某个猜想，已经得到了证明
你再证明一遍？有用吗？你就算证明出来了，人家多半也会说你是抄的
所以计算机语言这个level，已经没有什么可以继续搞的了
剩下无非继续傻瓜化，做成脚本或者置标语言... 阅读全帖 |
|
z****e
发帖数: 54598 | 8
vert.x过去两年大发展啊，早已今非昔比了
这两年错过vert.x的是一个巨大的损失，不是我说
准备技术输出了，然后噱头就是
比spring mvc快几十倍
生态比go好几十倍
市场买不买这个账，不知道，管他呢，反正就是宣传
至于kotlin对vert.x的促进作用，看上面讲的coroutine部分
这个中国人贡献的代码已经merge进官方库了
马上就release了，就能用了
3.5的新增功能包括
kotlin的coroutine原生支持
rxjava 2.0的升级
jdbc client的callback的简化
强烈建议马上升级
ceylon贡献给了eclipse之后，也会加入coroutine
java这个还需要时间
现在项目中，java, kotlin, groovy都有，因为idea社区版加入了scala的滋持
所以准备上scala了，至于js本来就有，但是gradle里面一般都放在resources目录下
最近搞了下ruby，感觉挺好玩的，拿ruby和另外一个中国人写的脚本到时候来做演示
展示一下这个随便选一个脚本就能用来开发项目是怎样一番光景
太有趣了
vert.x最... 阅读全帖 |
|
t******2
发帖数: 2265 | 9 GT350，0-60，3.7s，已经put the power down to wheel了，以前几代的老问题不能
carryover吧？要允许人家进步嘛。
再看看下面这个非专业马饭的数据,不进3s才是没谱的事吧。这还是没瘦身，没进化之
前的数据。
CMC Top 1/4 Mile ET List.
1. bob@kurganmotorsports - 7.72 @ 179.83 (1.227) 1986 GT, H, C, I, SC, X(364
) Powerglide
2. DynotuneMP - 7.754 @ 179.42 (1.216) 1988 GT, H, C, I, SC, X(352)
powerglide
1. vnmpind - 8.01@176 (1.41) 2003 cobra, H, C, I, T, X(363) Powerglide
2. Crazy Eddie - 8.75 @ 152 (1.27) 91 Notch, H, C, I, SC, X(304) C4
3. enginerd - 8.85 @ 155 (1.31) 93 LX, H,... 阅读全帖 |
|
|
z****e
发帖数: 54598 | 11 早就有定论了嘛
c/os -> jvm/java -> vert.x等平台化轮子，谁用matlab啊？
工业界没有人把这些东西当回事，unity也没啥用，3d游戏现在半死不活的
大量游戏公司倒闭裁员，连暴雪都不行了
现在都回到2d中去，因为2d游戏画面精美，适合艺术人员发挥
3d游戏麻痹的一个美工，要价上万，还做得跟屎一样，你认真看一下3d的美工
要做好，那个难度是2d的几倍都不止，小日本靠着2d的动画大行其道
美帝早就开始搞3d动画了，结果呢？你现在看过几部市场上反映好的3d动画片？
皮克斯那个是美国人自吹自擂的，真正动画产业还是看日本
所以短时间内，还是vert.x等轮子为王
vert.x之上，你看一下maven, npm, gem等repository
mvn现在有轮子接近120w，是目前为止数量最大的repo
java的确也只是阶段性产品，但是计算机语言到了java这个level，基本上就到头了
剩下的看轮子的，不是语言 |
|
z****e
发帖数: 54598 | 12
codegen是吧？
这个jvm和vert.x都有啊
jvm可以直接做一个script engine出来
你想怎么定义就怎么定义脚本语法
懂了没？
其次vert.x的codegen可以根据你定义的脚本
套入该框架，使得你的脚本能够用vert.x的架构实现分布式和并行计算 |
|
z****e
发帖数: 54598 | 13 就只有靠vert.x这种东西
或者类似的架构
否则没戏
其它人说得没错，java的复杂性来自多线程和并发
其实java和jvm解决了大部分low level的问题
就剩下并发了，这个由vert.x解决了
并且暴露出各种脚本接口来了
所以如果你想在效率上跟java竞争
只写脚本的话，你就应该了解vert.x
否则没戏，你自己写个单线程脚本，现在动不动都是几个cores的cpu
你跑单线程？？？您这是来逗我玩的吧？
各位索南，你们好歹也是高智商phd
这点基础知识还是要有，杀不杀老鼠，不重要
这点知识并不难以理解，文科生都懂 |
|
z****e
发帖数: 54598 | 14 跟你们boss说，用vert.x可以明显改善并提升效率并且可以兼容现有代码
一般资本家眼睛都会放光，因为有经济利益在里面
搞懂了vert.x你基本上nodejs和web service都懂了
还有message service这些也都会了，这几个都在这里面
vert.x的js部分就是照搬node.js的，这是一个超集
学习要主动一点，不可能什么都是别人教你的，绝大多数都是自己弄的
与其在这里灌水，不如自己动手做几个试验，把你想跑的跑起来
剩下的就是面试时候跟对方扯蛋了，别人也不可能去验证你是不是真用了这些产品
你说你用过node.js，他有办法证伪么？当然别把概念性的东西说错
前台 |
|
z****e
发帖数: 54598 | 15 如果是backend的话
java -> tomcat/jdbc/db(sql) -> spring/hibernate -> nosql/spark/flink/lucene
-> vert.x/netty/core java
差不多酱紫，虽然最后一步比倒数第二步数学要容易点，但是更迟出来
所以如果是学习的话，那就把最后两个颠倒一下
到了spark之后，就明显感觉数学要求陡然升高，高等数学就开始来了
第一步就是线性代数
一般的web也就是到tomcat这个level吧
很多full stack其实就是front end
无非php -> ror -> node酱紫一路过来
除了web还是web，无非换个写法而已，没啥大区别
真的full stack应该从swift -> java，像搞tableau/palantir一样搞法
那才叫真正的full stack，如果搞这种的话，java就直接跳到最后一步了
至少上netty了，现在可以上vert.x
netty作者是韩国人，也是游戏爱好者，本来初衷就是给网游用的
netty那几个core developers，基本上都在各个大公司做顾问... 阅读全帖 |
|
h*d
发帖数: 19309 | 16 你自己扯的你都不记得了? cql那货返回点数据也就罢了，处理数据还是算了。
http://www.mitbbs.com/article_t/JobHunting/33063511.html
发信人: zhaoce (米高蜥蜴), 信区: JobHunting
标 题: Re: full stack track 和 backend track 哪个更有前途？
发信站: BBS 未名空间站 (Thu Oct 1 07:59:32 2015, 美东)
如果是backend的话
java -> tomcat/jdbc/db(sql) -> spring/hibernate -> nosql/spark/flink/lucene
-> vert.x/netty/core java
差不多酱紫，虽然最后一步比倒数第二步数学要容易点，但是更迟出来
所以如果是学习的话，那就把最后两个颠倒一下
到了spark之后，就明显感觉数学要求陡然升高，高等数学就开始来了
第一步就是线性代数
一般的web也就是到tomcat这个level吧
很多full stack其实就是front end
无非php ->... 阅读全帖 |
|
z****e
发帖数: 54598 | 17 1）恭喜，你快找到工作了，如果运气好的话，这个就过了
虽然回答得还是不那么顺畅，但是基本上属于可以要的程度
虽然你自己感觉不好，但是回答得马马虎虎过得去吧
2）swjtuer说得是对的，你的问题在于，除了你自己做过的
其他不知道，也不懂得吹，所以回答得磕磕巴巴
要举一反三嘛，不要瞎子摸象嘛，java世界这么大
你不可能所有产品都用过去，你要懂得归类嘛
没用过，你可以猜嘛，举个例子
你用过tomcat，那么所有的servlet容器都是一回事了
这一大类有tomcat, jetty, resin, undertow, weblogic webserver
websphere webserver etc.还有很多
所以当其他名词出现在你面前的时候，你要懂得联系起来
题是死的，人是活的嘛
3）具体到nio，其实我昨天已经给了你一个framework了
vert.x啊，你这个人脑子就这么硬，给你说过的东西，一点也不看
跟谁拗呢？nio -> netty -> vert.x就是一个从底层到相对高层的三个东西
netty和vert.x这两个项目有一个核心程序员，就在apple的icloud干
德国人... 阅读全帖 |
|
z****e
发帖数: 54598 | 18
hadoop有价值的部分主要是hdfs
用vert.x之后，连这个都可以省掉其实
我直接用vert.x的file system，自己写replica这些，也没多难
要不是大学那边一定要用hadoop，因为他们买了cloudera的服务
不用浪费，所以说给我们用不收钱，我未必会主张用什么hadoop呢
data warehouse的hype居多
其实hadoop本身也是一个hype，大多数人只是觉得这个hot
就无脑上了，etl用一个scheduler就好了，如果非要streaming的话
用rxjava做一个稳定的连接，但是一般没有必要
vert.x的setPeriodic方法足以替代一般的scheduler |
|
d*******r
发帖数: 3299 | 19 请教板上 Java 大牛们，JAX Innovation Awards 在 Java community 影响有多大?
刚刚看到这个：
http://jax.de/awards2014/
list Most Innovative Java Technology: Vert.x
list Most Innovative Open Technology: Docker
list Most Innovative Open Tech Business: Hazelcast
list Special Jury Award: JDK8
Vert.x 和 Hazelcast 本来就是一起的，所以 Vert.x 是大赢家的样子
最好玩的居然是 Go 的 Docker 也能来客串，得个奖 |
|
z****e
发帖数: 54598 | 20 jboss如果你只是用来做网站，会显得比较重
因为jboss重心不是web server那些
而是背后的ejb container，hibernate这些东西
lightweight的当然是vert.x顶用了，而且异步的也快
vert.x看官方文档就好了
http://www.openshift.com/developers/vertx
不过vert.x搞website会比较折腾
tomcat吧，加一个spring mvc就好了，象古德霸说的那样 |
|
g*****g
发帖数: 34805 | 21 没看出来，你给讲讲？
Dummy database constrained benchmarks favors 3x vert.x over Node.js.
As for 'requests per second' it's 3.5x faster (7x using both processor cores
, but this is unfair).
Vert.x sent more data down the tubes, I suppose it's caused by different '
Date' header formatting (it uses Rhino's NativeDate instead of JavaScript's
Date) . It also prints slightly longer 'X-Response-Timeout' (e.g. 13.0
instead of 13). I might look into it in the future. I tried to even out
basic benchmarks by adding... 阅读全帖 |
|
z****e
发帖数: 54598 | 22 我一直都在寻找一种简易的系统集成的方法
让这些脚本语言的程序员能够参与到java世界里面来
尤其是big data这一波
目前看vert.x最好
其他方法
eai太麻烦，太重量级，非专业人士不行
jvm的script engine还没做出来，鬼知道做成什么样子
反正至少没火起来，文档支持太少
所以就剩下vert.x
如果你有兴趣，针对vert.x的language扩展，做一个r的扩展的话
可能卖点会有很多
当然其本质是写一个jvm上的r引擎 |
|
z*******3
发帖数: 13709 | 23 那vert.x就是你的下一步
vert.x的各种模型就是j2ee的模型的简化版
我怎么看怎么觉得象一个简化的app server
vert.x架起了一座python这些语言跟java衔接的桥梁
过去之后，剩下的你怎么搞都随便了 |
|
z****e
发帖数: 54598 | 24 vert.x的模式值得学习
它只做底层的封装
后续的发展通过pkg来做
这个就很像java和eclipse本身
java只做一些很基本的功能，然后爆第三方类库扩展
谁需要自己去下去，不同公司不同群体要求是不一样的
eclipse也是如此，只做最基本的标准化开发组件
其它的，自己去下plugins
vert.x现在也只做最基本的协议封装
其它的通过扩展模块来实现
现在就是hadoop目前还又大又全
看什么时候persistence能出现一个类似java,eclipse和vert.x的东西的话
就很有可能成功，目前为止，所有的persistence产品都是朝着大而全方向发展
这种模式到最后会拖垮自身，就跟现在的db一样
其实windows也是这种模式，恨不得什么都塞给你
而大多数人对其中99％的功能是不需要的
结果启动爆慢，然后学习门槛居高不下，最后所有人都放弃了，前功尽弃
被下一个简洁产品所取代 |
|
z****e
发帖数: 54598 | 25 i think u should try vert.rb
if the code lines are 10 times more than node.js
then come to tim the creator of vert.x
and post following statement: vert.x sucks |
|
g*****g
发帖数: 34805 | 26 蜥蜴错了。统一多语言的不是vert.x，是JVM。JVM包括了Rhino，从Native的角度对js
的支持比其他脚本语言好。
但你也错了，vert.x虽然对已经习惯多线程编程的java程序员吸引力不大。但对于node
.js社区的js程序员有很大吸引力。特别是等明年Nashorn JS engine跟着Java 8
release，Nashorn据说性能至少跟v8平级。到时候无论是node.jar，还是vert.x，都将
是node.js的有力竞争平台。node.js程序员不但可以继续写js，继续得到高性能(Rhino
不用JIT很慢)，还可以获得jvm上的巨大类库，这无疑是很有吸引力的。
Python |
|
z****e
发帖数: 54598 | 27 那篇文章感觉是给node.js mt什么东西做广告用的
估计是cluster的一种什么叉叉，不太了解这里面有啥玄机
但是基本上都同意，vert.x is faster than node.js
这句话也在文章中出现了n次，v8的动态类型明显拖慢了它的效率
这个只能依赖dartvm去搞定了，不过dart打算自己搞node.js做的事了
dart网页更新得很快，vert.x在过去一个月commit数量也创造了历史高峰
node.js前景很是堪忧
Overall, Vert.X is faster than Node.JS as suggested by others before. |
|
|
z****e
发帖数: 54598 | 29 这个真的是随便你用什么都可以
ws简化的就是一个简单的http请求和response
tomcat那个估计不是servlet而是jax-rs
如果你嫌ws太麻烦的话，你不用也没什么
就用最简单的http请求就好了，gae我成功过
但是动不动就给休眠，我现在用mimisoft推荐的digitalocean.com
$5一个月，不算贵，域名用internetbs.net，公孙大神推荐的
具体的服务器我不用tomcat，用vert.x，啥语言都支持
看了一些报告，韩国构架师领军的netty在cloud平台上，比如ec2表现最好
而vert.x是基于netty的，所以理论上表现不差，但是这个需要你自己折腾
这是netty的网站：
http://netty.io/
vert.x:
http://vertx.io/ |
|
p*****2
发帖数: 21240 | 30 刚才想了一下，现在大兵法的主要解决方案就是异步，这也是为什么Node这么火的原因
，还有新兴的Go语言，老树回春的Erlang。那么Java上边情况如何呢。
我的理解基本上最下边是NIO, 然后中间有一层Netty，上边有play，reactor，vert.x。
play本身是一个模仿rails的mvc框架。现在的趋势越来越不mvc了，所以前途有限。
play下边的akka很强大，但是即使coltzhao这样的scala大牛也认为太复杂了，可见流
行程度不会很大
reactor本身是想做一个framework，并不是直接可以创建app的，并且由于很新，
production还不可用。
vert.x是zhaoce大牛最中意的，算是完全copy了node的创意，并且解决了scale和
coordination的问题。当然在web server上，goodbug大牛早说过了，request都是独立
的，所以node完全没有压力。而vert.x最大的问题是不能实现纯异步，所以还必须实用
阻碍的线程，这样就造成了瓶颈，不利于大兵法。
所以，感觉JVM上确实还没有一个比较完美的大兵法解决方案。这也... 阅读全帖 |
|
z****e
发帖数: 54598 | 31 dart自带有http request和json的parse这些
直接发送http reqeust到vert.x上就好了
vert.x天然就是一个ws server
写一个wrapper，弄三个verticle/module
一个用来监听8080端口，接收来自dart的ui请求
一个用来对付cassandra/couchdb，从nosql里面收集数据
一个用来对付spark，收集完的数据交给spark，调用mllib pkg做处理
最后反馈结果给dart，dart再把结果plot到界面上去
核心还是vert.x，这种简单的app可以同时做web和android版
等搞定后，swift出来摸熟了之后，再上ios版
dart最让我喜欢的就是html和css还有dart脚本分离
尤其是html和dart本身分离，不象以前凑在一起，难看死了
用dart我觉得不用angular也没啥大不了的 |
|
z****e
发帖数: 54598 | 32 目前vert.x已经支持了8种语言
java
javascript(rhino)
python(jython)
ruby(jruby)
groovy
scala
clojure
ceylon
一个建议
如果你会一种脚本
倒是可以跟tim fox提出去implement这个脚本在vert.x上
比如php，lua
php已经有人在做了
lua可以用luaj，然后集成的部分交给你了
这样就有机会进入vert.x的core team
写在简历上也好看
当然这是左逼的贡献精神，完全志愿的原则
一个建议而已 |
|
z****e
发帖数: 54598 | 33 不过vert.x最让人讨厌的就是plugin做得还不够好
要对付eclipse，比如你要把vert.x的main找到
然后告诉eclipse，执行这个main酱紫
debug起来会有些小麻烦，很多时候还是要用vi来折腾
不过因为vert.x启动本身也快，不像tomcat,spring那些启动比较慢
所以也还能接受 |
|
d*******r
发帖数: 3299 | 34 就知道你会推 vert.x
vert.x 对于老 Java 用户搞着顺手吗... 我看都是在用异步
还有, vert.x + ORM_over_SQL 这种有成熟方案吗
用 tomcat 那些, Spring还是要研究吧? |
|
z*******3
发帖数: 13709 | 35
ror在设计上有它的好处
groovy并不负责搞spring和hibernate的那些东西
这些framework和语言各有各的用处
并不是mutually exclusive
spring主要负责di和ioc，hibernate负责orm
groovy则主要是负责简化逻辑代码
你用groovy写各种crud很快
vert.x里面所有例子，groovy的代码是最简短的
超过其他所有脚本语言，比js还有ruby都简短
这个你如果用vert.x的话，可以直接对比，一下就看出来了
而简化代码跟di还有orm并不冲突啊
所谓grails就把这些东西汇总起来的这么一个框架
实际上所有的web server都是好几个东西的汇总
比如html template，比如session management，比如web listener etc.
讲一个东西容易一堆东西一起上，乱七八糟
比如struts以前就用了那个啥freemarker
搞vert.x就把这些都分开，你自己搭配，任何一个组件出了问题
你就去看这部分是咋回事，而不是瞎子摸象
啊，好大一个概念，你都不懂里面到底咋回事
虽然最后你还是得挨个... 阅读全帖 |
|
z*******3
发帖数: 13709 | 36
vert.x天然就支持websocket
http,tcp,udp这些常见的网络协议vert.x都支持
还有jca, jms这些
自己翻翻manual吧，到处都是
http://vertx.io/docs/vertx-core/groovy/
WebSockets are a web technology that allows a full duplex socket-like
connection between HTTP servers and HTTP clients (typically browsers).
vert.x的api对新生事物的兼容性做得很好
各种features都围绕着新生的工具展开
下一步重点是streaming api |
|
z*******3
发帖数: 13709 | 37
其实不难，typesafe那帮人故意弄复杂了
估计好骗钱吧，it很多东西都故意弄得很复杂，便于收取咨询费
akka的基本单位跟vert.x一样
vert.x官方文档里面也说了，就是actor model
但是akka的是树状结构，一个接一个，就像tree node一样
vert.x是bus结构，所有的communication通过event bus完成
就更简单一点，然后各种接口什么也都比较完整
你可以随心所欲自由搭配和组合，这种非侵入式的设计比较讨喜 |
|
z****e
发帖数: 54598 | 38 既然“建模要周期性的重复进行”
那这个怎么会对latency比较高呢？
你需要的应该只是一个异步构架吧？
需要能够迅速响应你的请求，而非长时间石沉大海一样的无影无踪
能够告诉你，它在working
vert.x配合rxjava应该够你用了
akka我反正当时用得很痛苦
scala一直给我感觉不是那么容易搞
另外你的数学模型处理本身也需要一个接口
还有楼上说的数据传输可能会成为瓶颈
vert.x的设计可以当一个司令部用
最近有个年代古老的卡通寄生兽有看不？
那个卡通大boss就是一个寄生兽头部控制四肢寄生兽的一个东西
如果是我来做，我就用vert.x当头
然后控制其他部位，每个部位写一个mod，然后deploy |
|
z****e
发帖数: 54598 | 39 STABLE RELEASE 0.31.1
老样子，把版本号好好观赏下，第一个数字是啥？
vert.x的plugin太难做了
因为兼容一堆语言，clj的plugin都没搞好
vert.x只能继续等下去
不过如果坚持用 java的话，vert.x倒是很容易搞定 |
|
z****e
发帖数: 54598 | 40 verticle是抽象的概念，module是具体的文件
verticle是每次运行的时候，vert.x保证每一个verticle的instance会被单个thread所
访问
不会被多个thread同时访问，而module是你把文件打成的包叫做module
所以可以把多个verticle放到同一个module下面去
但是vert.x运行的时候，还是会将每一个verticle的instance安排给一个具体的thread
vert.x默认是你有多少个core，就运行多少个threads
这样你就不需要像node一样启动多个process了
这些threads之间的通信通过bus来通信 |
|
z****e
发帖数: 54598 | 41 系统什么时候并行你不需要操心
反正你的每一个verticle对象只会被一个thread所执行，在同一个时间点内
不会互相干扰，所以你不用去管vert.x什么时候做并行操作，什么时候不做
这个dispatch由vert.x来搞
所以哪怕你启动的只有一个verticle，只监听一个port
也还是会有多个threads来调用这个verticle的instances，java里面就是内存对象
然后当并发量大的时候，thread就会多起来
然后不同的threads如果调用同一个verticle
那么他们会分别持有这个verticle的不同instances
每一个thread分配一个instance酱紫
你就当你写的verticle是运行在单线程环境中就好了，并行的事，vert.x会帮你搞定
当然一个重要前提就是，你不能直接share object between threads
如果需要在不同threads中分享数据，则你需要看用bus
另外我记得他们好像提供了一个内存共享的map好像，你要自己查查 |
|
z****e
发帖数: 54598 | 42 用vert.x跟其他一样，切记部署时候一台虚拟机/真实机器
就启动一次vert.x的instance就好了
只有单线程的process instance需要启动多次
其他无论是fp的akka, play还是oop的ejb, spring这些
都没有说一个虚拟机启动多个instances的道理
一般就是一个虚拟机启动一个instance，搞定
node是奇芭的存在
然后一般多线程的框架，都会自动管理threads
让你从无聊而又繁琐的并发冲突中摆脱出来
写代码就不要各种lock, synchronised这些鸟
当然为了实现这个目的，会有这样那样的要求
比如要immutable，vert.x是所有多线程框架中，要求最低的一个
其他要求都很恶心 |
|
z****e
发帖数: 54598 | 43 是的，你的理解非常准确
其实所有的多线程框架都提供了一种机制解决冲突问题
因为lock&synchronised的确是很难搞
让用户不再需要去写这些东西是这些框架的目的
vert.x除了worker以外的verticle都是异步的，或者说都需要做成异步的
同步会block线程
ejb当初设计时候没有考虑到异步的情况
因为毕竟年代已经有些久远了，所以大多数操作都还是同步的
但是以后不知道，以后这个情况可能会发生改变
另外一个request未必对应一个thread，看设计
到了具体的instance，可能是多个对应一个，或者一个request调用多个instance
但是在同一个时间点内，一个线程只会调用一个instance
保证其他threads不会过来搞
异步的设计跟同步的架构设计有明显区别，同步是一个request启动一个thread
但是异步不是，异步是有多少个cpu的core，启动多少个thread
然后把event pool里面的events分配给这些threads
这个是vert.x，node是只有一个thread去轮询event pool
所以会启动多process，其他框... 阅读全帖 |
|
z****e
发帖数: 54598 | 44 昨晚给你的那个链接里面就说了一个例子
恰好那个例子就是游戏
vert.x用来对付游戏没有问题，会很容易
恰好我就在用vert.x来对付类似的场景
但是node会很苦逼，多线程这些手段还是有用的
至于这占多少百分比，那就不知道了
而且vert简单的场景也很容易，没觉得比node复杂
所以这个余地我还是留着了 |
|
z****e
发帖数: 54598 | 45
为0
游戏的backend不能一概而论
要根据需要选择网络协议
一般restful web service都是http
但是游戏一般是tcp or udp
而且udp比较多，所以你要自己处理丢包以及验证connection的事宜
所以backend不太可能是jax-rs
除非你只是用来存一下数据，那这个也许还可以用jax-rs
django亦然，这两个都差不多只能支持http协议
用vert.x就可以支持tcp,udp,http,web socket等等，都很容易搞
而且可以随便启thread，对于卡牌类游戏非常match
但是vert.x也只能做到卡牌，如果是再即时一点的
就需要自己控制thread了，thread pool去搞了
要求低于卡牌的，vert.x都可以轻松搞掂
数据库无所谓你用什么，用什么都会有问题，但是流量小都没有问题
postgresql都可以，zlike用的是mongo
这不是在前面问怎么对付mongo的问题嘛 |
|
z****e
发帖数: 54598 | 46
跟groovy一比，你们都是渣
vert.x乃神器也
说回vert.x，现在vert.x都放弃了什么ide support了
直接在verticle里面放main函数和做测试
如果对j2ee了解的话，今天很多语言做的事
其实就是当年ejb在做的事，没啥太大区别
一样的 |
|
z****e
发帖数: 54598 | 47
不映射，用spring直接干掉static
就是ejb2，ejb2很开心滴定义了一堆interface和functions，结果没人用
所以今天很多语言搞的东西都是被java证明过有问题的
spring这么古老的一个东西，居然还能在理念上横扫各个语言的eco
真的是很好笑啊，难怪vert.x那边要求加入spring和di的呼声很高
但是其他语言比如python, ruby等的作者都表示不太支持
因为其他语言没有这个东西，所以只能用比较落后的方式搞
我个人的初步想法是等vert.x3出来之后，再在vert.x上的基础之上做java的扩展
其他语言还是用ejb的方式去搞吧 |
|
z****e
发帖数: 54598 | 48 你敲了那么多为啥删了？
我就是这么做的
建模还是需要thread（vert.x的worker）
但是接收命令，用event（vert.x的一般verticle）
回合制游戏本身不就是一个接收命令
然后启动thread去轮询的一个过程吗？
哪怕是在客户端都是这样写的
我重用了客户端的model代码
客户端用mvc，服务器端用vert.x来接受命令
然后寄存到map里面去，命令本身是immutable的
然后每一局启动一个thread，当然这个thread已经建好模了
然后轮训map，然后执行命令后广播出去 |
|
z****e
发帖数: 54598 | 49 worker js根本没戏
js本质上就不支持多线程
所以不得不找其他语言给顶上
要么c要么go，当然是go好
从这点上说，node跟vert.x的设计差了两个档次
vert.x就没这种破事，轻轻松松搞定worker
现在worker都不算啥了，vert.x跑去搞spring那种beans了 |
|
z****e
发帖数: 54598 | 50 也是糟粕
vert.x的设计比akka强很多
网络上到处都有vert.x vs akka, vert.x vs node.js
随便看几个就有ideas了 |
|
