微服务 Spring Cloud Alibaba 项目搭建(一、框架介绍)
主要是为了记录 从0到1 搭建Spring Cloud Alibaba 项目的详细步骤,方便想学习搭建Spring Cloud 项目的小伙伴们提供一个详细的示例,欢迎各位大佬评论,互相学习,共同进步。
gitee地址:
SpringCloud+Docker项目部署经验
1. Linux 服务器安装宝塔面板
2.使用ssh root@ip 的方式远程连接
3.安装Docker ,参考: 中的Docker安装
1.项目中 eureka 配置需加上: prefer-ip-address: true 具体配置列如:
2.其余微服务的yml文件中也需配置:prefer-ip-address: true 具体配置列如:
3.微服务的pom.xml文件,配置打包插件,具体配置列如:
4.编译项目并打包 ,使用idea自带的打包方式 : 右侧Maven按钮 - 项目[root]-双击package -打包成功,获取jar包;
1.在服务器非系统盘符中(如果有)创建对应文件夹,以项目为例如下:
1) mhxs-eureka-server (eureka注册与发现)
2) mhxs-web-comment-api (客户端)
3) mhxs-web-novel-api (客户端)
4) mhxs-web-user-api (客户端)
5) mhxs-gateway (网关zuul,集成了swagger2)
2.上传对应的jar文件到对应对应的文件夹中.
3.在对应文件夹中的分别创建Dockerfile文件,并编辑内容例如:
注1:其中微服务jar包修改了版本(如:xx-1.jar,xxx-2.jar,xxx-3.jar,....),对应文件夹下的同理修改,目的是为了方便后期版本回退.
注2:注意修改对应的jar名称和端口
4.编写创建镜像的脚本文件 : build_images.sh 和 相应jar文件夹一级,具体内容列如:
注:其中modules中的为对应的 jar文件夹名称
5.使用ssh连接到linux服务器,进入到build_image.sh 文件夹下,创建Docker镜像,操作如下:
6.查看镜像
7.在jar包文件夹同一层中创建启动镜像脚本:start_services.sh具体内容例如:
注1: 其中CODE用于检测对应服务是否已经启动成功,需根据具体项目修改.
注2: 启动方式分为全顺序启动和非全顺序启动
8: 查看镜像容器:
9:更新jar:
10.查看日志,有两种方法
1)直接通过宝塔面板可以找到对应日志位置:
2) 使用命令查看
1. SprignCloud之快速搭建一个简单的微服务工程
springcloud 工程是基于 springboot 工程的。所以我们的父工程的pom直接继承spring-boot-starter-parent,让所有的子工程也作为springboot项目。
然后指定spring-cloud的依赖版本统一为Finchley.RELEASE,这样子工程在引入springcloud相关包的时候就不用特意指定版本了。
我们选择 eureka 作为注册中心。
新建一个子工程,指定parent为刚才我们建立的父工程
Eureka 服务端启动器导入
Eureka 服务端 完整pom文件:
application.properties 配置文件
启动类
新建一个子工程 订单服务,实际上是eureka的客户端。
同样指定parent为刚才我们建立的父工程
引入eureka客户端的pom依赖,以及web包,用来与eureka-server端进行通信。
订单服务完整pom文件:
bootstrap.properties配置文件
启动类
新建一个子工程 订单服务,实际上是eureka的客户端。
同样指定parent为刚才我们建立的父工程
引入eureka客户端的pom依赖,以及web包,用来与eureka-server端进行通信。
用户服务完整pom文件:
bootstrap.properties
启动类
先启动注册中心 eureka服务端工程, 然后启动两个eureka客户端:订单服务和用户服务,看看这两个服务是否都注册到注册中心了。
当订单服务和用户服务 启动注册成功时, 会发现eureka服务端 会有 注册服务实例成功的日志。
查看eureka的 监控页面 ,可以看到 服务列表里已经 有 订单服务和用户服务了。
当订单服务 和 用户服务都成功注册 到 注册中心之后,那么 这两个服务 都会定时的从注册中心拉取服务列表, 用于调用。
我们让 订单服务 作为服务提供者,让用户服务调用,测试一下能否调用成功。
模拟 返回某个用户的订单信息
浏览器 调用 用户服务的 /user/orderList接口:
可以看到已经成功通过用户服务的/user/ordeeList接口 调用到了订单服务的/order/list 接口。
SpringCloud入门搭建及服务调用
开发工具:idea 2020.2.3
java:1.8
maven:3.3.9
SpringBoot:2.1.3.RELEASE
SpringCloud:Greenwich.SR5 (版本和SpringBoot必须对应,对应表自行百度)
idea配置我就不细说了
然后next
finish
然后配置pom.xml:
一般在父项目配置
然后配置依赖,这里只是一个springboot项目,所以配一个springboot就行了:
然后配置pom.xml,它们俩都是独立的springboot项目了,这里也可以和父类工程做依赖继承,但是这里就没必要,更凸显服务的独立性:
controller:
power启动类:
UserController.java
在这里调用另一个服务power服务的接口,可以使用reatTeplate来实现,需要配置
reaTeplate配置文件:AppConfig.java
user服务启动类:
user服务的 application.yml
同样可以以相同方式在power服务中调用user的接口
然后在浏览器:
127.0.0.1:6060/power/getPower.do(6060是power服务的端口)
127.0.0.1:7070/user/getUser.do调用自己的接口(7070是user服务的端口)
127.0.0.1:7070/user/getPower.do调用power的接口
至此实现了不同服务之间的调用
「SpringCloud」(三十八)搭建ELK日志采集与分析系统
一套好的日志分析系统可以详细记录系统的运行情况,方便我们定位分析系统性能瓶颈、查找定位系统问题。上一篇说明了日志的多种业务场景以及日志记录的实现方式,那么日志记录下来,相关人员就需要对日志数据进行处理与分析,基于E(ElasticSearch)L(Logstash)K(Kibana)组合的日志分析系统可以说是目前各家公司普遍的首选方案。
作为微服务集群,必须要考虑当微服务访问量暴增时的高并发场景,此时系统的日志数据同样是爆发式增长,我们需要通过消息队列做流量削峰处理,Logstash官方提供Redis、Kafka、RabbitMQ等输入插件。Redis虽然可以用作消息队列,但其各项功能显示不如单一实现的消息队列,所以通常情况下并不使用它的消息队列功能;Kafka的性能要优于RabbitMQ,通常在日志采集,数据采集时使用较多,所以这里我们采用Kafka实现消息队列功能。
ELK日志分析系统中,数据传输、数据保存、数据展示、流量削峰功能都有了,还少一个组件,就是日志数据的采集,虽然log4j2可以将日志数据发送到Kafka,甚至可以将日志直接输入到Logstash,但是基于系统设计解耦的考虑,业务系统运行不会影响到日志分析系统,同时日志分析系统也不会影响到业务系统,所以,业务只需将日志记录下来,然后由日志分析系统去采集分析即可,Filebeat是ELK日志系统中常用的日志采集器,它是 Elastic Stack 的一部分,因此能够与 Logstash、Elasticsearch 和 Kibana 无缝协作。
软件下载:
因经常遇到在内网搭建环境的问题,所以这里习惯使用下载软件包的方式进行安装,虽没有使用Yum、Docker等安装方便,但是可以对软件目录、配置信息等有更深的了解,在后续采用Yum、Docker等方式安装时,也能清楚安装了哪些东西,安装配置的文件是怎样的,即使出现问题,也可以快速的定位解决。
Elastic Stack全家桶下载主页:
我们选择如下版本:
Kafka下载:
安装前先准备好三台CentOS7服务器用于集群安装,这是IP地址为:172.16.20.220、172.16.20.221、172.16.20.222,然后将上面下载的软件包上传至三台服务器的/usr/local目录。因服务器资源有限,这里所有的软件都安装在这三台集群服务器上,在实际生产环境中,请根据业务需求设计规划进行安装。
在集群搭建时,如果能够编写shell安装脚本就会很方便,如果不能编写,就需要在每台服务器上执行安装命令,多数ssh客户端提供了多会话同时输入的功能,这里一些通用安装命令可以选择启用该功能。
新建/usr/local/java目录
将下载的jdk软件包jdk-8u64-linux-x64.tar.gz上传到/usr/local/java目录,然后解压
配置环境变量/etc/profile
在底部添加以下内容
使环境变量生效
备注:后续可通过此命令停止elasticsearch运行
新建kafka的日志目录和zookeeper数据目录,因为这两项默认放在tmp目录,而tmp目录中内容会随重启而丢失,所以我们自定义以下目录:
修改如下:
在data文件夹中新建myid文件,myid文件的内容为1(一句话创建:echo 1 myid)
kafka启动时先启动zookeeper,再启动kafka;关闭时相反,先关闭kafka,再关闭zookeeper。
1、zookeeper启动命令
后台运行启动命令:
或者
查看集群状态:
2、kafka启动命令
后台运行启动命令:
或者
3、创建topic,最新版本已经不需要使用zookeeper参数创建。
参数解释:
复制两份
--replication-factor 2
创建1个分区
--partitions 1
topic 名称
--topic test
4、查看已经存在的topic(三台设备都执行时可以看到)
5、启动生产者:
6、启动消费者:
添加参数 --from-beginning 从开始位置消费,不是从最新消息
7、测试:在生产者输入test,可以在消费者的两台服务器上看到同样的字符test,说明Kafka服务器集群已搭建成功。
Logstash没有提供集群安装方式,相互之间并没有交互,但是我们可以配置同属一个Kafka消费者组,来实现统一消息只消费一次的功能。
Filebeat用于安装在业务软件运行服务器,收集业务产生的日志,并推送到我们配置的Kafka、Redis、RabbitMQ等消息中间件,或者直接保存到Elasticsearch,下面来讲解如何安装配置:
1、进入到/usr/local目录,执行解压命令
2、编辑配置filebeat.yml
配置文件中默认是输出到elasticsearch,这里我们改为kafka,同文件目录下的filebeat.reference.yml文件是所有配置的实例,可以直接将kafka的配置复制到filebeat.yml
后台启动命令
停止命令
2、测试logstash是消费Kafka的日志主题,并将日志内容存入Elasticsearch
自动新增的两个index,规则是logstash中配置的
数据浏览页可以看到Elasticsearch中存储的日志数据内容,说明我们的配置已经生效。
Gitee: GitEgg: GitEgg 是一款开源免费的企业级微服务应用开发框架,旨在整合目前主流稳定的开源技术框架,集成常用的最佳项目解决方案,实现可直接使用的微服务快速开发框架。
GitHub:
SpringCloud整体构架设计(一)
SpringClound整体核心架构只有一点:Rest服务,也就是说在整个SpringCloud配置过程之中,所有的配置处理都是围绕着Rest完成的,在这个Rest处理之中,一定要有两个端:服务的提供者(Provider)、服务的消费者(Consumer),所以对于整个SpringCloud基础的结构就如下所示:
既然SpringCloud的核心是Restful结构,那么如果要想更好的去使用Rest这些微服务还需要考虑如下几个问题。
1、所有的微服务地址一定会非常的多,所以为了统一管理这些地址信息,也为了可以及时的告诉用户哪些服务不可用,所以应该准备一个分布式的注册中心,并且该注册中心应该支持有HA机制,为了高速并且方便进行所有服务的注册操作,在SpringCloud里面提供有一个Eureka的注册中心。
对于整个的WEB端的构架(SpringBoot实现)可以轻松方便的进行WEB程序的编写,而后利用Nginx或Apache实现负载均衡处理,但是你WEB端出现了负载均衡,那么业务端呢?应该也提供有多个业务端进行负载均衡。那么这个时候就需要将所有需要参与到负载均衡的业务端在Eureka之中进行注册。
在进行客户端使用Rest架构调用的时候,往往都需要一个调用地址,即使现在使用了Eureka作为注册中心,那么它也需要有一个明确的调用地址,可是所有的操作如果都利用调用地址的方式来处理,程序的开发者最方便应用的工具是接口,所以现在就希望可以将所有的Rest服务的内容以接口的方式出现调用,所以它又提供了一个Feign技术,利用此技术可以伪造接口实现。
在进行整体的微架构设计的时候由于牵扯的问题还是属于RPC,所以必须考虑熔断处理机制,实际上所有的熔断就好比生活之中使用保险丝一样,有了保险丝在一些设备出现了故障之后依然可以保护家庭的电器可以正常使用,如果说现在有若干的微服务,并且这些微服务之间可以相互调用,例如A微服务调用了B微服务,B微服务调用了C微服务。
如果在实际的项目设计过程之中没有处理好熔断机制,那么就会产生雪崩效应,所以为了防止这样的问题出现,SpringCloud里面提供有一个Hystrix熔断处理机制,以保证某一个微服务即使出现了问题之后依然可以正常使用。
通过Zuul的代理用户只需要知道指定的路由的路径就可以访问指定的微服务的信息,这样更好的提现了java中的“key=value”的设计思想,而且所有的微服务通过zuul进行代理之后也更加合理的进行名称隐藏。
在SpringBoot学习的时候一直强调过一个问题:在SpringBoot里面强调的是一个“零配置”的概念,本质在于不需要配置任何的配置文件,但是事实上这一点并没有完全的实现,因为在整个在整体的实际里面,依然会提供有application.yml配置文件,那么如果在微服务的创建之中,那么一定会有成百上千个微服务的信息出现,于是这些配置文件的管理就成为了问题。例如:现在你突然有一天你的主机要进行机房的变更,所有的服务的IP地址都可能发生改变,这样对于程序的维护是非常不方便的,为了解决这样的问题,在SpringCloud设计的时候提供有一个SpringCloudConfig的程序组件,利用这个组件就可以直接基于GIT或者SVN来进行配置文件的管理。
在整体设计上SpringCloud更好的实现了RPC的架构设计,而且使用Rest作为通讯的基础,这一点是他的成功之处,由于大量的使用了netflix公司的产品技术,所以这些技术也有可靠的保证。
上述文章就是科灵网介绍的springcloud项目搭建和springcloud项目搭建及部署的详细回答,希望能够帮助到大家;如果你还想了解更多财经资讯知识,记得收藏关注我们。
标签: springcloud项目搭建