柚子快報邀請碼778899分享：架構 微服務和kafka

http://yzkb.51969.com/

一、微服務簡介

1.單體架構

分布式--微服務--云原生

傳統(tǒng)架構（單機系統(tǒng)），一個項目一個工程：比如商品、訂單、支付、庫存、登錄、注冊等等，統(tǒng)一部署，一個進程

all in one的架構方式，把所有的功能單元放在一個應用里。然后把整個應用部署到一臺服務器上。如果負載能力不行，將整個應用進行水平復制，進行擴展（擴展是指模塊擴展，不方便做開發(fā)測試），然后通過負載均衡實現(xiàn)訪問。

Java實現(xiàn)：JSP、Servlet，打包成一個jar、war部署易于開發(fā)和測試:也十分方便部署;當需要擴展時，只需要將war復制多份，然后放到多個服務器上，再做個負載均衡就可以了。如果某個功能模塊出問題，有可能全站不可訪問，修改Bug后、某模塊功能修改或升級后，需要停掉整個服務，重新整體重新打包、部署這個應用war包，功能模塊相互之間耦合度高,相互影響,不適合當今互聯(lián)網(wǎng)業(yè)務功能的快速迭代。特別是對于一個大型應用，我們不可能吧所有內容都放在一個應用里面，我們如何維護、如何分工合作都是問題。如果項目龐大，管理難度大

web應用服務器：開源的tomcat、jetty、glassfish。商用的有weblogic、websphere、Jboss

2.微服務

Microservices Guide

每個模塊跑一個單獨應用，微服務關注的業(yè)務邏輯（restful、API、http、grpc、tcp、http），

屬于SOA（Service Oriented Architecture）的子集

微服務化的核心就是將傳統(tǒng)的一站式應用，根據(jù)業(yè)務拆分成一個一個的服務，徹底去掉耦合，每一個微服務提供單個業(yè)務功能，一個服務只做一件事。每個服務都圍繞著具體業(yè)務進行構建，并且能夠被獨立地部署到生產環(huán)境、類生產環(huán)境等

從技術角度講就是一種小而獨立的處理過程，類似與進程的概念，能夠自行單獨啟動或銷毀

微服務架構（分布式系統(tǒng)），各個模塊/服務，各自獨立出來，"讓專業(yè)的人干專業(yè)的事"，獨立部署。分布式系統(tǒng)中，不同的服務可以使用各自獨立的數(shù)據(jù)庫。

服務之間采用輕量級的通信機制（通常是基于HTTP的RESTful API）。

微服務設計的思想改變了原有的企業(yè)研發(fā)團隊組織架構。傳統(tǒng)的研發(fā)組織架構是水平架構，前端、后端、DBA、測試分別有自己對應的團隊，屬于水平團隊組織架構。而微服務的設計思想對團隊的劃分有著一定的影響，使得團隊組織架構的劃分更傾向于垂直架構，比如用戶業(yè)務是一個團隊來負責，支付業(yè)務是一個團隊來負責。但實際上在企業(yè)中并不會把團隊組織架構拆分得這么絕對，垂直架構只是一種理想的架構

微服務的實現(xiàn)框架有多種，不同的應用架構，部署方式也有不同?

3.單體架構和微服務比較

單體架構的主要特征：

1.緊密耦合的組件：在單體架構中，組件之間緊密耦合，這使得修改和擴展應用程序的各個部分而不影響整個系統(tǒng)變得更加困難。

2.單一代碼庫：應用程序的所有部分都位于單一的代碼庫中，這對于開發(fā)和部署非常方便。

3.共享資源：組件共享相同的資源，如內存和CPU，這可能導致性能瓶頸和爭用問題。

4.有限的可擴展性：單體應用程序在水平方向上進行擴展可能具有挑戰(zhàn)性，因為擴展一個組件可能需要擴展整個應用程序。

5.復雜性：隨著應用程序的增長，由于復雜性增加，維護和理解可能變得困難。

微服務架構的主要特征：

1.松散耦合：微服務之間松散耦合，允許每個服務獨立開發(fā)、部署和擴展，而不影響其他服務。

2.分布式系統(tǒng)：微服務通過網(wǎng)絡通信，通常使用API，這需要仔細考慮網(wǎng)絡和通信模式。

3.獨立部署：服務可以獨立部署，實現(xiàn)持續(xù)交付和更快的發(fā)布周期。

4.專業(yè)化服務：每個微服務專注于特定的業(yè)務功能，使代碼庫更易于管理和維護。

5.可擴展性：微服務可以單獨擴展，根據(jù)需求有效地分配資源。

6.多語言架構：不同的微服務可以使用最適合其需求的不同編程語言和技術進行開發(fā)。?

4.微服務的優(yōu)缺點

微服務優(yōu)點：

每個服務足夠內聚，足夠小，代碼容易理解。這樣能聚焦一個簡單唯一的業(yè)務功能或業(yè)務需求。開發(fā)簡單、開發(fā)效率提高，一個服務可能就是專業(yè)的只干一件事，微服務能夠被小團隊單獨開發(fā)，這個小團隊可以是2到5人的開發(fā)人員組成

微服務是松耦合的，是有功能意義的服務，無論是在開發(fā)階段或部署階段都是獨立的。

微服務能使用不同的語言開發(fā)，易于和第三方集成，微服務運行容易且靈活的方式集成自動部署，通過持續(xù)集成工具，如:Jenkins、Hudson、Bamboo

微服務易于被一個開發(fā)人員理解、修改和維護，這樣小團隊能夠更關注自己的工作成果，無需通過合作才能體現(xiàn)價值

微服務允許你利用融合最新技術。微服務只是業(yè)務邏輯的代碼，不會和HTML/CSS或其他界面組件混合，即前后端分離

每個微服務都有自己的存儲能力，可以有自己的數(shù)據(jù)庫，也可以有統(tǒng)一數(shù)據(jù)庫

微服務缺點：（耦合性低，通信比較復雜，通過url）

微服務把原有的一個項目拆分成多個獨立工程，增加了開發(fā)(編寫API)、測試、運維(上線，需要會docker)、監(jiān)控等的復雜度

微服務架構需要保證不同服務之間的數(shù)據(jù)一致性，引入了分布式事務和異步補償機制，為設計和開發(fā)帶來一定挑戰(zhàn)

開發(fā)人員和運維需要處理分布式系統(tǒng)的復雜性，需要更強的技術能力

微服務適用于復雜的大系統(tǒng)，對于小型應用使用微服務，進行盲目的拆分只會增加其維護和開發(fā)成本

微服務技術棧

微服務治理：

注冊中心：將所有API、網(wǎng)關、Url，接口、端口所有調用的關系，放到注冊中心去，所有客戶端先訪問一個中間件發(fā)現(xiàn)中心，然后發(fā)現(xiàn)中心可以找到對應的調用關系，然后客戶再次訪問就可以訪問到對應的api節(jié)點

一旦微服務發(fā)生變更，會同步到注冊中心/目錄下

配置中心是一種統(tǒng)一管理各種應用配置的基礎服務組件。12

配置中心的主要作用是將配置從應用中抽取出來，進行統(tǒng)一管理，從而優(yōu)雅地解決配置的動態(tài)變更、權限管理、持久化、運維成本等問題。通過集中管理配置，配置中心將應用的配置作為一個單獨的服務抽離出來，同時也需要解決新的問題，如版本管理（為了支持回滾）、權限管理等。在系統(tǒng)架構中，配置中心是整個微服務基礎架構體系中的一個組件，雖然其功能看似簡單，即配置的管理和存取，但它是整個微服務架構中不可或缺的一環(huán)。

微服務網(wǎng)關：做業(yè)務的擴展，做OA系統(tǒng)（辦公、審計）

API網(wǎng)關：將多個不同業(yè)務的API整合在一起，業(yè)務的擴展、動態(tài)自制的管理反向代理、網(wǎng)關、負載均衡；API是入口，它還可以做限流（藍綠），流量控制、熔斷降級

微服務、分布式本質是區(qū)域中心化

異步通信技術：削峰、限流

把5個技術棧整合在一起，就會用到微服務框架

5.常見的微服務框架

Dubbo

阿里開源貢獻給了ASF，目前已經是Apache的頂級項目，一款高性能的Java RPC服務框架，微服務生態(tài)體系中的一個重要組件

將單體程序分解成多個功能服務模塊，模塊間使用Dubbo框架提供的高性能RPC通信

內部協(xié)調使用 Zookeeper，實現(xiàn)服務注冊、服務發(fā)現(xiàn)和服務治理

Spring cloud

一個完整的微服務解決方案，相當于Dubbo的超集

微服務框架，將單體應用拆分為粒度更小的單一功能服務

基于HTTP協(xié)議的REST(Representational State Transfer 表述性狀態(tài)轉移）風格實現(xiàn)模塊間通信

二、ZooKeeper

1.zookeeper介紹（注冊中心、配置中心）

ZooKeeper 是一個開源的分布式協(xié)調服務，ZooKeeper框架最初是在“Yahoo!"上構建的，用于以簡單而穩(wěn)健的方式訪問他們的應用程序。 后來，Apache ZooKeeper成為Hadoop，HBase和其他分布式框架使用的有組織服務的標準。 例如，Apache HBase使用ZooKeeper跟蹤分布式數(shù)據(jù)的狀態(tài)。ZooKeeper 的設計目標是將那些復雜且容易出錯的分布式一致性服務封裝起來，構成一個高效可靠的原語集，并以一系列簡單易用的接口提供給用戶使用。

ZooKeeper 是一個典型的分布式數(shù)據(jù)一致性解決方案，分布式應用程序可以基于 ZooKeeper 實現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱、負載均衡、命名服務、分布式協(xié)調/通知、集群管理、Master 選舉、分布式鎖（為了保持一致性，API、URL、配置文件內容保持一致）和分布式隊列等功能。

Zookeeper 一個最常用的使用場景就是用于擔任服務生產者和服務消費者的注冊中心(提供發(fā)布訂閱服務)。 服務生產者將自己提供的服務注冊到Zookeeper中心，服務的消費者在進行服務調用的時候先到Zookeeper中查找服務，獲取到服務生產者的詳細信息之后，再去調用服務生產者的內容與數(shù)據(jù)。如下圖所示，在 Dubbo架構中 Zookeeper 就擔任了注冊中心這一角色。

2.zookeeper工作原理

ZooKeeper 是一個分布式服務框架，它主要是用來解決分布式應用中經常遇到的一些數(shù)據(jù)管理問題，如：命名服務、狀態(tài)同步、配置中心、集群管理等。

①：ZooKeeper 功能

命名服務

命名服務是分布式系統(tǒng)中比較常見的一類場景。命名服務是分布式系統(tǒng)最基本的公共服務之一。在分布式系統(tǒng)中，被命名的實體通常可以是集群中的機器、提供的服務地址或遠程對象等——這些我們都可以統(tǒng)稱它們?yōu)槊郑∟ame），其中較為常見的就是一些分布式服務框架（如RPC、RMI）中的服務地址列表，通過使用命名服務，客戶端應用能夠根據(jù)指定名字來獲取資源的實體、服務地址和提供者的信息等。

Zookeeper 數(shù)據(jù)模型（樹狀結構）

在 Zookeeper 中，節(jié)點分為兩類，第一類是指構成Zookeeper集群的主機，稱之為主機節(jié)點；第二類則是指內存中zookeeper數(shù)據(jù)模型中的數(shù)據(jù)單元，用來存儲各種數(shù)據(jù)內容，稱之為數(shù)據(jù)節(jié)點 ZNode。Zookeeper內部維護了一個層次關系(樹狀結構)的數(shù)據(jù)模型，它的表現(xiàn)形式類似于Linux的文件系統(tǒng)，甚至操作的種類都一致。

Zookeeper數(shù)據(jù)模型中有自己的根目錄(/)，根目錄下有多個子目錄，每個子目錄后面有若干個文件,由斜杠(/)進行分割的路徑，就是一個ZNode,每個 ZNode上都會保存自己的數(shù)據(jù)內容和一系列屬性信息.（把狀態(tài)，相關模塊都放在注冊中心）

狀態(tài)同步

每個節(jié)點除了存儲數(shù)據(jù)內容和 node 節(jié)點狀態(tài)信息之外，還存儲了已經注冊的APP 的狀態(tài)信息，當有些節(jié)點或APP 不可用，就將當前狀態(tài)同步給其他服務。

配置中心

現(xiàn)在我們大多數(shù)應用都是采用的是分布式開發(fā)的應用，搭建到不同的服務器上，我們的配置文件，同一個應用程序的配置文件一樣，還有就是多個程序存在相同的配置，當我們配置文件中有個配置屬性需要改變，我們需要改變每個程序的配置屬性，這樣會很麻煩的去修改配置，那么可用使用ZooKeeper 來實現(xiàn)配置中心， ZooKeeper 采用的是推拉相結合的方式：客戶端向服務端注冊自己需要關注的節(jié)點，一旦該節(jié)點的數(shù)據(jù)發(fā)生變更，那么服務端就會向相應的客戶端發(fā)送Watcher事件通知，客戶端接收到這個消息通知后，需要主動到服務端獲取最新的數(shù)據(jù)。

Apollo（阿波羅）是攜程框架部門研發(fā)的開源配置管理中心,此應用比較流行

集群管理

所謂集群管理，包括集群監(jiān)控與集群控制兩大塊，前者側重對集群運行時狀態(tài)的收集，后者則是對集群進行操作與控制，在日常開發(fā)和運維過程中，我們經常會有類似于如下的需求：

希望知道當前集群中究竟有多少機器在工作。

對集群中每臺機器的運行時狀態(tài)進行數(shù)據(jù)收集。對集群中機器進行上下線操作。

ZooKeeper 具有以下兩大特性:

客戶端如果對ZooKeeper 的一個數(shù)據(jù)節(jié)點注冊 Watcher監(jiān)聽，那么當該數(shù)據(jù)節(jié)點的內容或是其子節(jié)點列表發(fā)生變更時，ZooKeeper服務器就會向已注冊訂閱的客戶端發(fā)送變更通知。對在ZooKeeper上創(chuàng)建的臨時節(jié)點，一旦客戶端與服務器之間的會話失效，那么該臨時節(jié)點也就被自動清除。

Watcher（事件監(jiān)聽器）是 Zookeeper 中的一個很重要的特性。Zookeeper 允許用戶在指定節(jié)點上注冊一些 Watcher，并且在一些特定事件觸發(fā)的時候， ZooKeeper 服務端會將事件通知到感興趣的客戶端上去，該機制是 Zookeeper 實現(xiàn)分布式協(xié)調服務的重要特性。

ZooKeeper 服務流程

1. 生產者啟動

2. 生產者注冊至zookeeper

3. 消費者啟動并訂閱頻道

4. zookeeper 通知消費者事件

5. 消費者調用生產者

6. 監(jiān)控中心負責統(tǒng)計和監(jiān)控服務狀態(tài)

3.zookeeper單機部署

官方文檔:https://zookeeper.apache.org/doc/r3.9.0/zookeeperStarted.html#sc_InstallingSingleMode

配置 Java 環(huán)境

官方依賴介紹? ZooKeeper: Because Coordinating Distributed Systems is a Zoo

案例: 安裝單機 zookeeper

wget -P /usr/local/src https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/stable/apache-zookeeper3.9.0-bin.tar.gz

tar xf /usr/local/src/apache-zookeeper-3.9.0-bin.tar.gz -C /usr/local/? ---解壓包

ln -s /usr/local/apache-zookeeper-3.9.0-bin /usr/local/zookeeper? ---做軟鏈接

echo 'PATH=/usr/local/zookeeper/bin:$PATH' > /etc/profile.d/zookeeper.sh? ---做環(huán)境變量

. /etc/profile.d/zookeeper.sh? ?---運行環(huán)境變量

cp /usr/local/zookeeper/conf/zoo_sample.cfg /usr/local/zookeeper/conf/zoo.cfg ---做數(shù)據(jù)目錄

?

tickTime=2000? #"滴答時間"，用于配置Zookeeper中最小的時間單元長度，單位毫秒，是其它時間配置的基礎

initLimit=10?? #初始化時間，包含啟動和數(shù)據(jù)同步，其值是tickTime的倍數(shù)

syncLimit=5??? #正常工作，心跳監(jiān)測的時間間隔，其值是tickTime的倍數(shù)

dataDir=/tmp/zookeeper #配置Zookeeper服務存儲數(shù)據(jù)的目錄,基于安全,可以修改為dataDir=/usr/local/zookeeper/data

#dataLogdir=/usr/local/zookeeper/logs #可以指定日志路徑

clientPort=2181 #配置當前Zookeeper服務對外暴露的端口，用戶客戶端和服務端建立連接會話

autopurge.snapRetainCount=3 #3.4.0中的新增功能：啟用后，ZooKeeper 自動清除功能,會將只保留此最新3個快照和相應的事務日志,并分別保留在dataDir 和dataLogDir中，刪除其余部分，默認值為3,最小值為3

autopurge.purgeInterval=24? #3.4.0及之后版本，ZK提供了自動清理日志和快照文件的功能，這個參數(shù)指定了清理頻率，單位是小時，需要配置一個1或更大的整數(shù)，默認是 0，表示不開啟自動清理功能

啟動 ZooKeeper

zkServer.sh start-foreground

zkServer.sh start

4.zookeeper集群部署

ZooKeeper集群用于解決單點和單機性能及數(shù)據(jù)高可用等問題

?

zookeeper集群基于Master/Slave的模型，處于主要地位(處理寫操作)的主機稱為Master節(jié)點，處于次要地位(處理讀操作)的主機稱為 slave節(jié)點，生產中讀取的方式一般是以異步復制方式來實現(xiàn)的。

對于n臺server,每個server都知道彼此的存在。只要有>n/2臺server節(jié)點可用，整個zookeeper系統(tǒng)保持可用。保證zookeep是基數(shù)節(jié)點，不可以為偶數(shù)

因此zookeeper集群通常由奇數(shù)臺Server節(jié)點組成

當進行寫操作時,由leader完成,并且同步到其它follower節(jié)點,當在保證寫操作在所有節(jié)點的總數(shù)過半后,才會認為寫操作成功

下圖表示讀的比例越高,性能越好

機器越多，寫性能就越差

集群角色?

?

領導者(Leader)??? 負責處理寫入請求的，事務請求的唯一調度和處理者,負責進行投票發(fā)起和決議，更新系統(tǒng)狀態(tài)

跟隨者(Follower) ??接收客戶請求并向客戶端返回結果，在選Leader過程中參與投票

觀察者(Observer)?? 轉交客戶端寫請求給leader節(jié)點，和同步leader狀態(tài)

? ? ? ? ? ? ? ? ? ? ? ? ? ?和Follower唯一區(qū)別就是不參與Leader投票,也不參與寫操作的"過半寫成功"策略

學習者(Learner)??? 和leader進行狀態(tài)同步的節(jié)點統(tǒng)稱Learner，包括:Follower和Observer

客戶端(client) ?????請求發(fā)起方

選舉過程

節(jié)點角色狀態(tài)：

LOOKING：尋找 Leader 狀態(tài)，處于該狀態(tài)需要進入選舉流程

LEADING：領導者狀態(tài)，處于該狀態(tài)的節(jié)點說明是角色已經是Leader

FOLLOWING：跟隨者狀態(tài)，表示 Leader已經選舉出來，當前節(jié)點角色是follower

OBSERVER：觀察者狀態(tài)，表明當前節(jié)點角色是 observer

選舉 ID：

ZXID（zookeeper transaction id）：每個改變 Zookeeper狀態(tài)的操作都會形成一個對應的zxid。

ZXID最大的節(jié)點優(yōu)先選為Leader

myid：服務器的唯一標識(SID)，通過配置 myid 文件指定，集群中唯一,當ZXID一樣時,myid大的節(jié)點優(yōu)先選為Leader

ZooKeeper 集群選舉過程：

當集群中的 zookeeper 節(jié)點啟動以后，會根據(jù)配置文件中指定的 zookeeper節(jié)點地址進行l(wèi)eader 選擇操作，過程如下：

每個zookeeper 都會發(fā)出投票，由于是第一次選舉leader，因此每個節(jié)點都會把自己當做leader 角色進行選舉，每個zookeeper 的投票中都會包含自己的myid和zxid，此時zookeeper 1 的投票為myid 為 1，初始zxid有一個初始值0x0，后期會隨著數(shù)據(jù)更新而自動變化，zookeeper2 的投票為myid 為2，初始zxid 為初始生成的值。每個節(jié)點接受并檢查對方的投票信息，比如投票時間、是否狀態(tài)為LOOKING狀態(tài)的投票。對比投票，優(yōu)先檢查zxid，如果zxid 不一樣則 zxid 大的為leader，如果zxid相同則繼續(xù)對比myid，myid 大的一方為 leader成為 Leader 的必要條件： Leader 要具有最高的zxid；當集群的規(guī)模是 n 時，集群中大多數(shù)的機器（至少n/2+1）得到響應并follower 選出的 Leader。

心跳機制：Leader 與 Follower 利用 PING 來感知對方的是否存活，當 Leader無法響應PING 時，將重新發(fā)起 Leader 選舉。當 Leader 服務器出現(xiàn)網(wǎng)絡中斷、崩潰退出與重啟等異常情況時，ZAB(Zookeeper Atomic Broadcast) 協(xié)議就會進入恢復模式并選舉產生新的Leader服務器。這個過程大致如下：

Leader Election（選舉階段）：節(jié)點在一開始都處于選舉階段，只要有一個節(jié)點得到超半數(shù)節(jié)點的票數(shù)，它就可以當選準 leader。

Discovery（發(fā)現(xiàn)階段）：在這個階段，followers 跟準 leader 進行通信，同步 followers 最近接收的事務提議。

Synchronization（同步階段）:同步階段主要是利用 leader 前一階段獲得的最新提議歷史，同步集群中所有的副本。同步完成之后 準 leader 才會成為真正的 leader。

Broadcast（廣播階段） ：到了這個階段，Zookeeper 集群才能正式對外提供事務服務，并且leader 可以進行消息廣播。同時如果有新的節(jié)點加入，還需要對新節(jié)點進行同步

ZAB 協(xié)議介紹

ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協(xié)議是為分布式協(xié)調服務 ZooKeeper 專門設計的一種支持崩潰恢復的原子廣播協(xié)議。 在 ZooKeeper 中，主要依賴 ZAB 協(xié)議來實現(xiàn)分布式數(shù)據(jù)一致性，基于該協(xié)議，ZooKeeper 實現(xiàn)了一種主備模式的系統(tǒng)架構來保持集群中各個副本之間的數(shù)據(jù)一致性。

ZooKeeper 集群特性

整個集群中只要有超過集群數(shù)量一半的 zookeeper工作是正常的，那么整個集群對外就是可用的假如有 2 臺服務器做了一個 Zookeeper 集群，只要有任何一臺故障或宕機，那么這個 ZooKeeper集群就不可用了，因為剩下的一臺沒有超過集群一半的數(shù)量，但是假如有三臺zookeeper 組成一個集群， 那么損壞一臺就還剩兩臺，大于 3臺的一半，所以損壞一臺還是可以正常運行的，但是再損壞一臺就只剩一臺集群就不可用了。那么要是 4 臺組成一個zookeeper集群，損壞一臺集群肯定是正常的，那么損壞兩臺就還剩兩臺，那么2臺不大于集群數(shù)量的一半，所以 3 臺的 zookeeper 集群和 4 臺的 zookeeper集群損壞兩臺的結果都是集群不可用，以此類推 5 臺和 6 臺以及 7 臺和 8臺都是同理

另外偶數(shù)節(jié)點可以會造成"腦裂"現(xiàn)象,所以這也就是為什么集群一般都是奇數(shù)的原因。

ZooKeeper 集群部署

運行腳本進行安裝

配置文件和單機模式略微不同之處

?nc 訪問 ZooKeeper

ZooKeeper支持某些特定的四字命令字母與其的交互。它們大多是查詢命令，用來獲取 ZooKeeper服務的當前狀態(tài)及相關信息。用戶在客戶端可以通過 netcat 或telnet向zookeeper發(fā)送下面命令

conf #輸出相關服務配置的詳細信息

cons #列出所有連接到服務器的客戶端的完全的連接/會話的詳細信息

envi #輸出關于服務環(huán)境的詳細信息

dump #列出未經處理的會話和臨時節(jié)點

stat #查看哪個節(jié)點被選擇作為Follower或者Leader

ruok #測試是否啟動了該Server，若回復imok表示已經啟動

mntr #輸出一些運行時信息

reqs #列出未經處理的請求

wchs #列出服務器watch的簡要信息

wchc #通過session列出服務器watch的詳細信息

wchp #通過路徑列出服務器watch的詳細信息

srvr #輸出服務的所有信息

srst #重置服務器統(tǒng)計信息

kill #關掉Server

isro #查看該服務的節(jié)點權限信息

將所有四字命令加入白名單

vim conf/zoo.cfg

4lw.commands.whitelist=*

echo stat | nc 127.0.0.1 2181

?

?

改完之后重啟服務：systemctl restart zookeeper.service?

圖形化客戶端 ZooInspector

git clone GitHub - zzhang5/zooinspector: An improved zookeeper inspector?? 然后結合阿里云加速進行mvn編譯即可使用

cd zooinspector/

mvn clean package -Dmaven.test.skip=true

chmod +x target/zooinspector-pkg/bin/zooinspector.sh

target/zooinspector-pkg/bin/zooinspector.sh

三、kafka

消息隊列歷史

2007 年的時候，Rabbit 技術公司基于Erlang語言開發(fā)了符合AMQP 規(guī)范RabbitMQ 1.0。

從最開始用在金融行業(yè)里面，現(xiàn)在MQ 已經在世界各地的公司中遍地開花。國內的絕大部分大廠都在用MQ，包括頭條，美團，滴滴，去哪兒，藝龍，淘寶也有用。

kafka的數(shù)據(jù)是存儲到zookeep中的/目錄下，kafka嫁接在zookeep上，kafka的消息是分片的，

MQ 定義

在分布式場景中，相對于大量的用戶請求來說，內部的功能主機之間、功能模塊之間等，數(shù)據(jù)傳遞的數(shù)據(jù)量是無法想象的，因為一個用戶請求，會涉及到各種內部的業(yè)務邏輯跳轉等操作。那么，在大量用戶的業(yè)務場景中，如何保證所有的內部業(yè)務邏輯請求都處于穩(wěn)定而且快捷的數(shù)據(jù)傳遞呢? 消息隊列(Message Queue)技術可以滿足此需求

消息隊列（Message Queue，簡稱 MQ）是構建分布式互聯(lián)網(wǎng)應用的基礎設施，通過 MQ 實現(xiàn)的松耦合架構設計可以提高系統(tǒng)可用性以及可擴展性，是適用于現(xiàn)代應用的最佳設計方案。

消息隊列是一種異步的服務間通信方式，適用于無服務器和微服務架構。消息在被處理和刪除之前一直存儲在隊列上。每條消息僅可被一位用戶處理一次。消息隊列可被用于分離重量級處理、緩沖或批處理工作以及緩解高峰期工作負載。

MQ 使用場合

消息隊列作為高并發(fā)系統(tǒng)的核心組件之一，能夠幫助業(yè)務系統(tǒng)結構提升開發(fā)效率和系統(tǒng)穩(wěn)定性

消息隊列主要有以下應用場景

削峰填谷

諸如電商業(yè)務中的秒殺、搶紅包、企業(yè)開門紅等大型活動時皆會帶來較高的流量脈沖，或因沒做相應的保護而導致系統(tǒng)超負荷甚至崩潰，或因限制太過導致請求大量失敗而影響用戶體驗，消息隊列可提供削峰填谷的服務來解決該問題。

異步解耦

交易系統(tǒng)作為淘寶等電商的最核心的系統(tǒng)，每筆交易訂單數(shù)據(jù)的產生會引起幾百個下游業(yè)務系統(tǒng)的關注，包括物流、購物車、積分、流計算分析等等，整體業(yè)務系統(tǒng)龐大而且復雜，消息隊列可實現(xiàn)異步通信和應用解耦，確保主站業(yè)務的連續(xù)性。

順序收發(fā)

細數(shù)日常中需要保證順序的應用場景非常多，例如證券交易過程時間優(yōu)先原則，交易系統(tǒng)中的訂單創(chuàng)建、支付、退款等流程，航班中的旅客登機消息處理等等。與先進先出FIFO（First In First Out）原理類似，消息隊列提供的順序消息即保證消息FIFO。

分布式事務一致性（zookeep）

交易系統(tǒng)、支付紅包等場景需要確保數(shù)據(jù)的最終一致性，大量引入消息隊列的分布式事務，既可以實現(xiàn)系統(tǒng)之間的解耦，又可以保證最終的數(shù)據(jù)一致性。

大數(shù)據(jù)分析

數(shù)據(jù)在“流動”中產生價值，傳統(tǒng)數(shù)據(jù)分析大多是基于批量計算模型，而無法做到實時的數(shù)據(jù)分析，利用消息隊列與流式計算引擎相結合，可以很方便的實現(xiàn)業(yè)務數(shù)據(jù)的實時分析。

分布式緩存同步

電商的大促，各個分會場琳瑯滿目的商品需要實時感知價格變化，大量并發(fā)訪問數(shù)據(jù)庫導致會場頁面響應時間長，集中式緩存因帶寬瓶頸，限制了商品變更的訪問流量，通過消息隊列構建分布式緩存，實時通知商品數(shù)據(jù)的變化

蓄流壓測

線上有些鏈路不方便做壓力測試，可以通過堆積一定量消息再放開來壓測

消息隊列在測試環(huán)境做壓測，先不在生產環(huán)境上線

主流 MQ

目前主流的消息隊列軟件有 kafka、RabbitMQ、ActiveMQ、RocketMQ等，還有相對小眾的消息隊列軟件如ZeroMQ、Apache Qpid 等。

kafka不能做集群，但是可以基于zookeep做集群

Kafka 介紹

Kafka 被稱為下一代分布式消息系統(tǒng)，由 Scala 和 Java編寫，是非營利性組織ASF(Apache Software Foundation)基金會中的一個開源項目，比如:HTTP Server、Tomcat、Hadoop、ActiveMQ等開源軟件都屬于 Apache基金會的開源軟件，類似的消息系統(tǒng)還有RabbitMQ、ActiveMQ、ZeroMQ。

Kafka用于構建實時數(shù)據(jù)管道和流應用程序。 它具有水平可伸縮性，容錯性，快速性，可在數(shù)千家組織中同時投入生產協(xié)同工作。

Kafka 特點和優(yōu)勢

特點

分布式: 多機實現(xiàn),不允許單機

分區(qū): 一個消息.可以拆分出多個，分別存儲在多個位置

多副本: 防止信息丟失，可以多來幾個備份

多訂閱者: 可以有很多應用連接kafka，在kafka中沒有嚴格的說法，都叫訂閱者

Zookeeper: 早期版本的Kafka依賴于zookeeper， 2021年4月19日Kafka 2.8.0正式發(fā)布，此版本包括了很多重要改動，最主要的是kafka通過自我管理的仲裁來替代ZooKeeper，即Kafka將不再需要ZooKeeper！

優(yōu)勢

Kafka 通過 O(1)的磁盤數(shù)據(jù)結構提供消息的持久化，這種結構對于即使數(shù)以 TB 級別以上的消息存儲也能夠保持長時間的穩(wěn)定性能。

高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒數(shù)百萬的消息。支持通過Kafka 服務器分區(qū)消息。

分布式： Kafka 基于分布式集群實現(xiàn)高可用的容錯機制，可以實現(xiàn)自動的故障轉移

順序保證：在大多數(shù)使用場景下，數(shù)據(jù)處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證數(shù)據(jù)會按照特定的順序來處理。 Kafka保證一個Partiton內的消息的有序性（分區(qū)間數(shù)據(jù)是無序的，如果對數(shù)據(jù)的順序有要求，應將在創(chuàng)建主題時將分區(qū)數(shù)partitions設置為1）

支持 Hadoop 并行數(shù)據(jù)加載

通常用于大數(shù)據(jù)場合,傳遞單條消息比較大，而Rabbitmq （支持單條小消息）消息主要是傳輸業(yè)務的指令數(shù)據(jù),單條數(shù)據(jù)較小，不適合集群化大規(guī)模的場景

Kafka 角色

Producer：Producer即生產者，消息的產生者，是消息的入口。負責發(fā)布消息到Kafka broker。

Consumer：消費者，用于消費消息，即處理消息

Consumer group: 每個consumer 屬于一個特定的consumer group（可為每個consumer 指定 group name，若不指定 group name 則屬于默認的group），使用 consumer high level API 時，同一topic的一條消息只能被同一個consumer group 內的一個consumer 消費，但多個consumer group 可同時消費這一消息。

Broker：Broker是kafka實例，每個服務器上可以有一個或多個kafka的實例，假設每個broker對應一臺服務器。每個kafka集群內的broker都有一個不重復的編號，如: broker-0、broker-1等……

Topic ：消息的主題，可以理解為消息的分類，相當于Redis的Key和ES中的索引，kafka的數(shù)據(jù)就保存在topic。在每個broker上都可以創(chuàng)建多個topic。物理上不同 topic 的消息分開存儲在不同的文件夾，邏輯上一個 topic的消息雖然保存于一個或多個broker 上, 但用戶只需指定消息的topic即可生產或消費數(shù)據(jù)而不必關心數(shù)據(jù)存于何處，topic 在邏輯上對record(記錄、日志)進行分組保存，消費者需要訂閱相應的topic 才能消費topic中的消息。

Replication: 同樣數(shù)據(jù)的副本，包括leader和follower的副本數(shù),基本于數(shù)據(jù)安全,建議至少2個,是Kafka的高可靠性的保障，和ES不同的，ES中的副本數(shù)不包括主分片數(shù)

Partition ：是物理上的概念，每個topic 分割為一個或多個partition，即一個topic切分為多份.創(chuàng)建topic時可指定 parition 數(shù)量，partition的表現(xiàn)形式就是一個一個的文件夾,該文件夾下存儲該partition的數(shù)據(jù)和索引文件，分區(qū)的作用還可以實現(xiàn)負載均衡，提高kafka的吞吐量。同一個topic在不同的分區(qū)的數(shù)據(jù)是不重復的,一般Partition數(shù)不要超過節(jié)點數(shù)據(jù)，注意同一個partition數(shù)據(jù)是有順序的，但不同的partition則是無序的。為了實現(xiàn)數(shù)據(jù)的高可用，比如將分區(qū) 0 的數(shù)據(jù)分散到不同的kafka 節(jié)點，每一個分區(qū)都有一個 broker 作為 Leader 和一個 broker 作為Follower，類似于ES中的主分片和副本分片，

AR： Assigned Replicas，分區(qū)中的所有副本的統(tǒng)稱，AR= lSR+ OSR

lSR：ln Sync Replicas，所有與leader副本保持同步的副本 follower和leader本身組成的集合，是AR的子集

OSR：out-of-Sync Replied，所有與leader副本同步不能同步的 follower的集合，是AR的子集

分區(qū)的優(yōu)勢：

實現(xiàn)存儲空間的橫向擴容，即將多個kafka服務器的空間結合利用提升性能，多服務器讀寫

實現(xiàn)高可用，分區(qū)leader 分布在不同的kafka 服務器，假設分區(qū)因子為 3, 分區(qū) 0 的leader為服務器A，則服務器 B 和服務器 C 為 A 的follower，而分區(qū) 1 的leader為服務器B，則服務器 A 和C 為服務器B 的follower，而分區(qū) 2 的leader 為C，則服務器A 和 B 為C 的follower。

假如設置一個wang的topic,它會生成多個目錄，在第一臺機器上有兩個目錄，一個存主本，一個存副本；第二個機器有兩個目錄，一個存主本，一個存副本；第三個機器有兩個目錄，都存副本。交叉是為了防止崩，這樣做可以保證數(shù)據(jù)的高可用

Kafka 寫入消息的流程

Kafka 部署

當前版本 Kafka 依賴 Zookeeper 服務,但以后將不再依賴

環(huán)境說明

#在三個節(jié)點提前部署zookeeper和kafka三個節(jié)點復用

node1:192.168.10.110

node2:192.168.10.110

node3:192.168.10.110

注意:生產中zookeeper和kafka一般是分開獨立部署的,kafka安裝前需要安裝java環(huán)境；確保三個節(jié)點的zookeeper啟動

Kafka 節(jié)點配置

配置文件說明

#配置文件 ./conf/server.properties內容說明

############################# Server Basics###############################

# broker的id，值為整數(shù)，且必須唯一，在一個集群中不能重復

broker.id=1

############################# Socket ServerSettings ######################

# kafka監(jiān)聽端口，默認9092

listeners=PLAINTEXT://10.0.0.101:9092

# 處理網(wǎng)絡請求的線程數(shù)量，默認為3個

num.network.threads=3

# 執(zhí)行磁盤IO操作的線程數(shù)量，默認為8個

num.io.threads=8

# socket服務發(fā)送數(shù)據(jù)的緩沖區(qū)大小，默認100KB

socket.send.buffer.bytes=102400

# socket服務接受數(shù)據(jù)的緩沖區(qū)大小，默認100KB

socket.receive.buffer.bytes=102400

# socket服務所能接受的一個請求的最大大小，默認為100M

socket.request.max.bytes=104857600

############################# Log Basics###################################

# kafka存儲消息數(shù)據(jù)的目錄

log.dirs=../data

# 每個topic默認的partition

num.partitions=1

# 設置副本數(shù)量為3,當Leader的Replication故障，會進行故障自動轉移。

default.replication.factor=3

# 在啟動時恢復數(shù)據(jù)和關閉時刷新數(shù)據(jù)時每個數(shù)據(jù)目錄的線程數(shù)量

num.recovery.threads.per.data.dir=1

############################# Log FlushPolicy #############################

# 消息刷新到磁盤中的消息條數(shù)閾值

log.flush.interval.messages=10000

# 消息刷新到磁盤中的最大時間間隔,1s

log.flush.interval.ms=1000

############################# Log RetentionPolicy #########################

# 日志保留小時數(shù)，超時會自動刪除，默認為7天

log.retention.hours=168

# 日志保留大小，超出大小會自動刪除，默認為1G

#log.retention.bytes=1073741824

# 日志分片策略，單個日志文件的大小最大為1G，超出后則創(chuàng)建一個新的日志文件

log.segment.bytes=1073741824

# 每隔多長時間檢測數(shù)據(jù)是否達到刪除條件,300s

log.retention.check.interval.ms=300000

############################# Zookeeper ####################################

# Zookeeper連接信息，如果是zookeeper集群，則以逗號隔開

zookeeper.connect=192.168.10.110:2181,192.168.10.120:2181,192.168.10.130:2181

# 連接zookeeper的超時時間,6s

zookeeper.connection.timeout.ms=6000

Kafka 讀寫數(shù)據(jù)?

kafka-topics.sh # 消息的管理命令

kafka-console-producer.sh?? #生產者的模擬命令

kafka-console-consumer.sh?? #消費者的模擬命令

創(chuàng)建 Topic

創(chuàng)建名為 wang，partitions(分區(qū))為3，replication(每個分區(qū)的副本數(shù)/每個分區(qū)的分區(qū)因子)為 2 的topic(主題)

/usr/local/kafka/bin/kafka-topics.sh --create --topic wang --bootstrap-server 192.168.10.110:9092 --partitions 3 --replication-factor 2

#? 在各節(jié)點上觀察生成的相關數(shù)據(jù)

ls /usr/local/kafka/data/

#? 獲取所有 Topic

/usr/local/kafka/bin/kafka-topics.sh --list --bootstrap-server 192.168.10.110:9092

#? 驗證 Topic 詳情

/usr/local/kafka/bin/kafka-topics.sh --describe --bootstrapserver 192.168.10.110:9092 --topic wang

#? 生產 Topic

/usr/local/kafka/bin/kafka-console-producer.sh --broker-list 192.168.10.110:9092,192.168.10.120:9092,192.168.10.130:9092 --topic wang

#? 消費 Topic

/usr/local/kafka/bin/kafka-console-consumer.sh --topic wang --bootstrap-server 192.168.10.110:9092 --from-beginning

#? 刪除 Topic

/usr/local/kafka/bin/kafka-topics.sh --delete --bootstrap-server 192.168.10.110:2181,192.168.10.120:2181,192.168.10.130:2181 --topic wang

?

創(chuàng)建消息

?在toplic中生產一下對應的生產消息

?消費消息

刪除wang這條消息

如何在應用程序中關聯(lián)kafka

首先基于filebeat從應用/web端將數(shù)據(jù)先收集進來，然后將數(shù)據(jù)先放入kafka中，然后將其適當?shù)姆制瑀edis做緩存，kafka做消息，然后將基于logstash的INPUT模塊去關聯(lián)kafka，把kafka/redis中消息消費出來，然后輸出值es中

柚子快報邀請碼778899分享：架構 微服務和kafka

http://yzkb.51969.com/

推薦鏈接