微服務導論
SpringCloud是微服務的技術落地方案，微服務是分散式架構的一種，是為了解決專案發展過程中出現的各種問題而出現的新的專案架構方案。
專案中模組繁多，耦合度無法避免的變高，最好的方案就是對服務進行拆分：將一個大型專案根據模組拆分成不同的小模組專案，各司其職完成各自的功能。
單體應用適合小型的專案，訪問量小或者業務簡單的專案。但是對於大型的、高可用、高併發的專案而言，單體是存在很多弊端的。單個服務併發難以控制、專案更新需要停機、模組更新導致耦合度越來越緊此類的問題，雖然可以透過負載均衡策略或者制定企業開發相關規範來避免，但是在專案體量越來越大、員工越來越多、更新迭代越來越頻繁的情況下此類的維護成本也會指數級增加。
微服務提倡將模組以獨立服務的方式獨立管理，整個專案依靠多個小型的服務同時運作來支撐，單個服務只關注自己的業務實現並且有專業的團隊進行開發。服務之間使用輕量的協議進行訊息傳送，並且對於單個模組的升級不應影響其他服務，也不應該被其他服務感知。每個服務可以釋出多個例項，所有的服務組建成一個網狀的服務叢集。
從前單體專案中也會涉及到跨模組間方法的呼叫，那在微服務中同樣也可以透過網路進行跨模組呼叫。模組之間的依賴關係錯綜複雜，並且因為每個服務都是獨立啟動的，相互之間必要的存在一些呼叫和互動，呼叫誰、怎麼呼叫、呼叫失敗怎麼辦，那微服務思想就是對此類服務叢集的治理提供一套解決標準和思想。
微服務元件之一：註冊中心
剛剛說到服務之間要做相互的呼叫，那呼叫誰就是一個問題。服務之間要想完成呼叫首先要知道誰和自己是同一個叢集的，註冊中心就是用來統計叢集中的各個服務以及服務狀態的。
微服務元件之二：配置中心
未來微服務叢集中，單個服務並不是單個例項執行的：如果某個模組的負載較高，就需要多例項負載均衡執行。那多個例項的配置在管理過程中如果要每個都進行獨立設定和管理，運維期間是很麻煩的，所以需要一個配置中心對微服務叢集的配置進行統一的管理，在配置中心的設定將同步到所有的需要此配置的服務中。
微服務元件之三：閘道器
閘道器就是網路關卡，每一個微服務講將到的訊息有兩種：來自客戶端的、來自其他微服務的。來自其他微服務的大可放行，但客戶端的就需要進行鑑權和認證類的判斷，並且客戶端所請求的服務極有可能正處在負載均衡的狀態，那就還要在多個同服務例項中選擇最佳的一個。閘道器就是攔截在客戶端與伺服器之間的一道關卡，透過負載均衡演算法進行具體服務的呼叫然後響應客戶端。
PS：客戶端是直接訪問閘道器的，閘道器再對服務進行負載均衡。如果要對閘道器進行負載均衡的話，就需要採用Nginx類反向代理工具對閘道器進行負載均衡。
微服務元件之四：訊息佇列
當一個請求透過閘道器落到一個具體的服務之後，此服務可能會請求其他服務進行相關操作，同樣的這個呼叫鏈路可能非常的長。那客戶端等待的時間就是所有服務執行時間之和，但對於客戶端來說也許大多數的等待是沒有意義的。所以可以採用非同步的訊息佇列，來完成各個服務之間的無需返回的請求呼叫，降低響應時長。
微服務元件之五：分散式日誌服務+系統監控和鏈路追蹤
在微服務中多個例項的健康管理非常複雜，所以需要藉助服務治理工具對服務進行監控和管理，並對日誌採集、響應速度、健康狀況等進行統一的統計，以解決運維過程中複雜問題的排查和服務健康管理。
微服務元件之六：持續整合
龐大叢集下每個服務例項的啟動和部署將非常複雜，所以對於專案編譯部署可以透過相關工具進行自動化管理。
微服務儲存設計之一：分散式快取
需要明確的是雖然每個服務都會提供CRUD操作，但永遠查詢大於其他操作。分散式系統中通常會採用分散式儲存方案，但為減輕資料庫查詢壓力，通常會在資料庫前攔截一層快取層，用於快取介面的查詢資料。
微服務儲存設計之二：分散式搜尋
資料庫和快取都是無法支撐海量資料查詢的，並且在分散式快取和儲存架構下，查詢效率也會降低，所以要採用分散式搜尋引擎來解決資料的搜尋問題。
PS：在分散式資料儲存設計中，快取儲存的是熱點資料，資料庫主要做寫操作和對事務要求較高的操作，分散式搜尋主要做大規模資料快速搜尋操作。