SpringCloud微服務帶來的問題

業務團隊的痛點 

1. 對於業務開發團隊而言，最強的是技術嗎？一定不是，業務團隊最強的一定是對於業務的理解和熟悉程度。 

2. 而業務應用的核心價值，就是為了實現業務場景，而不是寫微服務，微服務只是一種實現業務的手段。 

3. 業務團隊除了關心業務之外，他們所面臨的最大的挑戰在於，如何保證系統的穩定性何可擴充套件性、如何設計一個安全的open api。如果對服務進行拆分、如何保證跨庫的資料一致性。以及對於舊系統的改造。 

4. 於公司層面而言，業務團隊的壓力還來自於時間人力的投入，我們用於被各種deadline趕著走。所以作為一個業務程式設計師，如果在這個deadline之前還需要花更多的時間投入在spring cloud這些工具的學習上，那無疑是雪上加霜。公司對於業務團隊的考核，永遠只看結果！ 

服務治理功能不齊全 

SpringCloud對於服務治理的功能是不夠強大的，如果需要實現企業級的微服務落地以及服務治理，那麼我們還需要基於SpringCloud這套體系上來解決這些問題。 

跨語言帶來的問題 

微服務有一個很重要的特性，就是不同的微服務可以採用自己最擅長的語言來編寫程式。這種特性在企業中落地的時候又會帶來一些問題。 

比如公司內部會開發一些公共的類庫或者框架，也或者會使用第三方的類庫或者框架來實現某些功能。 

但是由於公司的微服務用了各種各樣的語言，那意味著這些類庫需要針對不同的語言開發相容版本。如果是主流語言還好，如果是一些小眾語言，那對於這些基礎元件的開發者而言無疑是晴天霹靂 

總結 

從這些痛點中可以發現，我們所做的所有非業務類的事情，都是為了保證把請求傳送到正確的地方，並且能夠及時或得正確的結果。那對於對於業務開發人員而言，是否有必要去關心這些呢？ 

回到最開始我們說的一個例子，在進行計算機網路通訊的時候，開發人員有必要去關心網路通訊的細節嗎？ 我們在使用http協議進行資料傳輸時，關心過底層是使用TCP還是udp？資料是怎麼傳輸的？ 

既然我們不需要關心這些，那對於微服務架構中的這些問題，業務開發人員為什麼一定要關心服務的通訊呢？ 

技術棧下沉 

那麼對於微服務實施來說，能不能像網路協議的下沉一樣，增加一個微服務層來完成這個而是情呢？這就引出了service mesh 

在每個服務中，會有一個service mesh例項，客戶端發起一個請求，首先會把請求傳送到本地的service mesh例項，service mesh例項中會完成完整的服務之間的呼叫流程，比如服務發現、負載均衡。最終傳送給目標服務。而這個service mesh例項，專業名稱應該為:sidecar , 簡單來說，它是原有的客戶端和服務端之間的一個代理 

在多個服務的呼叫中，這種通訊方式的表現形式就像一個網格，sidecar之間的連結形成了一個網路，這個就是service mesh的由來 

Service Mesh為業務開發團隊降低了門檻，提供了穩定的基礎設施，最重要的是，讓業務開發團隊從微服務實現的具體技術細節中解放出來迴歸到業務。