Microservice 101

Monolithic application V.S MicroService

當程式越來越大的時候…
* deploy 越來越慢,但又因為所有功能都和這份 code 有關,所以總是要一直 deploy 全部的程式
* 程式內部的介面是 class、method 等。當 devleoper 變多的時候,要清楚溝通這所有的介面變得越來越難。
* 可能有一部份的功能很適合一種技術(像是 relational database),但另一部份的功能卻適合另一種(像 nosql)
像是上述的問題,可能拆成小的 service 就可以解決。

下面列出一些可能會遇到的問題:
* 不同的 service 之間要互相溝通,本來可能是 method call 的,現在變成了要跨過 network(像是 http request)。
* 因為 network 有著不穩定的天性,所以要做更多的 error handling
* 程式的 monitoring,像是 performance 等,要做得更完整。不然可能會有其中一個 service 不小心死掉了也沒人知道。

微服務 Microservice

  • 每個微服務只負責單一功能
  • 每個微服務比須能獨立更新
  • 微服務是顆粒度更精細的SOA架構

一個好的API設計原則

  • 嚴肅地開發每個 API
  • 淺顯易懂
  • 自動文件化
  • 相信 Acceptance Tests
  • Log, Monitor and Alert

API 種類介紹

RESTful

REST原論文最大的功勞在於前後端分離與無狀態請求,而REST的資源化的請求方式只適合面向簡單的請求,對於具有複雜資源間關聯的請求就有點無能為力。

RPC

GraphQL

GraphQL可以看做一個業務邏輯層靈活有效地輔助工具。由於REST每個網址只對應到一個動作,因此,若要查詢有多個子表格或關聯的資料時,就必須執行多次查詢,若想要一次就查詢完需要的資料,就可以透過GraphQL來達成。
* Build a GraphQL Server with Node.js and Redis

Service 間如何溝通?

Kafa

Kafka 的強項在於可以承載的 producer 流量相當大(producer-centric)、可以保証順序性,而 RabbitMQ 則是在於有比較多的 routing 選擇,在 consumer 消化 message 的情境比較多彈性(broker-centric)。也因為這樣,在 usecase 方面,Kafka 比較常見於做 log analysis, 或者是 performance metric 相關的東西,因為流量和順序性正是這類的 usecase 不可或缺的一環。

研究案例

相關工具