国产精品看高国产精品不卡-国产精品看片-国产精品蝌蚪-国产精品狼人久久久久影院草久久一区二区三区午夜亚洲福-国产精品老熟女视频一区二区-国产精品理论片

分而治之是面對復雜問題時的慣用方法，微服務架構在分和治兩個方面都給出了很好的理論指導和最佳實踐。但是過去幾年，無數的中小團隊在微服務上陷入了掙扎，很多公司在放棄微服務，其中包括一些大型企業，比如 2020 年，Uber 放棄了微服務，轉而使用宏服務;GitHub 的前 CTO 近期也表示全面微服務是最大的架構錯誤，這其中不乏對引入微服務架構帶來的復雜性的聲討。那么，微服務架構帶來的復雜性和架構問題到底如何被干掉呢?

本期《極客有約》，我們邀請到了快手微服務中間件技術負責人魏詩白，去哪兒旅行技術總監、技術委員會委員鄭吉敏和網易數帆云原生技術專家、架構師裴斐一同探討云原生時代，微服務架構治理之道。

如何降低微服務架構復雜度?

InfoQ 第一問：大家有遇到哪些不適合用微服務架構，但卻用了微服務架構的案例?

裴斐： 主要有兩大類，第一類比較常見，比如一些架構復雜性并不高的小型業務系統，這類系統使用傳統的單體架構足以支撐，引入微服務架構反而會給研發團隊帶來很多復雜度和不確定性，進而導致不必要的成本損耗。

第二類是底層基礎平臺，典型的例子就是早期的 Istio。Istio 作為開源服務網格框架，其自身也采用了微服務架構，包括微服務的組件 Pilot、Mixer、Citadel 等。這樣設計的初衷是希望系統可以按照基礎能力更好地分層和配合，同時提供更好的能力抽象。弊端是這也成為了 Istio 早期的“阿喀琉斯之踵”，比如其以 Mixer 作為后端微服務，服務間互訪時候均會調用 Mixer 同步 Check，這就成為整個微服務系統的性能瓶頸。Istio 1.5 版本從微服務架構回歸到單體架構，重新走上了代表服務網格發展的正道。

魏詩白： 以快手的實際業務架構為例，早期內部有一個大型服務本身采用的是微服務架構，但是隨著業務迭代，其變得越來越復雜，于是業務架構師們就決策要不要做進一步拆分。

這個過程出現過很多反例，一是在實踐過程中發現有些業務的依賴較重，比如依賴很重的緩存，這可能影響服務本身的穩定性。為了解決該問題，我們將緩存相關邏輯打包成接口，并且服務化掉，看似通過物理隔離的方式解決了問題，但這對后續的維護包括資源占用都起到了反作用，真正解決這個問題應該從架構本身來看緩存設計是否合理。

二是有些業務開發人員服務拆分經驗較少且有一些工程師心理，寫新 Feature 時經常會找不到合理的、可實現的位置安放，于是就會想一些比較 Trick 的方式，比如寫一個 For Side Service，然后把相關邏輯包裝成微服務上線。他們沒有考慮業務本身的依賴邏輯關系，而是單純為了實現一個服務去實現一個服務，這也是一個比較明確的反例。

鄭吉敏： 我來自去哪兒旅行，主要負責酒業相關業務。在酒業搜索做召回時，用戶搜索指定日期會看到很多酒店，其內有對排序很重要的因子，就是這些酒店是否在條件里——是否有房態。假如酒店沒房，排序會特別置底。

為了做好這件事情，我們需要投入很多精力解決兩個核心問題：一是去哪兒網本身沒有庫存，資源完全來自于供應鏈，因此需要快速計算當前哪些酒店有庫存。

二是排序對性能要求特別高，舊版解決方案是在路由層面配置了 86 個有狀態的集群，請求進來會哈希到 86 個集群上面，這樣可以解決一些問題，比如正常情況下，在線酒店的日期組合是 80 多萬，結合日期差級是一個特別大的數量級，這是無法存儲下來的，但是為了保證性能，可以用到 86 個集群的內存。這也會帶來一些問題，比如每次請求都要先哈希到對應集群，再繼續看內存里面是否有庫存。如果有，直接返回有庫存。如果沒有，第一次返回無庫存，之后做異步探測，將庫存寫到內存里，第二次就可以返回有庫存。

這個設計短期內解決了一些問題，但我發現其中有兩個特別嚴重的問題。第一，每天哈希之后的結果是不同的，導致 86 個集群每天都有個別出現問題，但是又無法修正，相當于每次都會有請求受影響;第二，有些場景擴展特別難，這是我遇到最痛苦的不適合微服務但是用了的場景。為了對此做支持，團隊花費了很大精力，開發用了九個月的時間才把整個事情收尾。核心在于，我們因為微服務搞出來的一些有狀態的事情很不適合微服務架構，同時我們要解決的問題更多偏向擴展性，不太適合微服務架構。

InfoQ 第二問：微服務架構的復雜性具體體現在哪幾個關鍵的層面?各自在公司的實踐過程中踩過哪些坑?

魏詩白： 以我個人的實踐經驗為例。一方面，微服務架構本身肯定需要額外的基礎能力，比如需要做服務治理，本來的單體應用擴散到分布式可能需要服務本身的配置管理以及相關鏈路級別的監控、Tracing 能力，公司層面可能需要組織一個團隊搭一套微服務解決方案，這些對底層架構、工程師經驗、運維都提出了很高要求。

另一方面是業務層面，以一個 Java 生態棧為例，很可能出現 jar 包依賴版本管理問題，這是比較嚴重的，經常會有一些由于版本依賴管理不合理導致編譯沖突、上線的 Runtime Error 這種問題，一般都會影響整個研發和 CI/CD 效率。這就體現出業務之間如何做服務治理，包括合理的業務資源架構領域解耦等。

即便是現有的開源方案同樣無法完全自動化運維，肯定需要具備相關經驗的架構師參與進來解決問題，尤其是隨著公司本身的業務迭代速度，包括業務體量增長，對分布式架構包括分布式組件、中間件的要求會越來越復雜，很多能力是開源組件無法提供的，這就需要提供各種需求支撐業務發展，需要越來越龐大的團隊去支撐，這也是我們團隊現在面臨的主要問題之一。

裴斐： 我大概總結了三個關鍵詞，分別是引入、異構、冗余。

1. 引入。我們在引入微服務架構之后，必然會出現新的問題，比如服務網格本質上也是為了解決一些傳統微服務架構存在的升級難或者侵入性大等問題，但是同時服務網格的引入也帶來了一些新的問題，比如 Sidecar Proxy 帶來了更多的延遲和性能的損耗。

2. 異構。對業務來說，服務架構并不是天生統一的，一方面是業務中同時存在多種異構系統，比如有的業務會采購一些系統，彼此之間采用的開發語言、協議等可能都不一樣，不同異構系統之間非常難做到真正意義上的打通和統一管理。另外一方面是業務系統本身如何保障新老架構的平滑演進，在這個過程里面對于業務盡量無感知或者少感知。

3. 冗余。冗余就是業務遷移到新架構中可能會出現的問題，比如老技術組件的冗余。早年，非常多業務普遍在生產上使用 Nginx 這樣的流量代理軟件，后來隨著微服務架構的興起，業務往往會引入一個新的組件——微服務 API 網關。但從流量處理能力上 Nginx 與 API 網關存在重疊，這就使得很多微服務架構一上手就在架構邊緣有冗余，要解決組件重疊帶來的延時、資源損耗以及維護性變差等等問題。。

鄭吉敏： 微服務確實對整個公司的基礎研發要求特別高，比如正常的服務治理、協議轉換、網絡時延是否能用;需要開幾個新的微服務;鏈路治理，查問題特別依賴基礎組件本身的完善性，那么外部組件是否能滿足要求。很多時候，當我們真的引入那些組件時，需要基于它們做二次開發，來滿足公司定制方面的東西，這很考驗整個技術研發能力。

我們在做微服務時，除了要站在技術角度，還要站在業務角度。比如微服務究竟怎么劃分是個特別關鍵的問題，并不是說有了技術能力支持，就可以找到一個標準去開啟新的微服務。究竟怎么劃分能更好地支撐業務發展，尤其是支撐未來的業務擴展，這些都非常關鍵。

而且這個過程中如果出現不合理的情況，治理壓力會更大，比如遺留服務。遺留服務很多時候來源于前期的設計不合理，以及當前的設計很難滿足未來需求，這方面如果考慮的少也是很大的問題。因此，我認為微服務要兼顧當前整個公司的基礎水平以及業務發展的需要，兩者結合才能真正做好。

InfoQ 第三問：針對如何更好地去干掉微服務架構復雜性，有哪些解決思路?

鄭吉敏： 首先回歸事情的本質，我上述所言的業務邏輯本質是確定房態，房態是搜索因子，正常情況下應該放在搜索團隊內部。我們換一種方式，取一些稍微粗略的落地數據通過一個流程寫入搜索內存，相當于多耗一點內存就可以將路由層的 86 個集群全部干掉。這里面過程比較復雜，花費的時間比較長，因為要把整個鏈路走通，包括把全量和增量拉齊以及數據變更如何快速通知到位。

核心在于大家要先明確服務到底應該做什么事情，要解決的本質問題是什么以及屬于哪個領域內的問題，并把這些問題交給對應方解決而不是引入一個微服務去解決。

除了解決單點問題，我們對內部架構也做了特殊治理，我們把內部團隊劃分成幾個比較大的領域，比如供應鏈域、核心領域、網關域。一個請求進來之后會通過網關域組裝下面的核心領域，核心領域依賴供應鏈，供應鏈跟外部交互，網關相當于接收的是從自己 APP 過來的請求去組裝中間的核心領域。核心領域包含搜索域、報價域、營銷域以及訂單域，通過域把每個團隊資源的核心服務分開，報價域內部可能還分定價相關的模塊，營銷域分商家促銷、平臺促銷以及補貼方面的事情。基于此，每個核心域還會把自己內部的模塊進行劃分。

我們從全局視角知道模塊劃分原則以及每個模塊的具體職責。比如營銷域的一個商促通常會劃分成三個模塊：實時運算，數據同步，數據模型轉換。這樣，每個模塊做的核心事情比較明確，結合在一起就可以構成一個微服務組一起提供商促服務。當需要擴展時，我們只要在對應的微服務進行擴展就可以，接入也比較快。這是我受益最大的地方，相當于是先將團隊按照一定領域劃分，團隊內部負責的領域再拆分出多個核心模塊。

裴斐： 主要有三方面：一是如何解決新架構引入的新問題。舉例來說，比如服務網格引入了 Sidecar Proxy，帶來了更多延時損耗，從引入服務網格到業務之后一直做的事情是加速。最初我們針對性地做了一些網格加速能力的構建，目前也有一些沉淀，我們會配合網易云底層的網絡團隊、SR-IOV、用戶態協議棧等偏重于優化底層網絡、容器網絡的技術，一起優化服務之間通過 Sidecar 的網絡延時。

去年至今比較火的概念是 Proxyless。既然 Proxy 的方式帶來了很多問題，就需要嘗試把 Proxy “less” 化，相當于無 Proxy。有非常多的企業都在關注這方面，尤其是大的互聯網企業，都有自己的 Proxyless 技術路線。

我們在做的兩條路線：一條路線是基于 Java 的無侵入 Agent，在應用進程內實現 Mesh 能力，相當于業務可以不用獨立的 Sidecar Proxy，直接通過類似無侵入的方式在應用進程內把微服務的治理、監控、管理、配置等能力增強。同時因為本身是無侵入的，所以可在業務無感知的情況下在應用進程內生效;另外一條路線是基于 eBPF 以及 Istio 最近研發的 Ambient 技術路線。

總結來說是實現微服務四層流量和七層流量分拆的問題。具體來說，在內核態處理四層流量，使用共享數據面處理七層流量，這樣就可以逐步實現無 Proxy 的服務網格。因為四層流量是在內核態，不依賴 Proxy。七層流量目前完全做到不需要 Proxy 是非常難的，但是從每一個 Pod 使用一個 Proxy 降級為共享數據面方式，也是向無 Proxy 邁進了很大一步。

二是異構架構的問題。我們團隊服務網易內部以及外部的一些合作企業，遇到過非常多異構架構的問題。為了解決這些問題，我們內部提出了“雙引擎多模式”的架構。具體來說，我們構建的平臺不希望限制業務使用微服務引擎。當然這也是業務提給我們的訴求，不希望一定使用某一種微服務引擎去實現微服務。同時，我們可以支持多種引擎的完整能力，包括 SDK、Agent、服務網格的 Sidecar 以及后續可能的演進，包括 Proxyless 以及多運行時組件。完成這些能力之后再去拉齊不同引擎之間的核心能力，包括通信協議支持不同引擎之間的互訪互通以及統一管理。

三是解決技術冗余的問題。以解決網關重疊為例，我們的路線是建設一個七層的通用網關，統一使用服務網格數據面的標準 Envoy 做數據面的選型，進而構建七層通用網關。目標是實現傳統的軟件代理 Nginx 和新型流量軟件比如 API 網關、K8s、Ingress、Serverless 等的合一，這樣我們只需要部署一層 Envoy 這樣的七層通用網關就可以處理全部七層流量。好處是降低疊加不同組件造成的延時，并解決資源損耗、運維難度加大等問題。

魏詩白： 我上述提到了兩個問題：一是業務之間的服務相關治理怎么做;二是中間件團隊在微服務架構層面如何幫助業務解決復雜度。

第一個方面，公司內部的業務線之間需要考慮的事情是在整個微服務的研發生命周期，包括開發、測試、部署、上線、運維，都要有一整套產研的研發規范。

首先，公司層面需要有基礎規范，比如針對域的開發規范，一些明確會引入系統風險的明確禁止，類似研發與規范手冊;其次，團隊之間需要考慮包之間的依賴沖突問題，我們在公司統一層面需要有一套統一的包管理機制，至少能夠解決業務側不會因為基建的不完善導致研發效率被 block 掉。

公司業務層面需要思考彼此的依賴如何更好解耦。解決方案分為兩種：第一種是 SDK 設計更輕量級、更薄。比如，服務應該如何被上游使用方依賴以及服務的 SDK 面向使用方是否足夠合理，都需要一些規范去限制，這是業務之間的限制。當然還會有跨業務線、跨部門，比如電商可能會與中臺團隊做上下游關系的依賴，就需要有底層業務對上層業務支撐的能力，比如需要做好多租戶管理和接入規范等。

第二個方面，我們需要思考如何解耦業務與非業務架構，包括現在行業里面比較火的 Service Mesh 都在做這樣一個操作，中間件的 SDK 會把服務治理相關能力收斂再下沉，最后再去 Agent 化或者 Mesh 化，進而實現自身的非業務性訴求迭代與業務側迭代的解耦。解耦之后會極大提升我們對業務側需求、功能的支撐，不會讓公司大規模升級 SDK 版本。

我們一直在通過技術手段解決上述問題，進而幫助業務提升研發效率并解決微服務架構帶來的穩定性問題。這個過程需要有些服務治理的手段，比如流量保護機制、固態保護、熔斷、可觀測性等來幫助用戶主動挖掘系統側的風險，主動規避掉這些問題，比如當業務側的服務出現線上抖動之后能夠主動發現并且一鍵解決。

微服務架構設計焦點問題探討

InfoQ 第四問：如何盡量避免過度設計和過度拆分?

魏詩白： 我個人的觀點是，首先要克制。工程師、架構師們都需要克制對技術的過度追求，貼合公司的實際發展現狀，包括當前業務狀態以及業務體量。其次是需要衡量當前團隊人員背景及行業基本原則，比如兩個披薩原則——一位研發同學最多負責的服務數不要超過一定范圍，比如 3 到 5 個。因為負責的服務數過多對運維及功能迭代成本帶來了很大壓力，因此需要根據組織的當前構成考慮問題。

總體來說，一是有些行業中存在微服務的拆分原則，比如領域驅動設計等成熟的解決方案，其本身的理念是組織、團隊跟著整個業務形態走，組織與系統架構結合越緊密，越能實現往前迭代的發展，從而避免過度拆分的問題;二是每個人負責的微服務數不要過多，否則會導致整個團隊的運維成本陡增。

總結來看，我個人認為微服務拆分的最優解不一定非得是領域驅動設計。第一，肯定要參考當前所在業務團隊的整體架構風格，整個領域建模的風格、業務劃分的邏輯，不可能自己造一個與團隊架構非常不貼合的模式;第二，從公司實際的業務規模出發，如果是初創公司沒有必要一上來就用領域驅動設計，還是應該從簡。即便是微服務，沒有必要為了抽象而抽象，核心觀點還是要貼合業務發展。

裴斐： 對于過度設計，我認為是經驗和目標的問題。比如我們發現團隊里面的部分同學由于欠缺架構設計經驗會做一些過度設計。一般來說，我們在做設計時，首先要看需要達成的目標，然后圍繞目標做針對性設計，并且評估這個設計能不能達成目標。如果恰好可以達成目標，就是一個比較合適且不錯的設計，并不是越復雜、越宏觀的設計就越好。

InfoQ 第五問：針對遺留系統改造有哪些建議?

鄭吉敏： 我先說對遺留系統的理解，比如在日常業務迭代中會發現很多當前比較核心的業務，但是 1 到 2 年甚至更長時間的迭代之后，當時所謂的業務場景已經不再有價值，可能會使處理其的系統也變得沒那么有價值，這被我們稱為遺留系統。

我們公司內部當前也在做這件事情，我們希望團隊里的每個人平均維護的服務數在 3 個左右，我們也投入了很多精力。主要分為如下幾步：一是公司提供一些基礎能力，比如通過工具發現服務里面不經常被調用的代碼，基于此評估不被調用的原因再下結論;二是結合業務線對實際業務的理解，比如前年重點做的業務 A 現在因為疫情開始做業務 B，之前的 A 業務本身沒有價值了，我們會重新評估該業務是否需要存在;三是梳理或者重點治理時發現部分業務邏輯不清楚，我們會評估該業務價值來決策是否需要關閉入口或者下線服務。在業務關閉之后，相應的代碼同樣下線，最后對相關系統做整合，盡可能干掉遺留系統。

裴斐： 我從架構或者決策層的視角來回答這個問題。以金融領域的合作企業為例，一是選擇業務。企業申請業務時建議選擇一個準核心業務，既不是直接選非核心業務，因為非核心業務雖然壓力小，但是缺少全面的場景覆蓋，同時重視程度也沒那么高，真出了問題也沒那么多人關心，反而達不到試點業務的目標。也不是直接選擇核心業務，因為核心業務肯定會有比較大的風險，而準核心業務的風險不會特別大。

二是建設模式。這個問題困擾了我們很久，比如現在有一個比較好的系統，但是業務不是特別好推，這時如何體現我們平臺的價值。企業采用了業務系統加技術綁定的方式直接立項，簡單來說就是平臺和業務部門直接打通，這樣不管是目標還是想達到的價值以及在推動改造落地的過程都是有的放矢的，最終也是為了直接方便技術底座或者技術平臺呈現價值。

最后是團隊結構和決策鏈。結合業務系統技術底座綁定立項的方式，企業選擇的團隊同時會做業務開發和技術開發，這樣基本是以團隊之力把企業里面的試點做完，最終形成遺留系統改造的正反饋。當其他系統看到比較重要的業務以這種方式落地之后也會效仿，這樣就可以在企業內部形成比較良性的循環。

魏詩白： 關于遺留系統改造，我簡單理解就是做系統重構。我認為遺留系統能不動就不動，不動會更好。當然，如果系統本身又煥發一些新的活力，比如某些業務又活過來了。做重構很重要的點就是保證接口不變性，這里重點解答業務驗證部分，我們可以引入偏自動化回歸測試，保證接口的所有邏輯輸入、輸出都是同舊系統對等的，這是必須要實現的。我很少用重構改接口定義，因為這需要對上層做改造，這也是領域之間的耦合，而不是重構應該有的狀態。接口不變，首先需要有偏自動化的測試驗證手段，至少有類似的自動回歸測試系統，比如通過引流機制跑這類 Case，做一些覆蓋等。當然，核心系統重構肯定也要從自身的經營測試等層面做好相關驗證，至少避免由于重構丟失業務邏輯或業務關鍵數據，進而引入系統風險。

回到最開始的原則，重構也需要克制。如果系統沒有導致企業穩定性出現故障，比如導致整個團隊迭代效率降低百分之多少等，我建議不要重構，一定要靠實際的痛點去驅動。

我們公司今年上半年開啟了一個新項目，要把一些無用的應用和無效的代碼盡可能下掉，但是過程中我們確實踩了一些坑。我可以把這方面的治理經驗簡單分享下。

第一，有些時候梳理討論完之后感覺某服務沒用了，但實際線上還是有流量的。因此，我們先基于監控把流量降下來，這個過程需要與調用方溝通，在合適的時間降低接口調用頻率，確認沒有流量請求之后再去做其他事情。

第二，下線應用域名時，我們需要發郵件告知業務方下線的時間、原因及后續解決方案，給業務方足夠的時間調整，以防止個別雖然當下沒有流量但可能定時在某個時間會被業務方大量調用。

另外，當確定好具體下線的應用時，我們可以先停機一周觀察是否出現意料之外的問題，盡量降低潛在影響，動手之前將準備工作做足很重要。

經過一段時間的努力，我們安全地將無效的系統下線，人均運維系統會變少也提升了整體技術團隊的幸福感。

InfoQ 第六問：超大公司的大規模落地實踐對于中小企業而言參考價值有多少?

魏詩白： 我認為需要看一家大公司是如何從小公司做起來的，以及整個架構演進歷程是什么樣的，可以與該公司里的資深架構師、資深研發工程師等做一些深度交流。比如我們與字節跳動的技術團隊交流時發現他們在 Service Mesh 剛興起之時就開始做了，所以字節跳動在服務網格層面的進展目前是國內最好的公司之一，當然這與其內部當時出現的一些契機也有關系。

我的核心觀點是小公司在看整個大公司的技術演進歷程時需要思考不同體量的業務應該具備哪些技術能力，如何向一個正確的方向演進，是否在不同的階段有不同的側重點，比如一開始側重迭代效率，隨著業務體量不斷增加，側重點傾斜到穩定性上等，這是大廠實踐能夠給小廠包括新興創業公司帶來的參考價值。

未來趨勢

InfoQ 第七問：如何看待 Dapr 和 Mosn 等運行時的發展?

魏詩白：微軟的 Dapr、螞蟻的 Mosn 以及字節的 Better Runtime...... 我個人對此持開放態度。從我與大廠的交流經驗來看，目前除了字節跳動和螞蟻金服部分業務落地相對還可以之外，其他大廠還缺少落地實踐或者說大規模落地實踐。

整個愿景是好的，其核心是如何做好業務與非業務的解耦，并且能夠盡量讓業務更簡潔、更高效地關注應該關注的業務邏輯，而忽視或者盡量做到無感的底層架構、底層中間件相關的特性信息。所以會做類似于把不同的協議，包括不同的中間件，做一個通用接口層的抽象，所有底層類似于往 Bes 化的方向發展。我覺得未來可能是一個趨勢，但是目前來說還是缺少比較好的大規模實踐經驗。

對于小公司，我個人觀點是不建議一上來就追隨新技術，還是要從實際出發，可能用一個 Spring Cloud 或者 Dubbo 這樣的框架就夠用了。

裴斐： 關于 Dapr，我認為多運行時的架構或者標準非常值得關注，但同時也是一個非常遠期的概念。我們關注到非常多的大廠已經在做服務網格，但是實際上對大部分企業來說，尤其是中小型企業，基本上可能需要未來 3 到 5 年這樣的周期才能將服務網格普及和大規模落地。

相較于服務網格，Dapr 會更加超前。整體周期上大規模落地可能要 5 年甚至更多的時間去發展以達到真正的成熟，但是我認為這個標準還是非常值得關注的。如果有業務或者技術架構團隊想做這種偏底層的新平臺時，我認為多運行時這樣一個概念的設計不管是模塊化還是接口化的能力都值得借鑒。

InfoQ 第八問：Sidecar 是否會被 eBPF 逐漸取代?

裴斐： 我們關注 eBPF 較早。我們在做網格優化時已經在用該技術，只不過很多 Cillium 也是想在 Service Mesh 領域更進一步，進而提出了這樣一個方案——實現內核態的 Proxyless 。

我認為 Cilium eBPF 跟之前做的容器網絡加速非常相關的一點就是 Cilium 更擅長處理四層流量。簡單來說，Cilium 可以帶來四層流量的安全性、四層監控等能力，四層的流量并不需要一個獨立的 Proxy 去處理，而是在內核態用 eBPF 技術就足夠了。

反過來再看七層，因為非常多的能力需要在七層處理，這方面并不是 Cilium 的特長，所以在七層選擇的時候，還是要選擇 Envoy 這樣一個服務網格的數據面標準組件去做。這樣就形成了四七分離的架構，四層用 Cilium 這種比較成熟的技術，七層用 Envoy 組合，至少要比完全 Proxy 化的方案有進步。

但是具體來說，生產是不是可用，我覺得目前也是一個探索的狀態，畢竟這套東西距離真正的完全無 Proxy，或者達到目標態的收益，還有一定的距離。

總的來說，我認為四層上面 Cilium eBPF 做內核態的 Mesh 更合適。對于七層，我認為可以盡量往 Istio、Envoy 方向靠攏。Istio 的方案逐步可以形成 Cilium BPF 跟 Istio Envoy 這兩種方案分別在四層和七層形成優勢，共同實現無 Proxy 的服務網格。

魏詩白： 我結合目前互聯網環境的現狀做補充，各大公司現在都想降本增效，目前有一個趨勢叫逆微服務，譬如隨著團隊人員規模的縮減，之前的微服務數量肯定也要縮減。具體的操作是把一些服務做組合聚類和重構，組合成更大的微服務來去應對這樣的現狀。核心理論是適應公司當前的發展現狀，我認為一個好的架構是能夠適應公司當前的發展現狀，并且能夠為公司的發展保駕護航，不一定非得是微服務架構。

此外，eBPF 確實可以解決 Sidecar 面臨的一些問題，比較直觀的是多了兩跳這樣一個性能問題。以我們公司的實際經驗來說，可以對 Sidecar 做一些相關的優化，比如業務進程與 Sidecar 之間可以用 domain socket 做交互，在一些語言比如 Go、Python、Java 上還是有機會在性能層面打平的，未必一定要用 eBPF 的方式去取代 Sidecar。

但是，eBPF 有很多優勢，我們公司也在探索階段，我們更多地是用新興技術做內核層面的監控和性能分析。但其本身會有內核版本的要求，可能在大型公司應用需要過渡過程，因為內核版本升級是一個高危操作。

InfoQ 第九問：逆微服務會成為接下來一段時間大家調整的方向嗎?

裴斐： 我認為微服務不是唯一的正確答案，我認為最主要的是看要解決什么問題，到底能不能達到你的預期，而不是為了做微服務而去做，這會帶來更多成本損耗。

鄭吉敏： 我比較同意裴斐老師的回答，我們一定要看清單體服務或者微服務本身的優勢。如果不存在相應痛點，企業不需要特意引入微服務，畢竟引入的同時也帶來了其他的復雜性問題。

InfoQ 第十問：對于當前并不確定是否要搭建微服務架構的企業，有哪些建議?

鄭吉敏： 小公司是否適合搭建微服務架構不是根本性的問題。根本性問題在于當前的微服務化能承載多少人，假設一個單體應用需要太多人維護一定會影響效率。如果要拆分微服務，需要評估技術團隊是否能滿足，這里面涉及到業務側和中間件側，如果團隊能力沒問題，再評估怎么拆，這又涉及很多拆分原則，需要從架構師到整個團隊成員都達成共識。這里面需要經過磨合，讓大家都認可一個方向，按照一個目標去努力，否則很容易走偏。

裴斐： 首先要看業務場景。如果業務場景確實屬于比較小型的業務系統，或者比較底層的技術平臺，我認為不太必要搭建微服務架構。但是當業務系統達到一定規模，比如有幾十個以上相對獨立的業務時，就可以去拆分形成微服架構，此時團隊應該考慮怎樣搭建這個架構。

另外，需要結合團隊的實際情況，基于開源做一些擴展自建或者與相應的服務提供商、公有云平臺達成共建。基于開源，建議盡量選擇一些細分領域，可以代表技術趨勢的一些事實標準的框架去構建。避免因為技術標準小眾，或者很容易過時導致無法持續運行。

也可以與服務提供商多交流。假設認為自己團隊有實力完成整個架構，可以聽一些公開分享或者了解比較成熟的知名服務商是怎樣解決通用問題的，以這種方式做一些盡量長遠的選擇。

但是，如果還是希望與服務提供商達成協作，就需要判斷廠商解決異構架構、技術冗余問題的能力等。