2. 程式人生 > 實用技巧 >微服務下，使用 ELK 進行日誌採集以及統一處理

微服務下，使用 ELK 進行日誌採集以及統一處理

阿新 • • 發佈：2020-11-16

技術標籤：javarabbitmq中介軟體

RabbitMQ:

​

什麼是MQ（訊息佇列）：

​ 訊息的傳送者和接收者不需要同時與訊息佇列互交。訊息會儲存在佇列中，直到接收者取回它。

​ 三個特點：非同步，解耦，流量削峰。

實現：

​ 訊息佇列常常儲存在連結串列結構中。擁有許可權的程序可以向訊息佇列中寫入或讀取訊息。

當前使用較多的訊息佇列有 RabbitMQ（資料不會丟失，常用） 、 RocketMQ （有些不開源）、 ActiveMQ（併發量太小） 、 Kafka（訊息丟失） 、 ZeroMQ 、 MetaMq等，而部分資料庫如 Redis 、 Mysql 以及 phxsql 也可實現訊息佇列的功能。

2.2. 特點

​ MQ是消費者-生產者模型的一個典型的代表，一端往訊息佇列中不斷寫入訊息，而另一端則可以讀取或者訂閱佇列中的訊息。MQ和JMS類似，但不同的是JMS是SUN JAVA訊息中介軟體服務的一個標準和API定義，而MQ則是遵循了AMQP協議的具體實現和產品。

注意：

  1. AMQP ，即Advanced Message Queuing Protocol,一個提供統一訊息服務的應用層標準高階訊息佇列協議,是應用層協議的一個開放標準,為面向訊息的中介軟體設計。基於此協議的客戶端與訊息中介軟體可傳遞訊息，並不受客戶端/中介軟體不同產品，不同的開發語言等條件的限制。

  2. JMS ，Java訊息服務（Java Message Service）應用程式介面，是一個Java平臺中關於面向訊息中介軟體的API，用於在兩個應用程式之間，或分散式系統中傳送訊息，進行非同步通訊。 Java訊息服務是一個與具體平臺無關的API，絕大多數MOM提供商都對JMS提供支援。常見的訊息佇列，大部分都實現了JMS API，如 ActiveMQ ， Redis 以及 RabbitMQ 等。

2.3. 優缺點

優點

解耦、非同步處理、流量削鋒

缺點

​ 系統可用性降低、系統複雜性增加

2.4. 使用場景

​ 訊息佇列，是分散式系統中重要的元件，其通用的使用場景可以簡單地描述為：當不需要立即獲得結果，但是併發量又需要進行控制的時候，差不多就是需要使用訊息佇列的時候。

​ 在專案中，將一些無需即時返回且耗時的操作提取出來，進行了非同步處理，而這種非同步處理的方式大大的節省了伺服器的請求響應時間，從而提高了系統的吞吐量。

2.5. 為什麼使用RabbitMQ

​ AMQP，即Advanced Message Queuing Protocol，高階訊息佇列協議，是應用層協議的一個開放標準，為面向訊息的中介軟體設計。訊息中介軟體主要用於元件之間的解耦，訊息的傳送者無需知道訊息使用者的存在，反之亦然。

​ AMQP的主要特徵是面向訊息、佇列、路由（包括點對點和釋出/訂閱）、可靠性、安全。

​ RabbitMQ是一個開源的AMQP實現，伺服器端用Erlang語言編寫，支援多種客戶端，如： Python 、 Ruby 、 .NET 、 Java 、 JMS 、 C 、 PHP 、 ActionScript 、 XMPP 、 STOMP 等，支援AJAX。用於在分散式系統中儲存轉發訊息，在易用性、擴充套件性、高可用性等方面表現不俗。

總結如下：

​ 基於AMQP協議

​ 高併發(是一個容量的概念，伺服器可以接受的最大任務數量)

​ 高效能(是一個速度的概念，單位時間內伺服器可以處理的任務數)

​ 高可用(是一個持久的概念，單位時間內伺服器可以正常工作的時間比例)

​ 強大的社群支援，以及很多公司都在使用

​ 支援外掛

​ 支援多語言

4.4. ConnectionFactory**、Connection、**Channel

​ ConnectionFactory 、 Connection 、 Channel 都是RabbitMQ對外提供的API中最基本的物件。

​ Connection 是RabbitMQ的 socket 連線，它封裝了 socket 協議相關部分邏輯。

​ ConnectionFactory 為Connection的製造工廠。

​ Channel 是我們與RabbitMQ打交道的最重要的一個介面，我們大部分的業務操作是在Channel這個介面中完成的，包括定義 Queue 、定義 Exchange 、繫結 Queue 與 Exchange 、釋出訊息等。

5. 簡單模式佇列

https://www.rabbitmq.com/tutorials/tutorial-one-java.html

1.“Hello,World!”:

/**
 * 入門案例-生產者
 */
public class Send {
	//定義佇列名稱
	private final static String QUEUE_NAME = "hello";

	public static void main(String[] argv) throws Exception {
		//建立連線工廠
		ConnectionFactory factory = new ConnectionFactory();
		//工廠設定
		factory.setHost("192.168.10.100");
		factory.setVirtualHost("/shop");
		factory.setUsername("shop");
		factory.setPassword("shop");
		//根據連線工廠建立連線
		try (Connection connection = factory.newConnection();
		     //根據連線建立通道
		     Channel channel = connection.createChannel()) {
			/**
			 * 宣告佇列
			 *  第一個引數queue：佇列名稱
			 *  第二個引數durable：是否持久化
			 *  第三個引數Exclusive：排他佇列，如果一個佇列被宣告為排他佇列，該佇列僅對首次宣告它的連線可見，並在連線斷開時自動刪除。
			 *      這裡需要注意三點：
			 *          1. 排他佇列是基於連線可見的，同一連線的不同通道是可以同時訪問同一個連線建立的排他佇列的。
			 *          2. "首次"，如果一個連線已經聲明瞭一個排他佇列，其他連線是不允許建立同名的排他佇列的，這個與普通佇列不同。
			 *          3. 即使該佇列是持久化的，一旦連線關閉或者客戶端退出，該排他佇列都會被自動刪除的。
			 *          這種佇列適用於只限於一個客戶端傳送讀取訊息的應用場景。
			 *  第四個引數Auto-delete：自動刪除，如果該佇列沒有任何訂閱的消費者的話，該佇列會被自動刪除。
			 *                          這種佇列適用於臨時佇列。
			 */
			channel.queueDeclare(QUEUE_NAME, false, false, false, null);
			String message = "Hello World!";
			//傳送訊息
			channel.basicPublish("", QUEUE_NAME, null, message.getBytes(StandardCharsets.UTF_8));
			System.out.println(" [x] Sent '" + message + "'");
		}
	}
}

/**
 * 入門案例-消費者
 */
public class Recv {
	//定義佇列名稱
	private final static String QUEUE_NAME = "hello";

	public static void main(String[] argv) throws Exception {
		//建立連線工廠
		ConnectionFactory factory = new ConnectionFactory();
		//工廠設定
		factory.setHost("192.168.10.100");
		factory.setVirtualHost("/shop");
		factory.setUsername("shop");
		factory.setPassword("shop");
		//根據工廠建立連線
		Connection connection = factory.newConnection();
		//根據連線建立通道
		Channel channel = connection.createChannel();
		//繫結佇列
		channel.queueDeclare(QUEUE_NAME, false, false, false, null);
		System.out.println(" [*] Waiting for messages. To exit press CTRL+C");

		DeliverCallback deliverCallback = (consumerTag, delivery) -> {
			String message = new String(delivery.getBody(), "UTF-8");
			System.out.println(" [x] Received '" + message + "'");
		};
		/**
		 * 消費佇列
		 * 1.佇列名稱
		 * 2.自動確認
		 * 3.收到的訊息的實體類
		 */
		channel.basicConsume(QUEUE_NAME, true, deliverCallback, consumerTag -> {
		});
	}
}

問題：如果任務量很大，訊息得不到及時的消費會造成佇列積壓，問題非常嚴重，比如記憶體溢位，訊息丟失等。

解決：配置多個消費者消費訊息。

總結：簡單佇列-處理訊息效率不高，吞吐量較低，不適合生成環境

6. Work queues-工作模式佇列

6.1. 工作模式佇列-訊息輪詢分發(Round-robin)

問題：任務量很大，訊息雖然得到了及時的消費，單位時間內訊息處理速度加快，提高了吞吐量，可

是不同消費者處理訊息的時間不同，導致部分消費者的資源被浪費。

解決：採用訊息公平分發。

總結：工作佇列-訊息輪詢分發-消費者收到的訊息數量平均分配，單位時間內訊息處理速度加快，提高了吞吐量。

6.2. 工作模式佇列**-**訊息公平分發(fair dispatch)

消費者：

​ //限制每次只發送一條，消費者處理完在傳送下一條
​ int prefetchCount = 1;
​ channel.basicQos(prefetchCount);

/**
* 手動確認
* 1. 訊息實體裡的唯一標識
* 2. 是否多條確認
*/
			channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);

/**
* 消費佇列
* 1.佇列名稱
* 2.自動確認
* 3.收到的訊息的實體類
*/
channel.basicConsume(QUEUE_NAME, false, deliverCallback, consumerTag -> {});

​ 總結：工作佇列-公平輪詢分發-根據不同消費者機器硬體配置，訊息處理速度不同，收到的訊息數量也不同，通常速度快的處理的訊息數量比較多，最大化使用計算機資源。適用於生成環境。

7. Publish/Subscribe-訊息的釋出與訂閱模式佇列

queueName為唯一標識

在這裡插入圖片描述

fanout型別

廣播形式

問題：生產者產生的訊息所有消費者都可以消費，可不可以指定某些消費者消費呢？

解決：採用direct路由模式

8. Routing-路由模式佇列

direct型別

問題：生產者產生的訊息如果場景需求過多需要設定很多路由規則，可不可以減少？

解決：採用topic主題模式。

9. Topics-主題模式佇列（常用）

在這裡插入圖片描述

topic型別

問題：RabbitMQ本身是基於非同步的訊息處理，是否可以同步實現？

解決：採用RPC模式。

10. RPC-遠端過程呼叫模式佇列

同步的

11. RabbitMQ訊息的事務機制

在使用RabbitMQ的時候，我們可以通過訊息持久化操作來解決因為伺服器的異常奔潰導致的訊息丟失，除此之外我們還會遇到一個問題，當訊息的釋出者在將訊息傳送出去之後，訊息到底有沒有正確到達broker代理伺服器呢？如果不進行特殊配置的話，預設情況下發布操作是不會返回任何資訊給生產者的，也就是預設情況下我們的生產者是不知道訊息有沒有正確到達broker的，如果在訊息到達broker之前已經丟失的話，持久化操作也解決不了這個問題，因為訊息根本就沒到達代理伺服器，你怎麼進行持久化，那麼這個問題該怎麼解決呢？

RabbitMQ為我們提供了兩種方式：

​ 通過AMQP事務機制實現，這也是AMQP協議層面提供的解決方案；

​ 通過將channel設定成confirm模式來實現；

11.1. AMQP事物機制控制

​ RabbitMQ中與事務機制有關的方法有三個： txSelect() , txCommit() 以及 txRollback(), txSelect() 用於將當前channel設定成transaction模式， txCommit() 用於提交事務，txRollback() 用於回滾事務，在通過 txSelect() 開啟事務之後，我們便可以釋出訊息給broker代理伺服器了，如果 txCommit() 提交成功了，則訊息一定到達了broker了，如果在 txCommit() 執行之前broker異常崩潰或者由於其他原因丟擲異常，這個時候我們便可以捕獲異常通過 txRollback() 回滾事務。

​

​ 事務確實能夠解決producer與broker之間訊息確認的問題，只有訊息成功被broker接受，事務提交才能成功，否則我們便可以在捕獲異常進行事務回滾操作同時進行訊息重發，但是使用事務機制的話會降低RabbitMQ的效能，那麼有沒有更好的方法既能保障producer知道訊息已經正確送到，又能基本上不帶來效能上的損失呢？從AMQP協議的層面看是沒有更好的方法，但是RabbitMQ提供了一個更好的方案，即將channel通道設定成confirm模式。

12. confirm確認模式

通過AMQP協議層面為我們提供了事務機制解決了這個問題，但是採用事務機制實現會降低RabbitMQ的訊息吞吐量，此時處理AMQP協議層面能夠實現訊息事物控制外，我們還有第二種方式即:Confirm模式。

12.3. 同步Confirm

12.4. 非同步confirm

非同步confirm模式的程式設計實現最複雜，Channel物件提供的 ConfirmListener() 回撥方法只包含deliveryTag （當前Chanel發出的訊息序號），我們需要自己為每一個Channel維護一個 unconfirm的訊息序號集合，每publish一條資料，集合中元素加1，每回調一次 handleAck 方法， unconfirm 集合刪掉相應的一條 （multiple=false） 或多條 （multiple=true） 記錄。從程式執行效率上看，這個 unconfirm 集合最好採用有序集合SortedSet儲存結構。實際上， waitForConfirms() 方法也是通過SortedSet維護訊息序號的。

​ 非同步模式的優點就是執行效率高，不需要等待訊息執行完，只需要監聽訊息即可。

13. Spring整合RabbitMQ

官網：https://spring.io/projects/spring-amqp

13.1. 為什麼使用spring AMQP？

​ 基於Spring之上社群活躍

​ 對AMQP協議進行了高度的封裝

​ 極大的簡化了RabbitMQ的操作

​ 易用性、可擴充套件

13.7. 總結

當然這是官網最簡單的例子，以後如果專案是基於配置來做的話要掌握以下：

  1. pom中引用jar

  2. 先配置rabbitmq的配置

    1. 先配置ConnectionFactory

    2. 配置RabbitAmdmin

  3. 配置RabbitTemplate這裡通常在配置一個Message Convert使用JSON進行資料格式的傳輸

  4. 配置Exchange

  5. 配置Queue

  6. 配置一個訊息處理的bean或者通過Spring掃描，這個Bean最後繼承MessageListener 來處理JSON數 據

​ 極大的簡化了RabbitMQ的操作

​ 易用性、可擴充套件

13.7. 總結

當然這是官網最簡單的例子，以後如果專案是基於配置來做的話要掌握以下：

  1. pom中引用jar

  2. 先配置rabbitmq的配置

    1. 先配置ConnectionFactory

    2. 配置RabbitAmdmin

  3. 配置RabbitTemplate這裡通常在配置一個Message Convert使用JSON進行資料格式的傳輸

  4. 配置Exchange

  5. 配置Queue

  6. 配置一個訊息處理的bean或者通過Spring掃描，這個Bean最後繼承MessageListener 來處理JSON數 據

  7. 配置Listener Container

相關推薦

微服務下，使用 ELK 進行日誌採集以及統一處理

摘要：微服務各個元件的相關實踐會涉及到工具，本文將會介紹微服務日常開發的一些利器，這些工具幫助我們構建更加健壯的微服務系統，並幫助排查解決微服務系統中的問題與效能瓶頸等。

cat 常用的日誌分析架構方案_在Linux環境下，對nginx日誌進行統計分析的幾個常用業務場景和常用命令...

技術標籤：cat 常用的日誌分析架構方案 日誌大體長的樣子 以下幾種業務場景，不是絕對，但是經常使用

記錄go-python微服務實踐，希望能幫助需要的人

介紹 本文講述如何使用 grpc，由 go 作為客戶端，python 作為服務端進行通訊。 （題外：一直迷惑於怎樣讓他們兩個連起來，後來才發現只要對同一個proto檔案進行編譯就好了。。。?）

基於微服務下的持續交付環境

背景 隨著網際網路行業的興起，敏捷開發、Devops被越來越多的公司提及或實施，力求有效地降低交付過程所耗費的成本並提高交付的效率。

CODING DevOps 系列第五課：微服務測試——微服務下展開體系化的微服務測試

微服務測試的痛點與挑戰 這張圖可以形象地展示單體服務和微服務的對比，單體應用就像左邊巨大的集裝箱，軟體模組和應用都包括其中；而微服務就像是由一個小集裝箱組成，微小的服務組成一個龐大、完整的系統。單體服務

任何階段都不能缺少的spring cloud微服務實戰，快來解析一波

前言 “微服務 ” 架構在這幾年被廣泛傳播， 變得非常火熱. 以至於關於微服務架構相關的開源框架和工具都變得越來越活躍，比如： Net和xOSS、

Java架構之微服務下微服務架構廣告設計系統實戰分散式微服務架構體系詳解

課程介紹 微服務架構的技術體系、社群目前已經越來越成熟。在最初系統架構的搭建，或者當現有架構已到達瓶頸需要進行架構演進時，很多架構師、運維工程師會考慮是否需要搭建微服務架構體系。雖然很多文章都說微服務架

阿里技術官16個月心血終成佳話，微服務先驅，重學SpringCloud

如果你沒聽說過微服務，也沒有聽說過Spring Cloud，或者你正在學習或嘗試使用SpringCloud去落地微服務架構，那麼本文會非常適合你。因為本文更加偏實戰，文中所講是一套可落地的解決方案。不管你是初學者、

主流SpringCloud微服務架構，您可少走彎路

背景 時間回到2017年底，那會兒SpringCloud正處於如火如荼的狀態，加上與K8s的完美契合，整個網際網路公司也想借著這波熱度做一次真真正正轉型，但真正能落地有經驗的人少之甚少，大部分公司還是摸著石頭過

微服務下的持續整合-Jenkins自動化部署GitHub專案

附圖一張我們的Jenkins： 二、DevOps概念 DevOps 一詞的來自於 Development 和 Operations 的組合，突出重視軟體開發人員和運維人員的溝通合作，通過自動化流程來使得軟體構建、測試、釋出更加快捷、頻繁和可靠。Dev

微服務架構，多後臺應用，一鍵啟動

微服務架構下多個後臺服務，設定一鍵啟動指令碼。 　　思想：每個後臺服務都有一個對應的 \'start.sh\' 啟動檔案，用來對單個服務進行啟動控制，而後增加一個總控指令碼檔案 \'power_on.sh\' ，用來對每個服務的啟動

EFK中fluentd替換logstash進行日誌採集

ogstash的替代軟體有很多，常用有的fluentd和Filebeat，這裡主要以fluentd替換logstash進行日誌採集。elasticsearch和kibana安裝可以參考ELK日誌分析平臺叢集搭建 ，下面主要介紹fluentd的安裝以及配置。

Feign的攔截器，用於在微服務間使用feign遠端呼叫其他微服務時，傳遞令牌

package com.changgou.interceptor; import feign.RequestInterceptor; import feign.RequestTemplate; import org.springframework.beans.factory.annotation.Autowired;

分散式ID，分散式鎖，限流演算法，微服務原則，CAP，BASE，雙寫一致性

分散式ID UUID，缺點：頁分裂佔空間。 資料庫主鍵，缺點：改造複雜，多個庫主鍵會重複。

Linux服務下，設定開機自啟動服務

首先理解，/etc配置檔案存放目錄（軟體的配置檔案存放）（Linux常用命令基礎），rc.local是啟動載入檔案。

雲原生下的指標與日誌採集

引言： 眾所周知，對於一個雲原生 PaaS 平臺而言，在頁面上檢視日誌與指標是最為基礎的功能。無論是日誌、指標還是鏈路追蹤，基本都分為採集、儲存和展示 3 個模組。

微服務模組，配置mysql

1.建module 2.改POM 3.寫YML 4.主啟動 5.業務類   vue  controller  service  dao  mysql    my.ini

系統架構 | 基於微服務架構，改造企業核心系統之實踐

背景與挑戰 隨著公司國際化戰略的推行以及本土業務的高速發展，後臺支撐系統已經不堪重負。

微服務洞察，讓微服務更透明

微服務作為雲原生時代下一種開發軟體的架構和組織方法，通過將明確定義的功能分成更小的服務，並讓每個服務獨立迭代，增加了應用程式的靈活性，允許開發者根據需要更輕鬆地更改部分應用程式。同時每個微服務可以由單

.NET Core微服務之基於Steeltoe使用Spring Cloud Config統一管理配置

此篇已加入.NET Core微服務基礎系列文章索引 =>Steeltoe目錄快速導航： 1.基於Steeltoe使用Spring Cloud Eureka