有人在harriburgh吗？ - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Piebridge - 鹊桥

有人在harriburgh吗？

有人在harriburgh吗？# Piebridge - 鹊桥

z*c2012-02-25 08:02

1 楼

厚颜来板上请教大神，假设并发要求大概在10k/s 而且大量用到AWS service，在考虑
到开发成本和实际的deliverable timeline前提下，你们会怎么选择？考古了一下
mitbbs以前的帖子看起来不看好vertx的人不少觉得vertx是未来趋势的也有
AWS官方的sdk都是blocking的用vert.x就必须要用execute blocking或者用worker
verticle，感觉都很蛋疼，然后本身vertx future的chaining我感觉也并没有非常好用
play的前后版本不兼容让我非常倒胃口，然而performance benchmark上排名靠前而且
用java没有什么学习曲线，组里本来就主要用java
公司庙小，总想着快速迭代出成果，目前感觉vertx的学习曲线让组里的人有点蛋疼
已经不知道该怎么问了，也许另辟蹊径用falcon？
无奈了。。。

j*g2012-02-25 08:02

2 楼

这周买吉列剃须刀没出白条，当时小二忙，就没叫她打白条。今天想起这个事，打电话
给客服，查了一下当时的transaction，说白条48小时候到账上。Hooray！
建议大家多用客服！

r*n2012-02-25 08:02

3 楼

信用卡老被decline，为啥。。我信用卡没问题的。

m*G2012-02-25 08:02

4 楼

出来一起吃晚饭吧，人数不限
★ Sent from iPhone App: iReader Mitbbs Lite 7.39

p*22012-02-25 08:02

5 楼

如果zhaoce一定会推荐vertx

c*n2012-02-25 08:02

6 楼

cong pai
我年初时买的小黑瓶也没累计beauty club，电话客服也给补了
前些天买啤酒又没累计季度ecb,实在懒得打电话了

【在 j*****g 的大作中提到】

: 这周买吉列剃须刀没出白条，当时小二忙，就没叫她打白条。今天想起这个事，打电话
: 给客服，查了一下当时的transaction，说白条48小时候到账上。Hooray！
: 建议大家多用客服！

z*c2012-02-25 08:02

7 楼

2爷赏脸啊，我看到有个vertx俱乐部最新的帖子都已经是16年底的了然后看了下
github
vertx 103个contributor, play 606个，略心寒觉得被组里埋的vertx坑了。。。
我还写了个vertx aws client 感觉太麻烦了然后aws sdk .115版本之后还不兼容以前
版本实在没精力维护了感觉vertx做起来overhead太大了

f*y2012-02-25 08:02

8 楼

季度ecb也track哇，好细心

【在 c**********n 的大作中提到】

: cong pai
: 我年初时买的小黑瓶也没累计beauty club，电话客服也给补了
: 前些天买啤酒又没累计季度ecb,实在懒得打电话了

p*22012-02-25 08:02

9 楼

所以现在zhaoce也不见了。：）

c*n2012-02-25 08:02

10 楼

啤酒没法用任何胖子，一单oop都要20多，这个如果没累计还是挺明显的

【在 f*******y 的大作中提到】

: 季度ecb也track哇，好细心

x*92012-02-25 08:02

11 楼

spring boot

l*72012-02-25 08:02

12 楼

我的处方药好像都没加

u*n2012-02-25 08:02

13 楼

就是为什么不用人用的最多的

【在 x********9 的大作中提到】

: spring boot

z*c2012-02-25 08:02

14 楼

泪奔感觉vertx目前对我们组是个坑
估计是要弃掉了
spring boot有别的组在用不过我不太了解 service warm up会需要很长时间么？
不过说实在的warm up其实都是小事情。。。
我研究一下谢谢data point

h*02012-02-25 08:02

15 楼

用vertx和play都没错。
用worker verticle没什么毛病啊。你要理解vertx和play的概念其实都是差不多的。
verticle其实就是actor啊。用这种框架要考虑好业务逻辑。这样就不存在蛋疼了啊。
你的aws client就是client，和vertx没什么联系。用vertx实现好你的业务逻辑，各
个verticle关系弄好就行。用worker verticle来调用你的aws client。 play也是同
理。 actor本身也支持async 和sync两种。所以用哪个都行。。
我原来公司用的是play 大约3million req/min。所以handle10k/s不是问题。
其实你就算用spring也可以做到这个量级。但是新的框架对于non blocking io的支持
会好些，scale方面会好些，也会节约成本。

w*n2012-02-25 08:02

16 楼

不要用Play, 版本升级一次负担太大.
我们组有个老代码是Play 2.1...挺麻烦的

j*r2012-02-25 08:02

17 楼

10k/s不是什么大流量，后端的瓶颈从来都在数据库上。

好用

【在 z*******c 的大作中提到】

: 厚颜来板上请教大神，假设并发要求大概在10k/s 而且大量用到AWS service，在考虑
: 到开发成本和实际的deliverable timeline前提下，你们会怎么选择？考古了一下
: mitbbs以前的帖子看起来不看好vertx的人不少觉得vertx是未来趋势的也有
: AWS官方的sdk都是blocking的用vert.x就必须要用execute blocking或者用worker
: verticle，感觉都很蛋疼，然后本身vertx future的chaining我感觉也并没有非常好用
: play的前后版本不兼容让我非常倒胃口，然而performance benchmark上排名靠前而且
: 用java没有什么学习曲线，组里本来就主要用java
: 公司庙小，总想着快速迭代出成果，目前感觉vertx的学习曲线让组里的人有点蛋疼
: 已经不知道该怎么问了，也许另辟蹊径用falcon？
: 无奈了。。。