什么是Shim
Shim一词的原本含义是“垫片”或者“楔子”，而首先将这个词应用到软件工程领域的似乎是微软。根据Wikipedia的总结：
A shim is a library that transparently intercepts API calls and changes the arguments passed, handles the operation itself or redirects the operation elsewhere. Shims can be used to support an old API in a newer environment, or a new API in an older environment. Shims can also be used for running programs on different software platforms than they were developed for.
按照这个释义，Shim是一种（小型的）库，负责透明地拦截API调用，并更改其参数，或将其转发至其他组件，或者自行处理。它用于在新环境中支持旧API（或反过来），以及使程序能够在非特定支持的平台上运行。下面举两个栗子简单说明下Shim在不同场景下的实现。
Kubernetes中的Shim
熟悉K8s的看官可能会立即想起该体系中的containerd-shim组件，它作为containerd与OCI运行时交互的中间层发挥作用。
展开来讲，当Kubelet请求containerd来创建容器时，并不会由containerd直接来操作，而是创建一个叫做containerd-shim的进程，且containerd-shim会进一步启动containerd-shim-runc-v2进程并立即退出。这样，containerd-shim-runc-v2就和containerd脱离了关系（因为containerd-shim-runc-v2的父进程此时为systemd），而通过runc启动的容器进程父进程为containerd-shim-runc-v2，负责后续接管容器内虚拟OS的管理和状态上报。
也就是说，即使containerd守护进程异常退出，容器也不会受影响，将两者解耦开来就是containerd-shim最重要的作用。
Flink Hive Catalog中的Shim
Shim支持不同API版本这一方面的话，我们可以参考一下Flink（当然其他很多开源组件也同理）的设计思路。
我们知道，Flink 1.14支持从1.0.0~3.1.2各版本的Hive，而横跨这么多版本的Hive API底层逻辑势必不会完全一致，如果将全部版本的Hive依赖都引入进来，也一定会造成冲突，这里就需要Shims发挥作用。在代码中，HiveShim是一个接口，定义了所有需要做兼容性支持的方法，如下图所示。
该接口的实现类就从HiveShimV100一直命名至HiveShimV312，每个类都会override对应版本出现变更的方法。例如，alterPartition()方法对应1.0.0版本的实现是：
@Override
public void alterPartition(
IMetaStoreClient client, String databaseName, String tableName, Partition partition)
throws InvalidOperationException, MetaException, TException {
String errorMsg = "Failed to alter partition for table %s in database %s";
try {
Method method =
client.getClass()
.getMethod(
"alter_partition", String.class, String.class, Partition.class);
method.invoke(client, databaseName, tableName, partition);
} catch (InvocationTargetException ite) {
// ...
} catch (NoSuchMethodException | IllegalAccessException e) {
// ...
}
}
而由于Hive Metastore提供的API alter_partition() 方法的签名发生了变化，对应2.1.0版本的实现是：
@Override
public void alterPartition(
IMetaStoreClient client, String databaseName, String tableName, Partition partition)
throws InvalidOperationException, MetaException, TException {
String errorMsg = "Failed to alter partition for table %s in database %s";
try {
Method method =
client.getClass()
.getMethod(
"alter_partition",
String.class,
String.class,
Partition.class,
EnvironmentContext.class);
method.invoke(client, databaseName, tableName, partition, null);
} catch (InvocationTargetException ite) {
// ...
} catch (NoSuchMethodException | IllegalAccessException e) {
// ...
}
}
显然，由于Flink环境并不能事先确定外部Hive的版本，所以全部的Shim方法都需要依赖反射调用。另外，为了保持向后兼容性，Shim实现类从低版本到高版本会自然形成链式继承关系，如下图所示。
在Flink App启动时，HiveShimLoader组件会根据Catalog定义时传入的hive-version参数或者自动探测到的Hive版本加载特定的HiveShim，不再赘述。
不用Shim的场景？
在Flink Connector体系内也能找到这类场景，如ES Connector就使用了3个不同的module来实现：flink-connector-elasticsearch5、flink-connector-elasticsearch6和flink-connector-elasticsearch7：
造成这种不同选择的原因有二：一是ES版本并不像Hive版本那么细分，即使6.x和7.x之间有大量的重复代码也在可接受的范围内；二是5.x采用Transport Client进行通信，而6.x和7.x采用REST High Level Client进行通信，相当于破坏了统一的接口规约（统一接口的示例如上文中Hive的IMetaStoreClient），在这基础上再使用反射调用会更加复杂，得不偿失。
Iceberg基于同样的考虑，在0.13版本之后也对Spark和Flink做了非Shim化的支持，看官可以去GitHub看看。
vs 适配器模式？
在笔者看来，Shim是适配器模式的一种另辟蹊径的实现方式。参考GoF对适配器模式的解说：
The adapter design pattern solves problems like:
- How can a class be reused that does not have an interface that a client requires?
- How can classes that have incompatible interfaces work together?
- How can an alternative interface be provided for a class?
The adapter design pattern describes how to solve such problems:
- Define a separate adapter class that converts the (incompatible) interface of a class (adaptee) into another interface (target) clients require.
- Work through an adapter to work with (reuse) classes that do not have the required interface.
用上文HiveCatalog的例子套用这个定义，HiveShim就是适配器本体，而Hive的原生API就是被适配者（adaptee），各个不同版本的HiveShim实现的方法就是目标接口（target）。一家之言，仅供参考。
The End
晚安晚安。
