近日，Heroku 被暴露出存在严重的性能问题：由于其负载均衡系统效率底下，导致 HTTP 请求在实例层排队，造成大量 RoR 应用的延时。（详见报道： Heroku 的教训：糟糕的负载均衡 + RoR 单线程 = 糟糕的性能）
这一事件引起了很大的反响，也暴露出一系列问题：
Heroku 的负载均衡系统设计存在怎样的问题？应该如何针对大规模的 PaaS 设计 / 升级负载均衡？RoR 开发者面对这样的问题应如何优化自己的应用？云计算服务提供商是否有责任向用户公开自己的资源分配策略？开发者如何保证自己的投入的确换取了相应的资源？PaaS 服务本身是否不适合承载大规模部署的应用？
为此，InfoQ 计划召开一个虚拟座谈会，邀请几位云计算专家就这些话题表达自己的看法。在邀请专家的同时，我们将计划讨论的几个话题公开出来，邀请各位 Q 客们参与讨论：）
虚拟座谈会上计划讨论的问题：
- 你觉得 Heroku 的核心问题是在于随机路由的算法不好，还是在上层做路由本身就有问题，还是在其他的原因？你是否遇到过类似的问题，是如何解决的？
- IaaS 和 PaaS 的使用者如何不被供应商忽悠，有何途径可以度量他们是否提供了其承诺的性能指标？如吞吐率、响应时间、扩展性等。
- 你觉得是否有必要让开发者自己部署一套监控系统？中立的第三方监控平台是否会在未来成为行业标准之一？
- 由 Heroku 事件看出，随着用户量和应用量的增长，会带来用户体验变差的问题。云服务供应商如何保证服务水平？
- 按需扩展是云计算的特点之一。传统级企业解决性能扩展的问题的经验可否用于云计算架构中？
- 云服务的用户如何摆脱供应商锁定？即，一家供应商的运行性能不能满足其业务发展需要时，如何迁移（或扩展）到别的供应商，甚至迁移到 IaaS 平台？
虚拟座谈会预备期间希望收集的讨论：
- 你对于上面的问题，有什么看法？
- 你对于上面的问题，有没有哪个问题特别希望指定的人选来回答？
- 除了上述问题之外，你还希望了解跟本次事件相关的哪些方面的内容？
欢迎各位参与！在本预告文章下方评论，或在微博上给 InfoQ 留言均可。
虚拟座谈会预计在本周四（2 月 21 日）开始上线，敬请期待！
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
知识图谱及图数据库技术在金融行业落地实践
基于 Oracle APEX 能力的全栈应用开发实践
5G 和云原生时代，技术的下半场从哪里开始
评论