簡介微服務架構

Freddy
Aiii
Published in
6 min readOct 4, 2019

工程師的快樂就是這麼的樸實無華且枯燥

前言

近年來,「微服務」這三個字儼然已經成為業界主流,但是到底什麼是微服務,以及微服務所帶來的好處,還有為什麼大家會雨後春筍的使用,我想大家可能就沒有那麼清楚。本篇文章會透過 Aiii 的 ChatBot 架構簡單的說明並且帶大家認識微服務。

什麼是微服務

大家可以先想像一下,在一間公司裡面我們都會分好幾個部門,並且在每個部門底下,又會有負責的主管,主管底下又會有負責專案的PM,PM 下面才會是執行專案的人,我們這樣做的目的,不就是希望我們可以讓每件事情簡單化,並且一個 PM 負責一件專案(雖然好像不太可能,但是先假裝這樣),這樣在處理事情上面也會比較簡單且有效率。假設如果今天老闆突然把新的需求砸下來,也只會影響到那個專案,不會讓整個部門甚至是整間公司都必須一起改變,進而減少大家森77以及加班的機會。

再試想一個情境,我們丟垃圾的時候,也會先分好可燃或是不可燃垃圾,回收也會先分好是塑膠紙類還是寶特瓶等等,為什麼我們不會等到垃圾車都收走了,準備要處理垃圾的時候再分類,因為沒有效率啊。連垃圾都要分類了,一向注重效能的工程師當然也會分類。

如何分類

講到這邊,如果不是工程背景的讀者可能會有一點疑惑,所謂的分類是指資源的分類,還是資料庫的分類亦或是系統的分類?其實都是也不是,微服務的分類,指的是將每一項功能,都變成一項服務,例如登入登出是一項功能,所以他是一項服務,註冊則又是另一個功能,所以他又會是另一項服務,藉由這樣的拆分達到以下微服務的三個設計原則。

  • 單一目的: 每個服務專注於做好一件事情。
  • 低耦合: 服務跟服務之間極少互相了解。對一個服務的變更不應該要求其他服務也進而變更。服務之間的通信應該發生在公開的服務接口。
  • 高內聚: 每個服務應該對所有相關的行為以及數據進行封裝。如果需要建構新的功能,所有的變更只會落地到其中一個服務中。

這樣是不是像極了上面的公司分類的故事呢,沒錯這就是最基本的微服務架構,那麼要怎麼簡單實作這微服務呢,我們可以很簡單的利用 GCP (Google Cloud Platform) 來幫助我們完成這樣的目標。

如何實踐微服務

在這一個章節,筆者並不會將程式碼放上來,只會很間單的帶著大家認識所謂的雲端技術,以及我們可以怎麼有效的利用這些既有的服務,來達成我們的微服務架構。

透過 GCP 裡面的 Google Cloud Functions 這項服務可以輕鬆替我們達成目標。而什麼又是 Google Cloud Functions 呢?

Cloud Function是一種輕量級的雲端應用方式,也是一種微服務(Micro Service)適合單一目的、獨立的功能。透過各種事件的觸發,讓開發者可以不用管理Server或控制執行環境。

  • 雲端環境執行程式碼最簡單的方法
  • 自動擴充,具備高可用性和容錯性
  • 無需佈建、管理、修補或更新伺服器
  • 執行程式碼時才需付費
  • 可連結和擴充雲端服務

還是覺得像天書一樣嗎?那麼用圖來理解一下實際上是怎麼運作的吧

一個 cloud function 就是上述所說的一個微服務,他只負責一件事情,那麼他要怎麼知道什麼時候要開始做事情呢?以及它做完事情了以後他要怎麼主管說明呢。

首先,每個 cloud function 都會藉由一個 event 來觸發,只要被觸發了就會根據 event 來完成任務,等到完成任務了,他會跟傳送任務的人說我任務完成了或是我失敗了。如果失敗了,他也會說失敗的原因,而這就是左邊的過程。

任務成功以後他可以把結果再傳送給另一個 cloud function 讓他接續接下來的任務,或是將結果傳送給其他服務,讓他們知道結果是什麼,這邊不會限制只能傳送給一個服務知道。

我們可以將一個 cloud function 當成中心,將結果傳送給好多不同的服務,藉此減少伺服器重複運算的機會。

那我們就來看一個實際的例子吧,一般來說我們會使用 GitHub 來管理我們的程式碼,每當碼農將程式碼 push 到 GitHub 的時候,event 就產生了,而 cloud function 收到這樣的 event 會再去觸發他的任務,最後再將任務的結果傳送給 slack,讓工程師不用再打開其他頁面就可以知道結果。酷吧!這就是工程師每天上班的快樂,工程師的快樂,就是這麼樸實無華且枯燥。

Aiii Chatbot

那麼 Aiii 的 ChatBot 又是怎麼運作的呢,有些讀到這邊的讀者可能已經可以舉一反三了,沒錯就是將上述的 GitHub 替換成 Line 的訊息,右邊的 slack 替換成要收到訊息的人而已,而其中要怎麼產生出對應的內容就先讓筆者在這邊賣個關子吧,我們下次再談。

結語

雖然上述的例子沒有到非常複雜,只有一個 event 並且也只有一個 output,不過假如這樣的服務擴展到要處理 20 個 output 的時候,若不透過這樣的方式,是不是就要寫好多重複的程式碼,甚至在更新的時候,是不是也要照顧到好多一樣的程式碼,雖然說工程師的快樂就是這麼的樸實無華且枯燥,但是,我們還是可以透過一些方法來減輕工程師以及伺服器的壓力。

Reference:

https://blog.fleeto.us/post/microservice-at-medium/

https://cloud.google.com/functions/?hl=zh-tw

https://medium.com/宅男雜學筆記/淺談serverless-solution-以gcp-cloud-function為例-6374bf74df98

--

--

Freddy
Aiii
Writer for

iOS developer | golang lover | open source enthusiast |職人文化が大好き | software developer intern at Aiii | https://github.com/jamfly | freddy@aiii.ai