平台化三部曲之二模块化开发 - Google Guice 平台模块化开发的果汁

该文章来自阿里巴巴技术协会（ATA）精选集

在前文《从Eclipse平台看交易平台化》中，主要探讨平台的扩展机制。本文将继续探讨平台化开发中另一个重要方面: 模块机制。在阿里系统开发中，大家都有自己的模块化开发方式。比如目前交易中的TMF框架(Trade Module Framwork)也是从模块化开发解决业务隔离扩展。 Detail 2.0平台化项目中定义了一套自己的模块化方式。本文想通过介绍Guice Module的模块机制，介绍一种简单强大的模块开发解决方案，Guice在java开源软件中被广泛使用，也证明他的生命力。希望给有开发需求的开发者可以直接拿来主义，在开发中提高效率。

Guice是什么

Guice（读作Juice）是Google开发的一套注入框架，目前最新版本是4.0Beta。注入的好处是将使用者与实现者、提供者分离，降低代码间的依赖，提高模块化程度。

Google的java开源产品，一般都具有良好的口碑，简洁而强悍，比如guava类库。本文会只涉及Guice的DI基本功能，更主要是介绍利用Guice来组织平台的模块开发，在这点，Guice提供了非常好的解决方式，个人想通过这篇文章给需要模块化开发的同学推荐Guice的Module解决方案。

Guice的基本DI功能

在java开发方面，Spring是大部分系统采用的基本框架，我们利用Spring的IOC，DI等功能组织代码。 Spring的成功和优势无可置否，但是Google的Guice提供了更轻量级，更简洁高效的DI框架，并且更高程度抽象出模块的概念，为代码开发提供了强大的工具。他的基本功能可以通过Guice wiki中了解，
摘抄一些优点介绍：

IoC中Bean的注释：其实实现细节很是让人不得不佩服，因此，很多的其它框架也开发模仿；
通过“prodivers”和“modules”实现编程配置：这相对于其它语言的实现方式而言，显得更加的优美，至少认人觉得是一种比较实际可能的方法；
快速的“prototype”场景：可以通过CGLib快速的构建对象，这点让我很激动。Guice的出现让我们看到了其实prototype的bean和动态创建的bean其实也可以很容易的管理；
Modules：module可以将应用程序分割成几大块，或是将应用程序组件化，尤其是对于大型的应用程序；
Type safety：类型安全，它能够对构造函数、属性、方法（包含任意个参数的任意方法，而不仅仅是setter方法）进行注入；
快速启动；
简单、强大、快速的学习曲线；
Guice的思想在一定程度上积极的影响着Spring和WebBeans；
Guice的头Bob Lee（http://crazybob.org/）不愧为IoC大师；

Guice DI基本原理：创建一个GuiceInjector（一种DI依赖注入的实现方式）。 Injector将会使用它的配置完的模块来定位所有请求的依赖，并以一种拓扑顺序来为我们创建出这些实例

如果在新项目中，也建议用Guice作为DI解决方案。

Guice的模块概念

Guice定义Module这个接口用来确定各个接口和他对应的实现的绑定。

通过bind("interface").to("implementation")的方式来完成接口实现的组装。目前很多的开源框架都采用Guice进行模块化开发，最典型的例子是**ElasticSearch**这个著名的分布式搜索引擎。本文将大量通过ES的模块化开发实践来说明Guice是模块开发的利器。除了ES外，Apache Shiro， Apache Shindig等也也采用了Guice，越来越多的开源实开始将Spring DI换成Guice。

ok，从头开始，所有的Guice模块都实现一个通用接口Module, 这个接口定义很简单，注释里也跟精确的解释了模块的定义和功能：

A module contributes configuration information, typically interface bindings, which will be used to create an {@link Injector}. A Guice-based application is ultimately composed of little more than a set of {@code Module}s and some bootstrapping code.

/**
* A module contributes configuration information, typically interface
* bindings, which will be used to create an {@link Injector}. A Guice-based
* application is ultimately composed of little more than a set of
* {@code Module}s and some bootstrapping code.
* <p/>
* <p>Your Module classes can use a more streamlined syntax by extending
* {@link AbstractModule} rather than implementing this interface directly.
* <p/>
* <p>In addition to the bindings configured via {@link #configure}, bindings
* will be created for all methods annotated with {@literal @}{@link Provides}.
* Use scope and binding annotations on these methods to configure the
* bindings.
*/
public interface Module {

/**
 * Contributes bindings and other configurations for this module to {@code binder}.
 * <p/>
 * <p><strong>Do not invoke this method directly</strong> to install submodules. Instead use
 * {@link Binder#install(Module)}, which ensures that {@link Provides provider methods} are
 * discovered.
 */
void configure(Binder binder);
}

在configure方法里，我们将接口的具体实现通过模块绑定起来。当这个模块被使用时，他定义的接口实现就会被调用。

同时Guide提供了Module接口的一个抽象类AbstractModule，提供了一些模块绑定的便利支持，同时推荐开发者的模块都继承这个抽象类。

Guice模块开发实践

对于平台来说，将系统的功能通过模块来定义功能的边界，模块之间相对独立。模块作为平台功能的组成的基本形式，通过预定义配置和运行时配置来完成平台的组装。

模块的具体实现将利用Guice的Module功能，完成配置信息和绑定各接口的特定实现。平台启动后，通过各种途径将相关模块整合起来，构建Guice Injector, 来完成将模块定义的实通过依赖注入的方式，快速构建起来，从而创建一个复合的模块系统。

给大家一个直观的印象，看看下面这个Elasticsearch的模块图：

点这里可以看到完整的图。可以看到具体模块的组织。可以看到这么一个复杂的分布式搜索引擎实现通过guice的模块化处理，有了一个清晰的结构。

下面我们将跟深入模块实现的细节和一些实践，用来更好的开发我们的业务平台。

Guice组织多业务可扩展平台开发

对于阿里内部常见的多业务平台来说，模块可能会分为系统模块，领域模块，业务模块这三个类型。

系统模块是用来建设平台本身需要的功能组织，比如平台的日志模块，监控模块等。
领域模块是某个领域的功能组件，比如交易领域里的物流模块，优惠模块等。
业务模块是业务方业务功能的实现，比如航旅开发出机票查询模块。

这样的模块化组织设计，为我们系统的分层，降低耦合度也非常有好处。

模块元数据(Metadata)

我们可以给模块定义元数据，用来描述模块的基本信息，从而可以方便平台对模块的管理和监控。

ModuleMetaData:{name(名称), type(类型), setting(配置)}

名称是模块的基本命名，类型可以是模块命名空间，setting保存模块的更多配置信息。

模块命名空间

多个模块基于他们在源代码树或者代码中的调用情况被放进了不同的命名空间中。不同的侧面，诸如插件，监控，环境设置服务是分割的功能实体，他们之间没有模块层面的依赖。模块可能已经太过庞大或者难以复合使用的将会被进一步分割成嵌套命名空间中的稍小的模块。

如果把模块系统类比成文件系统，模块是一个文件，那么命名空间就像是文件夹，相关的模块通过命名空间归类管理。命名空间和模块形成一个树状结构。通过命名空间+模块名可以唯一的定位到一个模块。

这样平台的功能和结构便可以通过: {Namespace：Module Name： Bound Class}清晰管理起来。

模块扩展和替换

大多数模块仅仅会提供一个或者多个类或接口，但是某些模块可以产生它们需要的新模块。这些模块通常依赖当前配置或输入参数动态产生。这样我们便可能通过插件写出替代或者扩展平台的内置功能，然后通过一定的条件来开启和配置这些插件。

比如我们有个ScriptModule模块提供脚本功能，平台预先定义了Groovy和Python两种脚本，平台可以根据配置或运行时根据输入参数告诉平台动态采用某个Groovy或者Python，同时也可以使自定义脚本，开发平台的插件提供新的脚本模块，并通过注册到平台来满足平台对脚本功能的扩展。

这种类似ScriptModule的模块我们把他定义为可扩展模块，模块维护一个模块内功能的注册扩展机制，新的script实现可以通过该模块registerScript方法注册。平台在运行时，根据配置或者输入参数，动态决定某个脚本被调用。

public class ScriptModule extends AbstractModule {


private final Map<String, Class<? extends NativeScriptFactory>> scripts = Maps.newHashMap();

public void registerScript(String name, Class<? extends NativeScriptFactory> script) {
    scripts.put(name, script);
}

    @Override
protected void configure() {
    MapBinder<String, NativeScriptFactory> scriptsBinder
            = MapBinder.newMapBinder(binder(), String.class, NativeScriptFactory.class);
    for (Map.Entry<String, Class<? extends NativeScriptFactory>> entry : scripts.entrySet()) {
        scriptsBinder.addBinding(entry.getKey()).to(entry.getValue()).asEagerSingleton();
    }
  }
}

需要更复杂灵活实现的话，可以在上面的的基础上跟进一步扩展，维护一个子模块的注册扩展机制，首先定义一个ScriptsModule：

public class ScriptsModule extends AbstractModule {

private final Settings settings;

private Map<String, Class<? extends Module>> scriptTypes = Maps.newHashMap();

public ScriptsModule(Settings settings) {
    this.settings = settings;
}

/**
 * Registers a custom script type name against a module.
 *
 * @param type   The type
 * @param module The module
 */
public void registerScript(String type, Class<? extends Module> module) {
    scriptTypes.put(type, module);
}

@Override
protected void configure() {
    bind(ScriptsTypesRegistry.class).toInstance(new ScriptsTypesRegistry(ImmutableMap.copyOf(scriptTypes)));
}

}

然后我们提供具体的ScriptModule实现，比如通过配置文件来配置新的脚本，也可以开发一个插件将新的CustomSciptModule注册进去。从而跟灵活的扩展功能。

从这里大家可以看到，**我们可以利用这种可扩展模块的注册机制，实现对多业务的支持**：
比如交易平台提供了优惠类型模块，每个业务可以把自己的优惠实现模块注册进去，平台会识别出业务类型后，自动找到对应业务的优惠实现，完成业务对优惠功能的定制需求。

{
 "ticket":"TicketDiscountModule",//电影票优惠模块
 "flight":"FilghtDiscountModule",//机票优惠模块
  ... 
}

模块构建使用

在了解模块的功能和扩展方式后，平台需要构建和使用模块。

平台启动时，首先你的启动类里，可以指定需要加载的模块，这个可以通过ModulesBuilder这个类来快速完成：

        ModulesBuilder modules = new ModulesBuilder();
        modules.add(new PluginsModule(settings, pluginsService));
        modules.add(new EnvironmentModule(environment));
       …
       injector = modules.createInjector();

模块加载完成后通过创建Guice injector，就可以完成所有依赖实现的组装。
这是，你就可以通过

            client = injector.getInstance(Client.class);

得到需要的实现，完成相应的逻辑。

ModuleBuider有些很酷的特性，如果一个Module同时实现了SpawnModules接口，

public interface SpawnModules {

Iterable<? extends Module> spawnModules();
}

以为这这个模块具有创建子模块的能力，那么ModulesBuilder在加入这种类型的模块是，会递归的创建出所有的子模块。

public ModulesBuilder add(Module module) {
    modules.add(module);
    if (module instanceof SpawnModules) {
        Iterable<? extends Module> spawned = ((SpawnModules) module).spawnModules();
        for (Module spawn : spawned) {
            add(spawn);//这是一个递归调用
        }
    }
    return this;
}

总结

模块化是对复杂业务平台分而治之的方式，通过模块化开发，可以使我们的平台建设更高效更灵活。 Guice的Module功能再开源软件中被广泛使用，在本人自己过去使用经历中，发现确实是个模块化的利器，希望更多的人了解使用。