《大話雲原生》系列文章期望用最通俗、簡單的語言說明雲原生生態系統內的組成及應用關係。此專欄的前兩篇文章
- 《【大話雲原生】煮餃子與docker、kubernetes之間的關係》
- 《【大話雲原生】負載均衡篇-小飯館的流量變大了》
歡迎品鑑！
一、服務接待中心與微服務閘道器
老婆最近快過生日了，我答應她去旅遊住一次五星級酒店。我檢視了目的地的五星級酒店的價格，決定只住一天。第一次住所以檢視了一下特色服務專案：擦鞋、熨燙衣物、機場綠色通道、專車接送等等，幾乎在酒店場所範圍內一切可以讓你懶出奇跡的專案都可以提供。沒出息的時不我待，插入房卡，一鍵撥通前臺電話要求提供衣物熨燙服務，不一會服務人員就將衣物取走了，20分鐘後送了回來。真是太方便了！
五星級酒店所有的服務只有一個入口：服務接待中心。這個服務接待中心和微服務軟體架構中的閘道器功能真的是異曲同工啊
- 提供服務請求的唯一入口，也是面向使用者提供服務唯一入口
- 對請求資訊進行安全驗證，因為我在入住時已經獲得了房卡，這個房卡就像是在應用開發中的token(JWT、OAuth等登入認證方式都會發布令牌)
- 有了這個房卡（令牌），我們才能通過服務接待中心請求服務專案。同樣微服務閘道器也會進行許可權驗證後，才會提供API請求服務。
二、酒店內部通訊錄與服務註冊中心
其實我們仔細想一想，服務接待中心（微服務閘道器）提供面向使用者的服務入口。那麼酒店內部部門之間是不是隻對外提供服務，不對內提供服務？顯然不是的。舉幾個例子：
- 各種部們幾乎都依賴採購部採購的物品，所以一定會和採購部申請服務用品
- 服務部給客戶送餐的時候，一定需要和餐飲部進行通訊
對於微服務架構來說也是一樣的，有的微服務直接面向使用者提供服務，有的微服務是為系統內部服務提供服務。所以正確的架構方式是下面這樣的。
當服務之間存在呼叫關係，就存在一個問題：各個部門（各個服務）之間如何聯絡，聯絡方式是什麼？其實就是需要建立一個酒店內部的通訊錄，這個通訊錄只在酒店內部使用。對於微服務架構而言同樣需要這樣一個通訊錄
- 在服務建立的時候，把自己的聯絡方式(ip、埠、服務名稱)寫在“通訊錄”上
- 在服務下線的時候，自己的聯絡方式從“通訊錄”上被劃掉
這個服務之間的“通訊錄”，對於微服務架構而言就被叫做:服務註冊中心。常見的微服務註冊中心有nacos、eureka、zookeeper等等。
三、微服務的高可用
我們再考慮一個問題，這麼大的酒店是不是隻有一個服務部，只有一個採購部？當然不會，即使只有一個部門，也會分成多個小組。比如：服務部A小組負責1-3樓、服務部小組B負責4-6樓，依次類推（這其實就是一個負載均衡演算法）。所以進一步完善的架構應該是下面這樣的。
- 一個部門分成多個組，一旦A組忙不過來，B組完全可以過來幫忙。但在大多數情況下按照負載演算法各司其職。
- 一個好漢三個棒，有事大家一起扛。這在分散式服務架構中就是一種高可用的體現。
- 不會因為一個小組的罷工導致整個服務部門癱瘓。這在服務架構中體現的是容錯性和副本備份機制。
每個部門雖然分成了多個小組，但也會有該部門的統一的管理制度、服務標準。這個制度及服務標準統一制定，統一配置管理。對於微服務架構來說，也會有一個地方儲存某一類微服務的統一配置資訊，它就是服務配置管理中心。我們常見的服務配置管理中心有nacos、Spring Cloud Config等。（nacos既可以充當服務註冊中心，也可以充當配置管理中心）
歡迎關注我的部落格，更多精品知識合集
本文轉載註明出處（必須帶連線，不能只轉文字）：字母哥部落格 - zimug.com
覺得對您有幫助的話，幫我點贊、分享！您的支援是我不竭的創作動力！。另外，筆者最近一段時間輸出瞭如下的精品內容，期待您的關注。