0基础教你搭建一套可自动化构建的微服务框架(SpringBoot+Dubbo+Docker+Jenkins)

本文你将学到什么？

本文将以原理+实战的方式，首先对“微服务”相关的概念进行知识点扫盲，然后开始手把手教你搭建这一整套的微服务系统。

项目完整源码下载

https://github.com/bz51/SpringBoot-Dubbo-Docker-Jenkins

这套微服务框架能干啥？

这套系统搭建完之后，那可就厉害了：

• 微服务架构
  你的整个应用程序将会被拆分成一个个功能独立的子系统，独立运行，系统与系统之间通过RPC接口通信。这样这些系统之间的耦合度大大降低，你的系统将非常容易扩展，团队协作效率提升了N个档次。这种架构通过眼下流行的SpringBoot和阿里巴巴吊炸天的Dubbo框架来实现。

• 容器化部署
  你的各个微服务将采用目前处于浪潮之巅的Docker来实现容器化部署，避免一切因环境引起的各种问题，让你们团队的全部精力集中在业务开发上。

• 自动化构建
  项目被微服务化后，各个服务之间的关系错中复杂，打包构建的工作量相当可怕。不过没关系，本文将借助Jenkins，帮助你一键自动化部署，从此你便告别了加班。

---

知识点扫盲篇

咳咳，敲黑板啦！笔记赶紧记起来，课后我要检查的！检查不合格的同学放学后留下来！

知识点1：微服务

微服务一次近几年相当火，成为程序猿饭前便后装逼热门词汇，你不对它有所了解如何在程序猿装逼圈子里混？下面我用最为通俗易懂的语言介绍它。

要讲清楚微服务，我先要从一个系统架构的演进过程讲起。

单机结构

我想大家最最最熟悉的就是单机结构，一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。
那么，单机结构有啥缺点呢？我想缺点是显而易见的，单机的处理能力毕竟是有限的，当你的业务增长到一定程度的时候，单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式，往下接着看。

集群结构

集群模式在程序猿界由各种装逼解释，有的让你根本无法理解，其实就是一个很简单的玩意儿，且听我一一道来。

单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。

但问题是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。

集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。但是，当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了。这时候，你就需要使用微服务结构了。

微服务结构

先来对前面的知识点做个总结。
从单机结构到集群结构，你的代码基本无需要作任何修改，你要做的仅仅是多部署几台服务器，没太服务器上运行相同的代码就行了。但是，当你要从集群结构演进到微服务结构的时候，之前的那套代码就需要发生较大的改动了。所以对于新系统我们建议，系统设计之初就采用微服务架构，这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话，那就得对代码大动干戈了。所以，对于老系统而言，究竟是继续保持集群模式，还是升级成微服务架构，这需要你们的架构师深思熟虑、权衡投入产出比。

OK，下面开始介绍所谓的微服务。
微服务就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在微服务结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。

举个例子，假设需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。如果服务之间有依赖关系，那么通过RPC方式调用。

这样的好处有很多：

1. 系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。
2. 系统之间的耦合度降低，从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促，下单量可能会大大提升，因此我们可以针对性地提升订单系统、产品系统的节点数量，而对于后台管理系统、数据分析系统而言，节点数量维持原有水平即可。
3. 服务的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。

那么问题来了，当采用微服务结构后，一个完整的系统可能有很多独立的子系统组成，当业务量渐渐发展起来之后，而这些子系统之间的关系将错综复杂，而且为了能够针对性地增加某些服务的处理能力，某些服务的背后可能是一个集群模式，由多个节点构成，这无疑大大增加了运维的难度。微服务的想法好是好，但开发、运维的复杂度实在是太高。为了解决这些问题，阿里巴巴的Dubbo就横空出世了。

知识点2：Dubbo

Dubbo是一套微服务系统的协调者，在它这套体系中，一共有三种角色，分别是：服务提供者（下面简称提供者）、服务消费者（下面简称消费者）、注册中心。

你在使用的时候需要将Dubbo的jar包引入到你的项目中，也就是每个服务都要引入Dubbo的jar包。然后当这些服务初始化的时候，Dubbo就会将当前系统需要发布的服务、以及当前系统的IP和端口号发送给注册中心，注册中心便会将其记录下来。这就是服务发布的过程。与此同时，也是在系统初始化的时候，Dubbo还会扫描一下当前系统所需要引用的服务，然后向注册中心请求这些服务所在的IP和端口号。接下来系统就可以正常运行了。当系统A需要调用系统B的服务的时候，A就会与B建立起一条RPC信道，然后再调用B系统上相应的服务。

这，就是Dubbo的作用。

知识点3：容器化部署

当我们使用了微服务架构后，我们将一个原本完整的系统，按照业务逻辑拆分成一个个可独立运行的子系统。为了降低系统间的耦合度，我们希望这些子系统能够运行在独立的环境中，这些环境之间能够相互隔离。

在Docker出现之前，若使用虚拟机来实现运行环境的相互隔离的话成本较高，虚拟机会消耗较多的计算机硬件/软件资源。Docker不仅能够实现运行环境的隔离，而且能极大程度的节约计算机资源，它成为一种轻量级的“虚拟机”。

知识点4：自动化构建

当我们使用微服务架构后，随着业务的逐渐发展，系统之间的依赖关系会日益复杂，而且各个模块的构建顺序都有所讲究。对于一个小型系统来说，也许只有几个模块，那么你每次采用人肉构建的方式也许并不感觉麻烦。但随着系统业务的发展，你的系统之间的依赖关系日益复杂，子系统也逐渐增多，每次构建一下你都要非常小心谨慎，稍有不慎整个服务都无法正常启动。而且这些构建的工作很low，但却需要消耗大量的精力，这无疑降低了开发的效率。不过没关系，Jenkins就是来帮助你解决这个问题的。

我们只需在Jenkins中配置好代码仓库、各个模块的构建顺序和构建命令，在以后的构建中，只需要点击“立即构建”按钮，Jenkins就会自动到你的代码仓库中拉取最新的代码，然后根据你事先配置的构建命令进行构建，最后发布到指定的容器中运行。你也可以让Jenkins定时检查代码仓库版本的变化，一旦发现变动就自动地开始构建过程，并且让Jenkins在构建成功后给你发一封邮件。这样你连“立即构建”的按钮也不需要按，就能全自动地完成这一切构建过程。

---

实战动手篇

1. 学习目标

接下来我会带着大家，以一个在线商城为例，搭建一套能够自动化部署的微服务框架。这个框架能做如下几件事情：

1. 基于SpringBoot快速开发
   我们将选择目前热度很高的SpringBoot，最大限度地降低配置复杂度，把大量的精力投入到我们的业务开发中来。
2. 基于Dubbo的微服务化
   我们会使用阿里巴巴的开源框架Dubbo，将我们的系统拆分成多个独立的微服务，然后用Dubbo来管理所有服务的发布和引用。有了Dubbo之后，调用远程服务就像调用一个本地函数一样简单，Dubbo会帮我们完成远程调用背后所需要的一切。
3. 基于Docker的容器化部署
   由于使用了微服务架构后，我们的系统将会由很多子系统构成。为了达到多个系统之间环境隔离的目的，我们可以将它们部署在多台服务器上，可这样的成本会比较高，而且每台服务器的性能可能都没有充分利用起来。所以我们很自然地想到了虚拟机，在同一台服务器上运行多个虚拟机，从而实现环境的隔离，每个虚拟机上运行独立的服务。然而虚拟机的隔离成本依旧很高，因为它需要占用服务器较多的硬件资源和软件资源。所以，在微服务结构下，要实现服务环境的隔离，Docker是最佳选择。它比虚拟机更加轻量级，占用资源较少，而且能够实现快速部署。
4. 基于Jenkins的自动化构建
   当我们采用了微服务架构后，我们会发现这样一个问题。整个系统由许许多多的服务构成，这些服务都需要运行在单独的容器中，那么每次发布的复杂度将非常高。首先你要搞清楚这些服务之间的依赖关系、启动的先后顺序，然后再将多个子系统挨个编译、打包、发布。这些操作技术难度低，却又容易出错。那么有什么工具能够帮助我们解决这些问题呢？答案就是——Jenkins。
   它是一款自动化构建的工具，简单的来说，就是我们只需要在它的界面上按一个按钮，就可以实现上述一系列复杂的过程。

2. 项目背景介绍

本文我以一个大家都非常熟悉的在线商城作为例子，一步步教大家如何搭建微服务框架，它有如下功能：

• 产品管理
  产品的增删改查。
• 订单管理
  订单的增删改查、购物车功能。
• 用户管理
  用户的登录、注册、权限管理、收货地址等等。
• 数据分析
  提供对本系统数据分析的功能。

注意：本文的IDE使用的是intelliJ IDEA，推荐大家也用这个，用了都说好，用了你就会爱上它。

3. 创建项目的组织结构

在动手之前，我先来说一说这一步的目标：

• 创建一个Maven Project，命名为“Gaoxi”
  这个Project由多个Module构成，每个Module对应着“微服务”的一个子系统，可独立运行，是一个独立的项目。
  这也是目前主流的项目组织形式，即多模块项目。
• 在Gaoxi这个项目下创建各个子模块，每个自模块都是一个独立的SpringBoot项目：
  
  • Gaoxi-User
    用户服务
  • Gaoxi-Order
    订单服务
  • Gaoxi-Product
    产品服务
  • Gaoxi-Analysis
    数据分析服务
  • Gaoxi-Controller
    本系统的控制层，和以往三层结构中的Controller层的作用一样，都是用作请求调度，只不过在微服务架构中，我们将它抽象成一个单独的系统，可以独立运行。
  • Gaoxi-Common-Service-Facade
    它处于本系统的最底层，被所有模块依赖，一些公用的类库都放在这里。
  • Gaoxi-Redis
    我们将Redis封装成一个单独的服务，运行在独立的容器中，当哪一个模块需要使用Redis的时候，仅需要引入该服务即可，就免去了各种繁琐的、重复的配置。而这些配置均在Gaoxi-Redis系统中完成了。

下面开始动手。

3.1 创建Project

• New一个Project
  

• 选择Spring Initializr
  

• 设置groupId、artifactId、version

<groupId>com.gaoxi</groupId>
<artifactId>gaoxi</artifactId>
<version>0.0.1-SNAPSHOT</version>

• Project创建完毕！接下来在Project下面创建Module

3.2 创建Module

• 在Project上New Module
  

• 和刚才一样，选择Spring Initializr，设置groupId、artifactId、version

• 依次创建好所有的Module，如下图所示：
  

3.3 构建模块的依赖关系

目前为止，模块之间没有任何联系，下面我们要通过pom文件来指定它们之间的依赖关系，依赖关系如下图所示：

Gaoxi-User、Gaoxi-Analysis、Gaoxi-Product、Gaoxi-Order这四个系统相当于以往三层结构的Service层，提供系统的业务逻辑，只不过在微服务结构中，Service层的各个模块都被抽象成一个个单独的子系统，它们提供RPC接口供上面的Gaoxi-Controller调用。它们之间的调用由Dubbo来完成，所以它们的pom文件中并不需要作任何配置。而这些模块和Gaoxi-Common-Service-Facade之间是本地调用，因此需要将Gaoxi-Common-Service-Facade打成jar包，并让这些模块依赖这个jar，因此就需要在所有模块的pom中配置和Gaoxi-Common-Service-Facade的依赖关系。

此外，为了简化各个模块的配置，我们将所有模块的通用依赖放在Project的pom文件中，然后让所有模块作为Project的子模块。这样子模块就可以从父模块中继承所有的依赖，而不需要自己再配置了。

下面开始动手：

• 首先将Common-Service-Facade的打包方式设成jar
  当打包这个模块的时候，Maven会将它打包成jar，并安装在本地仓库中。这样其他模块打包的时候就可以引用这个jar。

<groupId>com.gaoxi</groupId>
<artifactId>gaoxi-common-service-facade</artifactId>
<version>0.0.1</version>
<packaging>jar</packaging>

• 将其他模块的打包方式设为war
  除了Gaoxi-Common-Service-Facade外，其他模块都是一个个可独立运行的子系统，需要在web容器中运行，所以我们需要将这些模块的打包方式设成war

<groupId>com.gaoxi</groupId>
<artifactId>gaoxi-user</artifactId>
<version><