五分钟阅读阿里巴巴架构师如何使用微服务框架搭建电商平台全过程

关注做者的微信公众号：

“Java架构师学习”

一个只分享Java架构干货的公众号

本文你将学到什么？

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

这套微服务框架能干啥？

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

• 微服务架构 。你的整个应用程序将会被拆分红一个个功能独立的子系统，独立运行，系统与系统之间经过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，最大限度地下降配置复杂度，把大量的精力投入到咱们的业务开发中来。

1. 基于Dubbo的微服务化 。

咱们会使用阿里巴巴的开源框架Dubbo，将咱们的系统拆分红多个独立的微服务，而后用Dubbo来管理全部服务的发布和引用。有了Dubbo以后，调用远程服务就像调用一个本地函数同样简单，Dubbo会帮咱们完成远程调用背后所须要的一切。

1. 基于Docker的容器化部署 。

因为使用了微服务架构后，咱们的系统将会由不少子系统构成。为了达到多个系统之间环境隔离的目的，咱们能够将它们部署在多台服务器上，可这样的成本会比较高，并且每台服务器的性能可能都没有充分利用起来。因此咱们很天然地想到了虚拟机，在同一台服务器上运行多个虚拟机，从而实现环境的隔离，每一个虚拟机上运行独立的服务。然而虚拟机的隔离成本依旧很高，由于它须要占用服务器较多的硬件资源和软件资源。因此，在微服务结构下，要实现服务环境的隔离，Docker是最佳选择。它比虚拟机更加轻量级，占用资源较少，并且可以实现快速部署。

1. 基于Jenkins的自动化构建 。

当咱们采用了微服务架构后，咱们会发现这样一个问题。整个系统由许许多多的服务构成，这些服务都须要运行在单独的容器中，那么每次发布的复杂度将很是高。首先你要搞清楚这些服务之间的依赖关系、启动的前后顺序，而后再将多个子系统挨个编译、打包、发布。这些操做技术难度低，却又容易出错。那么有什么工具可以帮助咱们解决这些问题呢？答案就是——Jenkins。 

它是一款自动化构建的工具，简单的来讲，就是咱们只须要在它的界面上按一个按钮，就能够实现上述一系列复杂的过程。文章中涉及到的微服务、dubbo，等技术均分享在群619881427已录制成视频，可免费下载。若有须要能够加入进来一块儿学习交流

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

请点击此处输入图片描述

• 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>0.0.1-SNAPSHOT</version><packaging>war</packaging>

• 在总pom中指定子模块

modules标签指定了当前模块的子模块是谁，可是仅在父模块的pom文件中指定子模块还不够，还须要在子模块的pom文件中指定父模块是谁。

 

<modules>
<module>Gaoxi-Analysis</module>
<module>Gaoxi-Order</module>
<module>Gaoxi-Product</module>
<module>Gaoxi-User</module>
<module>Gaoxi-Redis</module>
<module>Gaoxi-Controller</module>
<module>Gaoxi-Common-Service-Facade</module></modules>

 

 

• 在子模块中指定父模块

 

<parent>
<groupId>com.gaoxi</groupId>
<artifactId>gaoxi</artifactId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>../pom.xml</relativePath></parent>

 

 

到此为止，模块的依赖关系配置完毕！但要注意模块打包的顺序。因为全部模块都依赖于Gaoxi-Common-Servie-Facade模块，所以在构建模块时，首先须要编译、打包、安装Gaoxi-Common-Servie-Facade，将它打包进本地仓库中，这样上层模块才能引用到。当该模块安装完毕后，再构建上层模块。不然在构建上层模块的时候会出现找不到Gaoxi-Common-Servie-Facade中类库的问题。

3.4 在父模块的pom中添加全部子模块公用的依赖

 

<dependencies>
<!-- Spring Boot -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<!-- Spring MVC -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!-- Spring Boot Test -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<!-- MyBatis -->
<dependency>
<groupId>org.mybatis.spring.boot</groupId>
<artifactId>mybatis-spring-boot-starter</artifactId>
<version>1.3.1</version>
</dependency>
<!-- Mysql -->
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
</dependency>
<!-- Dubbo -->
<dependency>
<groupId>io.dubbo.springboot</groupId>
<artifactId>spring-boot-starter-dubbo</artifactId>
<version>1.0.0</version>
</dependency>
<!-- gaoxi-common-service-facade -->
<dependency>
<groupId>com.gaoxi</groupId>
<artifactId>gaoxi-common-service-facade</artifactId>
<version>0.0.1</version>
</dependency>
<!-- AOP -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-aop</artifactId>
</dependency>
<!-- guava -->
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>23.3-jre</version>
</dependency></dependencies>

 

 

当父模块的pom中配置了公用依赖后，子模块的pom文件将很是简洁，以下所示：

 

<groupId>com.gaoxi</groupId><artifactId>gaoxi-user</artifactId><version>0.0.1-SNAPSHOT</version><packaging>war</packaging><name>gaoxi-user</name><parent>
<groupId>com.gaoxi</groupId>
<artifactId>gaoxi</artifactId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>../pom.xml</relativePath></parent>

 

 

当项目的结构搭建完成以后，接下来你须要配置Docker环境，并将这些项目打包进容器中，验证下是否能正常启动。

4. 建立Docker容器

4.1 安装Docker

在使用Docker以前，你固然先要安装Docker，安装过程较为简单，基本上就是傻瓜式操做，这里就不做过多介绍了，你能够在Docker的官网下载相应系统的安装包。

https://www.docker.com/

4.2 获取Tomcat镜像

在微服务架构中，一个完整的系统被拆分红了多个被称为“微服务”的子系统，这些子系统能够独立运行在Web容器中。因此咱们须要为这些系统提供运行的Web容器，这里咱们选择你们较为熟悉的Tomcat。

咱们知道，Tomcat依赖于Java环境，安装Tomcat以前要进行一系列环境的配置：安装Java、配置环境变量、安装Tomcat等等。这些操做仍是有些繁琐的。不过不要紧，当使用了Docker以后，这些过程均可以垂手可得地完成。

咱们只需从Docker Hub上找到Tomcat的镜像资源，而后从上面拉取下来就可使用。你可使用Tomcat官方的镜像，也可使用我发布在Docker Hub上的Tomcat镜像。

注意点：推荐使用个人Tomcat镜像资源chaimm/tomcat，由于这个镜像中除了配置Tomcat的安装环境之外，还有一些本项目中要用到的Jenkins相关的配置。

采用以下命令从Docker Hub上拉取镜像：

docker pull chaimm/tomcat:1.1

简单解释下，docker pull是从从Docker Hub上拉取镜像的命令，后面的chaimm/tomcat是镜像的名称，:1.1是镜像的版本号。目前这个镜像的最新版本号是1.1，推荐你们拉取这个。

4.3 建立Tomcat容器

这里再简单介绍下“镜像”和“容器”的关系。

“镜像”就比如是面向对象中的“类”，“容器”就比如“类”建立的“对象”。在面向对象中，“类”定义了各类属性，“类”能够实例化出多个“对象”；而在Docker中，“镜像”定义了各类配置信息，它能够实例化出多个“容器”。“容器”就是一台能够运行的“虚拟机”。

接下来咱们须要为全部的微服务建立各自的容器：

• gaoxi-user
• gaoxi-product
• gaoxi-order
• gaoxi-analysis
• gaoxi-controller
• gaoxi-redis

以建立gaoxi-user容器为例，采用以下命令建立容器：

docker run --name gaoxi-user-1 -p 8082:8080 -v /usr/web/gaoxi-log:/opt/tomcat/gaoxi-log chaimm/tomcat:1.1

• --name：指定容器的名字
• -p：指定容器的端口映射

-p 8082:8080 表示将容器的8080端口映射到宿主机的8082端口上

• -v：指定容器数据卷的映射 

xxx:yyy 表示将容器yyy目录映射到宿主机的xxx目录上，从而访问宿主机的xxx目录就至关于访问容器的yyy目录。

• chaimm/tomcat:1.1：表示容器所对应的镜像。

这条命令执行成功后，你就能够经过 你的IP:8082 访问到gaoxi-user-1容器的tomcat了。若是你看到了那只眼熟了猫，那就说明容器启动成功了！

请点击此处输入图片描述

接下来，你须要按照上面的方法，给剩下几个系统建立好Tomcat容器。

注意点：这里要注意的是，你须要给这些Tomcat容器指定不一样的端口号，防止端口号冲突。固然，在实际开发中，你并不须要将容器的8080端口映射到宿主机上，这里仅仅是为了验证容器是否启动成功才这么作的。文章中涉及到的微服务、dubbo，等技术均分享在群619881427已录制成视频，可免费下载。若有须要能够加入进来一块儿学习交流

5. 整合Dubbo

5.1 建立zookeeper容器

Dubbo一共定义了三种角色，分别是：服务提供者、服务消费者、注册中心。注册中心是服务提供者和服务消费者的桥梁，服务消费者会在初始化的时候将本身的IP和端口号发送给注册中心，而服务消费者经过注册中心知道服务提供者的IP和端口号。

在Dubbo中，注册中心有多种选择，Dubbo最为推荐的即为ZooKeeper，本文采用ZooKeepeer做为Dubbo的注册中心。

建立ZooKeeper容器也较为简单，你们能够直接使用我建立的ZooKeeper镜像，经过以下命令便可下载镜像：

docker pull chaimm/zookeeper-dubbo:1.0

该镜像中不只运行了一个zookeeper，还运行了一个拥有dubbo-admin项目的tomcat。dubbo-admin是Dubbo的一个可视化管理工具，能够查看服务的发布和引用的状况。

使用以下命令启动容器：

docker run --name zookeeper-debug -p 2182:2181 -p 10000:8080 chaimm/zookeeper-dubbo:1.0

• -p 2182:2181：将容器的2181端口映射到宿主机的2182端口上，该端口是ZooKeeper的端口号。
• -p 10000:8080：将容器的8080端口映射到宿主机的10000端口上，该端口是Dubbo-Admin所在Tomcat的端口号。

启动成功后，你就能够经过 你的IP:10000/dubbo-admin-2.8.4/ 访问到Dubbo-Admin，以下图所示：

请点击此处输入图片描述

5.2 父pom文件中引入dubbo依赖

 

<!-- Spring Boot Dubbo 依赖 --><dependency>
<groupId>io.dubbo.springboot</groupId>
<artifactId>spring-boot-starter-dubbo</artifactId>
<version>1.0.0</version></dependency>

 

 

5.3 发布服务

假设，咱们须要将Gaoxi-User项目中的UserService发布成一项RPC服务，供其余系统远程调用，那么咱们究竟该如何借助Dubbo来实现这一功能呢？

• 在Gaoxi-Common-Service-Facade中定义UserService的接口

因为服务的发布和引用都依赖于接口，但服务的发布方和引用方在微服务架构中每每不在同一个系统中，因此须要将须要发布和引用的接口放在公共类库中，从而双方都可以引用。接口以下所示：

 

public interface UserService {    public UserEntity login(LoginReq loginReq);
}

 

 

• 在Gaoxi-User中定义接口的实现

在实现类上须要加上Dubbo的@Service注解，从而Dubbo会在项目启动的时候扫描到该注解，将它发布成一项RPC服务。

 

@Service(version = "1.0.0")public class UserServiceImpl implements UserService {    @Override
public UserEntity login(LoginReq loginReq) {        // 具体的实现代码
}
}

 

 

• 在Gaoxi-User的application.properties中配置服务提供者的信息

spring.dubbo.application.name=user-provider # 本服务的名称spring.dubbo.registry.address=zookeeper://IP:2182 # ZooKeeper所在服务器的IP和端口号spring.dubbo.protocol.name=dubbo # RPC通讯所采用的协议spring.dubbo.protocol.port=20883 # 本服务对外暴露的端口号spring.dubbo.scan=com.gaoxi.user.service # 服务实现类所在的路径

按照上面配置完成后，当Gaoxi-User系统初始化的时候，就会扫描spring.dubbo.scan所指定的路径下的@Service注解，该注解标识了须要发布成RPC服务的类。Dubbo会将这些类的接口信息+本服务器的IP+spring.dubbo.protocol.port所指定的端口号发送给Zookeeper，Zookeeper会将这些信息存储起来。

这就是服务发布的过程，下面来看如何引用一项RPC服务。

5.4 引用服务

假设，Gaoxi-Controller须要调用Gaoxi-User 提供的登陆功能，此时它就须要引用UserService这项远程服务。下面来介绍服务引用的方法。

• 声明须要引用的服务

引用服务很是简单，你只须要在引用的类中声明一项服务，而后用@Reference标识，以下所示：

 

@RestControllerpublic class UserControllerImpl implements UserController {    @Reference(version = "1.0.0")    private UserService userService;
@Override
public Result login(LoginReq loginReq, HttpServletResponse httpRsp) {        // 登陆鉴权
UserEntity userEntity = userService.login(loginReq);
}
}

 

 

• 在Gaoxi-Controller的application.properties中配置服务消费者的信息

spring.dubbo.application.name=controller-consumer # 本服务的名称spring.dubbo.registry.address=zookeeper://IP:2182 # zookeeper所在服务器的IP和端口号spring.dubbo.scan=com.gaoxi # 引用服务的路径

上述操做完成后，当Gaoxi-Controller初始化的时候，Dubbo就会扫描spring.dubbo.scan所指定的路径，并找到全部被@Reference修饰的成员变量；而后向Zookeeper请求该服务所在的IP和端口号。当调用userService.login()的时候，Dubbo就会向Gaoxi-User发起请求，完成调用的过程。这个调用过程是一次RPC调用，但做为程序猿来讲，这和调用一个本地函数没有任何区别，远程调用的一切都由Dubbo来帮你完成。这就是Dubbo的做用。

6. 自动化构建

Jenkins是一个自动化构建工具，它能够帮助咱们摆脱繁琐的部署过程，咱们只须要在一开始配置好构建策略，之后部署只须要一键完成。

6.1 建立Jenkins容器

Jenkins采用Java开发，也须要Java环境，但咱们使用Docker后，一切都采用容器化部署，Jenkins也不例外。

• 拉取镜像

这里咱们使用Jenkins官方提供的镜像，你们只需执行以下命令拉取便可：

docker pull docker.io/jenkins/jenkins

• 启动容器

因为Jenkins运行在Tomcat容器中，所以咱们将容器的8080端口映射到宿主机的10080端口上：

docker run --name jenkins -p 10080:8080 docker.io/jenkins/jenkins

• 初始化Jenkins 

而后你须要访问 IP:10080 Jenkins会带着你进行一系列的初始化设置，你只要跟着它一步步走就好了，比较傻瓜式。

6.2 在Jenkins中建立项目

接下来咱们要作的是，在Jenkins中为每个服务建立一个项目，每一个项目中定义了构建的具体流程。因为咱们将整个项目分红了6个微服务，因此咱们须要在Jenkins中分别为这6个服务建立项目。那句开始吧～

点击页面左侧的“新建”按钮： 

请点击此处输入图片描述

• 输入项目名称gaoxi-user，选择“构建一个Maven项目”，而后点击“OK”： 

请点击此处输入图片描述

• 配置Git仓库

选择Git，而后输入本项目Git仓库的URL，并在Credentials中输入Git的用户名和密码，以下图所示： 

请点击此处输入图片描述

• 构建触发器 

选择第一项，以下图所示： 

请点击此处输入图片描述

• Pre Step 

Pre Step会在正式构建前执行，因为全部项目都依赖于Gaoxi-Common-Service—Facade，所以在项目构建前，须要将它安装到本地仓库，而后才能被当前项目正确依赖。 

• Build 

而后就是正式构建的过程，填写以下信息便可： 

所以，在Pre Step中填写以下信息： 

请点击此处输入图片描述

请点击此处输入图片描述

OK，Gaoxi-User的构建过程就配置完成了。当咱们点击“当即构建”按钮时，Jenkins首先会从咱们指定的Git仓库中拉取代码，而后执行Pre Step中的Maven命令，将Gaoxi-Common-Serivce-Facade打包安装到本地仓库。而后执行Build过程，将Gaoxi-User进行编译打包。

6.3 远程部署

• 下载插件

首先你须要下载Deploy Plugin

• 安装插件 

在系统管理–>插件管理–>高级上传deploy.hpi进行安装。

• 在父项目的pom文件中增长远程部署插件：

 

<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.6.5</version>
<configuration>
<container>
<!-- 指明使用的tomcat服务器版本 -->
<containerId>tomcat8x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<cargo.remote.username>Tomcat的用户名</cargo.remote.username>
<cargo.remote.password>Tomcat的密码</cargo.remote.password>
</configuration>
</configuration>
<executions>
<execution>
<phase>deploy</phase>
<goals>
<goal>redeploy</goal>
</goals>
</execution>
</executions></plugin>

 

 

• 为Tomcat设置用户名和密码 

修改gaoxi-user容器中tomcat的tomcat-users.xml文件，增长tomcat的manager用户 

请点击此处输入图片描述

注意：若是你使用了chaimm/tomcat镜像，那么其中Tomcat配置都已经完成，默认用户名：admin、默认密码：jishimen2019。强烈建议修改用户名和密码。

• 修改Jenkins中gaoxi-user的配置

在“构建后操做”中增长以下配置：

请点击此处输入图片描述

- WAR/EAR files：表示你须要发布的war包- Containers：配置目标Tomcat的用户名和密码

7. Maven的profile功能

在实际开发中，咱们的系统每每有多套环境构成，如：开发环境、测试环境、预发环境、生产环境。而不一样环境的配置各不相同。若是咱们只有一套配置，那么当系统从一个环境迁移到另外一个环境的时候，就须要经过修改代码来更换配置，这样无疑增长了工做的复杂度，并且易于出错。但好在Maven提供了profile功能，能帮助咱们解决这一个问题。

• 父项目的pom中添加profile元素

首先，咱们须要在总pom的中添加多套环境的信息，以下所示：

 

<profiles>
<profile>
<id>dev</id>
<properties>
<profileActive>dev</profileActive>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<id>test</id>
<properties>
<profileActive>test</profileActive>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<profileActive>prod</profileActive>
</properties>
</profile></profiles>

 

 

• 父项目的pom中添加resource元素

resource标识了不一样环境下须要打包哪些配置文件。

 

<resources>
   <resource>
       <!-- 标识配置文件所在的目录 -->
       <directory>src/main/resources</directory>
       <filtering>true</filtering>
       <!-- 构建时将这些配置文件全都排除掉 -->
       <excludes>
           <exclude>application.properties</exclude>
           <exclude>application-dev.properties</exclude>
           <exclude>application-test.properties</exclude>
           <exclude>application-prod.properties</exclude>
       </excludes>
   </resource>
   <resource>
       <directory>src/main/resources</directory>
       <filtering>true</filtering>
       <!-- 标识构建时所须要的配置文件 -->
       <includes>
           <include>application.properties</include>
           <!-- ${profileActive}这个值会在maven构建时传入 -->
           <include>application-${profileActive}.properties</include>
       </includes>
   </resource></resources>

 

 

• 父项目的pom中添加插件maven-resources-plugin

该插件用来在Maven构建时参数替换

 

<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.0.2</version>
<configuration>
<delimiters>
<delimiter>@</delimiter>
</delimiters>
<useDefaultDelimiters>false</useDefaultDelimiters>
</configuration></plugin>

 

 

• 在子项目中建立配置

分别为dev环境、test环境、prod环境建立三套配置，application.proerpties中存放公用的配置。

请点击此处输入图片描述

• 在application.properties中添加spring.profiles.active=@profileActive@

spring.profiles.active=@profileActive@

 

• 修改Jenkins的配置 

在全部Jenkins中全部Maven命令的末尾添加 -P test ，在打包的时候-P后面的参数将会做为@profileActive@的值传入系统中，从而根据该值打包相应的application-{profileActive}.properties文件。文章中涉及到的微服务、dubbo，等技术均分享在群619881427已录制成视频，可免费下载。若有须要能够加入进来一块儿学习交流

8. 开发流程

到此为止，全部准备工做都已经完成，接下来就能够进入代码开发阶段。下面我以一个例子，带着你们感觉下有了这套微服务框架后，咱们的开发流程究竟有了哪些改变？下面以开发一个用户登陆功能为例，介绍下使用本框架以后开发的流程。

8.1 开发目标

• 在Gaoxi-User系统中实现登陆的业务逻辑，并发布成RPC服务
• 在Gaoxi-Controller中远程调用登陆服务，并向前端提供登陆的REST接口

请点击此处输入图片描述

8.2 开发登陆服务

首先须要在Gaoxi-Common-Service-Facade中建立UserService接口，并在其中声明登陆的抽象函数。

 

public interface UserService {    public UserEntity login(LoginReq loginReq);
}

 

 

PS：为何要将UserService放在Gaoxi-Common-Service-Facade中？

而后在Gaoxi-User中开发UserService的实现——UserServiceImpl。

UserServiceImpl上必需要加上Dubbo的@Service注解，从而告诉Dubbo，在本项目初始化的时候须要将这个类发布成一项服务，供其余系统调用。

 

@Service(version = "1.0.0")@org.springframework.stereotype.Servicepublic class UserServiceImpl implements UserService {    @Autowired
private UserDAO userDAO;    @Override
public UserEntity login(LoginReq loginReq) {        // 校验参数
checkParam(loginReq);        // 建立用户查询请求
UserQueryReq userQueryReq = buildUserQueryReq(loginReq);        // 查询用户
List<UserEntity> userEntityList = userDAO.findUsers(userQueryReq);        // 查询失败
if (CollectionUtils.isEmpty(userEntityList)) {            throw new CommonBizException(ExpCodeEnum.LOGIN_FAIL);
}        // 查询成功
return userEntityList.get(0);
}
}

 

 

8.3 引用登陆服务

当UserService开发完毕后，接下来Gaoxi-Controller须要引用该服务，并向前端提供一个登陆的REST接口。

若要使用userService中的函数，仅须要在userService上添加@Reference注解，而后就像调用本地函数同样使用userService便可。Dubbo会帮你找到UserService服务所在的IP和端口号，并发送调用请求。但这一切对于程序猿来讲是彻底透明的。

 

@RestControllerpublic class UserControllerImpl implements UserController {    @Reference(version = "1.0.0")
private UserService userService;
/**
    * 登陆
    * @param loginReq 登陆请求参数
    * @param httpRsp HTTP响应
    * @return 登陆是否成功
    */
@GetMapping("/login")
@Override
public Result login(LoginReq loginReq, HttpServletResponse httpRsp) {        // 登陆鉴权
UserEntity userEntity = userService.login(loginReq);        // 登陆成功
doLoginSuccess(userEntity, httpRsp);        return Result.newSuccessResult();
}
}

 

 

8.4 自动构建服务

上面的代码完成后，接下来你须要将代码提交至你的Git仓库。接下来就是自动化部署的过程了。

你须要进入Jenkins，因为刚才修改了Gaoxi-User和Gaoxi-Controller的代码，所以你须要分别构建这两个项目。

接下来Jenkins会自动从你的Git仓库中拉取最新的代码，而后依次执行Pre Step、Build、构建后操做的过程。因为咱们在Pre Step中设置了编译Gaoxi-Common-Service-Facade，所以Jenkins首先会将其安装到本地仓库；而后再执行Build过程，构建Gaoxi-User，并将其打包成war包。最后将执行“构建后操做”，将war包发布到相应的tomcat容器中。

至此，整个发布流程完毕！

8.5 查看服务的状态

当Jenkins构建完成后，咱们能够登陆Dubbo-Admin查看服务发布和引用的状态。

当咱们搜索UserService服务后，能够看到，该服务的提供者已经成功发布了服务：

请点击此处输入图片描述

点击“消费者”咱们能够看到，该服务已经被controller-consumer成功订阅：

请点击此处输入图片描述

9. 总结

总结一下，这套框架有以下优点：

1. 微服务架构 

咱们借助于SpringBoot和Dubbo实现了微服务架构。微服务架构的理念就是将一个本来庞大、复杂的系统，按照业务功能拆分红一个个具备独立功能、能够独立运行的子系统，系统之间如有依赖，则经过RPC接口通讯。从而最大限度地下降了系统之间的耦合度，从而更加易于扩展、更加易于维护。

1. 容器化部署 

咱们借助于Docker实现了容器化部署。容器可以帮助咱们屏蔽不一样环境下的配置问题，使得咱们只须要有一个Dockerfile文件，就能够到处运行。和虚拟机同样，Docker也拥有环境隔离的能力，但比虚拟机更加轻量级，因为每一个容器仅仅是一条进程，所以它能够达到秒级的启动速度。

1. 自动化构建 

咱们借助于Jenkins实现了全部项目的自动化构建与部署。咱们只须要点击“当即构建”这个按钮，Jenkins就能够帮助咱们梳理好错综复杂的项目依赖关系，准确无误地完成构建，并将war包发送到相应的web容器中。在启动的过程当中，Dubbo会扫描当前项目所须要发布和引用的服务，将所须要发布的服务发布到ZooKeeper上，并向ZooKeeper订阅所需的服务。 

有了Jenkins以后，这一切都是自动化完成。也许你并无太强烈地感觉到Jenkins所带来的便利。可是你想想，对于一个具备错综复杂的依赖关系的微服务系统而言，若是每一个服务的构建都须要你手动完成的话，你很快就会崩溃，你大把的时间将会投入在无聊但又容易出错的服务构建上。而Jenkins的出现能让这一切自动化完成。