马克杯在线设计网站,北京专业网站建设公司排名,wordpress收录前端页面插件,建设部网站建造师公示本文你将学到什么#xff1f; 本文将以原理实战的方式#xff0c;首先对“微服务”相关的概念进行知识点扫盲#xff0c;然后开始手把手教你搭建这一整套的微服务系统。 项目完整源码下载 https://github.com/bz51/SpringBoot-Dubbo-Docker-Jenkins 这套微服务框架能干啥 本文将以原理实战的方式首先对“微服务”相关的概念进行知识点扫盲然后开始手把手教你搭建这一整套的微服务系统。 项目完整源码下载 https://github.com/bz51/SpringBoot-Dubbo-Docker-Jenkins 这套微服务框架能干啥 这套系统搭建完之后那可就厉害了 微服务架构 你的整个应用程序将会被拆分成一个个功能独立的子系统独立运行系统与系统之间通过RPC接口通信。这样这些系统之间的耦合度大大降低你的系统将非常容易扩展团队协作效率提升了N个档次。这种架构通过眼下流行的SpringBoot和阿里巴巴吊炸天的Dubbo框架来实现。 容器化部署 你的各个微服务将采用目前处于浪潮之巅的Docker来实现容器化部署避免一切因环境引起的各种问题让你们团队的全部精力集中在业务开发上。 自动化构建 项目被微服务化后各个服务之间的关系错中复杂打包构建的工作量相当可怕。不过没关系本文将借助Jenkins帮助你一键自动化部署从此你便告别了加班。 知识点扫盲篇 咳咳敲黑板啦笔记赶紧记起来课后我要检查的检查不合格的同学放学后留下来 知识点1微服务 微服务一次近几年相当火成为程序猿饭前便后装逼热门词汇你不对它有所了解如何在程序猿装逼圈子里混下面我用最为通俗易懂的语言介绍它。 要讲清楚微服务我先要从一个系统架构的演进过程讲起。 单机结构 我想大家最最最熟悉的就是单机结构一个系统业务量很小的时候所有的代码都放在一个项目中就好了然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。 那么单机结构有啥缺点呢我想缺点是显而易见的单机的处理能力毕竟是有限的当你的业务增长到一定程度的时候单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式往下接着看。 集群结构 集群模式在程序猿界由各种装逼解释有的让你根本无法理解其实就是一个很简单的玩意儿且听我一一道来。 单机处理到达瓶颈的时候你就把单机复制几份这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”所有节点构成了一个集群。每个节点都提供相同的服务那么这样系统的处理能力就相当于提升了好几倍有几个节点就相当于提升了这么多倍。 但问题是用户的请求究竟由哪个节点来处理呢最好能够让此时此刻负载较小的节点来处理这样使得每个节点的压力都比较平均。要实现这个功能就需要在所有节点之前增加一个“调度者”的角色用户的所有请求都先交给它然后它根据当前所有节点的负载情况决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。 集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展当前的系统又支撑不住了那么给这个集群再增加节点就行了。但是当你的业务发展到一定程度的时候你会发现一个问题——无论怎么增加节点貌似整个集群性能的提升效果并不明显了。这时候你就需要使用微服务结构了。 微服务结构 先来对前面的知识点做个总结。 从单机结构到集群结构你的代码基本无需要作任何修改你要做的仅仅是多部署几台服务器没太服务器上运行相同的代码就行了。但是当你要从集群结构演进到微服务结构的时候之前的那套代码就需要发生较大的改动了。所以对于新系统我们建议系统设计之初就采用微服务架构这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话那就得对代码大动干戈了。所以对于老系统而言究竟是继续保持集群模式还是升级成微服务架构这需要你们的架构师深思熟虑、权衡投入产出比。 OK下面开始介绍所谓的微服务。 微服务就是将一个完整的系统按照业务功能拆分成一个个独立的子系统在微服务结构中每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中它们之间通过RPC方式通信。 举个例子假设需要开发一个在线商城。按照微服务的思想我们需要按照功能模块拆分成多个独立的服务如用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目可以独立运行。如果服务之间有依赖关系那么通过RPC方式调用。 这样的好处有很多 系统之间的耦合度大大降低可以独立开发、独立部署、独立测试系统与系统之间的边界非常明确排错也变得相当容易开发效率大大提升。系统之间的耦合度降低从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促下单量可能会大大提升因此我们可以针对性地提升订单系统、产品系统的节点数量而对于后台管理系统、数据分析系统而言节点数量维持原有水平即可。服务的复用性更高。比如当我们将用户系统作为单独的服务后该公司所有的产品都可以使用该系统作为用户系统无需重复开发。那么问题来了当采用微服务结构后一个完整的系统可能有很多独立的子系统组成当业务量渐渐发展起来之后而这些子系统之间的关系将错综复杂而且为了能够针对性地增加某些服务的处理能力某些服务的背后可能是一个集群模式由多个节点构成这无疑大大增加了运维的难度。微服务的想法好是好但开发、运维的复杂度实在是太高。为了解决这些问题阿里巴巴的Dubbo就横空出世了。 知识点2Dubbo 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. 学习目标 接下来我会带着大家以一个在线商城为例搭建一套能够自动化部署的微服务框架。这个框架能做如下几件事情 基于SpringBoot快速开发 我们将选择目前热度很高的SpringBoot最大限度地降低配置复杂度把大量的精力投入到我们的业务开发中来。基于Dubbo的微服务化 我们会使用阿里巴巴的开源框架Dubbo将我们的系统拆分成多个独立的微服务然后用Dubbo来管理所有服务的发布和引用。有了Dubbo之后调用远程服务就像调用一个本地函数一样简单Dubbo会帮我们完成远程调用背后所需要的一切。基于Docker的容器化部署 由于使用了微服务架构后我们的系统将会由很多子系统构成。为了达到多个系统之间环境隔离的目的我们可以将它们部署在多台服务器上可这样的成本会比较高而且每台服务器的性能可能都没有充分利用起来。所以我们很自然地想到了虚拟机在同一台服务器上运行多个虚拟机从而实现环境的隔离每个虚拟机上运行独立的服务。然而虚拟机的隔离成本依旧很高因为它需要占用服务器较多的硬件资源和软件资源。所以在微服务结构下要实现服务环境的隔离Docker是最佳选择。它比虚拟机更加轻量级占用资源较少而且能够实现快速部署。基于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 groupIdcom.gaoxi/groupId
artifactIdgaoxi/artifactId
version0.0.1-SNAPSHOT/version
复制代码Project创建完毕接下来在Project下面创建Module3.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。groupIdcom.gaoxi/groupId
artifactIdgaoxi-common-service-facade/artifactId
version0.0.1/version
packagingjar/packaging
复制代码将其他模块的打包方式设为war 除了Gaoxi-Common-Service-Facade外其他模块都是一个个可独立运行的子系统需要在web容器中运行所以我们需要将这些模块的打包方式设成wargroupIdcom.gaoxi/groupId
artifactIdgaoxi-user/artifactId
version0.0.1-SNAPSHOT/version
packagingwar/packaging
复制代码在总pom中指定子模块 modules标签指定了当前模块的子模块是谁但是仅在父模块的pom文件中指定子模块还不够还需要在子模块的pom文件中指定父模块是谁。modulesmoduleGaoxi-Analysis/modulemoduleGaoxi-Order/modulemoduleGaoxi-Product/modulemoduleGaoxi-User/modulemoduleGaoxi-Redis/modulemoduleGaoxi-Controller/modulemoduleGaoxi-Common-Service-Facade/module
/modules
复制代码在子模块中指定父模块parentgroupIdcom.gaoxi/groupIdartifactIdgaoxi/artifactIdversion0.0.1-SNAPSHOT/versionrelativePath../pom.xml/relativePath
/parent
复制代码 到此为止模块的依赖关系配置完毕但要注意模块打包的顺序。由于所有模块都依赖于Gaoxi-Common-Servie-Facade模块因此在构建模块时首先需要编译、打包、安装Gaoxi-Common-Servie-Facade将它打包进本地仓库中这样上层模块才能引用到。当该模块安装完毕后再构建上层模块。否则在构建上层模块的时候会出现找不到Gaoxi-Common-Servie-Facade中类库的问题。 3.4 在父模块的pom中添加所有子模块公用的依赖 dependencies!-- Spring Boot --dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter/artifactId/dependency!-- Spring MVC --dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId/dependency!-- Spring Boot Test --dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-test/artifactIdscopetest/scope/dependency!-- MyBatis --dependencygroupIdorg.mybatis.spring.boot/groupIdartifactIdmybatis-spring-boot-starter/artifactIdversion1.3.1/version/dependency!-- Mysql --dependencygroupIdmysql/groupIdartifactIdmysql-connector-java/artifactIdscoperuntime/scope/dependency!-- Dubbo --dependencygroupIdio.dubbo.springboot/groupIdartifactIdspring-boot-starter-dubbo/artifactIdversion1.0.0/version/dependency!-- gaoxi-common-service-facade --dependencygroupIdcom.gaoxi/groupIdartifactIdgaoxi-common-service-facade/artifactIdversion0.0.1/version/dependency!-- AOP --dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-aop/artifactId/dependency!-- guava --dependencygroupIdcom.google.guava/groupIdartifactIdguava/artifactIdversion23.3-jre/version/dependency
/dependencies
复制代码当父模块的pom中配置了公用依赖后子模块的pom文件将非常简洁如下所示 groupIdcom.gaoxi/groupId
artifactIdgaoxi-user/artifactId
version0.0.1-SNAPSHOT/version
packagingwar/packagingnamegaoxi-user/nameparentgroupIdcom.gaoxi/groupIdartifactIdgaoxi/artifactIdversion0.0.1-SNAPSHOT/versionrelativePath../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-usergaoxi-productgaoxi-ordergaoxi-analysisgaoxi-controllergaoxi-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端口映射到宿主机上这里仅仅是为了验证容器是否启动成功才这么做的。 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 依赖 --
dependencygroupIdio.dubbo.springboot/groupIdartifactIdspring-boot-starter-dubbo/artifactIdversion1.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 {Overridepublic UserEntity login(LoginReq loginReq) {// 具体的实现代码}
}
复制代码在Gaoxi-User的application.properties中配置服务提供者的信息spring.dubbo.application.nameuser-provider # 本服务的名称
spring.dubbo.registry.addresszookeeper://IP:2182 # ZooKeeper所在服务器的IP和端口号
spring.dubbo.protocol.namedubbo # RPC通信所采用的协议
spring.dubbo.protocol.port20883 # 本服务对外暴露的端口号
spring.dubbo.scancom.gaoxi.user.service # 服务实现类所在的路径
复制代码 按照上面配置完成后当Gaoxi-User系统初始化的时候就会扫描spring.dubbo.scan所指定的路径下的Service注解该注解标识了需要发布成RPC服务的类。Dubbo会将这些类的接口信息本服务器的IPspring.dubbo.protocol.port所指定的端口号发送给ZookeeperZookeeper会将这些信息存储起来。 这就是服务发布的过程下面来看如何引用一项RPC服务。 5.4 引用服务 假设Gaoxi-Controller需要调用Gaoxi-User 提供的登录功能此时它就需要引用UserService这项远程服务。下面来介绍服务引用的方法。 声明需要引用的服务 引用服务非常简单你只需要在引用的类中声明一项服务然后用Reference标识如下所示RestController
public class UserControllerImpl implements UserController {Reference(version 1.0.0)private UserService userService;Overridepublic Result login(LoginReq loginReq, HttpServletResponse httpRsp) {// 登录鉴权UserEntity userEntity userService.login(loginReq);}
}
复制代码在Gaoxi-Controller的application.properties中配置服务消费者的信息spring.dubbo.application.namecontroller-consumer # 本服务的名称
spring.dubbo.registry.addresszookeeper://IP:2182 # zookeeper所在服务器的IP和端口号
spring.dubbo.scancom.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:10080Jenkins会带着你进行一系列的初始化设置你只要跟着它一步步走就行了比较傻瓜式。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因此在项目构建前需要将它安装到本地仓库然后才能被当前项目正确依赖。 因此在Pre Step中填写如下信息 Build 然后就是正式构建的过程填写如下信息即可 OKGaoxi-User的构建过程就配置完成了。当我们点击“立即构建”按钮时Jenkins首先会从我们指定的Git仓库中拉取代码然后执行Pre Step中的Maven命令将Gaoxi-Common-Serivce-Facade打包安装到本地仓库。然后执行Build过程将Gaoxi-User进行编译打包。 但此时Gaoxi-User仍然只是一个本地war包并没有部署到Tomcat容器中而我们采用了容器化部署后Jenkins服务和Gaoxi-User服务并不在同一个Docker容器中那么究竟该如何才能将Jenkins本地编译好的war包发送到Gaoxi-User容器中呢这就需要使用Jenkins的一个插件——Deploy Plugin。 6.3 远程部署 下载插件 首先你需要下载Deploy Plugin下载地址如下 https://wiki.jenkins.io/display/JENKINS/DeployPlugin 安装插件 在系统管理–插件管理–高级上传deploy.hpi进行安装。 在父项目的pom文件中增加远程部署插件 plugingroupIdorg.codehaus.cargo/groupIdartifactIdcargo-maven2-plugin/artifactIdversion1.6.5/versionconfigurationcontainer!-- 指明使用的tomcat服务器版本 --containerIdtomcat8x/containerIdtyperemote/type/containerconfigurationtyperuntime/typecargo.remote.usernameTomcat的用户名/cargo.remote.usernamecargo.remote.passwordTomcat的密码/cargo.remote.password/configuration/configurationexecutionsexecutionphasedeploy/phasegoalsgoalredeploy/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的中添加多套环境的信息如下所示profilesprofileiddev/idpropertiesprofileActivedev/profileActive/propertiesactivationactiveByDefaulttrue/activeByDefault/activation/profileprofileidtest/idpropertiesprofileActivetest/profileActive/properties/profileprofileidprod/idpropertiesprofileActiveprod/profileActive/properties/profile
/profiles
复制代码父项目的pom中添加resource元素 resource标识了不同环境下需要打包哪些配置文件。resourcesresource!-- 标识配置文件所在的目录 --directorysrc/main/resources/directoryfilteringtrue/filtering!-- 构建时将这些配置文件全都排除掉 --excludesexcludeapplication.properties/excludeexcludeapplication-dev.properties/excludeexcludeapplication-test.properties/excludeexcludeapplication-prod.properties/exclude/excludes/resourceresourcedirectorysrc/main/resources/directoryfilteringtrue/filtering!-- 标识构建时所需要的配置文件 --includesincludeapplication.properties/include!-- ${profileActive}这个值会在maven构建时传入 --includeapplication-${profileActive}.properties/include/includes/resource
/resources
复制代码父项目的pom中添加插件maven-resources-plugin 该插件用来在Maven构建时参数替换pluginartifactIdmaven-resources-plugin/artifactIdversion3.0.2/versionconfigurationdelimitersdelimiter/delimiter/delimitersuseDefaultDelimitersfalse/useDefaultDelimiters/configuration
/plugin
复制代码 在子项目中创建配置 分别为dev环境、test环境、prod环境创建三套配置application.proerpties中存放公用的配置。 在application.properties中添加spring.profiles.activeprofileActive spring.profiles.activeprofileActive
复制代码修改Jenkins的配置 在所有Jenkins中所有Maven命令的末尾添加-P test在打包的时候-P后面的参数将会作为profileActive的值传入系统中从而根据该值打包相应的application-{profileActive}.properties文件。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服务的提供方Gaoxi-Controller是UserService服务的引用方。由于二者并不在同一个系统中所以必须要借助于Dubbo来实现远程方法调用。而Dubbo发布服务和引用服务的时候都是根据服务的接口标识服务的即服务引用方和发布方都需要使用服务的接口因此需要将服务的接口放在所有项目共同依赖的基础模块——Gaoxi-Common-Service-Facade中。 然后在Gaoxi-User中开发UserService的实现——UserServiceImpl。 UserServiceImpl上必须要加上Dubbo的Service注解从而告诉Dubbo在本项目初始化的时候需要将这个类发布成一项服务供其他系统调用。 Service(version 1.0.0)
org.springframework.stereotype.Service
public class UserServiceImpl implements UserService {Autowiredprivate UserDAO userDAO;Overridepublic UserEntity login(LoginReq loginReq) {// 校验参数checkParam(loginReq);// 创建用户查询请求UserQueryReq userQueryReq buildUserQueryReq(loginReq);// 查询用户ListUserEntity 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和端口号并发送调用请求。但这一切对于程序猿来说是完全透明的。 RestController
public class UserControllerImpl implements UserController {Reference(version 1.0.0)private UserService userService;/*** 登录* param loginReq 登录请求参数* param httpRsp HTTP响应* return 登录是否成功*/GetMapping(/login)Overridepublic 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. 总结 总结一下这套框架有如下优势 微服务架构 我们借助于SpringBoot和Dubbo实现了微服务架构。微服务架构的理念就是将一个原本庞大、复杂的系统按照业务功能拆分成一个个具有独立功能、可以独立运行的子系统系统之间若有依赖则通过RPC接口通信。从而最大限度地降低了系统之间的耦合度从而更加易于扩展、更加易于维护。 容器化部署 我们借助于Docker实现了容器化部署。容器能够帮助我们屏蔽不同环境下的配置问题使得我们只需要有一个Dockerfile文件就可以处处运行。和虚拟机一样Docker也拥有环境隔离的能力但比虚拟机更加轻量级由于每个容器仅仅是一条进程因此它可以达到秒级的启动速度。 自动化构建 我们借助于Jenkins实现了所有项目的自动化构建与部署。我们只需要点击“立即构建”这个按钮Jenkins就可以帮助我们梳理好错综复杂的项目依赖关系准确无误地完成构建并将war包发送到相应的web容器中。在启动的过程中Dubbo会扫描当前项目所需要发布和引用的服务将所需要发布的服务发布到ZooKeeper上并向ZooKeeper订阅所需的服务。 有了Jenkins之后这一切都是自动化完成。也许你并没有太强烈地感受到Jenkins所带来的便利。但是你想一想对于一个具有错综复杂的依赖关系的微服务系统而言如果每个服务的构建都需要你手动完成的话你很快就会崩溃你大把的时间将会投入在无聊但又容易出错的服务构建上。而Jenkins的出现能让这一切自动化完成。
