xiaozhigang

长风破浪会有时,直挂云帆济沧海。

简介

ELK是elasticsearch、logstash、kibana软件的集合,对外是作为一个日志管理系统的开源方案,它可以从任何来源、任何格式进行日志搜索、分析与可视化展示。
基本组成软件:

  • elasticsearch:一个开源分布式搜索引擎,提供收集、分析、存储数据三大功能。

  • kibana:一个基于web的图形界面,用于搜索、分析和可视化存储在elasticsearch中的日志数据。

  • logstash:一个服务端的数据处理管道,可以从多个源中提取数据,对其进行转换,然后将其存储到Elasticsearch中。简单来说就是日志的收集、分析、过滤工具。

搭建步骤

使用版本是7.9.3,部署前我们可以先提前从官网上下载下面4个安装包:
elasticsearch-7.9.3-linux-x86_64.tar.gz
kibana-7.9.3-linux-x86_64.tar.gz
logstash-7.9.3.tar.gz

这4个组件可以部署在不同的机器上,只要机器之间是端口开放即可
本文档中elasticsearch、logstash、kibana部署在一台机器,filebeat部署在有业务服务的机器上。

  1. 创建用户和解压文件
    groupadd elk
    useradd elk -g elk
    解压文件:
    tar -zxvf elasticsearch-7.9.3-linux-x86_64.tar.gz -C /home/elk
    tar -zxvf kibana-7.9.3-linux-x86_64.tar.gz -C /home/elk
    tar -zxvf logstash-7.9.3.tar.gz -C /home/elk


    cd /home/elk
    mv kibana-7.9.3-linux-x86_64 kibana-7.9.3

    chown -R elk:elk /home/elk/elasticsearch-7.9.3
    chown -R elk:elk /home/elk/kibana-7.9.3
    chown -R elk:elk /home/elk/logstash-7.9.3

  2. 部署elasticsearch

    1. 切换到elk用户
      su - elasticsearch
      cd /home/elk/

    2. 修改elasticsearch.yml
      cd /home/elk/elasticsearch-7.9.3/config
      vi elasticsearch.yml
      在文件末尾增加以下内容
      # 集群初始主节点
      cluster.name: “es-cluster”
      network.host: 0.0.0.0
      node.name: “node-1”


      # discovery type
      discovery.type: single-node
      #discovery.seed_hosts: [“127.0.0.1”, “[::1]”]

      # 设置允许所有ip可以连接该elasticsearch
      network.host: 0.0.0.0

      # 开启监听的端口为9200
      http.port: 9200

      # 增加新的参数,为了让elasticsearch-head插件可以访问es
      http.cors.enabled: true
      http.cors.allow-origin: “*”

      # 启用密码
      xpack.security.enabled: true

      # 使用默认密码
      xpack.security.authc.accept_default_password: true
      xpack.security.transport.ssl.enabled: true
      如果需要外置存储和日志,需要修改path.data和path.logs
      path.data: /nfsc/cnas_csp_pase_hrx_id010797_vol1003_dev/elasticsearch
      path.logs: /nfsc/cnas_csp_pase_hrx_id010797_vol1003_dev/elasticsearch_logs

    3. 修改Elasticsearch占用内存
      cd /home/elk/elasticsearch-7.9.3/config
      vi jvm.options
      修改JVM参数 :
      -Xms16g
      -Xmx16g

    4. 启动es的时候有可能会报类似的下面的错误【max virtual memory areas vm.max_map_count [65530] is too low】,所以我们可以通过下面的方法去处理:
      vi /etc/sysctl.conf
      文件末尾添加一行
      vm.max_map_count=655360
      保存之后执行下面的命令加载参数
      sysctl -p

    5. 启动Elasticsearch
      切换用户,进入bin目录启动:
      cd /home/elk/elasticsearch-7.9.3/bin
      ./elasticsearch -d

    6. 为内置账号添加密码

      interactive:给用户一一设置密码

      # auto:自动生成密码
      cd /home/elk/elasticsearch-7.9.3/bin/
      ./elasticsearch-setup-passwords interactive
      
    7. 验证是否启动成功

      curl -XGET -u elastic ‘localhost:9200’

      {
        "name" : "node-1",
        "cluster_name" : "es-cluster",
        "cluster_uuid" : "8eGk8_ohRbWl8ZcNSPsFDQ",
        "version" : {
          "number" : "7.9.3",
          "build_flavor" : "default",
          "build_type" : "tar",
          "build_hash" : "c4138e51121ef06a6404866cddc601906fe5c868",
          "build_date" : "2020-10-16T10:36:16.141335Z",
          "build_snapshot" : false,
          "lucene_version" : "8.6.2",
          "minimum_wire_compatibility_version" : "6.8.0",
          "minimum_index_compatibility_version" : "6.0.0-beta1"
        },
        "tagline" : "You Know, for Search"
      }
      
  3. 部署kibana

    1. 修改配置文件,文件位置在/home/elk/kibana-7.9.3/config目录下
      su - elasticsearch
      cd /home/elk/kibana-7.9.3/config
      vi kibana.yml
      添加es的配置,由于是都在同一台机器所以用localhost,如果是不同机器,就换成对应的ip即可
      # kibana端口
      server.port: 5601


      # 允许所有ip访问
      server.host: “0.0.0.0”

      # elasticsearch所在的ip及监听的地址
      elasticsearch.hosts: [“http://localhost:9200"]
      elasticsearch.username: “kibana_system”
      elasticsearch.password: “kibana_system”

      # kibana默认创建的索引
      kibana.index: “.kibana”

      # 字符编码
      i18n.locale: “zh-CN”

      # elasticsearch加密所需配置
      xpack.reporting.encryptionKey: “a_random_string”
      xpack.security.encryptionKey: “something_at_least_32_characters”

    2. 启动kibana
      cd /home/elk/kibana-7.9.3/bin
      ./kibana &

    3. 访问kibana
      http://IP:5601/

  4. 部署Logstash

    1. 修改Logstash的YML配置文件
      cd /home/elk/logstash-7.9.3/config/
      vim logstash.yml
      修改以下内容
      # 配置自动刷新
      config.reload.automatic: true
      config.reload.interval: 20s


      # 配置可任意地址都可访问
      http.host: 0.0.0.0
      http.port: 9600

      # 配置es的访问密码
      xpack.monitoring.enabled: true
      xpack.monitoring.elasticsearch.username: logstash_system
      xpack.monitoring.elasticsearch.password: logstash_system
      xpack.monitoring.elasticsearch.hosts: [“http://localhsot:9200"]

    2. 修改 pipelines配置文件

      • pipeline.id: gmp-logs
        queue.type: persisted
        path.config: “/home/elk/logstash-7.9.3/conf.d/*.config”
    3. 创建日志的config文件
      touch /home/elk/logstash-7.9.3/conf.d/logstash-beats.conf
      写入文件内容
      input {
      beats {
      port => 5044
      }
      }


      filter {
      grok {
      match => [
      “message”, “%{TIMESTAMP_ISO8601:timestamp_string}%{SPACE}%{GREEDYDATA:line}”
      ]
      }
      date {
      match => [“timestamp_string”, “ISO8601”]
      }
      mutate {
      remove_field => [message, timestamp_string]
      }
      }

      output {
      elasticsearch {
      hosts => [“http://localhost:9200"]
      user => elastic
      password => “elastic”
      }
      stdout {
      codec => rubydebug
      }
      }

    4. 启动Logstash(root用户)
      cd /home/elk/logstash-7.9.3/bin
      sh logstash -f ../conf.d/logstash-beats.conf &

阅读全文 »

简述

redis有两种持久化方式:RDB(Redis DataBase)持久化和 AOF(Append Only File)。

RDB:通过创建数据的快照,在指定时间间隔内将redis某个时刻的数据状态保存到磁盘RDB文件中。

AOF:通过记录每个操作命令并将其追加到AOF文件中,恢复时通过执行这些命令来重建数据。

image-20240331163759309

RDB持久化

RBD以快照的方式保存全量的数据,可通过save和bgsave两个命令来触发持久化。

1、save命令:会同步地将 Redis 的所有数据保存到磁盘上的一个 RDB 文件中。这个操作会阻塞所有客户端请求直到 RDB 文件被完全写入磁盘。

2、bgsave命令:会在后台异步地创建 Redis 的数据快照,并将快照保存到磁盘上的 RDB 文件中。这个命令会立即返回,Redis 服务器可以继续处理客户端请求。

image-20240331165755573

阅读全文 »

REST


RESTful本身是一种风格而不是规范,本文为该风格的规范实现的最佳实践,本文档详细说明了HTTP RESTful API的定义和使用规范,作为接口调用者和实现者的重要参考。

接口风格

遵循RESTful设计风格,同时控制复杂度及易于使用,仅遵循大部分原则。 遵循原则:

  • 使用https协议
  • 版本号放入URL或Header
  • 只提供json返回格式
  • post,put上使用json作为输入
  • 使用http状态码作为错误提示
  • Path(路径)尽量使用名词,不使用动词,把每个URL看成一个资源
  • 使用HTTP动词(GET,POST,PUT,DELETE)作为action操作URL资源
  • 过滤信息
    • limit:指定返回记录数量
    • offset:记录开始位置
    • direction:请求数据的方向,取值prev-上一页数据;next-下一页数据
    • page:第几页
    • per_page:每页条数
    • total_count:总记录数
    • total_pages:总页数,等于page时,表示当前是最后一页
    • sort:column1,column2排序字段
    • orderby:排序规则,desc或asc
    • q:搜索关键字(uri encode之后的)
  • 返回结果
    • GET:返回资源对象
    • POST:返回新生成的资源对象
    • PUT:返回完整的资源对象
    • DELETE:返回一个空文档
  • 速率限制
    • X-RateLimit-Limit: 每个IP每个时间窗口最大请求数
    • X-RateLimit-Remaining: 当前时间窗口剩余请求数
    • X-RateLimit-Reset: 下次更新时间窗口的时间(UNIX时间戳),达到下个时间窗口时,Remaining恢复为Limit

未遵循原则:

  • Hypermedia API(HATEOAS),通过接口URL获取接口地址及帮助文档地址信息
  • 限制返回值的域,fields=id,subject,customer_name
  • 缓存,使用ETag和Last-Modified

参考:

阅读全文 »

需求描述

我有一个仓库AAA,目录结构如下:

1
2
3
4
5
6
7
8
$ tree
├── .git
├── common-api
├── commons-pojo
├── commons-utils
├── account
└── payment
└── product

现在我需要把common-api、commons-pojo、commons-utils独立为一个新仓库xxx-common
从网上找到可以用”git filter-branch”和”git subtree split”两种方式独立目录为仓库,但是”git subtree split”只能独立一个目录为仓库,如果需要独立多个目录为仓库需要使用”git filter-branch”。

阅读全文 »

分层架构图

DDD

简述

  1. Controller层:接口层,负责对前端展示的路由和适配;如果需要的话,消费事件和发送消息通知等也可以放在这里;

  2. Application层:主要负责获取输入,组装上下文,参数校验,调用领域层做业务处理

  3. Domain层:领域是应用的核心,主要是封装了核心业务逻辑,通过领域服务(Domain Service)、领域对象(Entity)的方法对App层提供业务实体和业务逻辑计算;

  4. Infrastructure层:主要负责技术细节问题的处理,比如数据库的CRUD、搜索引擎、文件系统、分布式服务的RPC等;

分层说明

  • APP层采用CQE模型,查询和命令分离
  • AppService调用实体和IRepo进行编排实现简单业务,通过调用DomainService实现复杂业务场景
  • AppService和DomainService均为无状态服务
  • App只允许调用仓储以及实体自带方法,不允许写任何方法,避免出现AppService过大的情况
  • DomainService封装所有跨实体的业务逻辑
  • 为避免出现AppService之间或者Domainservice之间相互调用,抽取出两者公共部分为一个Helper

聚合根和实体

  • 按聚合根分包,和包名一样的实体为聚合根
  • 可以识别的聚合根就写成聚合根,否则做成实体
  • 聚合根的一致性由自己保障
  • 跨实体的操作放到领域服务中

领域对象实体为充血模型,为一般业务对象,具备业务属性和业务行为

  • 实体都有自己的唯一标识通常
  • 实体可以不和表一一对应,通常操作单个表,可以操作多表
阅读全文 »

简述

如果在线上环境,需要新建一个索引,会发生什么,会不会导致不可用,具体的创建步骤又是啥。

首先肯定会有一段时间导致表不可用的,主要就是看不可用的时间长短。

在不同的版本上主要有三种创建方式:Copy Table方式、Inplace方式、Online方式

Copy Table方式

早期版本,直接通过复制表实现

步骤

1、先为原表table创建临时表table_copy。

2、向临时表table_copy添加索引。

阅读全文 »

什么是JVM类加载

指将编译后的class文件,读到内存中,首先将其放在运行时数据区的方法区内,然后再堆内创建class对象。class对象封装了类在方法区内的数据结构,并提供了访问方法区内的数据结构的接口。

image-20240409215152713

类加载器

自带加载器

自带加载器有三个:

1、启动类加载器:负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录,下同)下,或被-Xbootclasspath参数指定的路径中的,并且能被虚拟机识别的类库(如rt.jar,所有的java.*开头的类均被Bootstrap ClassLoader加载)。启动类加载器是无法被Java程序直接引用的。

2、扩展类加载器:该加载器由sun.misc.Launcher$ExtClassLoader实现,它负责加载DK\jre\lib\ext目录中,或者由java.ext.dirs系统变量指定的路径中的所有类库(如javax.*开头的类),开发者可以直接使用扩展类加载器。

3、应用程序类加载器:该类加载器由sun.misc.Launcher$AppClassLoader来实现,它负责加载用户类路径(ClassPath)所指定的类,开发者可以直接使用该类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

类加载的三种方式

阅读全文 »

简述

提到分布式,那么CAP原则是绕不过去的,那么什么是CAP原则呢。

CAP原则:在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)不可能都同时满足,最多只能同时满足两个。

img

详解

选项 描述
一致性(Consistency 指在分布式系统中,多个副本之间能够保持严格的数据一致性。
可用性(Availability) 指服务一直处于可用状态,每次请求都能获取非错响应
分区容错性(Partition tolerance) 指在分布式系统中,某个分区或副本出故障了,其他分区或副本能继续对外提供服务

为什么不能CAP兼容

1、在分布式系统中,分区容错性肯定是必须的,所以必须要有P。

2、添加C,就是添加一致性,那么就是要保证所有分区中的数据是一致的。假设有A、B、C三个分区,现在分区上的数据一致。

3、添加A,添加可用性,保证服务一直可用,我们看能不能达到这种效果。

阅读全文 »

架构图

四层结构

cola-arch.jpg

  1. 适配层(Adapter Layer):负责对前端展示(web,wireless,wap)的路由和适配,对于传统B/S系统而言,adapter就相当于MVC中的controller;

  2. 应用层(Application Layer):主要负责获取输入,组装上下文,参数校验,调用领域层做业务处理,如果需要的话,发送消息通知等。层次是开放的,应用层也可以绕过领域层,直接访问基础实施层;

  3. 领域层(Domain Layer):主要是封装了核心业务逻辑,并通过领域服务(Domain Service)和领域对象(Domain Entity)的方法对App层提供业务实体和业务逻辑计算。领域是应用的核心,不依赖任何其他层次;

  4. 基础实施层(Infrastructure Layer):主要负责技术细节问题的处理,比如数据库的CRUD、搜索引擎、文件系统、分布式服务的RPC等。此外,领域防腐的重任也落在这里,外部依赖需要通过gateway的转义处理,才能被上面的App层和Domain层使用。

    阅读全文 »
0%