分散式系統詳解--架構簡介（微服務）
分散式系統詳解--架構簡介（微服務）
前面的一個集合我們也差不多聊完了整個分散式的基礎知識，把基本上包含的內容點也簡單做了一下了解和分析，在每一個基礎店裡面，如果細細探討和研究，都是至少一本數的技術和含量，而這裡只能起到一個拋磚引玉的過程，真正需要詳細的看待分散式系統詳解中的每一篇基礎知識的時候，還是相當的不足。希望起到一個系統的作用，讓大家在做分散式的時候有章可循當然歡迎指出錯誤。今天主要是就現在很火熱的微服務來進行一次微微的探討（最下面有文章快速跳轉連結~~
一。什麼是微服務呢？
讓我們先看一下之前的軟體架構風格，Monolithic架構，也叫整體架構。這個比較適合小專案，開發簡單、集中管理。缺點一大堆：功能都在本地、開發效率低、程式碼維護難、部署不靈活、穩定性不高、擴充套件性極差......
來看看應運而生的微服務：開發一個單個小型的但有業務功能的服務，每個服務都有自己的處理和輕量通訊機制，可以部署在單個或多個伺服器上。服務使用HTTP / REST等同步協議或AMQP等非同步協議進行通訊。也可以說他們可以彼此獨立地開發和部署服務。每個服務都有自己的資料庫，以便與其他服務分離。說白了：鬆耦合！！、
讓我們來看看微服務示意圖，有圖才好理解（仔細看你就明白了）。
再次強調的是，微服務運用了以業務功能的設計概念，應用程式在設計時，就能先以業務功能或流程設計先進行分割。將各個業 務功能都獨立實作成一個能自主執行的個體服務，然後再利用相同的協定將所有應用程式需要的服務都組合起來，形成一個應用程式。
二、微服務規劃
2.1 資料庫
2.1.1 資料庫的三種設計模式
（1）每個服務都各有一個數據庫，同屬性的服務可共享同個資料庫。
（2）所有服務都共享同個資料庫，但是不同表格，並且不會跨域存取。
（3）每個服務都有自己的資料庫，就算是同屬性的也是，資料庫並不會共享。
2.1.2 資料庫的可棄性
實踐微服務架構中有許多的做法。但是其中一種的做法是將資料庫視作短期的儲存空間而不是長期的資料。因為他們可以在上線時從事件中心回覆，因此可以快速的從記憶體中快速存取（例：Redis）作為資料庫伺服器。這種做法需要將每個請求當作事件來進行廣播，這樣就可以從事件儲存中心重播所有的事件。
2.2 溝通與事件廣播
在微服務中最重要的就是每個服務相互獨立，服務和服務之間不應該有所溝通，如果要進行溝通的話，那就採用非同步的方式進行溝通。在這裡也是有兩種方式：
2.2.1 事件儲存中心
這可以讓你的服務叢集中廣播事件，並且在每個服務中監聽每個事件並做處理，令這些服務之間沒有緊密的連線性，而發生的事件都會被儲存在事件儲存中心。這就意味著，當微服務重新上線，部署時可以重播所有事件。這造就了微服務的資料庫隨時可以刪除、摧毀、且不需要從其他服務中獲取資料。
2.2.2 訊息佇列
這令你能夠在服務叢集中廣播訊息，並傳遞到每一個服務，具有這個功能的有RabbitMQ，或者其他的訊息中介軟體。
2.3 服務探索
單個服務在上線的時候，會向服務中心註冊自己的IP位置、服務內容，如此以來，服務中心不需要向每個微服務表明自己的IP位置，也不用對每個微服務單獨設定，當A服務向另一個服務B呼叫的時候，會向服務中心詢問B的IP位置，得到位置就可以直接進行呼叫。
這樣就可以統一集中所有服務的位置，並不是分散於每一個服務。還有一個好處，服務探索中心還可以每隔一段時間就向各個服務進行檢查，如果這個服務在一定時間內沒有迴應，那麼就可以把這個服務除掉。避免其他服務對他進行呼叫反而得不到響應。
三、微服務架構部署圖
具體如何進行搭建微服務框架，比如說涉及到的Docker容器技術、springboot、SpringCloud技術後面的部落格中會一一講解。從下一章就進行真實的實戰部署程式碼階段。~~
參考地址 https://zh.wikipedia.org/wiki/%E5%BE%AE%E6%9C%8D%E5%8B%99
歡迎訂閱關注公眾號（JAVA和人工智慧）
獲取更多免費書籍、資源、視訊資料
知識點超級連結：