AutoMQ的博客

恰逢今天读到了行业大佬对近期频发的公有云故障的思考《》，该文章的核心观点是「公有云是没法测试的」。我其实对这个事情有相反的观点，云服务本身也是软件，软件工程发展至今测试手段是多样和丰富的，而且公有云因为有大规模的生产流量优势，用好金丝雀 / 灰度发布能在新版本全网发布前尽可能揪出从其他测试环节中逃逸的 Bug。那既然测试是好做的，为什么从结果来看，公有云故障还是那么多呢，结合我在云厂商的工作经历来看，两朵云近两次 IAM 相关的故障背后，大概率还是投入问题。

云计算所有的能力都是通过 API 来进行描述的，比如用 API 创建一台 ECS，用 API 重新挂载一块云盘，用 API 去调整云服务的 Quota 和 Limitation。正因为此，云原生的软件有机会利用 API 去编排资源，去实现 Auto Scaling，实现容灾的切换。通过利用云的 API 完成软件核心的能力建设，甚至容灾能力的建设，这也是传统的软件架构无法办到的事情。章文嵩，AutoMQ 联合创始人 & 首席战略官，开源项⽬ LVS 创始⼈。周新宇。

近年来，无论是海外还是国内，虽然受疫情影响，公有云的市场规模增速有所放缓，但是云的市场总规模仍然是持续增长的。公有云作为一个各个国家重点布局的战略方向和其本身万亿级市场的定位[1]，我们学习用好云是非常有必要的。AutoMQ Kafka 充分认识到“云优先”的重要性，围绕公有云具备规模化效益和技术红利的云基础设施重新设计了 Kafka。在保证 100% 兼容 Apache Kafka 的基础上带来了极致的云成本优势和弹性能力，云上综合有 10 倍以上的成本节约[2]。

到今天，我一直在思考一个问题，我们运维过全球最大的 RocketMQ 集群，服务过数万的 RocketMQ 企业客户，我们对每一行的代码，不仅仅是代码，甚至是这行代码在不同环境下的不同表现都清清楚楚，我们能否把这些经验，把曾经凌晨处理过的故障，把不分昼夜的报警电话，以及烂熟于心的日志，都通过代码的形式沉淀下来，能够帮助 RocketMQ 的运维团队，高效、轻松地运维好 RocketMQ 集群，给业务提供高质量的 RocketMQ 服务。，这到底是客户自身的问题，还是 RocketMQ 丢了消息？