業務團隊的痛點?

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為業務開發團隊降低了門檻，提供了穩定的基礎設施，最重要的是，讓業務開發團隊從微服務實現的具體技術細節中解放出來回歸到業務。?

?

總結

以上是生活随笔為你收集整理的SpringCloud微服务带来的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。