RocketMQ 实现了灵活的多分区和多副本机制，有效的避免了集群内单点故障对于整体服务可用性的影响。存储机制和高可用策略是 RocketMQ 稳定性的核心，社区上关于 RocketMQ 目前存储实现的分析与讨论一直是一个热议的话题。近期我一直在负责 RocketMQ 消息多副本和高可用能力的建设，和大家分享下一些有趣的想法。本文想从一个不一样的视角，着重于谈谈我眼中的这种存储实现是在解决哪些复杂的问题，因此我从本文最初的版本中删去了冗杂的代码细节分析，由浅入深的分析存储机制的缺陷与优化方向。
Knative 是在 Kubernetes 基础之上的 Serverless 计算的技术框架，可以极大简化 Kubernetes 应用的开发与运维体验。在 2022 年 3 月成为 CNCF 孵化项目。Knative 由两个主要部分组成：一个是支持 HTTP 在线应用的 Knative Serving，一个是支持 CloudEvents 和事件驱动应用的 Knative Eventing。Knative 可以支持各种容器化的运行时环境，我们今天来探索一下利用 WebAssembly 技术作为一个新的 Serverless 运行时。
如何讲清楚一件事我相信很多人都很困惑也很无助，尤其是在晋升场合，在向上汇报或者是做大范围分享的时候，恨不得找个地缝钻进去。很多时候我们常常是这样安慰自己，我是实干派技术人，不需要那些花里胡哨的东西，我技术过硬比什么都重要。曾经一度我也是这样认为，最后改变我这个想法的是一句话：如果你讲不清楚多半是想不清楚，如果你都想不清楚如何能够带领更多人拿到结果？
Apache RocketMQ 作为一款分布式的消息中间件，历年双十一承载了万亿级的消息流转，其中，实时读取写入数据和读取历史数据都是业务常见的存储访问场景，针对这个混合读写场景进行优化，可以极大的提升存储系统的稳定性。
目前的微服务架构中，通常包含服务消费者、服务提供者、注册中心、服务治理四元素，其中服务消费者会向注册中心获取服务提供者的地址列表，并根据路由策略选出需要调用的目标服务提供者地址列表，最后根据负载算法直接调用提供者。当大规模生产环境下，服务消费者从注册中心获取到的服务提供者地址列表过大时，采用传统的路由方式在每次服务调用时都进行大量地址路由选址逻辑，导致服务调用性能低下，资源消耗过多。
Helm Charts 如今已是一种非常流行的软件打包方式，在其应用市场中你可以找到接近一万款适用于云原生环境的软件。然后在如今的混合云多集群环境中，业务越来越依赖部署到不同的集群、不同的环境、同时指定不同的配置。再这样的环境下，单纯依赖 Helm 工具可能无法做到灵活的部署和交付。
定时任务作为一种按照约定时间执行预期逻辑的通用模式，在企业级开发中承载着丰富的业务场景，诸如后台定时同步数据生成报表，定时清理磁盘日志文件，定时扫描超时订单进行补偿回调等。程序开发人员在定时任务领域有着诸多框架和方案可供选择，并借此快速实现业务功能实现产品上线。本文将就当前主流定时任务解决方案进行介绍和分析，期望可以在企业技术选型和项目架构重构时作为参考。
