文章開始之前，我給大家推薦一個人工智能學習網站，首先說我之前是完全不涉及人工智能領域的，但是我盡然看懂了，以后老哥我就要參與人工智能了。如果你也想學習，點擊跳轉到網站

《大話云原生》系列文章期望用最通俗、簡單的語言說明云原生生態系統內的組成及應用關系。此專欄的前兩篇文章

• 《【大話云原生】煮餃子與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

覺得對您有幫助的話，幫我點贊、分享！您的支持是我不竭的創作動力！。另外，筆者最近一段時間輸出了如下的精品內容，期待您的關注。

• 《kafka修煉之道》
• 《手摸手教你學Spring Boot2.0》
• 《Spring Security-JWT-OAuth2一本通》
• 《實戰前后端分離RBAC權限管理系統》
• 《實戰SpringCloud微服務從青銅到王者》