构建gpmall集群应用系统环境

是垚不是土

已于 2024-09-28 10:34:23 修改

阅读量1.1k

点赞数 23

分类专栏：运维及平台搭建专栏文章标签：运维 linux 服务器 mysql 数据库 java zookeeper

于 2024-09-12 17:58:09 首次发布

本文链接：https://blog.csdn.net/2401_83649605/article/details/142139822

版权

运维及平台搭建专栏专栏收录该内容

5 篇文章 0 订阅

订阅专栏

项目目标：在10个节点分别部署mariadb，mycat，zookeeper，kafka，redis，nginx，java包

gpmall节点准备：

10个节点，每个节点各司其职

IP	主机名	节点
192.168.104.116	mycat	Mycat中间件服务节点
192.168.104.114	db1	MariaDB数据库集群主节点
192.168.104.115	db2	MariaDB数据库集群从节点
192.168.104.117	zookeeper1	集群节点
192.168.104.118	zookeeper2	集群节点
192.168.104.119	zookeeper3	集群节点
192.168.104.120	redis	消息队列服务节点
192.168.104.121	jar1	Tomcat1节点
192.168.104.122	jar2	Tomcat2节点
192.168.104.123	nginx	Nginx服务器

从单节点到多节点实现的功能：

1. 高可用性：

单节点问题: 单节点部署存在单点故障，一旦节点宕机，整个应用不可用。

多节点改进: 通过多节点部署，实现应用的高可用性。各个服务部署在多个节点上，即使一个节点故障，其他节点仍然可以提供服务。

2. 负载均衡

单节点问题: 单节点只能处理有限的请求量，容易成为性能瓶颈。

多节点改进: 引入负载均衡器，将请求均匀分发到多个节点，提高整体的吞吐量和响应速度。

3. 弹性伸缩

单节点问题: 单节点的扩展性差，性能无法随着业务增长而扩展。

多节点改进: 通过水平扩展（增加节点数量），系统可以根据负载动态增加或减少节点，优化资源使用。

4. 服务隔离与容错

单节点问题: 单节点部署时，各个服务运行在同一节点上，服务之间的耦合较高，任何一个服务的故障可能影响其他服务。

多节点改进: 各个微服务可以部署在不同的节点上，避免服务之间的相互影响，提高容错能力。

5. 分布式缓存与数据库

单节点问题: 缓存和数据库都是单点的，性能和可用性有限。

多节点改进: 部署分布式缓存（Redis 集群）和分布式数据库（MySQL 主从复制、读写分离），提高数据访问的速度和系统的扩展能力。

6.日志集中管理（Centralized Logging）

单节点问题: 单节点日志较容易管理，但多节点部署后日志分散。

多节点改进: 使用集中式日志管理系统（如 ELK Stack、Prometheus），实现日志的收集、分析和监控。

7. 监控与告警（Monitoring and Alerting）

单节点问题: 单节点监控较简单，但无法全面掌握多节点状态。

多节点改进: 可以部署监控系统，对多节点系统进行实时监控和告警，快速发现和处理问题。

一.数据库部署

1.在db1和db2节点修改映射文件

2.修改yum源为可用yum源文件，修改后安装数据库

[root@db1 ~]# yum install -y mariadb mariadb-server

[root@db2 ~]# yum install -y mariadb mariadb-server

3.初始化数据库，设置root用户登陆密码为123456

[root@db1 ~]# mysql_secure_installation

/usr/bin/mysql_secure_installation: line 379: find_mysql_client: command not found

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB

SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current

password for the root user. If you've just installed MariaDB, and

you haven't set the root password yet, the password will be blank,

so you should just press enter here.

Enter current password for root (enter for none): #默认按回车

OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB

root user without the proper authorisation.

Set root password? [Y/n] y

New password:

Re-enter new password:

Password updated successfully!

Reloading privilege tables..

... Success!

By default, a MariaDB installation has an anonymous user, allowing anyone

to log into MariaDB without having to have a user account created for

them. This is intended only for testing, and to make the installation

go a bit smoother. You should remove them before moving into a

production environment.

Remove anonymous users? [Y/n] y

... Success!

Normally, root should only be allowed to connect from 'localhost'. This

ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] n

... skipping.

By default, MariaDB comes with a database named 'test' that anyone can

access. This is also intended only for testing, and should be removed

before moving into a production environment.

Remove test database and access to it? [Y/n] y

- Dropping test database...

... Success!

- Removing privileges on test database...

... Success!

Reloading the privilege tables will ensure that all changes made so far

will take effect immediately.

Reload privilege tables now? [Y/n] y

... Success!

Cleaning up...

All done! If you've completed all of the above steps, your MariaDB

installation should now be secure.

Thanks for using MariaDB!

4.编辑数据库配置文件，加入server-idhelob-bin

db1和db2节点同理

5.数据库主从配置

db1登陆数据库：

Db1节点设置任何主机都可用root用户登陆数据库：

MariaDB [(none)]> grant all privileges on *.* to root@'%' identified by '123456';

在主节点db1数据库上创建一个user用户让从节点db2连接，并赋予从节点同步主节点数据库的权限，命令如下。

MariaDB [(none)]> grant replication slave on *.* to 'user'@'db2' identified

在从节点db2虚拟机上使用mysql命令登录MariaDB数据库，配置从节点连接主节点的连接信息。master_host为主节点主机名db1，master_user为在步骤（4）中创建的用户user

MariaDB [(none)]> change master to master_host='db1',master_user='user',master_password='123456';

完成之后启动同步：

查看同步状态：

数据库读写分离事实成功，导入gpmall.sql的数据库表：

数据库主从配置成功。创建数据库gpmall并导入数据库表

[root@db1 ~]# mysql -uroot -p123456

Welcome to the MariaDB monitor. Commands end with ; or \g.

Your MariaDB connection id is 19

Server version: 10.3.18-MariaDB-log MariaDB Server

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create database gpmall;

Query OK, 1 row affected (0.000 sec)

MariaDB [(none)]> use gpmall

Database changed

MariaDB [gpmall]> source /root/gpmall.sql

Query OK, 0 rows affected (0.000 sec)

6.数据库读写分离配置：

在Mycat节点上安装JDK

[root@mycat ~]# yum -y install java-1.8.0-openjdk java-1.8.0-openjdk-devel

在mycat节点下上传mycat的软件包

将文件解压在/usr/local下，赋予解压下的目录权限

将Mycat写入环境变量

编写mycat的schema.yml文件;

<?xml version="1.0"?>

<!DOCTYPE mycat:schema SYSTEM "schema.dtd">

<mycat:schema xmlns:mycat="http://io.mycat/">

<heartbeat>select user()</heartbeat>

</writeHost>

</dataHost>

</mycat:schema>

修改mycat的server.yml文件

修改后启动mycat服务：

查看是否运行了mycat，查看8066和9066端口是否启动

更新yum源，下载测试工具MariaDB-client

[root@mycat bin]# yum install -y MariaDB-client

下载完成后登入数据库

[root@mycat bin]# mysql -h127.0.0.1 -P8066 -uroot -p123456

测试数据库

[root@mycat bin]# mysql -h127.0.0.1 -P9066 -uroot -p123456 -e 'show @@datasource;'

读写分离测试成功。

二.部署zookeeper

修改三个节点主机名：

[root@C20240911463176 ~]# hostnamectl set-hostname zookeeper1

[root@C20240911463176 ~]# bash

[root@zookeeper1 ~]#

Zookeeper2和3节点同上

设置映射文件

测试连通性！！！

安装JDK组件

[root@zookeeper1 ~]# yum -y install java-1.8.0-openjdk java-1.8.0-openjdk-devel

上传zookeeper软件包到三个节点下

三个节点将zookeeper文件解压，将配置文件中的zoo_sample.cfg文件更名为zoo.cfg

在该文件下添加三个节点下的IP

在三个节点下创建/tmp/zookeeper/目录，并创建myid文件：三个节点以此修改，并对应server后的数字，修改过后三个节点启动zookeeper

启动zookeeper

启动后，查看选举状态，三个节点，一个leader，两个follower即为成功启动zookeeper

三.部署kafka

在三个zookeeper节点，部署kafka服务

三个节点上传kafka软件包

编辑配置文件server.properties 文件

#broker.id=0

#zookeeper.connect=localhost:2181

将这两项注释掉。并添加：

每个节点的ip，id。

设置完成后，启动kafka服务,并用jps进行查看

三个节点都启动成功可以进行测试：

在zookeeper1kafka1节点上创建topic，虽然是在1机器上创建的，但在2he3上均可查看到

Kafka服务启动成功。

四.部署redis

下载redis

[root@redis ~]# yum -y install redis

修改redis的配置文件

架构两处注释掉

修改完成后启动redis服务。

五.运行java包

在jar1和jar2节点上传java包

修改jar1和jar2节点下的映射文件

Jar1和jar2两个节点下载JDK包

[root@jar1 ~]# yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel

下载完成时候，按顺序运行四个java包

[root@jar ]# nohup java -jar shopping-provider-0.0.1-SNAPSHOT.jar &

[root@jar]# nohup java -jar user-provider-0.0.1-SNAPSHOT.jar &

[root@jar]# nohup java -jar gpmall-shopping-0.0.1-SNAPSHOT.jar &

[root@jar]# nohup java -jar gpmall-user-0.0.1-SNAPSHOT.jar &

查看后台是否正常运行

六.部署nginx

上传gpmall.repo并添加yum源文件

下载nginx

[root@nginx ~]# yum -y install nginx

修改其配置文件，在/et c/nginx/conf.c/default.conf下进行修改

配置字段详解：

Nginx 负载均衡配置，定义了多个 upstream 块和相关的 server

1. upstream 块

upstream 用于定义后端的服务器池，告诉 Nginx 应该将请求转发到哪些服务器。这里有三个 upstream，分别对应三个不同的服务。

1.1.
upstream myuser {

server 192.168.104.121:8082;

server 192.168.104.122:8082;

ip_hash;

}

myuser 是定义的服务器集群名称，用于表示处理 /user 请求的服务器集群。

两个 server 指定了 IP 地址和端口号，表示可以将请求转发到这两台服务器（192.168.104.121:8082 和 192.168.104.122:8082）。

ip_hash 是一种负载均衡算法，基于客户端的 IP 地址哈希值将请求分配给后端服务器，这样同一个客户端的请求总是会被分配到同一个后端服务器，保持会话的一致性。

upstream myshopping {

server 192.168.104.121:8081;

server 192.168.104.122:8081;

ip_hash;

}

myshopping 是另一个服务器集群名称，用于处理 /shopping 请求。

两个 server 指定了与 myuser 不同的端口号（8081），但使用相同的 IP 地址。

ip_hash 同样用于确保基于 IP 地址的负载均衡。

1.3.

upstream mycashier {

server 192.168.104.121:8083;

server 192.168.104.122:8083;

ip_hash;

}

mycashier 是处理 /cashier 请求的服务器集群。

两个服务器的端口号为 8083，同样启用了 ip_hash 负载均衡。

2. server 块

server 块定义了 Nginx 作为代理服务器的行为，主要包括监听端口、服务器名称、以及如何处理不同的请求路径

server {

listen 80;

server_name localhost;

listen 80：Nginx 监听 HTTP 的默认端口 80。

server_name localhost：表示该服务器响应的域名是 localhost，这是一个本地开发环境的配置，生产环境可以换成真实的域名。

2.1. location /

location / {

root /usr/share/nginx/html;

index index.html index.htm;

}

location /：定义根路径（即 http://localhost/）的处理方式。这里的配置表示：

root /usr/share/nginx/html：静态文件的根目录是 /usr/share/nginx/html。

index index.html index.htm：默认首页文件为 index.html 或 index.htm。

2.2. location /user

nginx

location /user {

proxy_pass http://myuser;

}

location /user：定义路径 /user 的处理方式，即当访问 http://localhost/user 时：

proxy_pass http://myuser：请求会被反向代理到 myuser 定义的服务器集群，即 192.168.104.121:8082 和 192.168.104.122:8082。

2.3. location /shopping

location /shopping {

proxy_pass http://myshopping;

}

location /shopping：定义路径 /shopping 的处理方式，表示请求被代理到 myshopping 定义的服务器集群（192.168.104.121:8081 和 192.168.104.122:8081）。

2.4. location /cashier

location /cashier {

proxy_pass http://mycashier;

}

location /cashier：路径 /cashier 的请求将被转发到 mycashier 集群中的服务器（192.168.104.121:8083 和 192.168.104.122:8083）。

将提供的dist文件夹上传至Nginx节点的/root目录下，然后将dist中的内容复制到nginx的项目目录，命令如下：

首先将Nginx默认项目目录的文件删除：

[root@nginx ~]# rm -rf /usr/share/nginx/html/*

然后将dist中的文件复制至/usr/share/nginx/html目录下：

[root@nginx ~]# cp -rvf dist/* /usr/share/nginx/html/

修改配置后，重启nginx

[root@nginx ~]# systemctl restart nginx

进行浏览器访问nginx节点ip地址，可以正常进入即可

至此，jpmall集群部署成功。

错误寻找：

日志查看

Java节点运行java包，若出现java包无法正常运行，查询根目录下的日志文件nohup.out下可以查看到具体信息及访问信息：

nohup.out文件是默认的输出文件，用于捕获由nohup命令运行的进程的标准输出（stdout）和标准错误输出（stderr）。

当使用nohup命令运行一个程序nohup my_program &

如果没有特别指定输出文件，那么my_program的输出将会被重定向到nohup.out文件中。这个文件通常包含以下类型的日志：

程序输出：程序正常运行时产生的所有输出信息，包括打印语句、警告、通知等。

错误信息：程序运行中遇到的错误或异常信息，这些信息对于调试程序至关重要。

程序日志：如果程序内部有日志记录机制，那么这些日志信息也会被写入nohup.out文件。

结束信息：当程序正常结束或被终止时，相关的结束信息也会记录在nohup.out文件中。

系统信息：如果程序运行过程中系统发生了变化，如资源限制、信号处理等，这些信息也可能被记录。

中断信息：如果程序因为接收到中断信号（如SIGINT）而终止，相关的中断信息也会被记录。需要注意的是，nohup.out文件的内容取决于你运行的程序本身。如果程序设计得当，它会将所有重要的输出信息和错误信息记录到日志中。如果程序没有设计日志记录功能，那么nohup.out文件可能只包含最基本的输出信息。

Nginx的日志文件为/var/log/nginx目录下，正确信息日志为access.log，错误信息日志为error.log，在两个不同日志文件下查询不同信息：

Nginx的错误日志（error_log）是用于记录服务器和请求处理过程中的错误信息，对于调试和监控Nginx服务非常重要。错误日志的配置是通过error_log指令来实现的，它可以设置日志文件的路径和日志级别。

在Nginx中，error_log指令可以设置在不同的配置级别，包括main、http、mail、stream、server和location。默认情况下，如果没有在特定级别明确定义错误日志文件，Nginx会使用默认的日志文件。错误日志的级别从低到高分别是：debug、info、notice、warn、error、crit、alert和emerg。每个级别都会记录该级别及以上级别的日志信息。例如，如果设置为warn，则会记录warn、error、crit、alert和emerg级别的日志。

在配置错误日志时，可以指定日志文件的路径

error_log /var/log/nginx/error.log warn;

这行配置表示将错误日志记录到/var/log/nginx/error.log文件中，并设置日志级别为warn。除了记录到文件，Nginx还支持将错误日志发送到syslog或者内存缓冲区。例如：

error_log syslog:server=192.168.1.1:1234 warn;

error_log memory:32m debug;

这些配置允许将日志发送到指定的syslog服务器或者内存缓冲区中，用于调试。错误日志的格式通常包括时间戳、错误级别、进程信息和错误消息。