使用 Spring Cloud 搭建微服務項目架構

前言：

    本文爲使用 Spring Cloud 搭建微服務項目架構的總體思路講述，歡迎討論。文章對新手不友好，推薦新手訪問此文：史上最簡單的 SpringCloud 教程 | 終章，講得很好。

一、微服務的定義

    微服務的通俗定義就是一個小型的項目服務，可是寫文章則須要有明確的定義才行。文縐縐的描述語言大概以下：

一個可以獨立運行的、可提供完整服務的微型服務。

    這裏面是三個條件：獨立運行、可提供完整服務、微型。

    獨立運行則意味着跟其餘服務徹底解耦，若是服務之間存在業務關聯，要麼把他們合併爲一個微服務，要麼經過接口進行交互。這也意味着，不一樣微服務之間若是涉及到數據庫操做的話，一個微服務不能夠直接操做屬於另外一個微服務的庫表，即便他們的表放在同一個庫。由於這種行爲一旦發生，那麼這兩個微服務又出現了新的耦合維度。

    可提供完整服務則意味着其餘與之無關的微服務即便掛掉，它本身經過接口提供的服務也不受任何影響，除非他們之間存在接口互動上的關聯，那樣也隻影響到有關聯的部分。

    微型則表示每一個微服務都不會有太多的接口，不然就變成了傳統的項目了。

    任何知足以上三個條件的服務，我都認爲是一個微服務了——因此，微服務是一個概念，而不是一種技術。無論使用何種技術、何種框架、何種方式進行搭建。

二、微服務的好處

    微服務的好處主要有：敏捷開發、選擇性擴容等

    使用微服務架構的項目，由於微服務之間徹底解耦，因此可實現敏捷開發——即某個微服務fix了某些BUG或者升級了版本，只須要從新部署升級便可，不須要像傳統的項目同樣，fix一個小BUG都要將整個服務從新部署升級；服務間的解耦，很是方便敏捷開發、升級等。

    同時也能夠根據微服務的併發量進行選擇性擴容或集羣等，好比某個併發量極高的微服務，能夠單獨部署項目、數據庫（上文提到微服務不能操做屬於其餘微服務的數據，即便是查詢也不容許。這樣，當某個微服務須要獨立部署時，就不存在任何耦合帶來的問題，不然就會致使其餘微服務直接操做本微服務數據庫由於遷移而失效的問題）等。

三、爲何要用 Spring Cloud

    Spring Cloud 推薦了不少微服務的解決方案，使用 Spring Cloud 可快速搭建微服務架構，而且背靠 Spring 社區的良好生態。

四、使用 Spring Cloud 搭建微服務的思路

    首先須要一個註冊服務的註冊中心，可選擇 zookeeper、eureka。

    其餘的微服務都在本身搭建的註冊中心註冊，經過 resttemplate+ribbon 進行通訊，這時url不須要使用完整的 ip+port 的方式，而是使用微服務在註冊中心註冊時提供的名稱便可。只用註冊名而非 ip+port 的方式進行通訊還有一個好處，就是能夠實現集羣：同一個微服務部署多份，無論 ip 和 port 是什麼，ribbon 都會調度微服務的集羣，起到負載均衡的效果。

    還有使用 feign 可達到類RPC的接口調用效果，feign 自己已經使用了 ribbon。

    微服務提供接口給外部訪問時，不能像微服務間通訊同樣使用註冊名通訊那麼方便，仍是須要 ip+port 才能訪問到：這樣對接口使用方來講是很是麻煩的，畢竟微服務的數量可能會很是多，外部調用方就要記住各個微服務的端口號等，並且這樣就不能讓集羣生效了。這時可經過配置統一網關，讓使用方經過網關再轉發到對應的微服務便可。這樣，多個微服務及集羣的狀況，對於調用方來講都是透明的，用戶的感知就是調用了服務的某個接口，而不是特定的某個微服務下的接口。

    統一網關可以使用zuul來配置。

這樣，就基本完成了一個微服務的搭建，不使用框架的話，搭建微服務須要解決的問題頗多，不建議本身造輪子。