# 虎年行大運 ~ Kafka - 開始的前因後果

## 【前言】
延宕了好久，終於要進入到學習 Kafka 的時候了!!

先跟大家道歉，一個標題掛那麼久才要開始寫... (深深一鞠躬

## 【單一系統到微服務架構】
對於 Back-End 程式設計師來說，MessageQueue 是一個必定會聽過的名詞，他就是俗稱的**訊息處理隊列**，或者我們可以更白話一點 -- **訊息處理中心**

有人可能會想，為什麼我們需要一個訊息處理中心呢?
對於系統架構發展有興趣的人可以先複習一下這篇 [虎年行大運 ~ SpringCloud - 負載平衡架構介紹](/MSPE1vCPTlaIP6Cm0DLxcQ)

世界正因為網際網路的發達進入了一個**資訊量爆炸**的時代，各位所接觸到的東西可能已經不需要花費長久的時間才能觸及，你可以在美國東岸獲取到西岸即時報導的新聞資訊；你可以在台灣從 Youtube 上瀏覽來自巴西上傳的影片。

在商業上，所面對的客戶已經從實體店面轉向了網路商城，到店的來客率也變成了商品被瀏覽數。營業策略的重點已經逐漸轉為數字化經營模式，為此你所需要的設備已經不是以往面對十幾人、百多人的小系統，而是必須扛住這數千、數萬不同訪問需求的大系統。

而若只是單純地將以往的系統架構給放大、再放大，則會失去面對未知的挑戰的彈性與變化的靈活度，永遠無法保證單一商業策略是否可以在現今的環境中生存，否則 Aamzon、Google 這種超大型企業為何要發展多角化經營?

回到系統架構來說，單純增添設備、買昂貴的 CPU、擴充硬碟、增加 RAM 並不能完全的解決資訊需求暴增的狀況，因此系統從單個大系統，逐漸轉變成小而精的多服務系統架構已是不可擋的趨勢，也就是目前常見的 -- **微服務架構**
> 要強調視應用面的不同，工程師們應因地制宜採用適當的系統架構為主，上述說的是面對巨量訪問需求的商業服務狀況。
>
> Kai 身邊仍有不少軟體公司打造的商品是採用單一系統架構，其客戶的商業服務不用面對高流量的問題，因此就不需要微服務架構了。
>
> BTW，如何把錢花的每一分都值得，亦是系統分析師、架構師(SA、SD) 的一大考驗

## 【訊息交換中心】
在微服務架構中，服務跟服務之間或多或少是需要交換訊息的，否則可能會發生漏資料、文不對題等錯誤發生。

例如：顧客在一個電商網站中下訂單，訂單的資訊需要給撿貨系統、倉儲系統、物流系統、甚至是財務系統知道，但每一個系統都還需要等待不同的系統處理好需要的資料才能繼續動作。
- 撿貨前需要倉儲告知商品庫存量
- 物流要等待撿貨完成
- 財務要等物流完成交付、金額入帳時啟動會計功能

面對一個又一個功能的 Pending，中間都需要有人去做通知處理，過往的做法可能是採用所謂的定時程式，類似分鐘結算、小時結算、一日結算、一周結算，甚至一月結算去處理，這在低流量的需求上沒太多問題，但在高流量的時候，速度就會慢了下來，且累積的量會越來越多！

因此就需要一個即時訊息交換的方式去不停的消化、吞吐這些流量資料，避免累積、同時讓這些事情可以統一在一個系統內自動完成，而不需要太多的程式或工法支援。

MessageQueue 就在這樣一個需求下，誕生了！
在其中的 Kafka，就是這篇與未來數篇章的主角~

首頁 [Kai 個人技術 Hackmd](/2G-RoB0QTrKzkftH2uLueA)

###### tags: `Kafka`