詳解4種微服務框架接入Istio方案
摘要：使用k8s和lstio網格進行開發，將服務發現、服務治理留給基礎設施，可以將開發人員從複雜的服務中解脫出來，專注於業務開發，是當前來說比較好的解決方案。
本文分享自華為雲社群《傳統微服務框架接入Istio方案詳解》，作者：香菜聊遊戲 。
微服務的概念和原理
微服務帶來的問題
微服務帶來的好處：
解耦了業務，解耦了程式碼和架構，業務更緊湊，邏輯更單一簡單。
微服務帶來的問題：
在早期的時候，使用單體架構，所有的業務都在一個服務內，沒有跨程序和網路上的一些複雜度。
微服務化之後引入的問題包括如何做服務發現，怎麼做負載均衡，包括服務間的訪問保護，例如熔斷，故障定位等等問題。
在故障定位時，在原來單體服務下只需要看下日誌，但是微服務化之後需要藉助分散式呼叫鏈工具，這無形中帶來了開發和定位問題的複雜度。
微服務和lstio網格架構對比
微服務框架我們瞭解比較多的Spring cloud 或者國內用的比較多的Dubbo，框架本身就不多介紹了，我想大家都有所瞭解。
原理就是提供了開發的SDK或者說叫框架，這些框架都是內建了一些解決微服務問題的方案，比如服務發現，負載均衡，服務的熔斷和降級，以及呼叫鏈路的埋點，動態路由這些事情。
下圖是一個典型的用法，也是應用非常廣泛的用法
基於網格的治理是近些年應用比較多的，從上圖可以看出，雖然基於網格的治理提供的能力和上圖的基於sdk的能力一樣，但是兩者的設計原理，使用場景，設計理念是不同的。
詳細介紹
服務發現和負載均衡
上圖是傳統的微服務框架的原理
一般的流程是：
• 服務啟動的時候向服務中心進行註冊
• 呼叫的時候先從服務中心獲取後端服務的地址
• 選擇一個例項傳送請求，等待回覆
服務網格的工作原理：
服務網格一般和k8s結合使用，因為k8s 本身做了服務的endpoint 維護，所以lstio不需要做服務註冊，只需要做服務發現。
看下詳細的區別
服務熔斷
服務熔斷的機制：
如果一個服務在配置的一段時間內一直不可用，可以通過熔斷機制，把服務隔離開，接觸不到流量，進入到半熔斷狀態，
如果在一定的考察時間段能夠恢復正常，熔斷狀態就會關閉，如果還是不能正常，會繼續進入到熔斷狀態。
傳統微服務框架的問題和基於服務網格的解決方案
問題1：微服務SDK的多語言問題
上面這張圖示意了微服務的之間的關係，一些大的客戶擁護大的系統，系統由多個服務組成，服務可能由多種語言開發。
比如系統中可能有go服務，C++服務，python服務以及spring cloud 服務等等，這是一種比較常見的情況。
在這些服務中想做一個通用的服務發現時，但是Spring cloud或者Dubbo開發的服務，有一套自己的服務發現機制，但是不同語言開發的服務之間發現框架是不同的，比如go服務開發的服務不可能去spring cloud的服務中心註冊，這個問題沒辦法解決。
比較粗暴的解決辦法是對其他語言的專案用Java重構，在專案不復雜的情況下是可以接受的，但是在系統業務比較複雜，需要修改的專案比較多的情況下是無法接受的，不僅需要大量的人力，還要花費大量的時間，服務的穩定性沒法保證。
服務網格的解決方案下，服務發現是業務解耦的，不管是什麼語言開發的服務，因為proxy不需要參與編譯，網格之間只需要開放埠，並且保持可以訪問，在這種方案下，不需要修改原來程式碼，減少了開發量，是企業可以接受的。
問題2：基於sdk的服務在k8s下出現延遲和資料不一致
在上圖這種情況下，Consumer服務原來在pod1 上，後來由於排程問題，導致Consumer服務遷移到pod2 上，正常情況下pod1 需要登出，pod2 進行重新註冊，但是如果pod 遷移比較頻繁，導致Producer 在訪問Consumer服務的時候仍然拿到老的註冊地址，就會出現延遲和資料不一致的情況。
問題3：基於SDK邏輯開發的服務升級必須重新編譯
基於SDK開發的邏輯程式碼進行升級的時候，必須重新編譯所有基於SDK開發的服務，這個升級會帶來大量的工作量，SDK的升級過程必須要和業務團隊一起升級，非常耗時。產生的需求就是如果業務程式碼沒有改變的情況下不需要重新編譯。
使用網格的解決方案下，如果業務沒有修改是不需要進行編譯和修改的，對開發人員和運維來說是非常友好的，同時降低了運維的風險，畢竟任何改動都是風險。
問題4：基於SDK開發，統一發現和治理能力，需要全部改造
如果對一個單體應用進行微服務化，一般是漸進微服務化，比如上圖，一般先對svc1進行微服務化，然後再對svc2 進行微服務化，在開發的過程中需要仍然訪問互通，但是使用SDK的微服務有時需要使用同一框架，同一版本才能進行通訊互動，這就是痛點。
在使用網格的情況下，第一步先對svc1進行微服務化，svc2不改動，在開發的期間仍然不影響原來的訪問。
傳統微服務框架在服務網格中整合的實踐詳情
總體思路
解除安裝SDK的服務發現和服務治理的功能，將這些功能遷移到基礎設施上，讓使用者從這些中解脫出來，只專注於自己的業務程式碼。
解決方案
傳統微服務的發現是註冊到註冊中心
在使用網格之後，平臺同一服務發現，使用kube-proxy進行服務發現和負載均衡，Kube-proxy 直接返回服務的ip和埠，這樣的話就消除容器環境下服務發現數據不及時的問題。
在使用k8s做服務發現，再使用網格的能力，服務完全無需修改適配
Spring cloud專案的改造
在原來的配置中，取消對註冊中心的註冊，改為直接使用服務名:埠進行訪問，直連的這種方式會被k8s 進行轉發，對業務程式碼無需修改，減少了工作量。
注意：要和訪問的服務保持協議一致。
移除spring cloud 的專案依賴
微服務閘道器的改進
情況1：微服務閘道器有業務邏輯
寫了很多自定義的邏輯，比如filter的過濾等等，這種情況下閘道器可以作為普通的微服務部署在網格內。
情況2：微服務只有通用邏輯能力
直接用Ingress進行替換，進行地址對映，路徑對映等基礎能力，移除原來的閘道器。
整合微服務註冊中心到網格
由於有些專案開發架構自成體系，不太適合直接排除原來的基礎能力，在這種情況下想使用網格的能力，需要把原來的註冊中心匯入。Istio從微服務的註冊中心匯入註冊資料，並且轉換格式儲存，在這種情況下依然可以配置相同的治理規則。
總結
使用k8s和lstio網格進行開發，將服務發現，服務治理留給基礎設施，可以將開發人員從複雜的服務中解脫出來，專注於業務開發，是當前來說比較好的解決方案。
視訊地址：https://education.huaweicloud.com/courses/course-v1:HuaweiX+CBUCNXI055+Self-paced/courseware/511f6f06d97d4aaf9b90445dca5800d1/c08eb6fa0dd14a34bd617c6beb63a923/