service phone
400-123-4657
400-123-4657
点击量：642 时间：2023-12-01
本文将以原理+实战的方式，首先对“微服务”相关的观点举行知识点扫盲，然后开始手把手教你搭建这一整套的微服务系统。这套微服务框架醒目啥？这套系统搭建完之后，那可就厉害了：微服务架构你的整个应用法式将会被拆分成一个个功效独立的子系统，独立运行，系统与系统之间通过RPC接口通信。这样这些系统之间的耦合度大大降低，你的系统将很是容易扩展，团队协作效率提升了N个档次。
这种架构通过眼下盛行的SpringBoot和阿里巴巴吊炸天的Dubbo框架来实现。容器化部署你的各个微服务将接纳现在处于浪潮之巅的Docker来实现容器化部署，制止一切因情况引起的种种问题，让你们团队的全部精神集中在业务开发上。
自动化构建项目被微服务化后，各个服务之间的关系错中庞大，打包构建的事情量相当恐怖。不外没关系，本文将借助Jenkins，资助你一键自动化部署，今后你便离别了加班。知识点扫盲篇敲黑板啦！条记赶快记起来，课后我要检查的！检查不及格的同学放学后留下来！知识点1：微服务微服务一次近几年相当火，成为法式猿饭前便后装逼热门词汇，你差池它有所相识如何在法式猿装逼圈子里混？下面我用最为通俗易懂的语言先容它。
要讲清楚微服务，我先要从一个系统架构的演进历程讲起。单机结构我想大家最最最熟悉的就是单机结构，一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。
那么，单机结构有啥缺点呢？我想缺点是显而易见的，单机的处置惩罚能力究竟是有限的，当你的业务增长到一定水平的时候，单机的硬件资源将无法满足你的业务需求。此时便泛起了集群模式，往下接着看。集群结构集群模式在法式猿界由种种装逼解释，有的让你基础无法明白，其实就是一个很简朴的玩意儿，且听我一一道来。单机处置惩罚到达瓶颈的时候，你就把单机复制几份，这样就组成了一个“集群”。
集群中每台服务器就叫做这个集群的一个“节点”，所有节点组成了一个集群。每个节点都提供相同的服务，那么这样系统的处置惩罚能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。但问题是用户的请求究竟由哪个节点来处置惩罚呢？最好能够让此时现在负载较小的节点来处置惩罚，这样使得每个节点的压力都比力平均。
要实现这个功效，就需要在所有节点之前增加一个“调理者”的角色，用户的所有请求都先交给它，然后它凭据当前所有节点的负载情况，决议将这个请求交给哪个节点处置惩罚。这个“调理者”有个牛逼了名字——负载平衡服务器。
集群结构的利益就是系统扩展很是容易。如果随着你们系统业务的生长，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。
可是，当你的业务生长到一定水平的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不显着了。这时候，你就需要使用微服务结构了。
微服务结构先来对前面的知识点做个总结。从单机结构到集群结构，你的代码基本无需要作任何修改，你要做的仅仅是多部署几台服务器，没太服务器上运行相同的代码就行了。可是，当你要从集群结构演进到微服务结构的时候，之前的那套代码就需要发生较大的改动了。
所以对于新系统我们建议，系统设计之初就接纳微服务架构，这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话，那就得对代码大动干戈了。所以，对于老系统而言，究竟是继续保持集群模式，还是升级成微服务架构，这需要你们的架构师深思熟虑、权衡投入产出比。OK，下面开始先容所谓的微服务。
微服务就是将一个完整的系统，根据业务功效，拆分成一个个独立的子系统，在微服务结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。举个例子，假设需要开发一个在线商城。
根据微服务的思想，我们需要根据功效模块拆分成多个独立的服务，如：用户服务、产物服务、订单服务、后台治理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。
如果服务之间有依赖关系，那么通过RPC方式挪用。这样的利益有许多：系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的界限很是明确，排错也变得相当容易，开发效率大大提升。系统之间的耦合度降低，从而系统更易于扩展。
我们可以针对性地扩展某些服务。假设这个商城要搞一次大促，下单量可能会大大提升，因此我们可以针对性地提升订单系统、产物系统的节点数量，而对于后台治理系统、数据分析系统而言，节点数量维持原有水平即可。服务的复用性更高。
好比，当我们将用户系统作为单独的服务后，该公司所有的产物都可以使用该系统作为用户系统，无需重复开发。那么问题来了，当接纳微服务结构后，一个完整的系统可能有许多独立的子系统组成，当业务量徐徐生长起来之后，而这些子系统之间的关系将错综庞大，而且为了能够针对性地增加某些服务的处置惩罚能力，某些服务的背后可能是一个集群模式，由多个节点组成，这无疑大大增加了运维的难度。
微服务的想法好是好，但开发、运维的庞大度实在是太高。为相识决这些问题，阿里巴巴的Dubbo就横空出世了。知识点2DubboDubbo是一套微服务系统的协调者，在它这套体系中，一共有三种角色，划分是：服务提供者（下面简称提供者）、服务消费者（下面简称消费者）、注册中心。
你在使用的时候需要将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 建立ProjectNew一个Project选择Spring Initializr设置groupId、artifactId、version
它们之间的挪用由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。
由于所有模块都依赖于Gaoxi-Common-Servie-Facade模块，因此在构建模块时，首先需要编译、打包、安装Gaoxi-Common-Servie-Facade，将它打包进当地堆栈中，这样上层模块才气引用到。当该模块安装完毕后，再构建上层模块。否则在构建上层模块的时候会泛起找不到Gaoxi-Common-Servie-Facade中类库的问题。3.4 在父模块的pom中添加所有子模块公用的依赖
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. 整合Dubbo5.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依赖
接口如下所示：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 StepPre Step会在正式构建前执行，由于所有项目都依赖于Gaoxi-Common-Service—Facade，因此在项目构建前，需要将它安装到当地堆栈，然后才气被当前项目正确依赖。因此，在Pre Step中填写如下信息：Build然后就是正式构建的历程，填写如下信息即可：OK，Gaoxi-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/Deploy+Plugin安装插件在系统治理–>插件治理–>高级上传deploy.hpi举行安装。
在父项目的pom文件中增加远程部署插件：
而差别情况的设置各不相同。如果我们只有一套设置，那么当系统从一个情况迁移到另一个情况的时候，就需要通过修改代码来更换设置，这样无疑增加了事情的庞大度，而且易于堕落。但幸亏Maven提供了profile功效，能资助我们解决这一个问题。父项目的pom中添加profile元素首先，我们需要在总pom的中添加多套情况的信息，如下所示：
下面我以一个例子，带着大家感受下有了这套微服务框架后，我们的开发流程究竟有了哪些改变？下面以开发一个用户登录功效为例，先容下使用本框架之后开发的流程。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.Servicepublic class UserServiceImpl implements UserService { @Autowired private UserDAO userDAO; @Override public UserEntity login(LoginReq loginReq) { // 校验参数 checkParam(loginReq); // 建立用户查询请求 UserQueryReq userQueryReq = buildUserQueryReq(loginReq); // 查询用户 List
若要使用userService中的函数，仅需要在userService上添加@Reference注解，然后就像挪用当地函数一样使用userService即可。Dubbo会帮你找到UserService服务所在的IP和端口号，并发送挪用请求。但这一切对于法式猿来说是完全透明的。
@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); // 登录乐成 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的泛起能让这一切自动化完成。本文转自知乎法式猿柴毛毛，如需转载请标明。
本文来源：开云app全站官网入口-www.vwjan.com
