monolithic單體 vs microservice微服務

想像一下你今天是一位手搖店店長...

monolithic單體 ->SOA

最怕的就是下課下班的人潮了

我只是要一杯氣泡水....

痛失訂單

需要更多的即戰力

專業分工,節省訓練時間,一方面可以增加出貨效率

如何人力分配？
如何溝通有效溝通？
新人的增加?

monolithic單體 ->SOA

每位工讀生都有著自己負責的地方,
具有一定的專業度,
但該如何溝通,相互調用資源就是一件困難的事了
是否也需要學會一定程度的對方專業知識才能溝通呢？

SOA 模組間不可直接讓別的模組直接呼叫資料庫,
代碼重複問題＝>服務化介面
調用關係問題=>ESB管理器

SOA->microservice微服務

事業經營到一定程度,開始拓展分店

是否需要中央廚房？

倉儲,營運,各項服務？

獨立部署

monolithic單體的缺點

monolithic結構(最一般的)
就是一個前端,一個後端服務器,再加上資料庫

But!

瞬時的巨量這時,某一個query造成資料庫爆了

後端也跟著爆掉

就連一般的服務也跟著爆了

火燒連環船!!!

1. 程式耦合性太強,開發困難
2. 新人學習曲線太高
3. 部署時間耗時長
4. 穩定性太差(一塊壞掉全部都壞)

microservice微服務的優缺點

microservice結構(最一般的)
每個業務都有著獨立的個體

上下界清楚分離

單一服務爆了,也不至於其他應該要正常的服務也爆

不過有些服務可能會彼此使用到,
造成雪崩,這又是另一個故事了

優點：
1. 邊界清楚
2. 技術靈活
3. 松耦合
4. 高可用性
5. 按需擴展
6. 彈性工程

缺點:
1. 維運成本高
2. 分布式問題：
    1. 容錯
    2. 序列化與反序列化
    3. 數據一致性問題

microservice-服務切分

我們可以看到,
店長如何把一家店面的生產線清楚的切分成各個微服務

在這當中,
如何重新設計一條界線清楚的微服務,是一項重要的課題

我們可以大致上從幾個面向著手
1. 資料面
2. 架構面

microservice- 服務切分 

microservice-服務切分(資料面)

FOREIGN KEY 呢？(demo db)

在單體的結構裡,我們可以清楚的知道每張table的關聯,
但是在微服務的世界裡,為了可以讓每一個服務都獨立部屬,
因分開成數個db了

隨之而來的,我們也需要考慮到分散式資料庫的transcation與同步等處理問題

microservice-服務註冊與發現

當服務在做auto scalar,zero downtime deployment 時,每次所開啟的服務位置不一定相同

該如何才能夠讓所有其他的服務和新啟用的服務溝通呢？

microservice-服務註冊與發現

以前做法

consul+nginx-consul-template+registrator
     ^                  ˇ
    ｜__________|

(demo: scalar)

現在做法