#17 楼 @luffycn 就是自适应，是个体力活。建议你自己对比感受下，非常欢改进意见或 bug 反馈 。

#2 楼 @kungs 省不是最终目的，主要是探索 auto scale，我们业务场景很需要。 #3 楼 @quakewang :thumbsup: 对，就是这个目的。工程的那部分，现在用青云的 API 容易实现。但算法那部分，只是设定上下限，觉得还不够好，最好能结合趋势判断，在上升还是下降。

#13 楼 @blacktulip 其实就是外键隔离。所谓“元”，就是为每位用户生成的标识。然后这个用户所有相关数据，都带这个标识的外键。

其实国内常提的 ecommerce（电子商务）主要是指 E-tail（电子零售），很多开源电商系统，比如 spree 和 magento，都是解决网上零售问题的，而且确实如 @hooooopo 说的，它们都是解决了一部分，对小商家够用。

但对那些规模大的商家，那些开源的系统功能不够用，此外，还需要各种系统集成起来，才能高效运转零售业务。

赞同@kgen，建议自己开发。Spree 比较适合标准的欧美电商业务。国内嘛，还是自己开发吧。

我们用自己部署的 errbit。 国内类似产品，应该有团队正在研发或内测吧？

云计算里面的 IaaS、PaaS、SaaS 三层，IaaS 对数据隔离特性要求最高，而 SaaS 对数据隔离特性要求最低。 SaaS 的应用，在数据隔离上，有三种做法：数据库实例隔离、表隔离（@hooooopo 指出的 newrelic 就是这种）、元数据隔离。

这三种隔离方式，在研发友好速搭期间，都尝试过。最后我们用的，是成本最低的元数据隔离方案。把所有数据（订单、商品、主题文件等）都存在数据库。后面就是从零开始写业务逻辑。目前针对国内的电商业务，友好速搭比 shopify 好很多。

国内很多同类产品，总在代码层面偷懒，稍微修改现有开源系统，搞个自动部署，就拿出来促进主机和域名销售，这么做成本不低，受到制约很多，没法在软件层面形成竞争力。

#10 楼 @blacktulip github 上面的介绍，既可以做 web server，就是取代 nginx 咯，还可以做 ruby、python 和 nodejs 的 app server。

原来变成支持多种语言的 app server 了。失望，太复杂了，不够性感。

#3 楼 @hammer 没用北京 2 区，我们用了北京 1 区，广东 1 区，还有香港 1 区。36kr 就部署在北 1 区。 去发工单 complain，要赔偿。

#1 楼 @mimosa 我去转告下他们。

我也在关注 Raptor。文章里面说的道理很好，但是很多代码，应该不是 Ruby 写的。 Raptor 不是专供 Rails，而是 Ruby App Server，它也是基于 Rack。 Ruby 在 HTTP Server 方面的瓶颈，主要在 Rack 的架构瓶颈，以及 MRI Ruby 的线程瓶颈，还有就是 GC 的低效。 如果 Raptor 没在 Rack 里面做手术，没用线程支持更好的 JRuby 之类去跑，估计很难有革命性的提升。 只是针对一些特定场景的 benchmark 结果好看罢了。

文章里面介绍 Raptor 的路线，估计会和 Sidekiq 一样，核心代码开源，免费使用。也可以花钱购买商业版，有更多功能实现，那部分代码不开源。

是指 api 设计里，经常用到的 access token 么？ 其实没啥特别的，就是一个包含用户 (或客户端) 信息的一个字符串。

一个用户登录了，server 端需要知道这个用户已经登录。 在 local 应用，会在程序里面，设置个变量记录。 在 web 应用，那就在浏览器，写个 cookie 记录。 而在 api 应用里，就是将标识用户的字符串，放在 url 作为参数，这个字符串就叫 access token。

门户建站这块，国内两家做的还不错： http://www.faisco.com/ http://www.9466.com/ 用 SaaS，省钱省力，还能帮朋友忙。 自己做那种搬砖的活，实在没必要。

#39 楼 @shinetechwuhan 感谢感谢，会场的签到袋有 U 盘的数量有限，是先到先得的。另外一部分，作为会场提问的奖品。 你是盛安德科技的兄弟吧？也许以后我们有合作机会哟，有些大客户可以介绍给你们~~~~。

#9 楼 @lowkeynull 刚才检查了短信发送记录，友好速搭的验证码没有发送失败的。 只有店铺里面手机注册，有些验证码发送失败。 主要是由于国内的短信发送，属管控行业，短信里面的签名签名设置很重要。 一不能太长，二不能全英文。有些商家没有针对短信签名做设置，踩到任何雷点，都可能导致短信发送不成功。 对于发送不成功的短信，友好速搭不会扣费。 这种问题，本身也不是技术问题，而是政策问题。

(port is in use or requires root privileges)

应该是端口号 4567 被占用。

ss -anp | grep 4567

检查看看。

你需要用reloader。

#6 楼 @kgen 是的。

#5 楼 @kgen ping 测速的话，在中国不同网络下，确实区别比较大，广东地区速度相比其它省份好很多。

访问的话，大部分地方都是不错的，主要是静态资源都在国内，链接：

#3 楼 @_samqiu 时间成本：我们已经在国内部署了 30 多台主机。 人民币成本：HK 那边的主机，比国内贵了 80%。 不过，我们的国际版，肯定是完全部署在境外，应该是青云的北美机房。

#1 楼 @Peter 亚太的这个 web server 不用 SSL，用的最低配置，1 核 1G。

也许是 ruby-china 社区管理员，高瞻远瞩。

好问题，但是提到的方面太多，其实，主要就是 ORM 的连接池问题吧？

建议阅读 Sequel 默认使用的连接池代码，重点看这个函数，还有这个函数，以及这个函数。 Sequel 的连接池中，默认的最大连接数是 4，你也可以通过 max_connections 修改最大连接数。

模拟多线程的 DB 操作： *使用 sequel 和 postgresql

#sequel连接pg略

all_threads = []
(1..10).each do |a|
  t = Thread.new do
    DB.run("select pg_sleep(3);")
  end
  all_threads << t
end

all_threads.each do |t|
  t.join
end
puts 'demo end'

在上面的代码执行期间，可以在数据库中，查看连接：

SELECT query,pid FROM pg_stat_activity where client_addr='你的IP';

结果类似这样：

所以，你想想，在多线程的 app server 中，如果有 4 个请求同时在处理，那么通过 ORM 的连接池，可以获取各自的数据库连接，进行 IO 操作，而不是等待数据库连接。

而在 unicorn 这种进程型的 app server，连接池的意义确实不大，因为请求在进程中，就是逐个处理的。就算是同时处理，也都是在不同的 worker 进程中进行。

sinatra 很简单，没必要看书。看看官方文档和单元测试就能写了。 IT 工程领域，其实关键在做，不在学。

#36 楼 @tyaccp_guojian 很感谢，问题已明确，只有在 mac 下才会有这种问题，我们针对 mac 下的浏览器，做了延迟响应，首页问题已经修复。 鹅厂的这个页面也有类似问题。 针对 mac 下的这种交互，大家都要留意做下处理哟。

#2 楼 @huobazi 作为一款小巧的工具，完全有这个潜力 。分享个成功案例：以前经常借我橡皮擦的女同学，现在变成我老婆，现在她经常找我借 U 盘了 。

呃，那是一个 8g u 盘。

#34 楼 @betterthornbird 很感谢，细心是个好品质。我们的前端小组，前几天已经修复了这个问题： 只是还没更新。 解决方法，就是加 padding 夹住。 再次感谢。

#6 楼 @cassiuschen 还有就是不同机器之间，能共享么？

#28 楼 @qige023 用的 NG 是 1.2.x 的版本。我们用了 CSS3 和 HTML5 一些特性，所以不兼容 IE8。NG 的 1.3.x 版本也放弃了对 IE8 的支持。

Wow，基于 IaaS 的 vagrant，而且还集成自动部署功能。