HackMD
容器化與微服務的實務經驗
[實務-理想篇]
實務上的畫我們會怎麼做
一樣 我們拿拍賣網站來做範例
一個網站[簡單說]會有那些區塊
前端 後端 資料庫
先講後端
我們如果現在要把一個拍賣網站做成微服務 複習一下 會有那些為服務
會員微服務
報表微服務
商品微服務
評語微服務
支付微服務
每個微服務都是一個獨立的專案
也就是 會有5個後端獨立的應用程式
再來前端
前端 也是可以拆分成五個的
會員微服務
報表微服務
商品微服務
評語微服務
支付微服務
[甚麼 前端也要拆成五個 你認真的嗎]
會
再來是資料庫
[難道 資料庫也是拆成五個嗎..]
理想上是這樣沒錯
假設你們使用MYSQL
所謂的五個資料庫 不是止五個資料拆開的獨立庫
而是獨立的5台主機 各自一台資料庫
如果你們還有用mongodb
那也是幾個為服務 就拆成幾個
[真假…]
假的 因為這樣架構成本太高了
[實務-真實篇]
那現實上會是怎麼樣?
以下是我工程師朋友他們公司容器化的作法不限至於搭配微服務或是單體式系統
作法不是絕對
但可以當作網站架構的入門磚
在介紹前 我先插播一下
以往 網站流量沒這麼大的公司會常看到
我們都知道網站有前台 後台
如果對前端後端前台後台不熟悉的朋友們 可以看右上角我之前的介紹影片
之前很常見的情況是
前台 有一個前端專案和一個後端專案
後台 有一個前端專案和一個後端專案
沒錯 所以一個網站 會有四個專案 分開的
不過因為微服務慢慢的被更多公司給採用 通常會變成
前台 一個前端專案
後台 一個前端專案
後端專案呢 跑去哪?
可能原本的前台與後台的後端專案
被拆成 7個微服務
這七個微服務就是不分前台後台 看前端當下需要哪個資料就從其中幾個微服務拿取
第一間公司
後端 切12個 這邊就不細數 但裡面有一個叫做支付微服務先說明
前端前台 切3個微服務 會員登入微服務、主頁為服務、支付為服務
前端後台 就2個->管理員登入微服務、後臺主業為服務
mongodb 兩台 一台專門給支副為服務 一台給其他為服務
資料庫 一台 應付所有後端的12個微服務
這間的容器化策略
後端12個容器 一台主機
前端前台3個容器 一台主機
前端後台2個容器 一台主機
芒果2個容器 一台主機
資料庫實體主機 無使用容器 一台主機
–
但是 有一個東西
我們這邊小提一下就好
網站的流量部屬 分為 分散式和集中式
記住 這個跟微服務和單體式 沒有任何關係 很多人會搞混
大流量使用分散式
小流量使用集中式
分散式就是很多台主機處理你的網站
集中式就是只有一台主機處理你的網站
之後會詳細提到 有個印象就好了
–
所以說 在一個大流量的網站
一台主機 夠嗎?
所以
後端 有 5台主機
前端前台 3台主機
前端後台 1台主機
芒果 五台主機
這樣的話 幾個容器
後端一台會有12個容器 所以125
前端前台一台會有3個容器 所以33
前端後台一台會有2個容器 所以21
芒果一台會有2個容器 所以25
至於主機配置的多寡 以及服務的切割 這就是貴公司自己的規劃了
[第二間]
後端 切8個微服務 也不細數 也是有一個叫做支付微服務先說明
前端前台 一個 也就是單體式系統
前端後台 一個 單體式系統
mongodb 兩台 一台專門給支副為服務和 一台給其他為服務
資料庫實體主機 無使用容器 一台主機
一樣這間公司也使用了多台主機 也就是分散式
後端配 4台
前端前台 3台主機
前端後台 1台主機
芒果 2台
這樣的話 幾個容器
後端初始會有8個微服務 所以48
前端錢台初始會有1個單體是 所以31
前端後台初始會有1個單體是 所以11
芒果初始會有2個 所以22
其實實務上大概就是這樣 這邊會發現 即使是單體式系統 也是可以包在容器裡
就像前端前台 以及前端後台一樣
資料庫 不會真的開五台主機資料庫
其實還是一台居多
芒果的話 她是緩存資料庫
依照經驗來看各為服務的流量區分
通常 支付 一台芒果 因為金流的流量是最即時和最大的 建議一台給他
會員 報表 或是其他的流量不高的集中一台芒果即可
畢竟上個影片有說過
為服務的切割也是一種挑戰 在網站流量不高 或是團隊人手不足的時候 要隨機應變
容器化對於為服務或是單體式系統的優勢
網路上很多說明容器化對於微服務有很好的相依姓
這點沒錯 但是對單體式系統就沒這麼友善嗎
其實不然
單體式系統使用容器化也是能吃到容器化的優勢
只是一個優勢拿不到而已
之前有提到 容器畫的三個特點
一至性
可攜性
隔離姓
這是圖表 各位可以按暫停看一下
| Column 1 | Column 2 | Column 3 |
|---|---|---|
| Text | Text | Text |
可以看到
單體式系統對於隔離性這個特點是沒有占到優勢的
今天你們的是單體式系統 放在一台主機上 而那主機可能就只有跑你們的後端應用程式
就一個 那的確是不是使用容器 因為這個房間只有他一個人
如果變成微服務 你這間房間變成容納五個人 應用程式不是一個脾氣很好的東西
你把五個人放在一個大房間內 各自沒有隱私 會不會打架 會
所以才要用容器化 把大房間隔成五個房間 給那五個微服務住
容器裡面只能放一種應用程式
會員微服務算是一種應用程式對嗎
所以一個容器只能放一個會員微服務 不能放其他應用程式
合理
那現在有一個單體式系統 A專案
基本上 它也算是一種應用程式
所以一個容器放一個A專案
也是合理的對吧
合理
但是網路上很多人都說
容器化與微服務是很好的搭配
但並不是單體式系統 就不適合 對吧
沒錯
如果要說的細一點
容器化的重點就是 只能放一種應用程式 而不是只能放微服務
你的會員微服務
或是單體式系統 A專案
都算是[一種]應用程式
微服務 是一種概念 但這個概念 是你們團隊決定的
絕對不會是非你團隊之人或是網友決定的
上肢影片有提到 商品評論會獨立一個微服務
但也許你們團隊會覺得 會員與商品評論 可以放在一起做個微服務
也是有道理 因為商品評論是會員發出來的
那商品跟商品評論放在一起 也有道理 因為都是屬於商品的範疇
下支影片會說分散式宇宙第四部 分散式架構與集中式架構 又是甚麼鬼
我們 下次見
