分布式对象存储Ambry（3）源代码结构与改造调试

上一篇文章中，我们对于Ambry做了简单的集群测试，但是再次强调一遍，这些只是最简单的测试，而且集群配置也不适用于生产环境。具体生产如何配置，我们之后在讲完原理之后会讲。
首先，我们目前Ambry的架构集群如下所示：

通过这幅图片，我们可以看出，ambry简单来看，分为：前端（Ambry frontend）还有后端数据负载节点（Ambry）。前端是一个简单的暴露Restful的API的包含Ambry-client-library的接口程序。客户端也可以直接通过依赖调用Ambry-client-library程序来访问后端Ambry数据负载节点。
我们查看下源代码结构：

由于本人对于Gradle不如Maven熟悉，而且为了去除一些无关的依赖还有熟悉源代码，我在这里利用Maven来替代原来的gradle依赖管理。
如果大家觉得麻烦，可以直接访问这个git库进行下载：我的项目-AmbryX，并且欢迎大家fork并一起补充想法，将Ambry改造成可以直接商用的，适合国内环境的框架。
改造的思路大概就是参考build.gradle这个gradle项目依赖根目录管理文件，通过allprojects配置了解全部模块的依赖和插件，这里是：

allprojects {    group = "com.github.ambry"    apply plugin: 'eclipse'    apply plugin: 'idea'    apply plugin: 'project-report'    repositories {        mavenCentral()        mavenLocal()    }}

看了下剩下的模块依赖，这些内容都没有必要添加，只有group这个属性有用，用来决定我们maven中的groupId。
然后我们看subprojects的内容：

subprojects {    apply plugin: 'java'    sourceSets {        test {            java.srcDir file('src/integration-test/java')            resources.srcDir file('src/integration-test/resources')        }        unitTest {            java.srcDir file('src/test/java')            resources.srcDir file('src/test/resources')        }    }    dependencies {        compile "log4j:log4j:$log4jVersion"        compile "org.slf4j:slf4j-api:$slf4jVersion"        compile "org.slf4j:slf4j-log4j12:$slf4jVersion"        testCompile "junit:junit:$junitVersion"        unitTestCompile sourceSets.main.output        unitTestCompile sourceSets.test.output        unitTestCompile configurations.testCompile        unitTestRuntime configurations.testRuntime    }    test {        testLogging {            exceptionFormat = 'full'        }    }    task unitTest(type: Test) {        testLogging {            exceptionFormat = 'full'        }        testClassesDir = sourceSets.unitTest.output.classesDir        classpath += sourceSets.unitTest.runtimeClasspath    }    // only run unit tests when doing a standard build,    // but run integration tests too when running the test target    check.dependsOn -= test    check.dependsOn += unitTest}

由于maven和gradle在单元测试的思路上是不一样的，maven的思路是在test目录下的所有class不会被包含在模块中。所以，模块与模块之间的单元测试不能互相依赖。但是gradle不一样，不同模块测试之间可以互相依赖。例如ambry-network模块：

project(':ambry-network') {    dependencies {        compile project(':ambry-api'),                project(':ambry-utils')        compile "com.codahale.metrics:metrics-core:$metricsVersion"        testCompile "org.bouncycastle:bcpkix-jdk15on:$bouncycastleVersion"        testCompile project(':ambry-utils').sourceSets.test.output    }}

其中compile相当于maven依赖中的compile scope，testCompile 相当于maven依赖中的test scope。但是，这里面testCompile project(':ambry-utils').sourceSets.test.output是依赖于ambry-utils的测试类，而不是main下面的。我们要改造成maven的项目，可以将所有模块的单元测试都放进一个新的模块-ambry-test中，来解决不同模块测试依赖。
之后，我们跟据每个模块的依赖，补充每个模块的pom文件。
在之后，在项目根目录整理conf目录，只留下如下几个文件即可：

在这里再说一遍，欲知详情，请参考：我的项目-AmbryX
解决依赖之后，我们在IDEA中重新载入这个项目，以maven project的形式。之后我们进行调试：
首先，定位到AmbryMain这个类，设置启动configuration：

主要设置VM options为：

-Dlog4j.configuration=file:./conf/log4j.properties

设置Program arguments为：

--serverPropsFilePath./conf/server.properties--hardwareLayoutFilePath./conf/HardwareLayout.json--partitionLayoutFilePath./conf/PartitionLayout.json

之后启动。看到日志打出Server startup time in Ms xxxx，则成功。
接下来我们设置下前端restful服务端：
设置VM options为：

-Dlog4j.configuration=file:./conf/log4j.properties

设置Program arguments为：

--serverPropsFilePath./conf/frontend.properties--hardwareLayoutFilePath./conf/HardwareLayout.json--partitionLayoutFilePath./conf/PartitionLayout.json

之后启动。
Ambry还有管理端，只不过接口比较少，我们这里也配置下：
AdminMain:
设置VM options为：

-Dlog4j.configuration=file:./conf/log4j.properties

设置Program arguments为：

--serverPropsFilePath./conf/admin.properties--hardwareLayoutFilePath./conf/HardwareLayout.json--partitionLayoutFilePath./conf/PartitionLayout.json

之后启动。

最后，我们简单过一下每个模块的作用，之后的文章里面我们会仔细讲：