科技化疯狂的复苏

科技化疯狂的复苏 查看完整档案

填写现居城市  |  填写毕业院校  |  填写所在公司/组织填写个人主网站
编辑
_ | |__ _ _ __ _ | '_ \| | | |/ _` | | |_) | |_| | (_| | |_.__/ \__,_|\__, | |___/ 该用户太懒什么也没留下

个人动态

科技化疯狂的复苏 发布了文章 · 5月29日

mysql学习(一)

1 启动mysql

通过服务开启:

启动 service mysqld start

停止 service mysqld stop

重启 service mysqld restart

2 连接数据库

mysql -u 用户名 -p密码

注意:-u和用户名之间可以用空格隔开,但是-p和密码必须连在一起。

-p与后面的字符串隔开,那么这个字符串就是数据库的名字了。

3 对库的操作

1 创建库

CREATE DATABASE [IF NOT EXISTS] 库名 CHARSET utf8

[]中的内容是可以选择的

IF NOT EXIST表示如果这个表不存在就建立这个表。

2 查看库

SHOW DATABASES

SHOW CREATE DATABASE 库名 查看建库时的详细信息

3 修改库

ALTER DATABASE [IF NOT EXISTS] 库名 [DEFAULT] CHARACTER SET 字符名

4 删除库

DROP DATABASE [IF EXISTS] 库名

4 对表的操作

1 增加表

CREATE TABLE 表名( 列名 类型 )

2 修改表

①:修改表名

RENAME TABLE old_table_name TO new_table_name;

旧表( old_table_name)必须存在,而新表( new_table_name)一定不存在。如果新表 new_table_name 确实存在,该语句将失败。

②:在表中添加列

ALTER TABLE 表名 ADD ( 列名 数据类型 );

③:modify

ALTER TABLE 表名 MODIFY 列名 数据类型 ;


modify不用来字段重命名,只能修改字段类型和约束;
change用来字段重命名,不能修改字段类型和约束;

3:查看表

SHOW TABLES; 查看该库中所有表

SHOW CREATE TALBE 表名; 查看表的创建细节

DESC 表名; 查看表结构

4 删除表

ALTER TABLE表名 DROP(列名);

删除表中某一列。

4:对表中数据的操作

1 增加

INSERT INTO 表名 ( 列名..) VALUES (数据..);

2 修改

UPDATE 表名 SET 列名=值.. , 列名=值 WHERE=条件 ;

原始数据

修改后

3 删除

①:清楚某张表中所有字段

DELETE FROM 表名 WHERE=条件;

②:删除某一张表

TRUNCATE TABLE

drop ,truncate ,delete区别

1、drop (删除表):删除内容和定义,释放空间。简单来说就是把整个表去掉.以后要新增数据是不可能的,除非新增一个表。drop语句将删除表的结构被依赖的约束(constrain),触发器(trigger)索引(index);依赖于该表的存储过程/函数将被保留,但其状态会变为:invalid。

2、truncate (清空表中的数据):删除内容、释放空间但不删除定义(保留表的数据结构)。与drop不同的是,只是清空表数据而已。
注意:truncate 不能删除行数据,要删就要把表清空。

3、delete (删除表中的数据):delete 语句用于删除表中的行。delete语句执行删除的过程是每次从表中删除一行,并且同时将该行的删除操作作为事务记录在日志中保存以便进行进行回滚操作。

truncate与不带where的delete :只删除数据,而不删除表的结构(定义)

4 查看

SELECT 列名
FROM 表名,
WHERE 条件,
GROUP BY 列名,
HAVING BY,
ORDER BY 列名

查询还在学习。。。

查看原文

赞 0 收藏 0 评论 0

科技化疯狂的复苏 发布了文章 · 5月9日

HTML基础学习

1:基本概念

1:元素

①:HTML文档是由各种HTML元素组成的, 这些元素都是通过尖括号“<>”组成的标签形式来表现的。

实际上,HTML文档内容就是标签、元素和属性。如

  • html元素(HTML文档根元素)
  • head(HTML头部)元素
  • body(HTML主体)元素
  • title(HTML标题)元素
  • p(段落)元素等

②:元素也可以分为块元素行元素

块元素在网页中的效果是该元素的内容对于其前后元素的内容都另起一行

行元素在网页中的效果是该元素的内容对于其前后元素的内容都在一行显示

③:常见的行元素和块元素

行元素:spanimginputalabelbuttonselecttextareasupsubabbrsiemustrongsmall

块元素:divph1~h6ullioldddtdltablehrblockquoteaddresspremenu

### 2:标签
HTML标签是由一对尖括号<>及标签名组成的。

标签分为起始标签结束标签两种,两者的标签名称是相同的,只是结束标签多了一个斜杠“/”。

例如:
标签

### 3:元素属性

HTML的元素属性提供了对HTML元素的描述和控制信息,也就是各个标签所具有的属性

一个标签可以有多个属性。

最为常见的属性包括:idclassnamestyletypevalue

不同的标签还百有各自的专属属性,比如表格元素所专用的 colspan,rowspan

4:HTML页面基本结构

5:常用标签介绍

常用标签介绍

脑图的连接

链接:https://pan.baidu.com/s/1jbHQ...
提取码:i7tn

暂时就写了这些,等后续我会继续添加的!

PSG21

查看原文

赞 0 收藏 0 评论 0

科技化疯狂的复苏 发布了文章 · 5月2日

遇见的一些error

谨以此文章,记录我在改bug时掉的头发
以前的没想过要记录下来,记录bug,从今天开始!

1:java.sql.SQLSyntaxErrorException

错误详情:
Caused by: java.sql.SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'load, staff_id, staff_name, brand' at line 1

原因
数据库字段存在关键字,表中的字段不可与SQL中的关键字相同(这次我遇到的问题:load是sql中的关键字)
数据库字段不匹配,语法错误 等引起的错误
只需检查数据库和sql语句即可解决!

2:java.lang.NullPointerException

错误详情

ERROR 13948 --- [nio-9090-exec-8] o.a.c.c.C.[.[.[/].
[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.NullPointerException] with root cause

java.lang.NullPointerException: null
    at mjtechzm.zmwlbackground.controller.VehicleController.listAll(VehicleController.java:82) ~[classes/:na]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_131]

场景描述
我是在用dubbo做微服务开发的过程中遇见的。通过dubbo-admin发现该服务没有消费者,和别的服务比对了一下,发现是包导错了。

@Reference
应该导入
import com.alibaba.dubbo.config.annotation.Reference;
而我却导入了
import jdk.nashorn.internal.ir.annotations.Reference;

原因
空指针异常,包导错了!!!
好气啊,包导错了!!!
强调一下:一定要配置好日志啊,不然都不知道在哪儿找错误!
所以,把包导对就可以了。

3:org.springframework.dao.DuplicateKeyException:

错误详情

java.lang.RuntimeException: org.springframework.dao.DuplicateKeyException: 
### Error updating database.  Cause: java.sql.SQLIntegrityConstraintViolationException: Duplicate entry '2' for key 'PRIMARY'
### The error may exist in com/zimin/wl/mapper/TOrderMapper.xml
### The error may involve com.zimin.wl.mapper.TOrderMapper.insertSelective-Inline
### The error occurred while setting parameters

场景描述
前端点击 修改按钮,按关键字修改时,出现了错误

原因
唯一性字段重复插入,比如主键重复了
检查一下就好。
我是把修改的方法中的id没有传回去,导致出错。

查看原文

赞 0 收藏 0 评论 1

科技化疯狂的复苏 赞了回答 · 4月4日

我想问一下,在思否发表的文章,有没有后台数据可以看到自己发表过的文章的一个月的总阅读量是多少?

https://segmentfault.com/mp/c...

上面这个地址,这块正在进行新的迭代优化,所以入口藏的比较深,在个人设置、专栏设置可以看到

关注 2 回答 2

科技化疯狂的复苏 发布了文章 · 4月4日

Git基本操作

一:基操

1:创建版本库

  • 在项目文件夹内,执行
git init

image.png

2:提交文件

  • 新建文件后,查看文件内容指令

    git status
  • 将文件添加到暂存区

    git add 文件名

image.png

  • 提交文件到本地仓库

    git commit
  • 编写注释,完成提交

image.png

这里的操作和Linux系统中编写操作一致。
进入编辑页面后,按 i 开始编写内容。
写完注释内容后,先按Esc,在按 :wq 保存内容退出。

image.png

  • 也可以直接带注释提交

    git commit -m 注释内容

image.png

3:查看文件提交历史

  • 查看历史记录

    git log 文件名

image.png

  • 简易信息查看

    git log --pretty=oneline 文件名

image.png

4:回退历史

  • 回退一次提交(回到前一次)

    git reset --hard HEAD^
  • 回退n次提交

    git reset --hard HEAD~n

5:版本穿越

  • 查看历史记录的版本号

    git reflog 文件名

image.png

  • 穿越~(不要误会,hhh)

    git reset --hard 版本号

image.png

6:还原文件

git checkout --文件名

7:删除文件

  • 先删除文件
  • 在git add,再提交

8:工作区+暂存区+本地库

image.png

二:分支

1:创建分支

git branch 分支名
git branch -v 查看分支

image.png

2:切换分支

git checkout 分支名
image.png

创建,切换一步完成

git checkout -b 分支名

image.png

3:合并分支

  • 先切换到主干
git checkout master
  • 合并
git merge 分支名

image.png

4:删除分支

  • 先切换到主干
  • 删除分支
git branch -D 分支名

5:冲突

  • 概念:冲突一般是指同一个文件同一位置的代码,在两种版本合并时版本管理软件无法判断应该保留那个版本,因此会提示该文件发送冲突,需要手工判断解决冲突
  • 合并时冲突:程序合并时冲突会提示CONFLICT关键字,命令行后缀会进入MERGING状态,表示此时是解决冲突的状态。

image.png

  • 解决冲突
通过git diff 可以找到发生冲突的文件以及冲突的内容

image.png

然后修改冲突的文件的内容,修改后,再次 git add 文件名 和 git commit 提交,后缀MERGING消失,冲突解决完成

image.png

查看原文

赞 0 收藏 0 评论 0

科技化疯狂的复苏 发布了文章 · 4月4日

Git简介及安装

一:Git简介

1:什么是Git?

一种先进的分布式版本控制系统

2:版本管理系统能干什么?

-冲突解决
-权限管理
-代码备份
-协同开发
-版本还原
-历史追查
-版本记录
-分支管理
-代码审查

二:安装

1:准备工作

1:下载命令行工具:Git for Windows
地址:https://gitforwindows.org/

image.png

2:操作系统中可视化工具TortoiseGit
地址:https://tortoisegit.org/

image.png

3:GitHub网站
http://www.github.xom

2:安装

点Next,遇见Adjusting your PATH environment,如下图

image.png

选择第一个。

image.png

image.png

image.png

image.png

image.png

image.png

image.png

这个是尚硅谷的Git课程中的
借花献佛~

下面这个是Git的操作
https://segmentfault.com/a/11...

查看原文

赞 0 收藏 0 评论 0

科技化疯狂的复苏 发布了文章 · 4月1日

nginx的安装及遇见的问题解决

一:准备工作

0:打开虚拟机。

使用远程连接工具连接Linux虚拟机。远程连接工具可以使用xshell。

1:到nginx官网下载软件

http://nginx.org/

image.png
image.png

二:开始安装

1:上传nginx安装包

将下载好的nginx的安装包上传到/usr/src下(我选择放在这),上传工具可以用xftp。

2:联网下载pcre依赖

wget http://downloads.sourceforge.net/project/pcre/pcre/8.37/pcre-8.37.tar.gz

下载完成后
image.png

解压缩文件

tar -zxvf pcre-8.37.tar.gz

进入解压后的文件,执行./configure命令 。
这时出现错误
image.png

执行

yum install -y gcc gcc-c++

指令即可。

继续./configure指令
等待完成。
然后在pcre目录下执行

make && make install

执行完毕显示
image.png

可以输入指令

pcre-config --version

查看安装的pcre的版本

3:安装openssl,zlib,gcc依赖

执行

yum -y install make zlib zlib-devel gcc-c++ libtool openssl openssl-devel

4:安装nginx

解压安装包
进入加压后的文件夹,执行

./configure

然后执行

make && make install

结果如下
image.png

5:进入以下目录

cd /usr/local/nginx/sbin/   

使用以下指令启动nginx

./nginx

可以通过查看进程查看nginx是否启动成功

ps -ef|grep nginx

image.png

6:验证

在浏览器中输入

http://虚拟机ip地址

可以看到
image.png

到这里nginx就安装成功了!

三:nginx的几个常用命令

进入nginx的安装目录 cd /usr/local/nginx/sbin

1:查看nginx的版本号
./nginx -v
2:启动nginx
./nginx
3:停止nginx
./nginx -s stop
4:重新加载nginx
./nginx -s reload

觉得有用点个赞在走呀~

查看原文

赞 0 收藏 0 评论 0

科技化疯狂的复苏 收藏了文章 · 3月30日

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

本文你将学到什么?

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

这套微服务框架能干啥?

这套系统搭建完之后,那可就厉害了:

  • 微服务架构:你的整个应用程序将会被拆分成一个个功能独立的子系统,独立运行,系统与系统之间通过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在构建成功后给你发一封邮件。这样你连“立即构建”的按钮也不需要按,就能全自动地完成这一切构建过程。

实战动手篇

学习目标

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

基于SpringBoot快速开发 。

我们将选择目前热度很高的SpringBoot,最大限度地降低配置复杂度,把大量的精力投入到我们的业务开发中来。

基于Dubbo的微服务化 。

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

基于Docker的容器化部署 。

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

基于Jenkins的自动化构建 。

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

它是一款自动化构建的工具,简单的来说,就是我们只需要在它的界面上按一个按钮,就可以实现上述一系列复杂的过程。

在此我向大家推荐一个架构学习交流群。交流学习群号:575745314 里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

项目背景介绍

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

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

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

创建项目的组织结构

在动手之前,我先来说一说这一步的目标:

  • 创建一个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系统中完成了。

clipboard.png

开始动手

3.1 创建Project

  • New一个Project
  • 选择Spring Initializr

clipboard.png

  • 设置groupId、artifactId、version

clipboard.png

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

3.2 创建Module

  • 在Project上New Module

clipboard.png

  • 和刚才一样,选择Spring Initializr,设置groupId、artifactId、version
  • 依次创建好所有的Module,如下图所示:

clipboard.png

3.3 构建模块的依赖关系

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

clipboard.png

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。

clipboard.png

  • 将其他模块的打包方式设为war

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

clipboard.png

  • 在总pom中指定子模块

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

clipboard.png

  • 在子模块中指定父模块

clipboard.png

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

3.4 在父模块的pom中添加所有子模块公用的依赖

clipboard.png

当父模块的pom中配置了公用依赖后,子模块的pom文件将非常简洁,如下所示:

clipboard.png

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

创建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上拉取镜像:

clipboard.png

简单解释下,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容器为例,采用如下命令创建容器:

clipboard.png

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

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

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

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

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

这条命令执行成功后,你就可以通过 你的IP:8082 访问到gaoxi-user-1容器的tomcat了。如果你看到了那只眼熟了猫,那就说明容器启动成功了!

clipboard.png

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

注意点:这里要注意的是,你需要给这些Tomcat容器指定不同的端口号,防止端口号冲突。当然,在实际开发中,你并不需要将容器的8080端口映射到宿主机上,这里仅仅是为了验证容器是否启动成功才这么做的。

在此我向大家推荐一个架构学习交流群。交流学习群号:575745314 里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

整合Dubbo

5.1 创建zookeeper容器

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

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

创建ZooKeeper容器也较为简单,大家可以直接使用我创建的ZooKeeper镜像,通过如下命令即可下载镜像:

clipboard.png

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

使用如下命令启动容器:

clipboard.png

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

启动成功后,你就可以通过 你的IP:10000/dubbo-admin-2.8.4/ 访问到Dubbo-Admin,如下图所示:

clipboard.png

5.2 父pom文件中引入dubbo依赖

clipboard.png

5.3 发布服务

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

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

由于服务的发布和引用都依赖于接口,但服务的发布方和引用方在微服务架构中往往不在同一个系统中,所以需要将需要发布和引用的接口放在公共类库中,从而双方都能够引用。接口如下所示:

clipboard.png

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

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

clipboard.png

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

clipboard.png

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

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

5.4 引用服务

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

  • 声明需要引用的服务

引用服务非常简单,你只需要在引用的类中声明一项服务,然后用@Reference标识,如下所示:

clipboard.png

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

clipboard.png

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

自动化构建

Jenkins是一个自动化构建工具,它可以帮助我们摆脱繁琐的部署过程,我们只需要在一开始配置好构建策略,以后部署只需要一键完成。

6.1 创建Jenkins容器

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

  • 拉取镜像

这里我们使用Jenkins官方提供的镜像,大家只需执行如下命令拉取即可:

clipboard.png

  • 启动容器

由于Jenkins运行在Tomcat容器中,因此我们将容器的8080端口映射到宿主机的10080端口上:

clipboard.png

  • 初始化Jenkins

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

6.2 在Jenkins中创建项目

接下来我们要做的是,在Jenkins中为每一个服务创建一个项目,每个项目中定义了构建的具体流程。由于我们将整个项目分成了6个微服务,所以我们需要在Jenkins中分别为这6个服务创建项目。那句开始吧~

clipboard.png

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

  • 输入项目名称gaoxi-user,选择“构建一个Maven项目”,然后点击“OK”:

clipboard.png

  • 配置Git仓库

选择Git,然后输入本项目Git仓库的URL,并在Credentials中输入Git的用户名和密码,如下图所示:

clipboard.png

  • 构建触发器

选择第一项,如下图所示:

clipboard.png

  • Pre Step

Pre Step会在正式构建前执行,由于所有项目都依赖于Gaoxi-Common-Service—Facade,因此在项目构建前,需要将它安装到本地仓库,然后才能被当前项目正确依赖。

  • Build

然后就是正式构建的过程,填写如下信息即可:

因此,在Pre Step中填写如下信息:

clipboard.png

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用户

clipboard.png

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

  • 修改Jenkins中gaoxi-user的配置

在“构建后操作”中增加如下配置:

clipboard.png

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中存放公用的配置。

clipboard.png

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

clipboard.png

  • 修改Jenkins的配置

在所有Jenkins中所有Maven命令的末尾添加 -P test ,在打包的时候-P后面的参数将会作为@profileActive@的值传入系统中,从而根据该值打包相应的application-{profileActive}.properties文件。

在此我向大家推荐一个架构学习交流群。交流学习群号:575745314 里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

开发流程

到此为止,所有准备工作都已经完成,接下来就可以进入代码开发阶段。下面我以一个例子,带着大家感受下有了这套微服务框架后,我们的开发流程究竟有了哪些改变?下面以开发一个用户登录功能为例,介绍下使用本框架之后开发的流程。

8.1 开发目标

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

clipboard.png

8.2 开发登录服务

首先需要在Gaoxi-Common-Service-Facade中创建UserService接口,并在其中声明登录的抽象函数。

clipboard.png

PS:为什么要将UserService放在Gaoxi-Common-Service-Facade中?

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

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

clipboard.png

8.3 引用登录服务

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

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

clipboard.png

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服务后,可以看到,该服务的提供者已经成功发布了服务:

clipboard.png

点击“消费者”我们可以看到,该服务已经被controller-consumer成功订阅:

clipboard.png

总结

总结一下,这套框架有如下优势:

微服务架构

我们借助于SpringBoot和Dubbo实现了微服务架构。微服务架构的理念就是将一个原本庞大、复杂的系统,按照业务功能拆分成一个个具有独立功能、可以独立运行的子系统,系统之间若有依赖,则通过RPC接口通信。从而最大限度地降低了系统之间的耦合度,从而更加易于扩展、更加易于维护。

容器化部署

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

自动化构建

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

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

查看原文

科技化疯狂的复苏 赞了文章 · 3月30日

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

本文你将学到什么?

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

这套微服务框架能干啥?

这套系统搭建完之后,那可就厉害了:

  • 微服务架构:你的整个应用程序将会被拆分成一个个功能独立的子系统,独立运行,系统与系统之间通过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在构建成功后给你发一封邮件。这样你连“立即构建”的按钮也不需要按,就能全自动地完成这一切构建过程。

实战动手篇

学习目标

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

基于SpringBoot快速开发 。

我们将选择目前热度很高的SpringBoot,最大限度地降低配置复杂度,把大量的精力投入到我们的业务开发中来。

基于Dubbo的微服务化 。

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

基于Docker的容器化部署 。

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

基于Jenkins的自动化构建 。

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

它是一款自动化构建的工具,简单的来说,就是我们只需要在它的界面上按一个按钮,就可以实现上述一系列复杂的过程。

在此我向大家推荐一个架构学习交流群。交流学习群号:575745314 里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

项目背景介绍

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

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

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

创建项目的组织结构

在动手之前,我先来说一说这一步的目标:

  • 创建一个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系统中完成了。

clipboard.png

开始动手

3.1 创建Project

  • New一个Project
  • 选择Spring Initializr

clipboard.png

  • 设置groupId、artifactId、version

clipboard.png

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

3.2 创建Module

  • 在Project上New Module

clipboard.png

  • 和刚才一样,选择Spring Initializr,设置groupId、artifactId、version
  • 依次创建好所有的Module,如下图所示:

clipboard.png

3.3 构建模块的依赖关系

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

clipboard.png

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。

clipboard.png

  • 将其他模块的打包方式设为war

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

clipboard.png

  • 在总pom中指定子模块

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

clipboard.png

  • 在子模块中指定父模块

clipboard.png

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

3.4 在父模块的pom中添加所有子模块公用的依赖

clipboard.png

当父模块的pom中配置了公用依赖后,子模块的pom文件将非常简洁,如下所示:

clipboard.png

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

创建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上拉取镜像:

clipboard.png

简单解释下,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容器为例,采用如下命令创建容器:

clipboard.png

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

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

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

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

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

这条命令执行成功后,你就可以通过 你的IP:8082 访问到gaoxi-user-1容器的tomcat了。如果你看到了那只眼熟了猫,那就说明容器启动成功了!

clipboard.png

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

注意点:这里要注意的是,你需要给这些Tomcat容器指定不同的端口号,防止端口号冲突。当然,在实际开发中,你并不需要将容器的8080端口映射到宿主机上,这里仅仅是为了验证容器是否启动成功才这么做的。

在此我向大家推荐一个架构学习交流群。交流学习群号:575745314 里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

整合Dubbo

5.1 创建zookeeper容器

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

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

创建ZooKeeper容器也较为简单,大家可以直接使用我创建的ZooKeeper镜像,通过如下命令即可下载镜像:

clipboard.png

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

使用如下命令启动容器:

clipboard.png

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

启动成功后,你就可以通过 你的IP:10000/dubbo-admin-2.8.4/ 访问到Dubbo-Admin,如下图所示:

clipboard.png

5.2 父pom文件中引入dubbo依赖

clipboard.png

5.3 发布服务

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

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

由于服务的发布和引用都依赖于接口,但服务的发布方和引用方在微服务架构中往往不在同一个系统中,所以需要将需要发布和引用的接口放在公共类库中,从而双方都能够引用。接口如下所示:

clipboard.png

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

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

clipboard.png

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

clipboard.png

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

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

5.4 引用服务

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

  • 声明需要引用的服务

引用服务非常简单,你只需要在引用的类中声明一项服务,然后用@Reference标识,如下所示:

clipboard.png

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

clipboard.png

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

自动化构建

Jenkins是一个自动化构建工具,它可以帮助我们摆脱繁琐的部署过程,我们只需要在一开始配置好构建策略,以后部署只需要一键完成。

6.1 创建Jenkins容器

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

  • 拉取镜像

这里我们使用Jenkins官方提供的镜像,大家只需执行如下命令拉取即可:

clipboard.png

  • 启动容器

由于Jenkins运行在Tomcat容器中,因此我们将容器的8080端口映射到宿主机的10080端口上:

clipboard.png

  • 初始化Jenkins

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

6.2 在Jenkins中创建项目

接下来我们要做的是,在Jenkins中为每一个服务创建一个项目,每个项目中定义了构建的具体流程。由于我们将整个项目分成了6个微服务,所以我们需要在Jenkins中分别为这6个服务创建项目。那句开始吧~

clipboard.png

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

  • 输入项目名称gaoxi-user,选择“构建一个Maven项目”,然后点击“OK”:

clipboard.png

  • 配置Git仓库

选择Git,然后输入本项目Git仓库的URL,并在Credentials中输入Git的用户名和密码,如下图所示:

clipboard.png

  • 构建触发器

选择第一项,如下图所示:

clipboard.png

  • Pre Step

Pre Step会在正式构建前执行,由于所有项目都依赖于Gaoxi-Common-Service—Facade,因此在项目构建前,需要将它安装到本地仓库,然后才能被当前项目正确依赖。

  • Build

然后就是正式构建的过程,填写如下信息即可:

因此,在Pre Step中填写如下信息:

clipboard.png

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用户

clipboard.png

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

  • 修改Jenkins中gaoxi-user的配置

在“构建后操作”中增加如下配置:

clipboard.png

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中存放公用的配置。

clipboard.png

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

clipboard.png

  • 修改Jenkins的配置

在所有Jenkins中所有Maven命令的末尾添加 -P test ,在打包的时候-P后面的参数将会作为@profileActive@的值传入系统中,从而根据该值打包相应的application-{profileActive}.properties文件。

在此我向大家推荐一个架构学习交流群。交流学习群号:575745314 里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

开发流程

到此为止,所有准备工作都已经完成,接下来就可以进入代码开发阶段。下面我以一个例子,带着大家感受下有了这套微服务框架后,我们的开发流程究竟有了哪些改变?下面以开发一个用户登录功能为例,介绍下使用本框架之后开发的流程。

8.1 开发目标

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

clipboard.png

8.2 开发登录服务

首先需要在Gaoxi-Common-Service-Facade中创建UserService接口,并在其中声明登录的抽象函数。

clipboard.png

PS:为什么要将UserService放在Gaoxi-Common-Service-Facade中?

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

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

clipboard.png

8.3 引用登录服务

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

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

clipboard.png

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服务后,可以看到,该服务的提供者已经成功发布了服务:

clipboard.png

点击“消费者”我们可以看到,该服务已经被controller-consumer成功订阅:

clipboard.png

总结

总结一下,这套框架有如下优势:

微服务架构

我们借助于SpringBoot和Dubbo实现了微服务架构。微服务架构的理念就是将一个原本庞大、复杂的系统,按照业务功能拆分成一个个具有独立功能、可以独立运行的子系统,系统之间若有依赖,则通过RPC接口通信。从而最大限度地降低了系统之间的耦合度,从而更加易于扩展、更加易于维护。

容器化部署

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

自动化构建

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

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

查看原文

赞 12 收藏 15 评论 1

科技化疯狂的复苏 关注了专栏 · 3月30日

终身学习者

我要先坚持分享20年,大家来一起见证吧。

关注 40744

认证与成就

  • 获得 0 次点赞
  • 获得 2 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 2 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 3月30日
个人主页被 92 人浏览