十万并发硬件要求,ECS,RDS,REDIS

问这个问题，估计网站不会做到 10 万并发

单机做不到的，及时做到了，其他瓶颈也就出来挡着你了，你现在应该考虑的是，slb，一堆一模一样的 ecs 挂到 slb 后端，数据库用一个 RDS 还不见的够用

举个例子，我做个 socket 服务端，(GPS 应用 TCP 并发长连接)，确实做到了单机 3 万很稳定，加 2 万也能正常运行，但是后来再也不看重单机指标了，换成了弹性云架构。因为
1，业务增长容易，单机性能难提高
2，重启一次，各种连接恢复周期长达 20 分钟以上，期间重建链接满载消耗 cpu
3，单点故障会导致一个崩溃级 bug 毁掉整个业务
4，压力太集中，早期 memcached 雪崩时候，数据库读炸了一次

总之，一个长久的业务，需要把架构做成不改代码只增加机器数量就能解决业务增长问题，这才是云架构发展起来的意义，云的单机性能都是远远低于物理机的，云时代不应当看重单机性能指标

@opengps 受教了。。 我想的有点极端了。。单机情况确实不迎合云架构。。有个疑问是，如果使用 SLB 来负载多台 ECS。对应的数据库方面是否也需要有对应的扩展。阿里云那边看到 RDS 是有最大连接数得。并发得数量和这个最大连接数是否要成正比呢。？

@yrebom 数据库总体来讲，也是我一直以来的困惑，量上来之后必然有一个瓶颈点，目前能想到的是：iops，并发连接数，文件大小三个方面
看准确瓶颈点在哪，就足够交付，瓶颈点不需要现在就去突破或者消除，但是一定是预期时间内不能遇到的。

方向一：可以考虑分布式的，例如阿里云的 DRDS，由于时间成本和价格成本问题我一直没去实际测试，等我后面时间宽裕了我会去试试

方向二：直接在软件架构上设计扩容方案，这个方向在传统架构里经常看到，例如我那种 [写多读少] 可以程序哈希分库或者做个中间路由库调度写入不同数据库。这种方案是将瓶颈点尽量往远期推迟。直到将来的路由数据库压力饱满才需要再次改造
方向三：根据业务特征，例如 V2EX 的帖子这种 [读多写少] 的业务特征可以只是用一主多从解决，这里我举得例子就是早期不需要消除瓶颈点，而是瓶颈点一时半会到不了，显然 V 站新建帖子数量一时半会不会达到每秒几千（数据库每秒写入几千），足够为下一步升级留够时间

@opengps 感谢解惑。 我这边业务(我自己能力有限)更加迎合第三个方向。方向 1，2 感觉还是要花时间沉淀。。程序哈希和中间路由没接触过。。

@yrebom 终于说到点上了，如果是 [读多写少] ，你要做的工作就很简单了：
公网 SLB 一台，低配 ECS 多台，如果有网站附件文件再来个 OSS 和 CDN，然后你早期可能只需要一台 RDS，将来多了，修改代码实现全部修改和写入进入主库，然后那一堆 ECS 分组读取不同的从库
搞定！多少年内不用改代码，只需要业务量增长加机器就行了

@opengps 非常感谢。。 现在可以确定方向去做了。。一开始都不知道怎么做才算合理。 现在你这么一说。。 我就有谱了。。

@yrebom 利益相关，最后问一句，确定用阿里云不，我有代理渠道可以折扣 ^_^

@opengps 哇。。可以。。不管怎么说还是感谢跟我说这么多。 折扣怎么说。？

@yrebom 用我 id 加我微信告诉你，现在的折扣不像以往，受多个条件影响没有太明确的结果了