z****e
发帖数: 54598 | 1
我的天哪
vert.x当然可以用作web framework
但是也可以用来做其他很多东西
比如rx programming
比如udp/tcp server
比如jca
比如msg broker
etc.
包括akka做的那些，也都可以用vert.x来实现
这就是vert.x的好处，它只做最基本的framework
剩下的你爱干嘛就干嘛，这个不是它要负责的东西
你是不是用framework用得有些走火入魔了？
是不是觉得一个framework一旦可以用来做web
就web forever？
看来还是没有摆脱死套框架的地步 |
|
z****e
发帖数: 54598 | 2
哦是吗？解释一下下面这段，第一句啥意思？
你的意思不是用vert.x？那mq当掉跟vert.x毛关系？
发信人: database (《※★※§Hey§※★※》), 信区: Programming
标 题: Re: 学scala从akka入手就可以了
发信站: BBS 未名空间站 (Sat Jun 20 22:32:07 2015, 美东)
这玩意我们用rabbitmq做过，mq当掉，所有的都死菜。
而且如果我写python绝对不会考虑vert.x这些jvm上的东西。
celery+rabbitmq就可以。 |
|
z*******3
发帖数: 13709 | 3
ft
vert.x就是一个web service的轮子啊
只不过没有明确写出来而已，json的处理用jackson
这个vert.x核心类库里面有
传输协议随便选一个，比如http
这就是一个web service呀
只不过vert.x没写出来说，这个是web service罢了
除非你想用soap，这个也不难就是了 |
|
z*******3
发帖数: 13709 | 4 java8, rxjava什么最新的api里面有一种streaming的api
这个用来搞什么real time的counting是绝佳的设计
以前只能用storm这些，现在很多都能用了
还有scalaz这些，不过估计你不太了解
rxjava是这些东东里面最简单的一个，vert.x也很简单
加上vert.x也有mail,web这些，所以用vert.x最好
http://vertx.io/docs/vertx-rx/java/ |
|
z*******3
发帖数: 13709 | 5
了。
vert.x的优势在这个case中发挥得淋漓尽致
首先第一，vert.x不拘泥于web，所以mail很容易搞掂
其次第二，支持多线程，大并发ok
最后第三，支持streaming，单机单node上做汇总ok
这样通过多个层面在单个node上的集成，可以直接干掉不必要的io操作
全部在内存中完成，以实现realtime的要求
实际上vert.x很多use cases都是realtime gaming
比起游戏来说，你这个小意思了
如果realtime要求再高点，就需要介入控制gc了 |
|
z*******3
发帖数: 13709 | 6 因为有worker的存在
所以哪怕是async的方式
你一样会出现超过core数量的threads
楼主里面的8个只是一个lower bound
基本上不管是event还是thread模式，都会超过8个
只是thread方式也就是blocking方式超过得多一点而已
event超过得少一点，但是如果不超过的话
8个streaming req过来就可以把你整个server block掉
所以基本上都会不得不启动多个workers去伺候这些东东
所以单单依赖async那8个也还是不够
所以需要set worker pool，这个就是传统的blocking的，thread pool的方式
然后进一步优化，还需要对components做pool
这就是vert.x v3新加入的multi-threaded worker verticles
这就很像spring对于ejb的优化，以及spring对于fp的优化
无论是ejb的singlethreadness还是fp的immutability，都过分吃资源了
看懂了vert.x，这些问题都小菜，vert.x把能优化的部分做到了极致 |
|
z*******3
发帖数: 13709 | 7 好东西到你手上你都不懂得欣赏的人是最可悲的
为了vert.x，vmware和red hat不惜对薄公堂，最后才同意给eclipse foundation
你是不是对这几家公司和组织豪无概念？red hat可是top it公司好不好
技术实力可不比google什么差
如果是一般的open source project，这些公司根本不会大动干戈
也就是vert.x, spring这种档次的才会引发这些公司的争夺
你想想你脑子里什么时候出现过两个上规模的it公司为了一个opensource大打出手的？
我印象中只有抢jboss这种才出现过，vert.x被某些媒体誉为jboss终结者
red hat是商用开源企业的一面旗帜，其地位等同于apache在公益开源中的地位
一般搞开源的，如果有red hat和apache的产品可以选择，就选他们的的产品
质量有保证
rbs |
|
|
z****e
发帖数: 54598 | 9
我说的vert.x的金字塔是node的那种callback hell
不是akka的tree状结构，你用vert.x要想造出akka那种tree状结构好像不太可能
因为没有必要这么搞，你要搞成这样也不是不可以啊
就按照akka那种方式做就是了，无非改改通信，其他一样的
只有保证父节点给子节点发msg，其他同级节点不跨越族群发msg就好了
这种服务block了干什么？等遇到了blocking code，再包装给worker
就跟你包装给下一个actor一样
那要看你要控制什么，通信就是从a点传递消息给b点，各种服务之间不需要通信的话
那就是多个verticles就好了，不存在关联，没有edge，形不成tree啊graph啊这种关联
结构
你还是先看看文档吧，vert.x的文档写得很好，现在找不到几个项目文档这么详细的了 |
|
z****e
发帖数: 54598 | 10 另外标准的制定，一般都比较缓慢
vert.x, spark这些现在做的，就像当年spring做的那样
走在标准的前面，而且标准本身是否有意义
也很值得商榷，因为vert.x现在搞的很多东西
并不是说特别有意义，比如polyglot
如果j2ee要采纳vert.x这种搞法
那就要求所有的ejb container比如websphere,weblogic
全部支持用ruby，js，python，groovy，scala这些写ejb的逻辑代码
我实在看不出来有这个必要
虽然某些app server比如websphere也支持ruby
但是那都是optional，并不是强制要求
如果j2ee什么都管，那就太大了，变得过于笨重了
实际上现在已经很大了，新标准出来，两三年之后都没有几个公司全部impl
以前ibm和bea是最积极的两个，现在都磨磨蹭蹭 |
|
z****e
发帖数: 54598 | 11 写了这么多废话，直接去看一下vert.x不就得了
event loop什么vert.x里面都有，你有空打这么多废话不如认真去看看源代码
说了这么久，你压根连看都没看过，如果看过开篇就会告诉你node和vert.x的区别在哪
主要就是eventloop数量的差异
而且说的一堆里面jee和future什么整个凑一块乱说
古德霸那个轮子你压根就没有认真看源代码
想当然地以为用了future，你就知道future
都不知道说你什么好，概念乱成一锅粥了
Future这个接口是java.util.concurrent pkg里面的
常见的实现有SwingWorker这些，至少五六个实现
而真正的non blocking是java.nio
大部分java的异步轮子都是基于netty的，netty基于nio
所以这里没有Future什么事
available
htm# |
|
z****e
发帖数: 54598 | 12
这个观念是错误的
netty是比akka底层
但是vert.x绝对不比akka底层
几乎是平级的一个东西
都是actor model的实现，怎么会比akka底层？
netty是网络socket的一个封装
spark用akka的一个主要原因是当时他们只有akka可以用
akka诞生于09年，vert.x诞生于11年，差不多到了今年才算稳定下来
而spark开始于10年，vert.x比spark还年轻，怎么可能让spark去用？ |
|
z****e
发帖数: 54598 | 13 vert.x最好一点就是polyglot
一堆不同语言的程序员，凑在一起，互通有无
vert.x就容易在不同的eco中取长补短
所以vert.x对于新生事物的好的部分
吸纳得特别快
你一说这个东西什么什么好
它马上抄过去 |
|
d*******r
发帖数: 3299 | 14 因为 Hazelcast 是 java JVM 生态的.
不过据我所知 Vert.x 用的是 Hazelcast 一个老版本的 fork,
上次瞄 Vert.x 时候，他们社区还在为是否更新 Hazelcast 版本讨论呢.
但是我总觉得 Vert.x 最后会跟 Hazelcast 保持相对独立. |
|
z****e
发帖数: 54598 | 15
vert.x已经把各种傻瓜化做到了极致
线程托管，内存托管，硬盘托管，跨平台
能搞的各种脏活累活都被它搞了
vert.x之后，关注底层的都是傻逼
你只需要关心上层逻辑就可以了
底层会越来越抽象，最后简化成几个数字而已
随着这些技术的成熟
社会对于c这种东西在server side的需求会大幅降低
而对于java的需求会大幅升高，因为vert.x打好了一个平台
然后java之后，其他脚本怎么搞，那就看domain了
物理层的封装接近完成
现在都有很成熟的方法来封装物理层面的部件了 |
|
z****e
发帖数: 54598 | 16
Vert.x would be ur 1st choice, u should really think of Vert.x instead of
the others
Servlet containers: Jetty, Tomcat, Undertow
Vert.x can also do this, actually almost all web server can be a restful
server
DI is now a standard of J2EE, so a lot of framework can do DI job including
all EJB containers like WebLogic, WebSphere, Wildfly etc.
ORM is also a standard of J2EE, so almost all J2EE impl*ed containers can do
the same thing
and ORM can over all RDBMS not just PostGreSql & MySql, includin... 阅读全帖 |
|
z****e
发帖数: 54598 | 17 declarative的目的是
dont make me fucking guess
让你的代码写清楚你要干什么
最好不要让我去看代码，因为我不想看
fp的很多东西做不到这一点
actor和oop可以做到
你见过有人说vert.x难的么？
但是vert.x又能实实在在解决问题哦
这就是为什么我认为vert.x有前途的主因
完全不看，是不可能的
但是如何尽力让别人看懂，这恰恰是oop所擅长的
hello world的确更难，但是java在一大堆代码的时候
其可读性是无与伦比的，项目失败
绝大多数不是因为功能点无法实现
而是因为代码不可维护，其中就包括fp这些老古董
如果这些古董成功的话，就没有java了，因为不需要嘛
就是因为fp的很多语言，外加c,c++做失败了
所以才会有了java的推广和流行
当然java太具体了，oop比较抽象
真正做到declarative的就是java
你的java代码给我，三分钟之内我可以说出这个java代码大概在干嘛
如果用上各种框架的话，比如spring的话，就更快了
我直接看annotation就大概能明白了 |
|
z****e
发帖数: 54598 | 18
说到taste，我觉得做后端就不应该有taste
因为人的感觉，80%来自视觉，apple的东西，主要是在视觉上给你以冲击和享受
其实视觉上的冲击力，有两个国家做的最好
一个是日本，女性的那种审美，在日本这个国家的作品里达到了极致
你应该看过各种卡通吧？妹子们都很喜欢
如果你不喜欢，抱歉，你没有taste
另外一个是德国，尤其是元首，纳粹军官在各种作品中
都是高大英俊帅气的代表，这个其实本质上也是女性的审美
女人比男人更有taste，但是女人不懂技术
为啥？因为技术不需要去伺候视觉，尤其是backend
你伺候个屁视觉，web那些不叫backend，那叫frontend
这个的确有视觉，但是如果你真的有taste的话
你会不满足于web ui那点狗屁视觉效果，你会很烦
你会对真正的ui感兴趣，那就是图形学
你会开始关注，fps是多少，动画该怎么制作
而不是满足于几秒换一张图片，那多没意思
难道你不喜欢日本动画？你不喜欢动画效果？
不喜欢控制动画？这就是游戏啊，男孩子小时候多少人为了玩游戏不惜偷家长的钱？
这个就是taste啊，如果你连游戏都不喜欢，你谈什么taste呢？
你知道群众到... 阅读全帖 |
|
z****e
发帖数: 54598 | 19 然后再说一下如何赚钱
商品一般分为必需品和艺术品
必需品能赚钱，我不否认
但是从我们这一代人之后
开始
必需品越来越不赚钱了
因为人们不再缺乏吃穿住和行的工具了
都有了嘛，我奶奶那个年代
不干活，会饿死，现在90后不干活
有几个会饿死的？不会嘛，社会资源富足了之后
你应该思考一下如何制作艺术品了
而不是必需品，因为必需品已经过剩了
这个时候，你务必要跟视觉接轨
因为前面说了，人的感觉，80%来自视觉
女人男人都是视觉动物，视觉上的享受和吸引，是不受你理性控制的
玩游戏就是纯粹的视觉冲击，男人喜欢美女，也是视觉啊
女孩子喜欢漂亮衣服，这难道不是视觉嘛？
而现在视觉效果做得最好的平台，就是apple嘛
所以前端怎么看都应该选择ios啊
后端又是另外一回事，后端要耐操
别三天两头出问题，jvm就很耐操
然后要尽快上手，便于维护和开发
vert.x就是一个很好的选择，vert.x的制作组
一直在做java和spring成功的事情
就是努力让事情变得简单，其实eclipse,groovy也都是这个思路
所以这些东西都会成功，而且关键是他们的确也耐操
不能像有些脚本那样，hello world很简... 阅读全帖 |
|
z****e
发帖数: 54598 | 20
吧。
啥？vert.x这种东西无非一工具而已，工具是不会有秘密的，也没有必要有秘密
我不卖工具赚钱的，我没吃那么饱去搞什么秘密，推广开来才对我有好处
工具无非都是大家用，，要不然开源了干什么？我也不靠这个赚钱
而且也不是我的钱，如果真有钱的话，vert.x是eclipse.org的
就是eclipse一样的公益开源项目，随便用，node好像有点私心
麻痹的npm居然不能随便点链接下载，这点很恶心
至于idea，这个当然不要随便说，早就说了，你要做什么，把嘴闭上
我只是讨论怎么实现一个目标，具体要做什么，那跟我没关系
我说的本质上跟是日系车好还是德系车好是一样的
或者是马车好还是汽车好，扯扯蛋而已
公司才不管我说vert.x啥呢，这个跟公司没半毛钱关系
倒是wdong这种要小心，一天到晚在bbs上晒自己做的产品
这种行为危险很大 |
|
z****e
发帖数: 54598 | 21 大规模、大数据量、高并发企业级或者互联网应用为了解决数据缓存、降低数据库负载
、提高查询性能等突出问题，很多采用了Hazelcast或者Oracle Coherence或者GemFire
（比如12306网站）或者目前应用越来越广泛的Redis等缓存技术
所以说，现在还在琢磨如何省机器钱的人明显思想上落伍了，自大得要死，还热备，上
个世纪的破烂构架，不知道有啥好吹的，in memory db现在满大街都是，都快烂大街了
，还在做计数器，看了真是很有喜感，所以说，不弄vert.x，能行吗？vert.x的
cluster模式就是hazelcast，也支持redis这些，比起卖机器来说，vert.x实在是可爱
太多 |
|
z****e
发帖数: 54598 | 22 受不了了，楼上推荐的都是什么垃圾
一回来就看各种笑话
显然这种需求vert.x秒杀好吧？
vert.x同时支持ruby, java, js, groovy
外加天生一个microservice的web service架构
同时具有一个web framework
如果不是白痴，应该都能看出这个需求摆明了就是给vert.x设计的 |
|
z****e
发帖数: 54598 | 23
又看了一遍，对vert.x的认识又加深了一层
对go反而没啥感觉
你说到在多核上做用户态线程是很恶心的一件事
假设是真的
那么vert.x就更加合理了
因为vert.x对比node.js，就是把原来单核的事
变成了多核的事，由multiple reactors来解决这个问题
所以等到它找到coroutine的时候
coroutine只需要考虑单核情况就可以了
就类似node.js
所以actor model越看越不可或缺，如果没有actor model
光靠语言一个来做，够呛
你说go做成了，嗯
只能说道路不同，go想做的更多
但是这样做的效果如何，目前看，觉得它做的一般
从benchmark上看，并没有表现出多少优势
https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json |
|
z****e
发帖数: 54598 | 24 lambda是java8的东西
java8第一个版本在2014年
实际上在java之前，scala先做出了jvm上的lambda
所以有了akka，先于java的vert.x之前好多年做出来
然后java有了lambda，消化吸收了node.js和akka之后才有了vert.x
有了vert.x我们才能把线程数降下来，减少lock
从而对coroutine的要求就简化成了node.js对于coroutine那种的要求
不需要考虑多核，不需要考虑lock，actor model解决了这个问题
所以这个时候coroutine只要很简单的能够暂停，能够恢复
就够用了，这样就能解决callback带来的恶心的书写问题
而在此之前，因为lock满天飞，所以即便能够暂停，能够恢复
也很难提升性能，但是当前提改变了
要求降低了之后，coroutine的作用就体现出来了
所以这个时候一堆语言才开始搞coroutine
这里有一个lambda和actor model成熟的前提
如果线程数降不下来，lock一大堆，用不用coroutine都一样
反正性能就是上不去，线程数降下来，节省一个线程，内存stac... 阅读全帖 |
|
z****e
发帖数: 54598 | 25
Function0
停停停
你没有用过vert.x
所以鸡同鸭讲
我给你一个建议，去看看vert.x的设计
然后再来谈
死锁？
都lock free了，死锁什么哟？
都用这么久，遇到过搞不定高阶函数的
还真没遇到过死锁的
vert.x一直就是reactive programming
正是在实践中遇到了问题
所以我们才会寻找答案
而现在说的coroutine
正是我们找到的答案
之前搞reactive programming
最大的麻烦就是普通程序猿掌握不了高阶函数的使用
map, flatmap，副作用，绕晕了，搞不定我去
后来情愿换成kotlin，coroutine白菜化异步api
然后就ok啦
还是那句话，你们没有经验，看不懂
我当然知道高阶函数，reactive是一种解决方案
但是很麻烦，一般程序猿搞不定
思维上的改造不是那么容易的
这就是为什么一大堆语言都在搞coroutine/async/await的主因
fp那些，主流不感兴趣，因为搞不懂嘛
没有coroutine之前，我们推广reactive，多恶心你知道嘛？
一说副作用，无状态函数，fp下面一大堆人在睡觉，哈欠连天
这... 阅读全帖 |
|
r******o
发帖数: 1851 | 26 For example, I just ordered some pin and connector from digikey. These are
the part numbers:
WM4620-ND
CONN HEADER 2POS .156 VERT TIN
WM4621-ND
CONN HEADER 3POS .156 VERT TIN
WM4622-ND
CONN HEADER 4POS .156 VERT TIN
Corresponding to
WM1566-ND
CONN HOUSING 4POS .156 W/O RAMP
WM1565-ND
CONN HOUSING 3POS .156 W/O RAMP
WM1564-ND
CONN HOUSING 2POS .156 W/O RAMP
And you need to some clips:
WM2303-ND
CONN TERM FEMALE 22-26AWG TIN
Then I just made by myself |
|
z****e
发帖数: 54598 | 27 scala和vert.x都可以打包
vert.x的pkg格式更自由一点
scala不用vert.x只能做成jar
做成jar也够了，对于java程序来说
管他是java写的还是scala写的
反正都是jar
对此可能需要sbt |
|
z****e
发帖数: 54598 | 28
我是码农，所以我可以负责任滴说，中国的码农水平不如美国的
当然两个都有问题，中国的主要是有些凹凸，集中在tomcat这些上个世纪的产品上
美国的主要问题是走错路了，集中在python等脚本这些上
两个都很垃圾，都远不如vert.x，但是总得而言，美国的强一点
主要是敢于换语言，这点比较牛逼，虽然在我看来根本就是走错路了
但是殊途同归，迟早这两个都会意识到vert.x的好处的
还有swift |
|
t****m
发帖数: 135 | 29 赵兄是来搞笑的吧。
知道你在vert.x工作，也不用这么肉麻吹捧java和vert.x吧。 |
|
z****e
发帖数: 54598 | 30
应该说java是最后一个大规模流行的语言
以后看脚本的了，但是脚本就像方言
每个领域的脚本是不一样的
比如matlab，你用matlab脚本来做web……我靠，大傻可能能做到吧
同样的脚本还有sql这些，这些都是脚本，但是脚本注定了只能在某一个领域内横行
离开了这个领域，就挂了，java和c都是general的语言
java已经把能封装的common问题封装到了极致
vert.x则是进一步封装，主要是处理并发问题
到这一步之后，就没有共通的ifnra问题需要处理了
内存，cpu，网络，硬盘都封装起来了，统一接口
vert.x则处理了app的并发问题，没有了
再也没有共通的基础问题需要解决了
我想不出来，要不你说一个？ |
|
z****e
发帖数: 54598 | 31 matlab就是一个脚本
你来说说，对于16个core的cpu，你该如何充分发挥其性能？
脚本除了忽悠点数学理论外，屁都做不出来
你再说说，因为分布式必然接触网络
所谓网络就是连接神经元的神经系统
java写个internet socket分分钟搞定
你用c写，写到明天能搞定不？还别错
你用脚本？除了http req/resp以外，你还能干嘛？
来，写个udp server试试，看你出不出问题
最像神经系统的就是vert.x的eventbus
简直就是神经系统的直接模拟，而每一个verticle就像是一个神经树突
整个vert.x在单机上就像是一个神经元
懂了没？这就是一个人的大脑的雏形了 |
|
|
发帖数: 1 | 33 发信人: vert (vert), 信区: Poetry
标 题: 在老婆承认自己出轨以后我终于想起来自己曾给她写过情诗
发信站: 水木社区 (Fri Oct 19 01:04:47 2018), 站内
她承认自己出轨以后
我重新翻了结婚证才
终于想起来我们是在
2016年5月领的证。
那个周六
我们在招商银行还完信用卡
在旁边的兰州拉面馆里
吃兰州拉面。
她舀油泼辣子的时候说
她妈给她安排的相亲对象
西北出生，
和我们一样刚毕业但家里是兵团的
已经安排了事业编。
我那时25岁，
在中关村的华为店里推销手机
和手机壳，
底薪加提成有时候能有一万。
我在店里认识的她，
登记客户信息时候偷偷留了她的电话
她那天穿了一件紧身黑线衣
显得胸很大。
领证的那天我们刚认识一个月
做过二十多次
从没想过结婚。
但她的胸很大而且我工资一万
总比事业编牛逼所以
我说你可以跟我过一辈子我爱你
她说好。
然后那天我写了一首情诗
但其实那首诗是我自己翻译的歌词
她看了以后哭了很久然后
我们做了很多次。 |
|
发帖数: 1 | 34 lol
：发信人: vert (vert), 信区: Poetry
：标 题: 在老婆承认自己出轨以后我终于想起来自己曾给她写过情诗 |
|
z****e
发帖数: 54598 | 35
可以啊
你这么做下去的结果就会发现
vert.x居然能包治百病
这个thread里面罗列出来的各种轮子
其实用vert.x一路做，都可以做出来
只要理解了原理 |
|
z*******3
发帖数: 13709 | 36
actor是erlang, akka的东西，他说复杂了
你要是有兴趣，看看akka,vert.x这些就知道了，vert.x里面的verticle就是actor
server挂了之后，问问能不能启新的node，假设你用的是cloud
如果可以的话，新的node需要从persistence中读出之前的数据来
所以用redis就比较合理，因为redis可以做到persistence
如果是纯内存计算的server的话，就不行了
或者前面说的，多个设备之间自己做一个copy
第一次登陆了之后，server把多个设备的信息反馈给每一个client
然后每一个client本地做备份，然后就可以不用经过server了
就像qq聊天，大多数时候都是client -> client
但是你也可以选择client -> server -> client |
|
z****e
发帖数: 54598 | 37 r4你做过android就很清楚，主要问你网络协议用什么
看看你对gui部分是否有所了解，gui未必做重点
但是你可能需要对udp之类的比较熟悉才行
r3其实也是类似的idea，r3可以用http，因为是回合制
不像俄罗斯方块那样real time要求比较强
所以平常多看点vert.x之类的，这种就比较容易对付
vert.x对付udp轻轻松松 |
|
z****e
发帖数: 54598 | 38 作为练手
你可以试试自己做一个
比如android上的app＋后台的这么一个系统
就跟他们做的产品很像了，比如app做一个俄罗斯方块的对战
这个难度很高，虽然做完之后觉得也就是那么一回事
但是明显难度高不少，比起一般的web项目
后台建议你用vert.x，会简单点，用一般的web server比较麻烦
因为一般web server都是http，协议的overhead太多
如果是自己用socket裸写的话，先进的思想就无法吸收
用vert.x基本上各种先进的思想有个汇总
你可以学习先进的思想都是怎么对付这些问题的
怎么做就自己去折腾了，从不懂到懂，估计你自己要折腾上至少个把月吧 |
|
z****e
发帖数: 54598 | 39 r4你做过android就很清楚，主要问你网络协议用什么
看看你对gui部分是否有所了解，gui未必做重点
但是你可能需要对udp之类的比较熟悉才行
r3其实也是类似的idea，r3可以用http，因为是回合制
不像俄罗斯方块那样real time要求比较强
所以平常多看点vert.x之类的，这种就比较容易对付
vert.x对付udp轻轻松松 |
|
z****e
发帖数: 54598 | 40 作为练手
你可以试试自己做一个
比如android上的app＋后台的这么一个系统
就跟他们做的产品很像了，比如app做一个俄罗斯方块的对战
这个难度很高，虽然做完之后觉得也就是那么一回事
但是明显难度高不少，比起一般的web项目
后台建议你用vert.x，会简单点，用一般的web server比较麻烦
因为一般web server都是http，协议的overhead太多
如果是自己用socket裸写的话，先进的思想就无法吸收
用vert.x基本上各种先进的思想有个汇总
你可以学习先进的思想都是怎么对付这些问题的
怎么做就自己去折腾了，从不懂到懂，估计你自己要折腾上至少个把月吧 |
|
z****e
发帖数: 54598 | 41
no，我说的是真的
如果你在payment gateway混过的话
从netty什么开始写
东方剑桥是搞jboss的
跟写netty那个韩国人搞不好都互相认识
这个分量应该他更清楚
很多搞payment gateway的公司
早过vert.x5-6年就制造出类似vert.x的一个内部系统了
大谈async这些，node那都是后来的事了
java要搞async，最早就是netty |
|
z****e
发帖数: 54598 | 42 你对网络协议了解的话，就不会觉得难了
website的话，无非就是网络协议（socket，如果你认真学过java的话，这个肯定写过
作业）
其次是session的management，这个看看cache，比如redis之类的，自己写也差不多
以及最后一个html template，这个很多个选择
看看vert.x的template engines
所以说，多看看vert.x，这些都是小菜 |
|
z****e
发帖数: 54598 | 43 如果你想要真实的例子
一个是tomcat的源代码，jetty什么也都行
还有一个是vert.x，vert.x更容易点 |
|
z****e
发帖数: 54598 | 44 jmx用来监控app的情况
用jconsole可以直接接上
jconsole就在jdk的文件夹里面
每一个jdk都有jconsole
如果是开发中debug，用ide可以做很多事
认真区分f789的区别
thread dump如果用了thread管理工具，vert.x, tomcat之类的
应该不太可能用得上
然后log很重要，unit test要做好
最后就是system之间的问题了
这个经验就是不要用各种mq，全部用json，会容易很多
你要想办法能够监听每一个msg，vert.x的shell service非常好用
现在系统越来越大，这些问题越来越多滴给到各个后台的猴子手中
光从无到有做几个网站，没啥意义 |
|
z****e
发帖数: 54598 | 45 嘴巴上无非说这里技术好那里技术不错
那请问到底你想学的是什么技术呢？
然后再看看你打算去的那家公司有什么技术让你学呢？
就比如google吧，google做得好的
比如android, search还有youtube，你觉得你创业跟这几个对着干
有戏吗？我觉得你没戏，肯定被google干掉
然后google做得不好的，比如google+
你跑去做这个，你打算创什么业？你做一个google+有戏？
google都没戏好吧，说到这里就像一个两难了
到底要怎么学？其实很简单
你想打工，就要想明白
第一，这家公司有什么东西你带得走
带不走对你来说几乎没用，所谓带得走就是你换一家公司也能用的东西
这就是为啥我们对开源非常感兴趣，因为开源基本上都带得走
对猴子自身有利，这是一，其次，这家公司有什么独门绝技
你可以偷师的？有些技术只有这里有，其他地方没有
尤其是开源没有的，你可以考虑学一点，因为开源没有的
意味着市场上跟你竞争的少，所以你出去创业，尤其是回国创业
会有比较大的优势，如果开源也有的，你应该优先考虑开源
因为前面说了，带得走，换个公司，东家也能受益
但是这个时候就不宜自己再去瞎搞了，因为... 阅读全帖 |
|
i*****h
发帖数: 1534 | 46 正准备学你一直推崇你的vert.x 有什么好的材料推荐吗？不想网上乱搜。哪个大牛也
用vert.x的请传授些经验吧？ 非常感谢 |
|
z****e
发帖数: 54598 | 47 这就好像说不会手动挡就不懂得开车一样
编程的目的是为了完成任务解决问题和赚钱，不是为了什么professional
底层有什么关系啊？如果能找个傻瓜来替我干活，我才没兴趣去自己动手呢
谁不想做boss啊？因为找不到，所以找个机器来当这个傻瓜
这就好比自动档(c)和手动档(java)，以后都自动驾驶(vert.x)了，连自动档都凹凸了
谁还去弄手动档？人又不是机器，如果机器能做的，就让机器去做好了
否则要机器干嘛？而且c其实已经是个半自动档，算个屁全盘操控
直接对机器下指令才算是全盘操控好吧？否则i++这里面的步骤还不是一样看不懂？
不懂汇编，你能看得懂i++为啥不是原子操作？一样不懂嘛
只是在c那个年代，发明unix的人，只能搞定封装cpu指令等的封装
像内存自动管理这些东西，他搞不定，因为比较难，等到java出来之后，才算是搞定了
java还搞定了跨平台啊等乱七八糟的玩意
但是java本身并没有搞定并发，然后人们发明了各种轮子来尝试搞定，比如tomcat
vert.x出来之后，才算是把并发解决了，人类就是这样一步一步逼近自动驾驶
现在还在拿一些偏底层运算说(zhuang)事(bi)的... 阅读全帖 |
|
z****e
发帖数: 54598 | 48 很多人之所以不用gc
其实无非因为stop the world
但是如果你认真搞过gc
就应该知道，gc的效率大概是17ms这样
当然你的内存不要太大，别搞100g，那停顿会比较久
所以古德霸也说过，就算你有一台super computer
比如mainframe，hpc这种，最好也还是虚拟化之后
弄成虚拟的nodes，搞成虚拟的分布式，以便提升效率
一般我设置一个node内存20g
大gc大概20ms，小gc大概10ms
不够用，那就爆instance/node，而不是爆内存
启动慢主要是spring的问题，它会actively initiate beans
要把所有的beans实例化一遍，以优化效率
但其实没有必要，现在new的效率极高，大概1s能new 2w个对象
不涉及io的话，所以其实lazy initiate很多时候更为合适
把spring设置成lazy init，启动会快很多，但是运行效率可能会下降
不过这些问题都是legacy的问题
现在vert.x为代表的java下一代轮子
基本上都没这些问题
这个是startup的优势，就看有没有这个魄力敢用vert.x了 |
|
z****e
发帖数: 54598 | 49
最好的优化就是不优化
我一般能不tune jvm就不tune
因为tune了之后，自己过一段都看不懂
现阶段的gc pause足够了，我做pvp都敢用，一般的应用小意思了
发信人: zhaoce (米高蜥蜴), 信区: Vertx
标 题: 说说java的代码构成
发信站: BBS 未名空间站 (Fri Jan 22 23:15:59 2016, 美东)
一般代码分成三块
一块是自己写的，这个c还有脚本等其他语言都有
这个只要大学里面好好读书，一般一两个月就能把语法全部背下来
很容易的，文科生都能学好
另外一个块是你抄的，就是轮子，这个要看repository的大小
java就是找maven的repository了，node就是下npm了，ruby就是下gem了
python就是找module了，数量分别是120w-，23w+, 11.3w以及7w左右
然后vert.x是这些轮子都能用，所以vert.x超爽的
但是c和c++没有repo，根本没听说过，谁知道，说说？
所以这一块，明显c就落伍了
这一块不容易，因为轮子数量爆发式增长，你要跟上时代
理解轮子本身就是一个学习的过程
Ti... 阅读全帖 |
|
z****e
发帖数: 54598 | 50 如何线程安全
jcu，concurrenthashmap是答案之一，可以加分
如何scale
同步转异步，io bound节省线程
actor model随便找一个
java当然用vert.x啊
akka也行，但是akka比较难用
lock free的节奏
lock用多了，性能就下来了，lock越少越好
actor model可以实现lock free
但是前提是要完成同步转异步，线程数不能开太多
一般是available cores，比如jvm自身的fork&join pool
vert.x的eventloop pool，这个是available cores*2
因为netty里面需要分一半cpu资源给io，这一句猜的，不确定
因为线程数少了，所以lock数自然也少了，线程多，lock就多
最后写起来很ugly，怎么办？
future/promise, reativex(rxjava)和coroutine，三选一
还记得那个snapshot还是什么用的是erlang么？
最早actor model就是那边出来的 |
|
