歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

房多多Service Mesh實踐

2019-02-25 分類：後端 閱讀(411) 評論(0)

隨著微服務數量越來越多，給業務開發團隊的增加了溝通和維護的成本，為瞭解決這一的痛點，我們關註到了Service Mesh技術，本文主要介紹房多多在Service Mesh中的一些經歷和過程，以及在工程效率方面的一些感悟。
概述和需求背景

 

房多多國內領先的經紀人直賣平臺，目前房多多APP和多多賣房APP的後端服務主要執行在自建的IDC機房。2018年之前，我們的服務都是執行在VM上，也同時基本上完成了基於Dubbo的微服務改造，目前的語言技術棧主要有：Java、Node.js、Golang。相對於其他公司而言，技術棧不是特別分散，這給我們服務容器化帶來了極大的便利。
我們在2018年Q3的時候已經完成大部分服務容器化，此時我們的微服務數量已經超過400個了，在溝通和維護上的成本很高。因為我們後端服務是主要是基於Dubbo的，跟前端直接的互動還是透過http的方式，在沒有上Service Mesh之前，http請求都是經過Nginx轉發的。維護Nginx的配置檔案是一個工作量大且重覆性高的事情，運維團隊和業務團隊迫切的需要更高效的方案來解決配置管理和溝通成本的問題，構建房多多Service Mesh體系就顯得尤為重要。Envoy是一個成熟穩定的專案，也能夠滿足近期的需求，在現階段我們並沒有人力去動Envoy，所以我們直接使用了Envoy做Service Mesh的資料平面，關於控制平面這塊，在調研了一些方案之後，我們採用了自研的方案。

 

整體平臺架構

 

我們的容器平臺整體是基於物理機的，除了排程節點是用的虛擬機器以外，所有的工作節點都是使用物理機。之前我們的虛擬化方案是用的Xenserver，Xenserver對高版本的核心支援並不好，會時不時的出現自動虛擬機器關機的bug，所以我們在工作節點上只使用物理機以保障業務的穩定和高效。
我們的業務主要工作在自建IDC機房，公有雲只有少量的災備服務。因為是自建機房，相比較公有雲而言，自建機房使用Macvlan是一個比較好的方案。我們預先劃分了幾個20位地址的子網，每個子網內配置一些物理機，透過集中式的IP管理服務去管理物理機和容器的IP。相比較bridge網路，Macvlan網路有著非常接近物理網路的效能，尤其是在大流量場景下效能出色，下麵一張圖顯示了效能對比：

我們把Envoy作為兩個網路之間的連線橋，這麼做的好處在於可以控制流量都經過負載均衡器，便於集中管理以及對流量做分析。看到這裡，肯定有疑問是為什麼不使用Sidecar的方式部署Envoy。關於Sidecar我的考慮是，在現有的業務場景下，集中部署的維護成本更低且效能滿足需求，也相對來說比較簡單。我們在2018年Q4已經完成主要業務http2接入，目前來看，我們的網站速度應該是同行業中最快的，大家可以體驗一下，https://m.fangdd.com。

如何解決虛擬機器業務和容器業務的並存問題

 

我們原有的架構大量使用了虛擬機器，遷移虛擬機器上面的服務是一個漫長的過程，當前階段還需要解決業務的並存問題，我們自己開發了Envoy對應的配置集中管理服務，同時支援虛擬機器服務和容器服務。
控制平面服務主要基於data-plane-api開發，功能上主要是給資料平面提供服務的叢集配置、路由配置等資訊，並且需要實現微服務架構中降級和限流的配置功能。容器內部的叢集資料主要依賴DNSRR實現，而虛擬機器上的服務，我們在CMDB上存有AppID和機器的對應關係，很容器生成叢集配置資料。
由於歷史原因，還有相當多的業務無法從VM遷移到容器，需要有一個同時相容容器和VM的資料平面服務，目前XDS服務的支援的功能如下：

  • 叢集資料來源同時包括容器內部DNS和外部CMDB中的VM資料

  • 支援多個vhost配置

  • 支援路由配置

  • 支援速率控制和閘道器錯誤重試

 

應用開發流程變化

 

初步建設起Service Mesh體系之後，理論上業務開發只需要開發一個單體服務，在服務間互相呼叫的過程中，只需要知道服務名即可互相呼叫，這就很像把所有服務都看做一個微服務一樣，所以我們的業務開發流程發生了以下變化：

同時也降低了框架開發成本和業務改動的成本，每次推動業務升級框架都需要比較長的一段時間，業務無法及時用上新框架的功能，多種框架版本也加重運維負擔，Service Mesh幫我們解決了很多痛點。同時再加上我們的閘道器層建設，我們上線一個新服務幾乎是零配置成本的。

  • 代理層實現服務發現，對於開發而言只需要開發一個單機的應用，降低框架開發成本

  • 降級和限流都在代理層實現，規則靈活，方便修改策略

  • 框架功能的升級無需依賴業務

SOA和Service Mesh的對比與取捨

 

在我們的Service Mesh實踐中，增加了鏈路的請求長度，並且服務的鏈路越長，鏈路請求的放大效應會越明顯，這就帶來了一些效能上面的擔憂。毫無疑問，Mesh層本身的業務邏輯開銷是不大，但是在網路傳輸和記憶體複製上的效能消耗在一定程度上會影響鏈路的效能，Envoy也在探索相關的方案來最佳化網路傳輸效能，如Bpfilter和VPP，減少使用者態和核心態的記憶體複製。在可定製性層面，SOA能做的事情也相對較多，可以實現很多hack的需求。
在我們現有的業務場景下，Service Mesh主要還是解決前後端的微服務對接問題，當做前後端服務的連線橋梁。但不可否認的是，Service Mesh帶來研發效率的提升，在現有的場景下的價值遠大於效能上的損失。在大多數的場景下，維護業務框架需要比較大的人力成本，很多團隊都沒有全職的人去維護業務框架。此外，推動業務框架的更新和升級也相對來說成本較高，這也是我們考慮的一個重要方面。

 

總結

 

得益於雲原生架構，Service Mesh可以使用雲原生的基礎設施，基礎設施能力的改進可以直接賦能業務，而不像傳統的框架一樣，基礎設施的升級和改進無法提高傳統框架的服務能力。房多多的Service Mesh還處於初級階段，後面還將繼續探索。
Q&A;

 

Q：容器和微服務的區別以及它們的關聯性、應用場景、客戶群體、帶來的價值？
A：微服務的應用場景主要是解決降低單個服務體積，滿足業務的快速開發需求。容器可以說是微服務的載體，容器方面還是運維關註的比較多，帶來的標準化流程和環境的提升對整個研發團隊都有很大的作用。
Q：軟體實現 Service Mesh，Istio？
A：我們目前只使用了Envoy，Istio也做過一些選型的調研，不是很符合我們現在的業務場景和業務需求，我們在之後的實踐中會考慮使用一部分Istio的功能。
Q：實施過程當中有使用到Istio嗎？有定製一些Mixer配接器嗎？
A：目前還沒有用，之後會考慮是用Istio中的pilot，我們目前在流量的控制的精細程度上面還欠缺，粒度還很粗。
Q：請問，實現微服務過程中有沒有考慮分散式跟蹤和分散式？
A：Service Mesh層可以做到簡單的分散式追蹤，比如可以做到基於請求的追蹤，Envoy可以把trace資料接入Zipkin這樣的trace系統，但是更細粒度的trace目前還做不到。
Q：不論是使用都會產生大量的配置（yaml），尤其是Envoy/Istio，系統中會有大量零散的配置檔案，維護困難，還有版本管理，有什麼很好的維護實踐經驗嗎？謝謝。
A：是的，據我所知有些團隊會使用ConfigMap來管理配置，我們做了一個配置的集中管理服務，從CMDB和DNS定時的抓取資料，資料會存在資料庫裡面，也會存一定量的副本用於配置回退，這個地方還是要結合你們現在其他配套系統的建設來看看怎麼做比較好的。
Q：有沒有遇到過Envoy被oom kill的情況，你們是如何處理的？
A：這個我有碰到過一次，之前我們在對Envoy做測試的時候，發現Envoy總會盡可能的佔滿CGroup的記憶體大小，這個之前在使用TLS的情況下碰到的比較多。但是目前我們內部服務間使用TLS的情況並不多，所以後續這個問題就沒有繼續跟進了。
Q：性化方案有哪些？
A：上面文章中有提到過，對於http服務可以全量接入http2，http2的長連線和多路復用對於一般的業務來說升是很明顯的，我們在全量接入http2之後，網站的響應時間幾乎下降了50%。另外還可以在底層的依賴上面做一些最佳化，比如底層的libc庫，以及盡可能的減少基礎映象的大小，我們基本上所有業務都使用了alpine，這樣可以保證釋出效能和速度在一個很好的水平上。
Q：還是有一個服務治理/配置管理的問題請教，比如CPU，記憶體，這種資源request，在dev，test，staging，prod環境均不同，那麼我們在編寫Kubernetes配置的時候不同環境會不同，比如測試環境的replics數跟CPU需求就很低，生產就很高，另外這個配置在不同環境是多個還是一個呢？謝謝。
A：我們現在會在CMDB裡面維護這些配置資料，一般來說在新建專案的時候，我們就會要求業務線評估一下這個業務需要的資源，比如你說到的test和staging環境這種，我們預設會給一個很低的需求，比如1c1g這樣的，而且replication也會預設設定為1，除非業務有特殊的需求，然後我們去根據配置的資料去生成yaml格式為配置。
配置在資料儲存的形式上是多個，但是在對業務展示上，儘量讓業務感覺到是一個資料，這樣也能使每個環境都規範起來，跟生產環境盡可能保持一致，這個對測試的好處還是很大的。
Q：你們目前的專案中，大量的微服務，以及排程層，瓶頸和容災是如何處理的？
A：由於我們的業務型別還是B端業務為主，流量的峰值是可以預估的，很少會出現突發的大流量的情況，我們一般都預留了1倍的容量用於臨時的擴容。容災和排程的話我們主要還是盡可能的隔離工作節點和排程節點，以及大量使用物理機叢集，從我們的使用體驗上來看，物理機的穩定性還是很不錯的。
Q：如何用Jenkins自動完成Kubernetes部署？
A：自動部署這塊我們有完善的釋出系統，如果單純只要實現Jenkins自動完成Kubernetes的話，Jenkins可以直接呼叫Kubernetes的API，這個網上有挺多資料的，你可以找找看。
Q：Service Mesh比傳統的微服務治理好在哪裡？
A：降低框架開發成本、代理規則靈活，方便修改策略、框架功能的升級無需依賴業務，最大的好處我覺得就是可以降低框架開發成本。
Q：我理解房多多目前的Mesh方案沒有給每個微服務配一個Envoy作為Sidecar，而是使用一組Enovy並自研了xDS的配置釋出管理系統，對嗎？我想請問backend微服務之間的請求現在是怎麼走的呢？謝謝。
A：是的，剛剛文章中說了，我們後端SOA服務還是基於Dubbo的，這塊目前我們還沒有做改動，之後的話我們的初步構想會透過Sidecar的方式把這些Dubbo服務都接入到Mesh裡面來。我們目前的Envoy也是會充當閘道器的角色。

贊(0)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂