架构-微核模式案例

微核模式

我们来看第二个案例，这是一个多人在线的游戏社区。在这个社区中，除了可以聊天、换衣服之外，还有大量的小型、中型、甚至大型游戏可以玩。这些游戏的内容，都会和整个社区以及角色集合起来，有点像几十个不同的游戏融合成的一个大游戏。

【此案例并非完全真实情况，有一定提炼修改成分】

我们这次要讨论的是客户端的架构。由于这个游戏，有一个统一的社区场景，还有大量的游戏内容，再加上覆盖在场景上的UI，所以我们针对每个功能，设计了模块。如“场景：码头”就是一个模块，包含了场景中的美术资源和其他所有功能。每个游戏也是一个单独模块，玩家开始这个游戏，就整个进入这个单独的模块。退出游戏则返回到之前的场景模块中。而UI也是分成主工具栏，聊天界面等模块，每个可以打开的面板，都是一个单独的模块，比如背包就是一个模块。

这种设计在初期有很大的好处，因为每个模块都可以单独的开发、修改和测试。一个模块包含了所有的代码和资源，是一个完整的整体。对于添加功能，只需要增加一个这样的模块，然后把连接代码组合到就的模块中就大功告成了。

但是这种架构并没能维持很久，因为策划要求加入一个“商店系统”，需求是：玩家能够在场景中触发商店的界面进行购买操作，同时在每个游戏中，也要能购买物品，但是界面却不能是商店本地的UI界面，因为要和游戏中的风格结合。同时，玩家还要能从聊天界面中，通过点击文字连接，去打开针对物品的商店界面。这种需求同样需要修改多个模块，导致工作量很大。加上每个模块都是单独开发的，连开发人员都不是同一个人，所以这种需求要实现起来似乎困难重重。同时作为修改速度非常快的客户端部分，策划和程序员们也都迫切希望能维持之前的能单独调试的结构。

因此，我们通过改进架构，实现了一个“不可见”的客户端模块——“统一处理框架”，这个框架负责处理网络通信、界面事件、模块事件三个主要的模块关联操作。

每个原来的模块，都必须使用这个“统一处理框架”来和其他模块互动。另外，我们还对所有的游戏整合了一个“游戏系统”的模块，对游戏中统一的开始游戏、结束游戏、物品产出、物品消耗等功能做了接口定义。

所有的游戏都需要符合“游戏系统”的需求，实现其要求的接口，这样整个系统任意的代码，都可以使用这些接口去控制一个具体的游戏行为。最后，我们把场景的基础代码和具体美术资源、具体逻辑代码做了拆分，形成了一个“场景播放器”模块，这个模块能让任意的代码，实现对任何一个场景的切入和退出。

通过这样的修改，对于商店系统的实现，仅仅是调用“统一处理框架”的API，发送几个功能事件，具体的图形播放和逻辑处理都会由提供功能的模块实现。同样，这些每个模块还是可以单独运行和单独调试，他们之间的关系，都通过发送事件和接收事件来处理就可以了。你可以发送一个没人处理的事件，也可以自己虚拟一个需要接收处理的事件，这样就可以调试任何一个模块。

这个架构，实际上就是参考了著名的“微核模式”而构成的。微核模式的核心是：

• 基本服务封装到微核 ——主要是一些每个模块都会用到的功能

• 内、外服务器负责功能实现（插件系统）——外服务器负责整合某个特定领域的抽象。内部服务器负责通用的功能抽象，如网络功能、日志等。

• 应用程序、服务器通过微核通信 ——这是最核心的部分，一个基于“事件”的运行时交互系统，用来沟通各个不同的模块。

• 外部服务和应用程序的差别，在于是否通过一个适配器来和微核耦合。这个适配器实际上能让应用程序模块更换不同的微核，这在于可移植系统上很重要。

微核模式实际上是一种特化的分层模式，他把最底层的功能封装层“微核”，同时把各个模块的交互规定为“运行时的事件”。这样简化了的3层架构，提供能非常好的模块独立性。

微核模式也就是我们常见的“插件系统”——模块高度独立，可移植

★ 适应：运行时多模块协作系统 ——如果我们需要系统可以运行起来之后，动态的加载和运行不同的模块，微核将是最合适的架构。在许多需要运行时扩展的系统中，比如一些IM软件想要带上各种和好友关系有关的功能；或者是希望同样的代码能在不同的“平台”、“环境”、“操作系统”下运行，都会使用这种架构。

★ 不适应：无需运行时多模块协作系统——如果软件本身不会分为多个需要不定时启动、运行的模块，就不必要实现这个稍嫌复杂的架构。

★ 方法论：实现运行时耦合——这个架构的核心，是把代码的直接耦合，变成运行时的动态调用，因此我们会使用事件机制、消息队列等手段，把代码的调用和具体的“数据”关联起来，从而避免了代码直接写死。

★ 设计模式实现：

观察者模式——观察者模式是最常用的运行时耦合的编码手段，在其他的架构中，我们还将见到他的身影。他是如此的常见，以致于JAVA直接把这个模式的实现代码收纳标准库JDK当中了。