c****3
发帖数: 10787 | 1 两个方案各有优缺点，但实际做的时候，都可能有意想不到的情况
魏老师的方法，是在现有系统上修补，实施速度可能快一些。从他的经验上看，也许他
可以处理。但毕竟不是业界通用做法，没有被充分研究过，风险比较大，万一出现设计
意想不到的情况，项目就泡汤了。另外一个风险是，这是非常规方案，完全依赖他个人
经验，如果他撂挑子不干了，铁路系统就虾米了。后期维护也存在同样问题，是高风险
的方案。
NoSQL的方法，毕竟是研究了十几年了，虽然不完全适合春运卖票，但是是业界通用做
法，大部分情况已经被充分研究过，风险比较小。少量有实施风险的地方，可以充分论
证在动手。但铁路旧系统可能是传统的基于SQL数据库的，这种方法实施速度比较慢，
还要迁移现有系统和数据。但从长远来讲，扩展性比较好。而且因为是业界通用方案，
不存在被人撂挑子，没有别人能接手的情况，风险比较少。
从风险控制的角度，选哪种还是很显然的 |
f****4
发帖数: 1359 | 2 这里很多新方案也就是科技公司在用。实际的企业用户用得也不多。
国内客户那是根本不让上。。。
魏老师撂挑子的风险我没考虑，因为我默认这就是他自己去招标了 -_-
【在 c****3 的大作中提到】
: 两个方案各有优缺点，但实际做的时候，都可能有意想不到的情况
: 魏老师的方法，是在现有系统上修补，实施速度可能快一些。从他的经验上看，也许他
: 可以处理。但毕竟不是业界通用做法，没有被充分研究过，风险比较大，万一出现设计
: 意想不到的情况，项目就泡汤了。另外一个风险是，这是非常规方案，完全依赖他个人
: 经验，如果他撂挑子不干了，铁路系统就虾米了。后期维护也存在同样问题，是高风险
: 的方案。
: NoSQL的方法，毕竟是研究了十几年了，虽然不完全适合春运卖票，但是是业界通用做
: 法，大部分情况已经被充分研究过，风险比较小。少量有实施风险的地方，可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的，这种方法实施速度比较慢，
: 还要迁移现有系统和数据。但从长远来讲，扩展性比较好。而且因为是业界通用方案，
|
P********l
发帖数: 452 | 3 撂挑子？ 签了合同就身不由己了．
【在 c****3 的大作中提到】
: 两个方案各有优缺点，但实际做的时候，都可能有意想不到的情况
: 魏老师的方法，是在现有系统上修补，实施速度可能快一些。从他的经验上看，也许他
: 可以处理。但毕竟不是业界通用做法，没有被充分研究过，风险比较大，万一出现设计
: 意想不到的情况，项目就泡汤了。另外一个风险是，这是非常规方案，完全依赖他个人
: 经验，如果他撂挑子不干了，铁路系统就虾米了。后期维护也存在同样问题，是高风险
: 的方案。
: NoSQL的方法，毕竟是研究了十几年了，虽然不完全适合春运卖票，但是是业界通用做
: 法，大部分情况已经被充分研究过，风险比较小。少量有实施风险的地方，可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的，这种方法实施速度比较慢，
: 还要迁移现有系统和数据。但从长远来讲，扩展性比较好。而且因为是业界通用方案，
|
P********l
发帖数: 452 | 4 魏老师撂挑子的风险我没考虑，因为我默认这就是他自己去招标了 -_-
＾＾＾ 我还以为只有我心理阴暗呢！ ：）
【在 f****4 的大作中提到】
: 这里很多新方案也就是科技公司在用。实际的企业用户用得也不多。
: 国内客户那是根本不让上。。。
: 魏老师撂挑子的风险我没考虑，因为我默认这就是他自己去招标了 -_-
|
T********i
发帖数: 2416 | 5 其实智者不立危墙之下。除非我完全掌控项目，否则我也不会去趟那混水。
【在 P********l 的大作中提到】
: 魏老师撂挑子的风险我没考虑，因为我默认这就是他自己去招标了 -_-
: ＾＾＾ 我还以为只有我心理阴暗呢！ ：）
|
l*****9
发帖数: 9501 | 6 所谓nosql风险小，obamacare网站开发者就是这么想的。哈哈
【在 c****3 的大作中提到】
: 两个方案各有优缺点，但实际做的时候，都可能有意想不到的情况
: 魏老师的方法，是在现有系统上修补，实施速度可能快一些。从他的经验上看，也许他
: 可以处理。但毕竟不是业界通用做法，没有被充分研究过，风险比较大，万一出现设计
: 意想不到的情况，项目就泡汤了。另外一个风险是，这是非常规方案，完全依赖他个人
: 经验，如果他撂挑子不干了，铁路系统就虾米了。后期维护也存在同样问题，是高风险
: 的方案。
: NoSQL的方法，毕竟是研究了十几年了，虽然不完全适合春运卖票，但是是业界通用做
: 法，大部分情况已经被充分研究过，风险比较小。少量有实施风险的地方，可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的，这种方法实施速度比较慢，
: 还要迁移现有系统和数据。但从长远来讲，扩展性比较好。而且因为是业界通用方案，
|
g*****g
发帖数: 34805 | 7 您老就别打酱油了。他那系统是在原来基础上打补丁吗？他首先完全没考虑出票系统，
也就是legacy系统。然后原来不存在的订票系统，自己手写了一个轮子，还单机的。
我跟他是本质的区别，首先我拿了一个业界验证过的好轮子，Cassandra来对付高订单
并发。其次我懂得把计数和订单完整分开，避免transaction产生的bottleneck。最后
我分析了后台出票系统各种优化的方法。但我完全可以直接使用legacy系统出票呀，能
撑得住最好，撑不住我讨论了怎么优化。
这中间的关键是啥？一个好的架构师，要懂得分析数据的不同特性，用不同的轮子去处
理。比如我把订单和计数分开，这没有对CAP深入理解，是不会想到的。
像他那种，上来就是这么多数据，我就是能单机处理。纯粹吹牛装逼。一个从没写过高
性能服务器的人，他给你设计一个春运系统，你敢用吗？
【在 c****3 的大作中提到】
: 两个方案各有优缺点，但实际做的时候，都可能有意想不到的情况
: 魏老师的方法，是在现有系统上修补，实施速度可能快一些。从他的经验上看，也许他
: 可以处理。但毕竟不是业界通用做法，没有被充分研究过，风险比较大，万一出现设计
: 意想不到的情况，项目就泡汤了。另外一个风险是，这是非常规方案，完全依赖他个人
: 经验，如果他撂挑子不干了，铁路系统就虾米了。后期维护也存在同样问题，是高风险
: 的方案。
: NoSQL的方法，毕竟是研究了十几年了，虽然不完全适合春运卖票，但是是业界通用做
: 法，大部分情况已经被充分研究过，风险比较小。少量有实施风险的地方，可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的，这种方法实施速度比较慢，
: 还要迁移现有系统和数据。但从长远来讲，扩展性比较好。而且因为是业界通用方案，
|
T********i
发帖数: 2416 | 8 呵呵，有进步了。这回不敢提我的系统断电就挂了。看来我打脸还是有成效的。
【在 g*****g 的大作中提到】
: 您老就别打酱油了。他那系统是在原来基础上打补丁吗？他首先完全没考虑出票系统，
: 也就是legacy系统。然后原来不存在的订票系统，自己手写了一个轮子，还单机的。
: 我跟他是本质的区别，首先我拿了一个业界验证过的好轮子，Cassandra来对付高订单
: 并发。其次我懂得把计数和订单完整分开，避免transaction产生的bottleneck。最后
: 我分析了后台出票系统各种优化的方法。但我完全可以直接使用legacy系统出票呀，能
: 撑得住最好，撑不住我讨论了怎么优化。
: 这中间的关键是啥？一个好的架构师，要懂得分析数据的不同特性，用不同的轮子去处
: 理。比如我把订单和计数分开，这没有对CAP深入理解，是不会想到的。
: 像他那种，上来就是这么多数据，我就是能单机处理。纯粹吹牛装逼。一个从没写过高
: 性能服务器的人，他给你设计一个春运系统，你敢用吗？
|
c****3
发帖数: 10787 | 9 所以说光在架构上讨论没有啥意义，只要架构没有致命缺陷就成了。条条大路通罗马，
从来没有一个项目只有一种方法的。
魔鬼都是在细节上。nosql的东西大部分是开源的项目，在开源上做，必须要有能搞定
细节的人，开源有bug，要能自己去修，不能指望开源项目的人。大部分情况人家根本
不鸟你。
做不到这点，必然死的难看无比。
【在 l*****9 的大作中提到】
: 所谓nosql风险小，obamacare网站开发者就是这么想的。哈哈
|
g*****g
发帖数: 34805 | 10 开源跟质量没有本质关系。时间长，名气大的开源软件，只要你不追最新版，都是很稳
定的。
如果你不差钱，大的开源软件都有backing的公司给你提供服务。比如我提的Cassandra，
DataStax就提供服务和维护。
【在 c****3 的大作中提到】
: 所以说光在架构上讨论没有啥意义，只要架构没有致命缺陷就成了。条条大路通罗马，
: 从来没有一个项目只有一种方法的。
: 魔鬼都是在细节上。nosql的东西大部分是开源的项目，在开源上做，必须要有能搞定
: 细节的人，开源有bug，要能自己去修，不能指望开源项目的人。大部分情况人家根本
: 不鸟你。
: 做不到这点，必然死的难看无比。
|
|
|
c****3
发帖数: 10787 | 11 你说的是常用功能，这种开源项目是比较稳定。
开源的宗旨是用户就是QA，开发人员就不用QA了。所以如果碰到非常用功能，50%以上
的几率都是不工作的。
想春运订票之类的项目，是很极端的情况。肯定很多地方要用到开源项目里面不常用功
能，如果自己没有人搞定细节，死的才难看。
找做开源的人维护，属于投骰子，碰到好的算你运气好，差的态度特别差。你又怎么知
道投骰子的结果
Cassandra，
【在 g*****g 的大作中提到】
: 开源跟质量没有本质关系。时间长，名气大的开源软件，只要你不追最新版，都是很稳
: 定的。
: 如果你不差钱，大的开源软件都有backing的公司给你提供服务。比如我提的Cassandra，
: DataStax就提供服务和维护。
|
t*******y
发帖数: 1289 | 12 你错了，你是用开源的东西做产品，你需要你自己的QA测试你的东西，如果开源的有问
题，你可以自己修复，也可以提出来等别人修复。
几十那几个 Debian, ubuntu, redhat, centos 等等也都是有自己的QA的，当然，他们
的QA很多是自愿的。
【在 c****3 的大作中提到】
: 你说的是常用功能，这种开源项目是比较稳定。
: 开源的宗旨是用户就是QA，开发人员就不用QA了。所以如果碰到非常用功能，50%以上
: 的几率都是不工作的。
: 想春运订票之类的项目，是很极端的情况。肯定很多地方要用到开源项目里面不常用功
: 能，如果自己没有人搞定细节，死的才难看。
: 找做开源的人维护，属于投骰子，碰到好的算你运气好，差的态度特别差。你又怎么知
: 道投骰子的结果
:
: Cassandra，
|
g*****g
发帖数: 34805 | 13 在整个设计里，我只用了Cassandra最简单的存储，没有什么非常功能。
整个春运网站，特别的是量大，而不是什么变态功能，或者逻辑很复杂。
而春运的量，在Internet company看来，也不是很变态的量。我前面给的benchmark，
已经超出了设计需要的10倍。
你们微软出来的人，总是成天对开源的东西瞎担心。不是说开源的东西没有问题，但是
开源的东西
要解决，要找workaround远比闭源的容易多了。一个复杂系统，总是会碰到问题。那些
正规backing开源东西的公司，跟闭源公司做服务并没有什么不同。你付钱，他为啥态
度不好。
【在 c****3 的大作中提到】
: 你说的是常用功能，这种开源项目是比较稳定。
: 开源的宗旨是用户就是QA，开发人员就不用QA了。所以如果碰到非常用功能，50%以上
: 的几率都是不工作的。
: 想春运订票之类的项目，是很极端的情况。肯定很多地方要用到开源项目里面不常用功
: 能，如果自己没有人搞定细节，死的才难看。
: 找做开源的人维护，属于投骰子，碰到好的算你运气好，差的态度特别差。你又怎么知
: 道投骰子的结果
:
: Cassandra，
|
t*******y
发帖数: 1289 | 14 我喜欢成熟的开源产品，因为免费，被大量使用，有案例，有经验学习。
但是每个人的使用环境是不同的，会有不同的问题，有了问题，因为是开源的，自己可
以解决。
闭源的质量好，但是因为使用环境不同，也会有不同的问题，这个时候你只能是要吗绕
圈子，要吗花钱买支持，等。
【在 c****3 的大作中提到】
: 你说的是常用功能，这种开源项目是比较稳定。
: 开源的宗旨是用户就是QA，开发人员就不用QA了。所以如果碰到非常用功能，50%以上
: 的几率都是不工作的。
: 想春运订票之类的项目，是很极端的情况。肯定很多地方要用到开源项目里面不常用功
: 能，如果自己没有人搞定细节，死的才难看。
: 找做开源的人维护，属于投骰子，碰到好的算你运气好，差的态度特别差。你又怎么知
: 道投骰子的结果
:
: Cassandra，
|
c****3
发帖数: 10787 | 15 所以说用开源项目，你自己必须有人能搞定细节，会修里面的bug。即使你的程序在高
层运行，底层的问题也得自己会搞定。
等他们修，等两年没准也没有人理你，人家有其他更重要的事情。到时候你才惨了。
【在 t*******y 的大作中提到】
: 你错了，你是用开源的东西做产品，你需要你自己的QA测试你的东西，如果开源的有问
: 题，你可以自己修复，也可以提出来等别人修复。
: 几十那几个 Debian, ubuntu, redhat, centos 等等也都是有自己的QA的，当然，他们
: 的QA很多是自愿的。
|
m*******l
发帖数: 12782 | 16 更重要的是峰值.
【在 g*****g 的大作中提到】
: 在整个设计里，我只用了Cassandra最简单的存储，没有什么非常功能。
: 整个春运网站，特别的是量大，而不是什么变态功能，或者逻辑很复杂。
: 而春运的量，在Internet company看来，也不是很变态的量。我前面给的benchmark，
: 已经超出了设计需要的10倍。
: 你们微软出来的人，总是成天对开源的东西瞎担心。不是说开源的东西没有问题，但是
: 开源的东西
: 要解决，要找workaround远比闭源的容易多了。一个复杂系统，总是会碰到问题。那些
: 正规backing开源东西的公司，跟闭源公司做服务并没有什么不同。你付钱，他为啥态
: 度不好。
|
w*******r
发帖数: 34 | 17 肯定都能跑起来，但大家在意的是能不能做到四个9和能不能应对峰值请求 |
c****3
发帖数: 10787 | 18 我可不是微软的，也不是做数据库这一块的。
不过工作里用到大量开源项目，知道里面的trick，不是表面看着那么光鲜。
用开源产品，用的好能让你的项目节约大量时间，而且有很好的结果。但是前提就是万
一出问题，你必须能从上到下都能搞定这些细节，不能有幻想依靠其他人。
这些都是架构设计的时候没法考虑的不确定因素。
【在 g*****g 的大作中提到】
: 在整个设计里，我只用了Cassandra最简单的存储，没有什么非常功能。
: 整个春运网站，特别的是量大，而不是什么变态功能，或者逻辑很复杂。
: 而春运的量，在Internet company看来，也不是很变态的量。我前面给的benchmark，
: 已经超出了设计需要的10倍。
: 你们微软出来的人，总是成天对开源的东西瞎担心。不是说开源的东西没有问题，但是
: 开源的东西
: 要解决，要找workaround远比闭源的容易多了。一个复杂系统，总是会碰到问题。那些
: 正规backing开源东西的公司，跟闭源公司做服务并没有什么不同。你付钱，他为啥态
: 度不好。
|
m*******l
发帖数: 12782 | 19 大牛说的好,我用开源的看法也差不多,
有时候自己也不得不重新做一下
【在 c****3 的大作中提到】
: 我可不是微软的，也不是做数据库这一块的。
: 不过工作里用到大量开源项目，知道里面的trick，不是表面看着那么光鲜。
: 用开源产品，用的好能让你的项目节约大量时间，而且有很好的结果。但是前提就是万
: 一出问题，你必须能从上到下都能搞定这些细节，不能有幻想依靠其他人。
: 这些都是架构设计的时候没法考虑的不确定因素。
|
g*****g
发帖数: 34805 | 20 我记得你是微软出来的。有可能记错见谅。
我们工作中用的每个类库都是开源的，事实上，除了服务器这种东西，不开源的是不让
用也没人用的。
我做了十几年java，产品中的非开源类库屈指可数。
【在 c****3 的大作中提到】
: 我可不是微软的，也不是做数据库这一块的。
: 不过工作里用到大量开源项目，知道里面的trick，不是表面看着那么光鲜。
: 用开源产品，用的好能让你的项目节约大量时间，而且有很好的结果。但是前提就是万
: 一出问题，你必须能从上到下都能搞定这些细节，不能有幻想依靠其他人。
: 这些都是架构设计的时候没法考虑的不确定因素。
|
|
|
c****3
发帖数: 10787 | 21 象你公司这种，有个现有系统，已经工作很好，就不怕了。其他用开源的项目可以慢慢
试验，这个开源不行，可以换另一个，时间长点不要紧，反正我已经有工作的系统了。
最怕的就是现在的系统不工作，或者工作不好，赶鸭子上架，急着弄出另一个。这时候
开源那点风险，就全冒出来了。没有人是神仙，能事先知道这个开源项目有啥问题，正
好我需要用的功能不工作，或者有毛病。尤其有些问题是系统流量大的时候才冒出来的
，这些开源开发人员，根本自己没有条件模拟或者测试这种环境。
【在 g*****g 的大作中提到】
: 我记得你是微软出来的。有可能记错见谅。
: 我们工作中用的每个类库都是开源的，事实上，除了服务器这种东西，不开源的是不让
: 用也没人用的。
: 我做了十几年java，产品中的非开源类库屈指可数。
|
g*****g
发帖数: 34805 | 22 您老不是做java server端这块的吧？除了weblogic, websphere, DB，基本上没有啥有
人用的类库是不开源的。整个生态系统就是如此，如果不开源，根本没人用。
【在 c****3 的大作中提到】
: 象你公司这种，有个现有系统，已经工作很好，就不怕了。其他用开源的项目可以慢慢
: 试验，这个开源不行，可以换另一个，时间长点不要紧，反正我已经有工作的系统了。
: 最怕的就是现在的系统不工作，或者工作不好，赶鸭子上架，急着弄出另一个。这时候
: 开源那点风险，就全冒出来了。没有人是神仙，能事先知道这个开源项目有啥问题，正
: 好我需要用的功能不工作，或者有毛病。尤其有些问题是系统流量大的时候才冒出来的
: ，这些开源开发人员，根本自己没有条件模拟或者测试这种环境。
|
t*******y
发帖数: 1289 | 23 一样的，像上面说的，花钱有人干这个，我们请过人，很便宜，修改的代码全给你，挺
好交流，对他的工作有问题，随时问，合作很高兴。
微软的东西我们在用，有要花钱去请微软的人来帮助解决问题，但是每有一个问题，都
有记时花钱，而且那些烙印尽量的赚钱，胡说八道一番，反正10句里面有一半有用就不
错了。小公司，成本有压力。请我们就是来干活的，当然能自己干最好。
曾经和微软一个合作，花钱解决一个问题，一个月下来，给了一个东西，但是有bug，
反复几次，还有问题，告诉我们开发的要去度假了，你们自己搞吧，操。
【在 c****3 的大作中提到】
: 所以说用开源项目，你自己必须有人能搞定细节，会修里面的bug。即使你的程序在高
: 层运行，底层的问题也得自己会搞定。
: 等他们修，等两年没准也没有人理你，人家有其他更重要的事情。到时候你才惨了。
|
t*******y
发帖数: 1289 | 24 着急的项目，开源和闭源有区别吗？你说的问题都会有啊。
【在 c****3 的大作中提到】
: 象你公司这种，有个现有系统，已经工作很好，就不怕了。其他用开源的项目可以慢慢
: 试验，这个开源不行，可以换另一个，时间长点不要紧，反正我已经有工作的系统了。
: 最怕的就是现在的系统不工作，或者工作不好，赶鸭子上架，急着弄出另一个。这时候
: 开源那点风险，就全冒出来了。没有人是神仙，能事先知道这个开源项目有啥问题，正
: 好我需要用的功能不工作，或者有毛病。尤其有些问题是系统流量大的时候才冒出来的
: ，这些开源开发人员，根本自己没有条件模拟或者测试这种环境。
|
c****3
发帖数: 10787 | 25 你算幸运的，JAVA的开源有很多大公司的人帮助搞定和修bug
我做通信的。算是Linux嵌入系统的应用层，也做C写的服务器应用。这块就没有那么幸
运了，经常要自己搞定。
不过你说的和订票相关的那些noSQL分布系统，象mongodb之类，基本也是C和C++写的，
项目时间也不长，这块我听同事讲，也是问题多多，不过还算修复及时。
【在 g*****g 的大作中提到】
: 您老不是做java server端这块的吧？除了weblogic, websphere, DB，基本上没有啥有
: 人用的类库是不开源的。整个生态系统就是如此，如果不开源，根本没人用。
|
g*****g
发帖数: 34805 | 26 我们比你更惨。一起干得一个小公司，client要写一个windows driver。发现windows
api有bug，
成天扯皮，一直给拖着。client team lead天天打电话催，最后工期误了半年，项目没
卖出去，人直接砍掉了一半。
开源是再没办法，总归自己fix还是个办法。闭源真是花钱还要求爷爷告奶奶。
【在 t*******y 的大作中提到】
: 一样的，像上面说的，花钱有人干这个，我们请过人，很便宜，修改的代码全给你，挺
: 好交流，对他的工作有问题，随时问，合作很高兴。
: 微软的东西我们在用，有要花钱去请微软的人来帮助解决问题，但是每有一个问题，都
: 有记时花钱，而且那些烙印尽量的赚钱，胡说八道一番，反正10句里面有一半有用就不
: 错了。小公司，成本有压力。请我们就是来干活的，当然能自己干最好。
: 曾经和微软一个合作，花钱解决一个问题，一个月下来，给了一个东西，但是有bug，
: 反复几次，还有问题，告诉我们开发的要去度假了，你们自己搞吧，操。
|
g*****g
发帖数: 34805 | 27 mongodb是C/C++写的，Cassandra和HBase是java写的。
项目也有几年了，比如Cassandra 0.8起production ready，现在都2.0了。
【在 c****3 的大作中提到】
: 你算幸运的，JAVA的开源有很多大公司的人帮助搞定和修bug
: 我做通信的。算是Linux嵌入系统的应用层，也做C写的服务器应用。这块就没有那么幸
: 运了，经常要自己搞定。
: 不过你说的和订票相关的那些noSQL分布系统，象mongodb之类，基本也是C和C++写的，
: 项目时间也不长，这块我听同事讲，也是问题多多，不过还算修复及时。
|
t*******y
发帖数: 1289 | 28 一样一样的。介绍的时候说，这个东西能干什么干什么，一测，不行，开始找人，找了
一圈，确认，不行。
闷头自己写一个。
我们老板话说的，开源，只完成了10%，剩下的90%自己想办法。
闭源，完成了90%，剩下的10%没办法。
各有优缺点。自己喜欢开源，可控。
windows
【在 g*****g 的大作中提到】
: 我们比你更惨。一起干得一个小公司，client要写一个windows driver。发现windows
: api有bug，
: 成天扯皮，一直给拖着。client team lead天天打电话催，最后工期误了半年，项目没
: 卖出去，人直接砍掉了一半。
: 开源是再没办法，总归自己fix还是个办法。闭源真是花钱还要求爷爷告奶奶。
|
t*******y
发帖数: 1289 | 29 其实你这个看要求了，资源紧张不好办，如果可以的话，也有很多工具和framework用
啊。 我们的client to server http用的就是curl库，挺好用。
【在 c****3 的大作中提到】
: 你算幸运的，JAVA的开源有很多大公司的人帮助搞定和修bug
: 我做通信的。算是Linux嵌入系统的应用层，也做C写的服务器应用。这块就没有那么幸
: 运了，经常要自己搞定。
: 不过你说的和订票相关的那些noSQL分布系统，象mongodb之类，基本也是C和C++写的，
: 项目时间也不长，这块我听同事讲，也是问题多多，不过还算修复及时。
|
c****3
发帖数: 10787 | 30 说到底，架构师一方面，架构不行肯定完蛋。
但是到细节，象铁路订票这种流量，这种形式的应用，那个系统能顶得住，经得住考验
。在这种流量下没有大的bug，也得碰运气。
碰到开源系统在这样的流量下有严重bug，肯定也得被人骂死。人家买票的人才不管这
些。
【在 g*****g 的大作中提到】
: mongodb是C/C++写的，Cassandra和HBase是java写的。
: 项目也有几年了，比如Cassandra 0.8起production ready，现在都2.0了。
|
|
|
t*******y
发帖数: 1289 | 31 我同意主要是架构师和实现的问题。
但是和是否开源没关系。铁道部有条件做压力测试。简单一点的在一个铁路局局部试用
。主要问题是从上到下没有大拿。
【在 c****3 的大作中提到】
: 说到底，架构师一方面，架构不行肯定完蛋。
: 但是到细节，象铁路订票这种流量，这种形式的应用，那个系统能顶得住，经得住考验
: 。在这种流量下没有大的bug，也得碰运气。
: 碰到开源系统在这样的流量下有严重bug，肯定也得被人骂死。人家买票的人才不管这
: 些。
|
g*****g
发帖数: 34805 | 32 如果这个类库只达到你想要东西的10%，不管开源闭源，你是不会去使用的，你是有选
择的。
【在 t*******y 的大作中提到】
: 一样一样的。介绍的时候说，这个东西能干什么干什么，一测，不行，开始找人，找了
: 一圈，确认，不行。
: 闷头自己写一个。
: 我们老板话说的，开源，只完成了10%，剩下的90%自己想办法。
: 闭源，完成了90%，剩下的10%没办法。
: 各有优缺点。自己喜欢开源，可控。
:
: windows
|
t*******y
发帖数: 1289 | 33 你说的对，我那个是一种比方。
【在 g*****g 的大作中提到】
: 如果这个类库只达到你想要东西的10%，不管开源闭源，你是不会去使用的，你是有选
: 择的。
|
g*****g
发帖数: 34805 | 34 这不是运气，这是靠测试。测试充分，问题就少。我们弄了个chaos monkey，每天随机
把产品环境的结点直接当掉，就是为了这个。
【在 c****3 的大作中提到】
: 说到底，架构师一方面，架构不行肯定完蛋。
: 但是到细节，象铁路订票这种流量，这种形式的应用，那个系统能顶得住，经得住考验
: 。在这种流量下没有大的bug，也得碰运气。
: 碰到开源系统在这样的流量下有严重bug，肯定也得被人骂死。人家买票的人才不管这
: 些。
|
c****3
发帖数: 10787 | 35 你有做够时间，当然啥也不怕。愿意测试多久，测试多少，都没有问题。
象铁路这种系统，已经出问题，如果你想短时间修复它，更改了系统架构，写出代码，
那里还有多少时间测试。这时候，你选哪个开源系统，能否顶住这种应用，还是要靠运气
【在 g*****g 的大作中提到】
: 这不是运气，这是靠测试。测试充分，问题就少。我们弄了个chaos monkey，每天随机
: 把产品环境的结点直接当掉，就是为了这个。
|
t*******y
发帖数: 1289 | 36 这个更会测，不然还不如不换。
这是工程问题加商业问题。
运气
【在 c****3 的大作中提到】
: 你有做够时间，当然啥也不怕。愿意测试多久，测试多少，都没有问题。
: 象铁路这种系统，已经出问题，如果你想短时间修复它，更改了系统架构，写出代码，
: 那里还有多少时间测试。这时候，你选哪个开源系统，能否顶住这种应用，还是要靠运气
|
c****3
发帖数: 10787 | 37 不换肯定被人骂死。换又要面临时间的压力。
实际工作这种情况经常发生。谁还有功夫仔细斟酌架构细节，只要架构没有致命问题就
行了。
最后还得靠摸着石头过河，以及具体做事人的直觉。也许大公司不这样，但是大公司失
败项目也是一堆一堆的。
【在 t*******y 的大作中提到】
: 这个更会测，不然还不如不换。
: 这是工程问题加商业问题。
:
: 运气
|
g*****g
发帖数: 34805 | 38 我不反对你说的这个，我纯粹觉得这个跟开源闭源没啥关系。像铁道部这种，喜欢
直接整体外包IBM之类的，真出了问题，好找替罪羊。就一句IBM都做不出来，你让我
找谁去？
【在 c****3 的大作中提到】
: 不换肯定被人骂死。换又要面临时间的压力。
: 实际工作这种情况经常发生。谁还有功夫仔细斟酌架构细节，只要架构没有致命问题就
: 行了。
: 最后还得靠摸着石头过河，以及具体做事人的直觉。也许大公司不这样，但是大公司失
: 败项目也是一堆一堆的。
|
c****3
发帖数: 10787 | 39 是和开源没有关系。我说到开源风险，也是因为有人说obamacare用noSQL，结果很失败。
铁道部用noSQL，也会有同样的风险。但是如果铁道部有做够好的人，有足够经验做细
节实施，知道如何避免开源的风险，也可能没有任何问题。
同样的道理，找魏老师，也许他的经验做够丰富，就能避免很多实施中的细节问题。他
的架构也许细节有问题，但是除非是架构致命缺陷，实施的时候，总归能找到办法绕过
去。但是最大风险也许是魏老师撂挑子。
这也是我说两个方案没准最后都可以工作的原因。
【在 g*****g 的大作中提到】
: 我不反对你说的这个，我纯粹觉得这个跟开源闭源没啥关系。像铁道部这种，喜欢
: 直接整体外包IBM之类的，真出了问题，好找替罪羊。就一句IBM都做不出来，你让我
: 找谁去？
|
g*****g
发帖数: 34805 | 40 分布式的系统，从一开始就在考虑瓶颈，摊开流量。做得不好崩了，可能，那是个bug
，总归可以改好。
单机系统，根本就撑不住这个流量，怎么办，优化优化再优化，大部分时间都放在优化
，而不是写商业逻辑上。还是不行最后怎么办？还是得走分布式，而这个架构改动之大
几乎是从头写。
我一直让魏老师给个写SSD的benchmark，就是让他知道他吹牛逼吹得有多荒谬。他倒是
知难而退，20行的程序打死都不肯写。
我总结了很多次，魏老师提出了一个轮子，而市面上已经有现成更好更可靠的轮子。
败。
【在 c****3 的大作中提到】
: 是和开源没有关系。我说到开源风险，也是因为有人说obamacare用noSQL，结果很失败。
: 铁道部用noSQL，也会有同样的风险。但是如果铁道部有做够好的人，有足够经验做细
: 节实施，知道如何避免开源的风险，也可能没有任何问题。
: 同样的道理，找魏老师，也许他的经验做够丰富，就能避免很多实施中的细节问题。他
: 的架构也许细节有问题，但是除非是架构致命缺陷，实施的时候，总归能找到办法绕过
: 去。但是最大风险也许是魏老师撂挑子。
: 这也是我说两个方案没准最后都可以工作的原因。
|
|
|
f****4
发帖数: 1359 | 41 恩，所以很多时候自己造轮子，那真得不是喜欢造轮子 -_-
【在 c****3 的大作中提到】
: 你算幸运的，JAVA的开源有很多大公司的人帮助搞定和修bug
: 我做通信的。算是Linux嵌入系统的应用层，也做C写的服务器应用。这块就没有那么幸
: 运了，经常要自己搞定。
: 不过你说的和订票相关的那些noSQL分布系统，象mongodb之类，基本也是C和C++写的，
: 项目时间也不长，这块我听同事讲，也是问题多多，不过还算修复及时。
|
h******k
发帖数: 388 | 42 我觉得在美国IT界一个人的工资基本反映了他的能力，能力强的人设计的系统自然应该
更好。所以只要比比味老师和古德霸谁的工资高就知道谁的系统好了。：-）
【在 c****3 的大作中提到】
: 两个方案各有优缺点，但实际做的时候，都可能有意想不到的情况
: 魏老师的方法，是在现有系统上修补，实施速度可能快一些。从他的经验上看，也许他
: 可以处理。但毕竟不是业界通用做法，没有被充分研究过，风险比较大，万一出现设计
: 意想不到的情况，项目就泡汤了。另外一个风险是，这是非常规方案，完全依赖他个人
: 经验，如果他撂挑子不干了，铁路系统就虾米了。后期维护也存在同样问题，是高风险
: 的方案。
: NoSQL的方法，毕竟是研究了十几年了，虽然不完全适合春运卖票，但是是业界通用做
: 法，大部分情况已经被充分研究过，风险比较小。少量有实施风险的地方，可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的，这种方法实施速度比较慢，
: 还要迁移现有系统和数据。但从长远来讲，扩展性比较好。而且因为是业界通用方案，
|
N******K
发帖数: 10202 | 43 一堆破机器堆系统 哪个金融机构用过？
【在 c****3 的大作中提到】
: 两个方案各有优缺点，但实际做的时候，都可能有意想不到的情况
: 魏老师的方法，是在现有系统上修补，实施速度可能快一些。从他的经验上看，也许他
: 可以处理。但毕竟不是业界通用做法，没有被充分研究过，风险比较大，万一出现设计
: 意想不到的情况，项目就泡汤了。另外一个风险是，这是非常规方案，完全依赖他个人
: 经验，如果他撂挑子不干了，铁路系统就虾米了。后期维护也存在同样问题，是高风险
: 的方案。
: NoSQL的方法，毕竟是研究了十几年了，虽然不完全适合春运卖票，但是是业界通用做
: 法，大部分情况已经被充分研究过，风险比较小。少量有实施风险的地方，可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的，这种方法实施速度比较慢，
: 还要迁移现有系统和数据。但从长远来讲，扩展性比较好。而且因为是业界通用方案，
|
d********u
发帖数: 5383 | 44 "要找workaround远比闭源的容易多了"
扯挤吧蛋吧，我玩开源那会儿你还中关村卖毛片呢。没有一支NB的队伍来维护，用开源
的东西基本就是嫌死得不够快。
【在 g*****g 的大作中提到】
: 在整个设计里，我只用了Cassandra最简单的存储，没有什么非常功能。
: 整个春运网站，特别的是量大，而不是什么变态功能，或者逻辑很复杂。
: 而春运的量，在Internet company看来，也不是很变态的量。我前面给的benchmark，
: 已经超出了设计需要的10倍。
: 你们微软出来的人，总是成天对开源的东西瞎担心。不是说开源的东西没有问题，但是
: 开源的东西
: 要解决，要找workaround远比闭源的容易多了。一个复杂系统，总是会碰到问题。那些
: 正规backing开源东西的公司，跟闭源公司做服务并没有什么不同。你付钱，他为啥态
: 度不好。
|
z****e
发帖数: 54598 | 45 臭臭你这是变相夸古德霸nb吗？
【在 d********u 的大作中提到】
: "要找workaround远比闭源的容易多了"
: 扯挤吧蛋吧，我玩开源那会儿你还中关村卖毛片呢。没有一支NB的队伍来维护，用开源
: 的东西基本就是嫌死得不够快。
|
d********u
发帖数: 5383 | 46 靠，尼玛这又是亮W2的节奏？KB的60亿精子又要出来了。。。
【在 h******k 的大作中提到】
: 我觉得在美国IT界一个人的工资基本反映了他的能力，能力强的人设计的系统自然应该
: 更好。所以只要比比味老师和古德霸谁的工资高就知道谁的系统好了。：-）
|
g*****g
发帖数: 34805 | 47 淘宝，单日300亿订单。
【在 N******K 的大作中提到】
: 一堆破机器堆系统 哪个金融机构用过？
|
h*****a
发帖数: 1718 | 48 要光看今年收入我赌goodbug，Netflix股票今年太猛了。呵呵
【在 h******k 的大作中提到】
: 我觉得在美国IT界一个人的工资基本反映了他的能力，能力强的人设计的系统自然应该
: 更好。所以只要比比味老师和古德霸谁的工资高就知道谁的系统好了。：-）
|
g*****g
发帖数: 34805 | 49 您老每年都至少这个数，别谦虚了。我说的这些轮子有的还是你写的。
您老要是来拍我，至少我听着。魏老师就算了吧。
【在 h*****a 的大作中提到】
: 要光看今年收入我赌goodbug，Netflix股票今年太猛了。呵呵
|
h*****a
发帖数: 1718 | 50 这个基本上没错。所以选开源组件很重要的一点就是社区的情况，有没有大的公司做
user或者contributor。现在比较流行的开源软件后面都有巨头公司的身影，质量上来
说比几年前好多了。
没有一支NB的队伍来维护，用开源
【在 d********u 的大作中提到】
: 靠，尼玛这又是亮W2的节奏？KB的60亿精子又要出来了。。。
|
|
|
g*****g
发帖数: 34805 | 51 我觉得流行的一直很好。从最早的ant，junit，log4j，到后来struts, spring,
hibernate, maven。
别赶最新版就行。
【在 h*****a 的大作中提到】
: 这个基本上没错。所以选开源组件很重要的一点就是社区的情况，有没有大的公司做
: user或者contributor。现在比较流行的开源软件后面都有巨头公司的身影，质量上来
: 说比几年前好多了。
:
: 没有一支NB的队伍来维护，用开源
|
h******k
发帖数: 388 | 52 没看明白，什么典故？
【在 d********u 的大作中提到】
: 靠，尼玛这又是亮W2的节奏？KB的60亿精子又要出来了。。。
|
s*****r
发帖数: 43070 | 53 难点就一个，车票数据之间有高度依赖关系，系统还要求实时同步，这个问题确实很难
解决
【在 c****3 的大作中提到】
: 两个方案各有优缺点，但实际做的时候，都可能有意想不到的情况
: 魏老师的方法，是在现有系统上修补，实施速度可能快一些。从他的经验上看，也许他
: 可以处理。但毕竟不是业界通用做法，没有被充分研究过，风险比较大，万一出现设计
: 意想不到的情况，项目就泡汤了。另外一个风险是，这是非常规方案，完全依赖他个人
: 经验，如果他撂挑子不干了，铁路系统就虾米了。后期维护也存在同样问题，是高风险
: 的方案。
: NoSQL的方法，毕竟是研究了十几年了，虽然不完全适合春运卖票，但是是业界通用做
: 法，大部分情况已经被充分研究过，风险比较小。少量有实施风险的地方，可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的，这种方法实施速度比较慢，
: 还要迁移现有系统和数据。但从长远来讲，扩展性比较好。而且因为是业界通用方案，
|
z****e
发帖数: 54598 | 54 比w2一直就有
一旦有人说java vs 其他什么东西
说到比w2，其他东西基本上都遁了
只有swjtuer亮过自己的w2
精子那个说的是古德霸是湖人粉
所以科比有一个强奸案
臭臭经常说这个
【在 h******k 的大作中提到】
: 没看明白，什么典故？
|
