在面向对象出现之前，已有面向过程的分析方法，为什么面向对象被提出了呢？究其本质原因，人们发现面向过程并不是按照人正常认识事物的方式去分析软件，那么人究竟是怎么认识事物的呢，Yourdon 在《面向对象的分析》一书中提到，人类认识事物是遵循分类学的原理，分类学主要包含三点：区分对象及其属性；区分整体对象及其组成部分；不同对象类的形成及区分。
本文对完美Hash的概念进行了梳理，通过Hash构建步骤来了解它是如何解决Hash冲突的，并比较了Hash表和完美Hash表。下面介绍常见的Hash与Perfect Hash函数及它们在不同场景的应用。
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 工具可能无法做到灵活的部署和交付。
