如何基于现有系统快速部署不同环境？

目录

• 1. 多环境部署解决方案列举
• 2. 基于jar包多模块部署实践
• 3. 基于war包多模块部署实践 

---

　　业务场景，基于同一套代码，可能会有不同的部署需求。原因可能是为做数据隔离，权限隔离，等等。。。

　　没有什么新的实际需求，基本上只要根据新的环境配置把代码部署过去就可以了。说直接点，就是配置文件不一样。如何处理呢？

 

返回顶部

1. 多环境部署解决方案列举

　　要解决这类问题，实际上已经有很多的现成的案例了。我们唯一的痛点在于，各个公司有各个公司的技术背景，并不能有一个放之四海而皆准的东西。但我还是想罗列下解决方案，以供参考：

　　　　1. 如果有一个完善的部署系统，那么，你可能会支持直接在这个系统直接定制化你的配置信息。（如蚂蚁的AKS服务）
　　　　2. 如果应用比较少，你也可以直接配置文件放到对应机器的目录，部署完成后，将配置项指向该地址即可加载不同配置。
　　　　3. 如果不方便改机器信息，且有一个配置系统支持，那么，可能通过配置中心，提供不同的配置项给到相应集群。（代码需要做适配）
　　　　4. 新增一个系统模块，除了配置信息之外，全部依赖现有代码，在部署时使用该新模块即可。（这是本文想说的）

　　第一个方案是最优的，但是前提是公司得有这样的技术背景。

　　第二个方案基本都会被抛弃，运维成本太高，人工处理的时代早已过去。

　　第三个方案，需要做较多适配，代码修复复杂，可能带来过多复杂的逻辑。

　　第四个方案，需要新建一个应用模块，看似复杂，实则相当简单方便，相当于是在代码里新增一些配置文件，替换掉相应的项后，直接将老代码跑起来。可以说，实现相当干净。

　　下面我们就第四个方案看下如何实现！

 

返回顶部

2. 基于jar包多模块部署实践

　　如果现有的项目是jar包方式运行，那么就非常方便了。直接在新增的模块中，引入jar依赖，然后写入自己的配置文件，就搞定了。就和普通的依赖无差别如：

<!-- 1. 添加原项目依赖 -->    
<dependency>
    <groupId>com.test</groupId>
    <artifactId>old-proj</artifactId>
    <version>1.0.0</version>
</dependency>
<!-- 2. 生成新的构建 -->
<build>
    <finalName>new-proj</finalName>
        <sourceDirectory>src/main/java</sourceDirectory>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.1</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.17</version>
                <configuration>
                    <skip>true</skip>
                </configuration>
            </plugin>
        </plugins>
</build>

 

返回顶部

3. 基于war包多模块部署实践 

　　如果现有项目是war包运行，那么会稍微麻烦些，主要就是涉及到war包依赖war包的问题。但也是引入几个依赖就可以了。

<!-- 1. 添加原项目依赖 -->    
<dependency>
    <groupId>com.test</groupId>
    <artifactId>old-proj</artifactId>
    <version>1.0.0</version>
        <type>war</type>
</dependency>
<!-- 2. 生成新的构建 -->
<build>
    <finalName>new-proj</finalName>
        <sourceDirectory>src/main/java</sourceDirectory>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.1</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.17</version>
                <configuration>
                    <skip>true</skip>
                </configuration>
            </plugin>
        <!-- 3. 将原项目打包过来 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <configuration>
                    <overlays>
                        <overlay>
                            <groupId>com.test</groupId>
                            <artifactId>old-proj</artifactId>
                        </overlay>
                    </overlays>
                </configuration>
            </plugin>
        </plugins>
</build>

<!-- 4. 在原项目上添加attachClass选项 -->
<build>
    <plugins>
        ...
        <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <configuration>
            <attachClasses>true</attachClasses>
        </configuration>
        </plugin>
    </plugins>
</build>

　　最后，在相应的位置上，替换掉老的配置文件，打包之后，就是新的项目了。再不怕不同集群部署带来的差异了，因为原来的项目基本一点也没动。老系统风险几乎为0.