One, foreword

Previous articles have covered the back-end architecture evolution series. This series uses a classic e-commerce system as an example to show how Robben built a large back-end architecture step by step in actual development. This series of articles more about some practical operation aspects of operation and selection.

To do a good job, he must sharpen his tools. Before the business code is developed, let’s set up the infrastructure.

Second, cloud platform

Cloud services include Ali Cloud, Tencent Cloud, Huawei cloud and so on. Ali cloud is a veteran cloud service provider, complete set of products, rich documentation, the price is correspondingly a little more expensive. Tencent cloud is a rising star, Tencent endorsement, the price is cheaper than Ali cloud. Huawei cloud used not to evaluate.

You can choose to run jar packages directly on Linux or use Kubernets for deployment.

The cloud service provider here chooses Tencent Cloud, and the platform chooses Kubernetes to manage our entire back-end application cycle.

Third, code management

Git and Svn are now basically choose Git. Using a private GitLab, or a Cloud service Git repository, is another good option. Most companies build their own repository for code security.

  • Self-built GitLab Reference: Deploy GitLab server in TKE container cluster
  • Tencent Cloud Coding:

This series of articles uses the coding repository to manage coding.

4. Document service

File services are singled out here because the security and maintenance of file storage are more important and independent.

  • Self-built distributed file service Fastdfs

Fastdfs is an open source distributed file system that takes into account redundant backup, load balancing, and linear expansion, and emphasizes high availability and high performance. Generally used in pictures and audio this kind of small file storage, have their own needs can be considered by the team.

  • Use the file service provided by the cloud service provider

This is nothing to say, like Ali cloud OSS, seven niuyun and so on.

This series of articles uses seven Niuyun’s file service.

5. Unified dependency management Maven

As dependencies grow, internal services are created. Unified versioning is important.

The Maven server

For unified management of dependency and internal binary libraries. You can choose to build your own or use cloud services. Self-built Nexus: Omitted, but there are tons of them on the Internet. Cloud services: Artifact management for Coding.

Maven Setting

<profile>
    <id>robbendev-robbendev-robbendev</id>
    <activation>
        <activeByDefault>true</activeByDefault>
    </activation>
    <repositories>
        <repository>
            <id>robbendev-robbendev-robbendev</id>
            <name>robbendev</name>
            <url>https://robbendev-maven.pkg.coding.net/repository/robbendev/robbendev/</url>
            <releases>
                <enabled>true</enabled>
                <updatePolicy>always</updatePolicy>
            </releases>
            <snapshots>
                <enabled>true</enabled>
                <updatePolicy>always</updatePolicy>
            </snapshots>
        </repository>
    </repositories>
</profile>
Copy the code

Unified dependency project

Unity depends on the project structure

Robbendev - maven ├ ─ ─ pom. XML ├ ─ ─ robbendev - bom │ ├ ─ ─ pom. The XML ├ ─ ─ robbendev - dependencies │ ├ ─ ─ pom. The XML └ ─ ─ Robbendev - parent ├ ─ ─ pom. XMLCopy the code

Let’s look at the code

The robbendev.maven/ pop.xml is mainly to configure the private server address

<groupId>com.robbendev</groupId>
<artifactId>robbendev-maven</artifactId>
<version>1.0 the SNAPSHOT</version>

<modules>
    <module>robbendev-bom</module>
    <module>robbendev-dependencies</module>
    <module>robbendev-parent</module>
</modules>

<packaging>pom</packaging>

<name>robbendev-maven</name>
<description>Robbendev Maven Nexus basic configuration</description>

<! -- omitted xml -->
<distributionManagement>
    <repository>
        <! Settings. XML must have the same id as settings. XML
        <id>robbendev-robbendev-robbendev</id>
        <name>robbendev</name>
        <url>https://robbendev-maven.pkg.coding.net/repository/robbendev/robbendev/</url>
    </repository>
</distributionManagement>
Copy the code

Robbendev-maven /robbendev-bom/pom. XML is mainly a dependent version of the unified internal two-party library

<parent>
    <artifactId>robbendev-maven</artifactId>
    <groupId>com.robbendev</groupId>
    <version>1.0 the SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>

<artifactId>robbendev-bom</artifactId>
<name>robbendev-bom</name>
<description>Robbendev binary library dependency configuration</description>
<packaging>pom</packaging>

<properties>
    <robbendev-common.version>1.0 the SNAPSHOT</robbendev-common.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.robbendev</groupId>
            <artifactId>robbdendev-common</artifactId>
            <version>${robbendev-common.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>
Copy the code

Robbendev-maven /robbendev-dependencies/ pop. XML is a dependency version of the external library

<parent>
    <artifactId>robbendev-maven</artifactId>
    <groupId>com.robbendev</groupId>
    <version>1.0 the SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>

<artifactId>robbendev-dependencies</artifactId>
<name>robbendev-dependencies</name>
<description>Robbendev tripartite library dependency configuration</description>
<packaging>pom</packaging>

<properties>
    <spring-cloud.version>Hoxton.SR7</spring-cloud.version>
    <spring-boot.version>2.3.3. RELEASE</spring-boot.version>.</properties>

<dependencyManagement>
    <dependencies>

        <! --spring cloud-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>

        <! --spring boot-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>${spring-boot.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>.</dependencies>

</dependencyManagement>

Copy the code

Robbendev-maven /robbendev-parent/ pop.xml Aggregate binary and tripartite libraries depend on the configured POM as the parent POM file for all projects

    <properties>
        <robbendev-bom.version>1.0 the SNAPSHOT</robbendev-bom.version>
        <robbendev-dependencies.version>1.0 the SNAPSHOT</robbendev-dependencies.version>
    </properties>

    <dependencyManagement>
        <dependencies>

            <! Database dependency Management -->
            <dependency>
                <groupId>com.robbendev</groupId>
                <artifactId>robbendev-bom</artifactId>
                <version>${robbendev-bom.version}</version>
                <scope>import</scope>
                <type>pom</type>
            </dependency>

            <! Library dependency Management -->
            <dependency>
                <groupId>com.robbendev</groupId>
                <artifactId>robbendev-dependencies</artifactId>
                <version>${robbendev-dependencies.version}</version>
                <scope>import</scope>
                <type>pom</type>
            </dependency>
        </dependencies>

    </dependencyManagement>
Copy the code

So our dependency management is done, and the new project just inherits

<parent>
    <groupId>com.robbendev</groupId>
    <artifactId>robbendev-parent</artifactId>
    <version>1.0 the SNAPSHOT</version>
</parent>
Copy the code

Automatic integration of CI/CD

Custom integration frees developers from the cumbersome packaging and distribution process and allows them to focus on business code development. It is an effective way to improve team performance.

Release of two-party library

Taking the Robbendev-Maven project as an example, how do we quickly push maven private server every time a dependency version changes? Taking this project as an example, there are common solutions in the industry

  1. Gitlab-ci This option can be considered if the gitlab repository is used.
  • Self-built Jenkins If you have your own operation and maintenance team, you can consider using a self-built operation and maintenance platform.
  • Using cloud Services

Here is a brief introduction to the coding continuous inheritance used by the author, which is fully compatible with Jenkins. It is also basically configured on the console:

You can use either the process configuration or Jenkinsfile in the repository

. stage('compiled') {
    steps {
        sh 'mvn clean package'
    }
}
stage('Push to CODING Maven Artifact library') {
    steps {
        echo 'In release... '
        sh 'mvn deploy -DskipTests'
        echo 'Publish complete.'}}}Copy the code

The packaging machine chose to build a custom node because maven’s setting file was to be configured.

Select the trigger that suits you and now commit code to see automatic integration and deployment triggered:

Service publishing

To a most basic SpringBoot program as an example in Tencent cloud image warehouse to obtain the account password in Maven setting configuration

<server>
    <id>robbendev-docker</id>
    <username>100000000000</username>
    <password>xxxxxxxxxx</password>
    <configuration>
        <email>xxxxxxx</email>
    </configuration>
</server>
Copy the code

Application code structure

├ ─ ─ pom. XML ├ ─ ─ the SRC │ ├ ─ ─ the main │ │ ├ ─ ─ docker │ │ │ └ ─ ─ Dockerfile │ │ ├ ─ ─ Java │ └ ─ ─ the testCopy the code

Pom. XML using a docker plug-in, pay attention to the serveId corresponding setting. In XML configuration, maven. Build. The timestamp. The format attribute must be specified. ImageName means to use the timestamp as the version number.

<properties>
    <maven.build.timestamp.format>yyyyMMddHHmm</maven.build.timestamp.format>.</properties>

<plugin>
    <groupId>com.spotify</groupId>
    <artifactId>docker-maven-plugin</artifactId>
    <version>1.0.0</version>
    <configuration>
        <skipDockerBuild>false</skipDockerBuild>
        <imageName>ccr.ccs.tencentyun.com/robbendev.hello-docker/robbendev-hello-docker:${maven.build.timestamp}
        </imageName>
        <dockerDirectory>src/main/docker</dockerDirectory>
        <resources>
            <resource>
                <targetPath>/</targetPath>
                <directory>${project.build.directory}</directory>
                <include>${project.build.finalName}.jar</include>
            </resource>
        </resources>
        <serverId>my-docker</serverId>
    </configuration>
</plugin>
Copy the code

Take a look at the Jenkins key code

stage('Compile, package and deploy') {
    steps {
        sh ''' git checkout master git pull mvn clean package docker:build -DpushImage'''}}Copy the code

In this way, when submitting the code, you can automatically package the image and push it to Tencent cloud image warehouse, and then automatically release it through the image trigger.

Seven, summary

With this one-two punch, Robben can finally start to develop. We’ll see how Robben develops from singleton applications to clusters to microservices.

If you think it’s helpful, please give it a thumbs up. Have a problem pat brick [email protected]