untitledabc

@HTravel 开心就好，你这适合玩传统行业，运营商/银行都这么玩的。用不用微服务那是业务决定的，技术靠后，你这种玩法都不是云的目标用户，真的。

担心啥绑定，你想迁移，厂商立马分分钟帮你一起整。

@HTravel 这个 case 有很多值得深挖和复盘的地方，但好像没一个是你说的。已经有公开 message

这里的 dns 明显是个服务注册发现用的，因为代码产生极端情况下的竞态触发了问题。不是平时接触的公共 dns 。

所谓的两地三中心是人家提供的基础设施有这个条件，而不是你的单个应用程序在云上就从单一部署变成多活。一个多 az 单 region 部署的应用，理想情况下，可以到 99.99%，又不是永不停机。每增加一个小数点的可用性，成本是曲线增长的，架构设计没有银弹，只有权衡。

别说 aws 这种体量的公司，就算国内的二三线互联网公司，每天成千上万次发布，评审 step by step 、文档指导书，按这个玩法公司效率得被拖垮。

另外遇到的国内云常规骚操作，很多时候是有点小聪明过头了：

例如国内的很多云，租几个运营商的机柜就是 az 了，很多应用例如 es/kafka 这种是需要副本+选举来运作的，需要被部署在不同的 az 。而这种小 az 是没办法用来高可用部署的，新的硬件机器永远只出现在新的 az ，老 az 开不出机器。甚至某些服务升级还需要迁移 az 。选 3 个 az 用最新一代的实例去部署一个高可用服务都是个问题。

最后个人觉得国内真认真做云的只有 A 家，水平至少也是 Azure 之上的，有没 GCP 的水平不好说，其他几家真有点那啥。

@ferock 我刚升级到 1.141 ，这个升级太麻烦了，中间还得过渡一个版本。docker 镜像国内还拉不动

不会有人觉得云厂商能帮你屎一样的业务实现 5 个 9 吧？ 5 个 9 是有很多前提的，按 aws 多 az 部署的架构，理论上也就 4 个 9 ，5 个 9 得跨 region 结合应用架构来实现的。高可靠性是实打实要花钱的，一般会有个权衡，很多客户只有核心业务链路需要 4 个 9 。5 个 9 得金融交易所这种了。
弹性扩容这个在现在容器这么普及的情况下，大部分场景下是基操。
秒级恢复看恢复啥了，数据是不可能的，你要说出现一个 site 异常，自动将流量切换到其他 site ，是可能做到的。

这些 ppt 都是往理想情况下去吹牛逼的。可以去看看 aws well architected framework ，影响应用 sla 的因素很多。云厂商的 sla 承诺很多是针对云的单个服务，并不是你的应用 sla 。然后 sla 是个数字游戏，是个合同承诺，我见过传统存储厂商 100% sla ，做不到靠保单理赔的。不过云厂商的 sla 一般会严谨的多。

怎么可能不用 docker 部署，出这种问题的人大部分半桶水。

google 的 gemini 结合 research 已经非常好用了，Perplexity 这种小公司未来必死

对 web 来说 s3 完美：
横向扩展
把站点消耗 cpu 的 io 从服务卸载到 s3 ，使得 web 服务本身更容易扩展
海量小文件在文件系统里检索起来就是灾难
数据共享和服务集成，不会有人喜欢搬数据吧

啥鬼，难不成群晖做企业用户？企业存储群晖连边都没摸到吧