分布式系统中的Gaggles与面向对象互操作性探索

### 分布式系统中的Gaggles与面向对象互操作性探索 #### 1. Gaggles相关机制 在分布式系统里，Gaggles机制为对象调用和管理带来了新的思路。当消息接收者收到消息后，拥有了更多的操作自由。若Gaggle中选定的成员是本地的，就可直接执行调用；若选定成员不是本地的，但Gaggle里其他成员是本地的，调用仍能进行；若这两种情况都不满足，接收者可以选择遵循最初选定对象的转发链，或者替换为其他已知的Gaggle成员并将调用转发给它。 为确保该算法能终止，需要在调用消息中记录对所有尝试调用的成员的最新带时间戳的转发指针。在嵌套Gaggles的情况下，这也有助于检测成员循环。该算法的有效性依赖于每一步中对转发调用的特定成员的精心选择。为辅助选择，我们要尽可能多地保存关于各个成员的信息，除了带时间戳的转发指针，还可以保存网络拓扑、系统负载以及之前调用时测量的响应时间等信息。 初始调用者（实际上，调用路径上的任何节点）还能通过设置最大转发步数来限制后续节点的灵活性。当达到最大步数时，调用将不再转发，而是向初始调用者返回包含更新后的成员信息和转发指针的进度报告，初始调用者再决定是继续选择最初的成员还是尝试其他成员。 从整体来看，定位算法有两个参数：网络拓扑和Gaggle的成员。若能掌握这两方面的完整信息，选择最佳的调用成员就会很容易，但实际上我们很难获取到如此全面的信息。对此，我们采取了两个策略：一是尽可能低成本地传播更多信息；二是认识到信息永远不可能完整，尽力利用现有的信息。 下面是Gaggles定位算法的流程： ```mermaid graph TD; A[接收消息] --> B{选定成员是否本地}; B -- 是 --> C[执行调用]; B -- 否 --> D{是否有其他本地成员}; D -- 是 --> C; D -- 否 --> E{是否达到最大转发步数}; E -- 是 --> F[返回进度报告]; E -- 否 --> G[遵循转发链或替换成员并转发]; ``` ##### 1.1 稳定存储 Hermes对象查找算法将稳定存储作为最后的手段。我们可以利用名称服务为gaggleManager提供一种稳定存储形式，以此提高Gaggles的健壮性。当有成员加入组时，可以立即更新（全局）名称服务，也可以批量更新。若节点找不到已知的Gaggle成员，它可以向名称服务器请求成员列表，查看是否有其他成员。不过，由于名称服务器的信息并非实时更新，不能完全依赖它提供所有成员的名称，而且它作为全局服务，成本相对较高，应仅作为最后的手段使用。但由于成员不会从Gaggle中移除，从名称服务获取的信息虽然不完整，但不会出错。因此，Gaggle的稳定存储实现方式与普通对象略有不同，但并不复杂。就像单个位置的对象将其状态存储在单个存储站点一样，多个位置存在的对象将其状态存储在“分布式存储站点”——名称服务中。 ##### 1.2 addMember操作 当成员加入Gaggle时，不清楚该信息应传播给谁。发生addMember调用的节点上的成员表肯定要更新，此外，如前文所述，还可以进行或排队更新名称服务器。除此之外，还有多种选择。传播成员信息的目的是减少实现调用所需的消息流量。因此，任何使用额外消息的传播策略都值得怀疑。不过，将Gaggle成员信息搭载到现有的节点间通信中是一个不错的方法。例如，在交换状态和负载信息时，可以通知附近的机器有新的Gaggle成员加入；或者，当添加节点下次看到对gaggleInvokee的调用时，返回成员更新信息。 #### 2. Emerald对Gaggles的实现 Emerald运行时库实现Gaggles的代码如下： ``` const Gaggle c immutable object Gaggle export function of [memberType : type ] -+ [result : gaggleType 3 where gaggleType t typeobject gaggleType function getSignature [ ] -+ [Signature] operation new [ ] -+ [gaggleManage ```