簡介：本篇是整個《如何構建流量無損的在線應用架構》系列的第一篇，這一系列共三篇，旨在使用最為樸素的語言將影響在線應用流量穩定性的技術問題做一個歸類，這些問題的解決方案有的只是一些代碼層面的細節，有的需要工具進行配合，有的則需要昂貴的解決方案，如果您的應用想在云上有一個【流量無損】的一站式體驗，可以關注阿里云的《企業級分布式應用服務（EDAS）》這個云產品，EDAS 也將會持續向默認接入流量無損的方向演進。

作者 | 孤弋、十眠

前言

Github 因為軟件升級曾經導致過長達 6 個多小時的全球性服務中斷 ...Meta(原名：Facebook) 也剛剛經歷一起因為配置推送錯誤導致全球 6 個多小時的系統癱瘓 ...

諸如此類的大型 IT 系統故障每隔一段時間都會出來一個。為企業搭建一個安全可靠的在線應用架構，是一個系統架構師主要責任，他除了將業務系統架構吃透以安全地應對當前的業務流量之外，還需要具備構建未來的能力，即所選取的架構需要能應對業務未來幾年的業務增長。這種能力，和技術潮流無關，和所選擇的技術的人才市場容量有關，和企業自身業務形態和增長方向有關。

我們先拋開 IT 系統的基礎設施和企業業務的具象，抽象到在線應用的兩個關鍵衡量指標中去：流量和容量。容量的目標還是為了滿足流量的基本需求，而我們不斷優化的目標，就是一直在這個兩個指標中找出一個能代表"技術先進性"的平衡點。這個平衡點意味著：高效且精確的將現有的資源（容量）服務于現有的，及其可預見的業務流量；高效意味著性能，精確則需無損。

這系列文章一共三篇，旨在讓技術回歸到系統架構師們需要解決的本質問題：如何讓在線應用最大化的流量無損。

問題定義

我們先參考一個通用業務的部署架構圖（說明：由于筆者的技術背景是 Java，熟悉的基礎設施也主要是云服務為主，所以其中很多的例子是使用 Java 體系中的一些技術架來和云服務進行闡述，一些細節點上可能不太具備其他編程語言的參考的意義。）：

這張圖是一個典型而且很簡單的一個業務架構，這個業務會服務于來自全球的用戶，當用戶的請求到達之后，經過負載均衡轉入后面的微服務網關集群，微服務網關做完一些基礎的流量清洗、鑒權、審計等工作之后再根據業務形態路由到后面的微服務集群中；整個微服務集群最終會和不同的數據服務進行數據的交換（讀/寫）操作。

根據上面這一描述，我們暫且將整個流量請求服務的過程分為：流量解析、流量接入、流量服務、數據交換四個主要階段。在這四個階段中，都有可能發生流量損耗的可能性，而且每一種可能發生之后我們所采取的解決方案會是截然不同的，有的通過一些框架配置就能解決，而有的可能需要整體架構的重構。我們會通過三篇系列文章對這四個階段，一一進行剖析，開篇主要講的是流量解析和流量接入。

流量解析

解析的場景的本質還是通過一個服務名稱獲取一個服務的地址，這一過程是我們常規意義上的 DNS 解析。但是傳統域名解析在目前各個服務商的管理策略影響下，經常會遇到域名緩存、域名轉發、解析延遲、跨服務商訪問等問題。尤其在面向全球的互聯網業務中，Web 服務通過傳統 DNS 解析時，不會判斷終端用戶的來源，隨機選擇其中一個 IP 地址返回給終端用戶，這不僅會可能由于跨服務商解析而降低了解析效率，而且還會導致終端用戶可能因為跨洋訪問而導致速度變慢。
上面的這些問題都有可能會直接導致我們的流量受損。為應對上述的場景，常用的解決方案有智能解析和 HTTP DNS 技術，分別闡述如下：

1、智能解析

智能解析，一開始主要用來解決不同運營商之間跨網絡解析而引起網絡不通的問題，他主要是根據訪問端的地址，選擇對應網絡下的接入點，從而達到解析正確的地址的目的。隨著這一技術的持續迭代和演進，有的產品在此基礎上加入了不同地域的網絡質量監測節點，可以從一組機器中根據不同節點的服務質量，進行更智能的解析。目前阿里云上的智能解析依托于云的基礎設施，甚至可以以應用為單位動態擴縮節點池中的節點，最大化的在這一領域發揮了云上彈性的價值：

（圖片來源于阿里云云解析文檔）

2、HTTPDNS

HTTPDNS 顧名思義，就是使用 HTTP 協議代替 DNS 的發現協議；一般由服務商（或者自建）提供一個 HTTP 服務器，這個服務器提供一個極其簡練的 HTTP 接口，客戶端在發起訪問之前，由 HTTPDNS SDK 先行發起解析，解析失敗再 Fallback 回原來的 LocalDNS 解析。HTTPDNS 在解決 DNS 劫持、域名緩存 等場景下特別有效，缺點就是大部分方案還需要客戶端侵入 SDK；同時 Server 的建設成本會有點高昂。不過在隨著云廠商在這一領域的持續迭代，已經涌現出來了越來越多更加輕量的解決方案；這也會幫助 HTTPDNS 這種技術成為今后 DNS 領域演進的主流趨勢之一。

流量接入

當 DNS 解析到正確的地址之后，便進入到了流量接入這個核心的入口，這個過程的主角是網關，一個網關通常意義上扮演的角色重要有路由、鑒權、審計、協議轉換、API 管理、以及安全防護等重要的功能。業界常見的CP是負載均衡和微服務網關的結合，但是這個兩個組件配合起來往往有一些場景比較容易忽略，以下圖為例，我列舉三個容易忽略的場景簡單做一些介紹，分別是：流量安全、網關應用管控與流量路由。

1、流量安全

不安全的流量分為兩類，第一類是攻擊類型的流量；第二類是超過系統容量的流量。攻擊類型流量的防范主要以軟硬件的防火墻為主。這一類解決方案頗為成熟，這里不再贅述。這里比較難以甄別是超過系統容量的非攻擊流量，如何在這種場景下，最大限度的保證正常流量得到相應的服務，還能保護極有可能雪崩的整個業務系統是抉擇的難點。

簡單的嘗試，是在網關這里按照請求 QPS、并發數、分鐘請求數甚至接口參數等，做類似于 RateLimit 的流量控制。但是在此之前，是要求系統架構師能對系統的容量心中有數。我們推薦的做法是在做類似的安全防護之前，先要做到一個整體的容量評估，這里的評估不單單只是針對某些 API 做一次壓力測試這么簡單，是推薦針對生產環境做一次真正全鏈路的壓測（第三篇中將有一節專門介紹），然后再針對性的作出安全策略的調整。

2、網關應用管控

網關歸根結底還是一個應用，按照我們目前接觸到的客戶線上系統來看，一個完全是微服務架構的業務系統，這個應用會占用整個系統 1/6 - 1/3 不等的機器資源，這已經算得上是一個很大規模的應用了。既然是一個應用，它就會進行一些常規的運維管控操作如啟動、停止、部署、擴容等。但是由于網關是一個業務系統的咽喉，他是不能做頻繁的操作的，這意味著有幾點原則要非常清晰的傳導到開發團隊內部：

• 配置與代碼解耦：能力（協議轉發、限流配置、安全策略、路由規則等）是必須可配置，且可以動態下發的。
• 不要夾雜業務邏輯：讓網關回歸到網關的本質，不要夾雜業務邏輯；一個自己不加戲的網關就是一個好網關！

除了上述兩點開發側的原則之外，在運維側也有相應的原則。運維上除了常規的監控和報警，還需要具備自適應的彈性能力。但是網關的彈性牽扯的點太多：比如需要配合前面的負載均衡一起操作（如：進行應用部署之前需要在負載均衡處將對應節點下線或降權，應用部署確保啟動成功之后再將節點上線）；同時彈性還需要和應用管控體系自動化的進行配合才能做到線上流量無損。

3、流量路由

經過網關的下一步，則是將應用路由到下一節點，互聯網場景在有高可用多機房部署的情況下，為了服務質量，都會采取就近路由的原則。即如果網關入口在主機房，下一跳就希望路由到同機房的節點，同樣的道理，在一個微服務集群中的下下一跳，還是希望可以路由到相同的機房。否則，如果出現了跨機房調用的請求時，RT 就會變的很長，最終因請求超時而導致流量有損，如下圖：

要想做到同機房調用的效果，我們需要對選擇的服務框架有很好的理解。核心的原理是對于下一跳的路由時，需要優先選擇相同機房的地址。而不同的框架和業務所在的部署環境，都需要作出一些針對性的定制開發才能做到嚴格意義上的同機房優先調用。

結語

本篇是整個《如何構建流量無損的在線應用架構》系列的第一篇，這一系列共三篇，旨在使用最為樸素的語言將影響在線應用流量穩定性的技術問題做一個歸類，這些問題的解決方案有的只是一些代碼層面的細節，有的需要工具進行配合，有的則需要昂貴的解決方案，如果您的應用想在云上有一個【流量無損】的一站式體驗，可以關注阿里云的《企業級分布式應用服務（EDAS）》這個云產品，EDAS 也將會持續向默認接入流量無損的方向演進。下一篇，我們將從在線應用發布與服務治理的角度帶來不一樣的干貨，敬請期待。

原文鏈接?

本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的如何构建流量无损的在线应用架构 | 专题开篇的全部內容，希望文章能夠幫你解決所遇到的問題。

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