w***g
发帖数: 5958 | 1 最近在国内的青云上部署了个服务，几十个instance，脚本控制机器启动/销毁/负载均
衡，非常傻瓜化根本不需要任何技术。倒是确实是linear scale out，就是instance起
来后钱就开始花花地流了。负载均衡更新的一瞬间会有一批连接失败，但也就是一瞬间
的事情，一般客户端本来就有容错机制，基本不会造成实际的问题。
后来还是我花了几分钟优化了下C++程序，程序性能加倍，instance数立马减半。
开公司的，上云好，容易招人。程序员还是修炼点有技术含量的东西，不容易被取代。 |
N*****m
发帖数: 42603 | 2 青云什么价？便宜吗？
【在 w***g 的大作中提到】
: 最近在国内的青云上部署了个服务，几十个instance，脚本控制机器启动/销毁/负载均
: 衡，非常傻瓜化根本不需要任何技术。倒是确实是linear scale out，就是instance起
: 来后钱就开始花花地流了。负载均衡更新的一瞬间会有一批连接失败，但也就是一瞬间
: 的事情，一般客户端本来就有容错机制，基本不会造成实际的问题。
: 后来还是我花了几分钟优化了下C++程序，程序性能加倍，instance数立马减半。
: 开公司的，上云好，容易招人。程序员还是修炼点有技术含量的东西，不容易被取代。
|
z****e
发帖数: 54598 | 3 你的程序客户与客户之间交流少，所以linear scale out很容易
就像社交网站一样，从来没觉得网站的scale out有多难
做个游戏pvp试试，能保持fps在30以上么？每一局游戏你敢做replica么？
chaos monkey进去砸砸试试，马上出问题 |
W***o
发帖数: 6519 | 4 请教大牛一下这里说的什么东西有技术含量？谢谢
【在 w***g 的大作中提到】
: 最近在国内的青云上部署了个服务，几十个instance，脚本控制机器启动/销毁/负载均
: 衡，非常傻瓜化根本不需要任何技术。倒是确实是linear scale out，就是instance起
: 来后钱就开始花花地流了。负载均衡更新的一瞬间会有一批连接失败，但也就是一瞬间
: 的事情，一般客户端本来就有容错机制，基本不会造成实际的问题。
: 后来还是我花了几分钟优化了下C++程序，程序性能加倍，instance数立马减半。
: 开公司的，上云好，容易招人。程序员还是修炼点有技术含量的东西，不容易被取代。
|
w***g
发帖数: 5958 | 5 请参考你楼上。
【在 W***o 的大作中提到】
: 请教大牛一下这里说的什么东西有技术含量？谢谢
|
w***g
发帖数: 5958 | 6 有的人做的系统就容易scale out，有的人做的就不行。
跟客户交流啥的没太大关系。设计能力不一样。
游戏我不懂，玩也只玩模拟器上的街霸，不知道你在说什么。
【在 z****e 的大作中提到】
: 你的程序客户与客户之间交流少，所以linear scale out很容易
: 就像社交网站一样，从来没觉得网站的scale out有多难
: 做个游戏pvp试试，能保持fps在30以上么？每一局游戏你敢做replica么？
: chaos monkey进去砸砸试试，马上出问题
|
z****e
发帖数: 54598 | 7
别想那个了，实际工作中真正的scale out的瓶颈是db
而非server，server一般没问题，就是用ejb一样scale out
我觉得很多人说ejb不能scale out的本质原因是他们不懂ejb
淘宝他们就是从ejb scale out出来的
【在 w***g 的大作中提到】
: 请参考你楼上。
|
z****e
发帖数: 54598 | 8
不用那么复杂，估计你根本没想过
就让chaos monkey进去砸一顿你现在的系统
随机干掉几个nodes，你觉得可以吗？
【在 w***g 的大作中提到】
: 有的人做的系统就容易scale out，有的人做的就不行。
: 跟客户交流啥的没太大关系。设计能力不一样。
: 游戏我不懂，玩也只玩模拟器上的街霸，不知道你在说什么。
|
w***g
发帖数: 5958 | 9 自然可以。满负荷运行状态下随机杀死一半节点，
所有人的响应时间慢一倍而已。
走了scale out这条路，显然对节点故障都是有准备的。
早都已经测试过了。cloud的一个好处就是node干掉了
根本不用修复，直接destroy上新的node。也就是丢失了
些存在本地的日志数据而已。
【在 z****e 的大作中提到】
:
: 不用那么复杂，估计你根本没想过
: 就让chaos monkey进去砸一顿你现在的系统
: 随机干掉几个nodes，你觉得可以吗？
|
w***g
发帖数: 5958 | 10 据说国内的诸多云中青云是比较贵的。我选的阿里云，他们后来给改成青云了。
因为有免费的试用额度。当时我还挺不爽。不过至今服务都很不错，也算是
意外的惊喜了。有一次我这边下午国内半夜，我试着提交了一个扩充配额的请求，
应该是需要人工处理的，那边一两分钟就给处理了。
【在 N*****m 的大作中提到】
: 青云什么价？便宜吗？
|
|
|
d******e
发帖数: 2265 | 11 看不懂啊
【在 w***g 的大作中提到】
: 最近在国内的青云上部署了个服务，几十个instance，脚本控制机器启动/销毁/负载均
: 衡，非常傻瓜化根本不需要任何技术。倒是确实是linear scale out，就是instance起
: 来后钱就开始花花地流了。负载均衡更新的一瞬间会有一批连接失败，但也就是一瞬间
: 的事情，一般客户端本来就有容错机制，基本不会造成实际的问题。
: 后来还是我花了几分钟优化了下C++程序，程序性能加倍，instance数立马减半。
: 开公司的，上云好，容易招人。程序员还是修炼点有技术含量的东西，不容易被取代。
|
d*******r
发帖数: 3299 | 12 我之前看过一下，好像国内比较好的有：ucloud 和 青云
请教下，你青云用起来跟美国主要的VPS有啥差别，
基本类似Linode, DigialOcean？功能少，机器比较好？跟AWS不是一个路数?
【在 w***g 的大作中提到】
: 据说国内的诸多云中青云是比较贵的。我选的阿里云，他们后来给改成青云了。
: 因为有免费的试用额度。当时我还挺不爽。不过至今服务都很不错，也算是
: 意外的惊喜了。有一次我这边下午国内半夜，我试着提交了一个扩充配额的请求，
: 应该是需要人工处理的，那边一两分钟就给处理了。
|
N********n
发帖数: 8363 | 13
"客户与客户之间交流"属于GAME CHANGER。举凡俩REQUEST之间无影响是
最容易SCALE OUT的。一旦有影响比如买车票俩人去抢同一张票马上性质
就变了。所以做互联网的不谈REQUEST性质，张嘴闭嘴空谈每秒能做多少
REQUEST都是骗外行的。
【在 z****e 的大作中提到】
: 你的程序客户与客户之间交流少，所以linear scale out很容易
: 就像社交网站一样，从来没觉得网站的scale out有多难
: 做个游戏pvp试试，能保持fps在30以上么？每一局游戏你敢做replica么？
: chaos monkey进去砸砸试试，马上出问题
|
N********n
发帖数: 8363 | 14
你没听懂他在说啥。他看的是你的用户REQUEST之间是否有耦合，比如
是否都在打同一个游戏、买一张车票、股票之类的。一旦是而且还高频
想SCALE OUT就难了。
【在 w***g 的大作中提到】
: 有的人做的系统就容易scale out，有的人做的就不行。
: 跟客户交流啥的没太大关系。设计能力不一样。
: 游戏我不懂，玩也只玩模拟器上的街霸，不知道你在说什么。
|
f******2
发帖数: 2455 | 15 Fps完全是客户端render，xbox的能力，和云主机有什么关系？
赵老师忽悠人不可以这样不走脑子
【在 z****e 的大作中提到】
: 你的程序客户与客户之间交流少，所以linear scale out很容易
: 就像社交网站一样，从来没觉得网站的scale out有多难
: 做个游戏pvp试试，能保持fps在30以上么？每一局游戏你敢做replica么？
: chaos monkey进去砸砸试试，马上出问题
|
z****e
发帖数: 54598 | 16 当然有关系
最合理的是每一frame都从server side取数据，然后render到screen上去
而为了保持client和server同步，一般理想的状态就是你的server side主循环thread
也保持在30fps的水平上，而server和client都保持在30fps的时候
如何在33ms内把数据从server广播到client上去
就非常关键，压力就要大很多，如果像wdong那种
node挂了就挂了，直接destroy的话
这个其实要scale out一点难度都没有
你想想啊，两个clients，正在pvp的时候，突然这个node挂了
咋办？要断线重连吧，关键是这一局的游戏不能丢掉
要能够从中间开始，那就需要把之前的每一个step全部写入log
那增加了这个步骤之后的话，33ms还够用吗？
【在 f******2 的大作中提到】
: Fps完全是客户端render，xbox的能力，和云主机有什么关系？
: 赵老师忽悠人不可以这样不走脑子
|
z****e
发帖数: 54598 | 17
是这个道理
不同的requests所用资源都相互独立，是最容易scale out的
如果不同的requests有争抢资源的话，如果是硬盘上的数据
如果时间压力没那么大，可以异步处理的话，这个也相对ok
慢就慢一点，如果是内存中的数据，有明显的时间压力的话
就像游戏那样，短时间33ms内需要完成一系列任务
那难度就很大了，如果还不允许错，那就很有讲究了
光说一个scale out其实没有多大意义，还是要看做什么
【在 N********n 的大作中提到】
:
: 你没听懂他在说啥。他看的是你的用户REQUEST之间是否有耦合，比如
: 是否都在打同一个游戏、买一张车票、股票之类的。一旦是而且还高频
: 想SCALE OUT就难了。
|
g*****g
发帖数: 34805 | 18 Stateless scale 是不难，难的是数据库。所以才要 NoSQL. 可是又需要data
integrity 咋办？ 说起来都简单，实践中能把 DDBMS, NoSQL 熟练运用的已经是百里
挑一了。
【在 w***g 的大作中提到】
: 最近在国内的青云上部署了个服务，几十个instance，脚本控制机器启动/销毁/负载均
: 衡，非常傻瓜化根本不需要任何技术。倒是确实是linear scale out，就是instance起
: 来后钱就开始花花地流了。负载均衡更新的一瞬间会有一批连接失败，但也就是一瞬间
: 的事情，一般客户端本来就有容错机制，基本不会造成实际的问题。
: 后来还是我花了几分钟优化了下C++程序，程序性能加倍，instance数立马减半。
: 开公司的，上云好，容易招人。程序员还是修炼点有技术含量的东西，不容易被取代。
|
