12月12日，OSC源創(chuàng)會年終盛典在北京國際會議中心如期舉行，時速云展臺聚集了很多對容器云平臺感興趣的與會嘉賓。而且時速云技術總監(jiān)楊樂在容器和微服務專場進行了topic為《微服務設計模式與容器云平臺》的演講，楊樂從四個方面對容器和微服務進行了闡釋，分享了自己在容器和微服務方面積累的知識和經(jīng)驗。來聽此次演講的技術人員熱情很高，楊樂也同這些關注創(chuàng)新和技術發(fā)展潮流的技術人員一起討論容器及微服務，現(xiàn)場氣氛十分活躍。
圖為時速云楊樂演講現(xiàn)場
圖為大會現(xiàn)場時速云展臺
常見的有六種微服務架構的設計模式：
- 聚合器微服務設計模式
這是一種最常用也最簡單的設計模式，聚合器調(diào)用多個服務實現(xiàn)應用程序所需的功能。它可以是一個簡單的Web頁面，將檢索到的數(shù)據(jù)進行處理展示。它也可以是一個更高層次的組合微服務，對檢索到的數(shù)據(jù)增加業(yè)務邏輯后進一步發(fā)布成一個新的微服務，這符合DRY原則。另外，每個服務都有自己的緩存和數(shù)據(jù)庫。如果聚合器是一個組合服務，那么它也有自己的緩存和數(shù)據(jù)庫。聚合器可以沿X軸和Z軸獨立擴展。
- 代理微服務設計模式
這是聚合器模式的一個變種，在這種情況下，客戶端并不聚合數(shù)據(jù)，但會根據(jù)業(yè)務需求的差別調(diào)用不同的微服務。代理可以僅僅委派請求，也可以進行數(shù)據(jù)轉(zhuǎn)換工作。
- 鏈式微服務設計模式
這種模式在接收到請求后會產(chǎn)生一個經(jīng)過合并的響應，在這種情況下，服務A接收到請求后會與服務B進行通信，類似地，服務B會同服務C進行通信。所有服務都使用同步消息傳遞。在整個鏈式調(diào)用完成之前，客戶端會一直阻塞。因此，服務調(diào)用鏈不宜過長，以免客戶端長時間等待。
- 分支微服務設計模式
這種模式是聚合器模式的擴展，允許同時調(diào)用兩個微服務鏈。
- 數(shù)據(jù)共享微服務設計模式
自治是微服務的設計原則之一，就是說微服務是全棧式服務。但在重構現(xiàn)有的“單體應用(monolithicapplication)”時，SQL數(shù)據(jù)庫反規(guī)范化可能會導致數(shù)據(jù)重復和不一致。因此，在單體應用到微服務架構的過渡階段，可以使用這種設計模式，
在這種情況下，部分微服務可能會共享緩存和數(shù)據(jù)庫存儲。不過，這只有在兩個服務之間存在強耦合關系時才可以。對于基于微服務的新建應用程序而言，這是一種反模式。
- 異步消息傳遞微服務設計模式
雖然REST設計模式非常流行，但它是同步的，會造成阻塞。因此部分基于微服務的架構可能會選擇使用消息隊列代替REST請求/響應。
除了常見的微服務架構模式外，楊樂的演講還設計以下4個方面：
1.Docker的本質(zhì)，Docker改變了什么，革了誰的命
2.日漸火熱的微服務到底有哪些用途及其設計模式
3.Kubernetes容器編排系統(tǒng)基本理念和優(yōu)勢，以及與微服務的關系
4.時速云平臺在容器與微服務的實踐
