Spring Cloud 實現微服務系列以前言（一）

這是Spring Cloud實現微服務系列文章的第一篇。打算先把相關概念、文章的後續內容及文章風格等介紹一下。

Spring Cloud

標題講到兩個概念， 第一個是Spring Cloud。那就先來講下它。

Spring Cloud是一個微服務框架， 或者說是一套微服務生態。總而言之， 它爲微服務的開發提供了便利。

微服務

那Spring Cloud 是用來開發微服務工程的， 那什麼叫作微服務工程?

單體工程

和微服務相對的是單體應用， 經過對比來了解什麼是微服務。單體應用指的是， 整個應用只有一個服務。全部的功能模塊、都放在一個項目裏面。隨着功能愈來愈來， 問題也慢慢的暴露出來， 微服務的出現就是爲了解決單體開發產生的一些問題。微服務把不一樣的功能模塊拆分紅不一樣的服務。

單體有哪些問題

微服務解決了單體開發的一些問題， 那具體是哪些問題

• 效率低

開發都在同一個項目改代碼，相互等待，衝突不斷

• 不靈活

構建時間長，任何小修改都要重構整個項目，耗時

• 穩定性差

一個微小的問題，均可能致使整個應用掛掉

• 擴展性不夠

沒法知足高併發下的業務需求

• 維護難

代碼功功能耦合在一塊兒，新人不知道何從下手

要應用微服務開發須要解決的問題

要使用微服務開發， 須要解決如下問題， 才能應用

1. 如此多的服務， 客戶端如何訪問?

後端功能模塊都已經拆分紅不一樣的服務， 對應的ip地址和端口均可能不一致， 如今客戶端要先登陸，而後下單。這時候對應後端可能就是兩個不一樣服務，難道要客戶端去記住這兩個不一樣的地址來調用嗎， 若是客戶端的操做涉及到十幾個不一樣服務呢？

2. 服務之間如何通訊

功能模塊拆分紅不一樣服務後， 服務之間還須要互相調用， 好比， 下單時， 我要獲取到下單的用戶信息一塊兒保存。這時下單服務就要去調用用戶服務。這就是服務間的通訊問題。

3. 如何管理這些服務

服務這麼多， 須要對每一個服務的狀態進行監控。和服務間的調用鏈查看等。

4. 服務掛了怎麼辦

單體開發方式一個很大的風險是，把全部雞蛋放在一個籃子裏，一榮俱榮，一損俱損。而分佈式最大的特性就是網絡是不可靠的。經過微服務拆分能下降這個風險，不過若是沒有特別的保障，結局確定是噩夢。因此當咱們的系統是由一系列的服務調用鏈組成的時候，咱們必須確保任一環節出問題都不至於影響總體鏈路。相應的手段有不少：

• 重試機制
• 限流
• 熔斷機制
• 負載均衡
• 降級（本地緩存）

微服務開發還存在哪些問題

• 代碼重複編寫

好比shiro攔截進行登陸鑑權，在每一個服務中都得單獨寫一份。

• 服務調用鏈路長

服務之間相互調用， 調用消耗大

• 部署工做量相對大

對於運維人員來講， 部署一個微服務開發的應用了， 須要部署和維護的服務多。

• 硬件需求高

一句話，在微服務開發的方式中， 內存是不值錢的。

微服務相關時間點

微服務這個概念是 2012 年出現的，做爲加快 Web 和移動應用程序開發進程的一種方法，2014 年開始受到各方的關注，同年爲微服務的元年。

後續文章內容

微服務須要解決上述提出的問題，才能得以應用。Spring Cloud 這套生態已經給咱們提供瞭解決方案。接下來就是對Spring Cloud提供的微服務核心組件進行學習。感興趣的同窗能夠先關注一下。

文章合集地址

發佈的文章有些多， 整理出來一份目錄大綱及文章說明。點這裏查看