1. 阿里巴巴是用的什麼伺服器阿里巴巴是用的什麼伺服器的
轉載:阿里巴巴為什麼選擇ApacheFlink？
本文主要整理自阿里巴巴計算平台事業部高級技術專家莫問在雲起大會上的演講。
一棵大樹從一棵小樹苗長成；小小橡實可能長成參天大樹
隨著人工智慧時代的到來和數據量的爆炸，在典型的大數據業務場景中，最常見的數據業務方式是使用批處理技術處理全量數據和流計算處理實時增量數據。在大多數業務場景中，用戶的業務邏輯在批處理和流處理中往往是相同的。但是，用戶用於批處理和流處理的兩套計算引擎是不同的。
因此，用戶通常需要編寫兩套代碼。無疑，這帶來了一些額外的負擔和成本。阿里巴巴的商品數據處理往往需要面對增量和全量兩種不同的業務流程，所以阿里在想，我們能不能有一個統一的大數據引擎技術，用戶只需要根據自己的業務邏輯開發一套代碼就可以了。在這樣不同的場景下，無論是全數據還是增量數據，還是實時處理，都可以有一套完整的解決方案支持，這也是阿里選擇Flink的背景和初衷。
目前開源的大數據計算引擎有很多選擇，如Storm、Samza、Flink、KafkaStream等。、以及Spark、Hive、Pig、Flink等批量處理。但是同時支持流處理和批處理的計算引擎只有兩個選擇:一個是ApacheSpark，一個是ApacheFlink。
技術、生態等多方面綜合考慮。首先，Spark的技術思路是模擬基於批量的流量計算。另一方面，Flink使用基於流的計算來模擬批處理計算。
從技術發展的角度來看，用批處理來模擬流程存在一定的技術局限性，這種局限性可能很難突破。Flink基於流模擬批處理，在技術上具有更好的可擴展性。從長遠來看，阿里決定將Flink作為統一通用的大數據引擎作為未來的選擇。
Flink是一個統一的大數據計算引擎，具有低延遲、高吞吐量。在阿里巴巴的生產環境中，Flink的計算平台每秒可以處理數億條消息或事件，延遲為毫秒級。同時，Flink提供了一次性的一致性語義。保證了數據的正確性。這樣，Flink大數據引擎就可以提供金融數據處理能力。
弗林克在阿里的現狀
基於ApacheFlink在阿里巴巴搭建的平台於2016年正式上線，從阿里巴巴的搜索和推薦兩個場景實現。目前，包括阿里巴巴所有子公司在內的所有阿里巴巴業務都採用了基於Flink的實時計算平台。同時，Flink計算平台運行在開源的Hadoop集群上。Hadoop的YARN作為資源管理調度，HDFS作為數據存儲。所以Flink可以和開源大數據軟體Hadoop無縫對接。
目前，這個基於Flink的實時計算平台不僅服務於阿里巴巴集團，還通過阿里雲的雲產品API向整個開發者生態系統提供基於Flink的雲產品支持。
Flink在阿里巴巴的大規模應用表現如何？
規模:一個系統是否成熟，規模是一個重要的指標。Flink最初推出阿里巴巴只有幾百台伺服器，現在已經達到上萬台伺服器，在全球屈指可數；
狀態數據:基於Flink，內部積累的狀態數據已經是PB規模；
事件:如今，每天在Flink的計算平台上處理的數據超過萬億條；
PS:高峰期每秒可承擔超過4.72億次訪問，最典型的應用場景是阿里巴巴雙11的大屏；
弗林克的發展之路
接下來，從開源技術的角度，我們來談談ApacheFlink是如何誕生，如何成長的。而阿里又是如何在這個成長的關鍵時刻進來的？你對它做過哪些貢獻和支持？
Flink誕生於歐洲大數據研究項目平流層。這個項目是柏林工業大學的一個研究項目。早期，Flink做的是批量計算，但2014年，同溫層的核心成員孵化了Flink，同年將Flink捐贈給Apache，後來成為Apache最頂尖的大數據項目。同時，Flink計算的主流方向被定位為流式，即使用流式計算來計算所有的大數據。這就是Flink技術誕生的背景。
2014年，Flink作為專注於流計算的大數據引擎，開始在開源大數據行業嶄露頭角。不同於Storm、SparkStreaming等流計算引擎，它不僅是一個高吞吐量、低延遲的計算引擎，還提供了許多高級功能。比如提供有狀態計算，支持狀態管理，支持數據語義的強一致性，支持事件時間，水印處理消息無序。
Flink核心概念和基本概念
Flink區別於其他流計算引擎的地方其實是狀態管理。
是什麼狀態？比如開發一套流量計算系統或者任務做數據處理，可能經常需要對數據做統計，比如Sum，Count，Min，Max，這些值都需要存儲。因為它們是不斷更新的，所以這些值或變數可以理解為一種狀態。如果數據源正在讀取Kafka，RocketMQ，可能需要記錄讀取的位置並記錄偏移量。這些偏移變數是要計算的狀態。
Flink提供了內置的狀態管理，可以將這些狀態存儲在Flink內部，而不需要存儲在外部系統中。這樣做有以下優點:第一，減少了計算引擎對外部系統的依賴和部署，運維更簡單；其次，在性能上有了很大的提升:如果是通過外部訪問，比如Redis，HBase必須通過網路和RPC訪問。如果Flink在內部訪問這些變數，它只通過自己的進程訪問這些變數。同時，Flink會定期讓這些狀態的檢查點持久化，並將檢查點存儲在分布式持久化系統中，比如HDFS。這樣，當Flink的任務出錯時，它會從最新的檢查點恢復整個流的狀態，然後繼續運行它的流處理。對用戶沒有數據影響。
Flink如何保證在檢查點恢復的過程中沒有數據丟失或冗餘？要保證計算準確？
原因是Flink使用了一套經典的Chandy-Lamport演算法，其核心思想是將這種流計算視為一種流拓撲，在這種拓撲的頭部有規律地插入來自源點的特殊屏障，並將屏障從上游廣播到下游。當每個節點接收到所有柵欄時，它將拍攝狀態快照。每個節點完成快照後，整個拓撲將被視為一個完整的檢查點。接下來，無論發生什麼故障，都會從最近的檢查點恢復。
Flink使用這種經典演算法來確保語義的強一致性。這也是Flink與其他無狀態流計算引擎的核心區別。
以下是Flink解決無序問題的方法。比如星球大戰的序列，如果按照上映時間來看，可能會發現故事在跳躍。
在流量計算上，和這個例子很像。所有消息的到達時間與源在線系統日誌中實際發生的時間不一致。在流處理的過程中，希望消息按照它們在源端實際發生的順序進行處理，而不是按照它們實際到達程序的時間。Flink提供了一些先進的事件時間和水印技術來解決亂序問題。以便用戶可以有序地處理該消息。這是Flink的一個很重要的特點。
接下來介紹一下Flink起步時的核心概念和理念，這是Flink發展的第一階段；第二階段是2015年和2017年。這個階段也是Flink發展和阿里巴巴介入的時候。故事源於2015年年中我們在搜索事業部做的一項調查。當時阿里有自己的批處理技術和流計算技術，既有自研的，也有開源的。但是，為了思考下一代大數據引擎的方向和未來趨勢，我們對新技術做了大量的研究。
結合大量的研究成果，我們最終得出結論，解決一般大數據計算需求，整合批量流的計算引擎是大數據技術的發展方向，最終我們選擇了Flink。
但2015年的Flink還不夠成熟，規模和穩定性都沒有付諸實踐。最後我們決定在阿里成立Flink分公司，對Flink進行大量的修改和改進，以適應阿里巴巴的超大型業務場景。在這個過程中，我們團隊不僅改進和優化了Flink的性能和穩定性，還在核心架構和功能上做了大量的創新和改進，並貢獻給了社區，比如:Flink全新的分布式架構、增量式檢查點機制、基於信用的網路流量控制機制和流式SQL。
阿里巴巴對Flink社區的貢獻
我們來看兩個設計案例。第一個是阿里巴巴重構了Flink的分布式架構，對Flink的作業調度和資源管理做了明確的分層和解耦。這樣做的第一個好處是Flink可以在各種開源資源管理器上本地運行。這種分布式架構改進後，Flink可以原生運行在HadoopYarn和Kubernetes這兩種最常見的資源管理系統上。同時將Flink的任務調度由集中式調度改為分布式調度，使Flink可以支持更大的集群，獲得更好的資源隔離。
另一個是實現增量檢查點機制，因為Flink提供了有狀態計算和規則檢查點機制。如果內部數據越來越多，檢查點就會越來越大，最終可能導致做不下去。提供增量檢查點後，Flink會自動找出哪些數據是增量更改的，哪些數據是修改的。同時，只有這些修改過的數據被持久化。這樣檢查點就不會隨著時間的運行越來越難，整個系統的性能也會非常穩定，這也是我們貢獻給社區的一個非常重要的特性。
經過2015-2017年對Flink流媒體能力的提升，Flink社區逐漸走向成熟。Flink也成為了流媒體領域最主流的計算引擎。因為Flink最開始是想做一個統一流式、批量處理的大數據引擎，這個工作在2018年就已經開始了。為了實現這一目標，阿里巴巴提出了新的統一API架構和統一SQL解決方案。同時，在流式計算的各種功能得到改進後，我們認為批量計算也需要各種改進。無論在任務調度層還是數據洗牌層，在容錯性和易用性方面都有很多工作需要改進。
究其原因，這里有兩個要點與大家分享:
●統一的API堆棧
●統一的SQL方案
我們來看看FlinkAPI棧的現狀。研究過Flink或者用過Flink的開發者應該知道。Flink有兩個基本的API，一個是數據流，一個是數據集。數據流API提供給流用戶，數據集API提供給批量用戶，但是這兩個API的執行路徑完全不同，甚至需要生成不同的任務來執行。所以這和統一API是沖突的，這也是不完善的，不是最終的解決方案。在運行時之上，應該有一個統一批量流程集成的基礎API層，我們希望API層能夠統一。
因此，我們將在新架構中採用一個DAG(有限非循環圖)API作為批處理流的統一API層。對於這種有限無環圖，批量計算和流量計算不需要明確表示。開發者只需要在不同的節點和不同的邊定義不同的屬性，就可以規劃數據是流屬性還是批屬性。整個拓撲是一個統一的語義表達，可以集成批量流。整個計算不需要區分流量計算和批量計算，只需要表達自己的需求。有了這個API，Flink的API棧就統一了。
除了統一的基礎API層和統一的API棧，SQL解決方案在上層也是統一的。而批處理SQL，我們可以認為有流計算和批處理計算的數據源，我們可以把這兩個數據源模擬成數據表。可以認為流數據的數據源是一個不斷更新的數據表，而批量數據的數據源可以認為是一個相對靜態的表，沒有更新的數據表。整個數據處理可以看作是SQL的一個查詢，最終結果也可以模擬成一個結果表。
對於流計算，它的結果表是一個不斷更新的結果表。對於批處理，其結果表是相當於一次更新的結果表。從整個SOL語義表達來看，flow和batch是可以統一的。此外，流SQL和批處理SQL都可以使用同一個查詢來表示重用。通過這種方式，所有流批次都可以通過同一個查詢進行優化或解析。甚至許多流和批處理操作符都可以重用。
弗林克的未來方向
首先，阿里巴巴要基於Flink的本質做一個全能的統一大數據計算引擎。放在生態和場景的地面上。目前Flink是主流的流計算引擎，很多互聯網公司已經達成共識，Flink是大數據的未來，是最好的流計算引擎。接下來的重要任務是讓Flink在批量計算上有所突破。在更多的場景下，已經成為主流的批量計算引擎。然後進行流量和批次的無縫切換，流量和批次的界限越來越模糊。使用Flink，在一個計算中，可以同時進行流量計算和批量計算。
第二個方向是Flink得到更多語言的生態支持，不僅僅是Java，Scala，還有Python和Go進行機器學習。未來希望用更豐富的語言開發Flink計算任務，描述計算邏輯，連接更多生態。
最後不得不說AI，因為很多大數據計算需求和數據量都在支撐非常熱門的AI場景。所以我們會在完善Flink流批生態的基礎上，繼續往上走，完善上層Flink的機器學習演算法庫。同時，Flink會借鑒成熟的機器，深度學習融合。比如Flink上的Tensorflow，可以用來整合大數據的ETL數據處理和機器學習的特徵計算、特徵計算，以及訓練的計算，讓開發者同時享受多個生態系統帶來的好處。
阿里巴巴雲境是什麼東西？
這個是阿里巴巴做的一款信息化系統產品，主要針對中小企業，它的伺服器??硬體的支持，都是阿里放在雲端的。相當於都是由阿里來幫你管理數據??，客戶的硬體投入非常低，系統管理成本也很低，通常是以年費的形式來運行。
為什麼阿里巴巴，騰訊等這些公司要把伺服器放在美國？
為了讓美國人民享受到阿里巴巴和騰訊的服務啊，另外國內的人到美國去，也是需要相關的服務的。
阿里巴巴屬於哪個行業？
阿里巴巴主營屬於電子商務，還包括互聯網金融、電子支付、物流等。同時，阿里巴不斷發展還涉及到更廣的領域，比如傳媒、物聯網等。
阿里巴巴集團本家產業：阿里巴巴、淘寶、支付寶、阿里軟體、阿里媽媽、口碑網、阿里雲、中國雅虎、一淘網、淘寶商城、中國萬網，聚劃算、雲峰基金、螞蟻金服。
一般的網店需要多大的伺服器？
不需要因為你申請的淘寶店是一個虛擬空間來著，在阿里巴巴自已建設的機房之中，可直接使用，無需自備伺服器。直接裝修店鋪，上架商品即可
阿里千島湖數據中心建在湖底嗎？
是的，阿里巴巴的一個伺服器中心就放在千島湖湖底。阿里雲千島湖數據中心建築面積30000平方米，共11層，可容納至少5萬台設備。作為水冷驅動的工業數據中心建設的模板，很有創新性和代表性。數據中心90%時間不需要電製冷，深層湖水通過完全密閉的管道流經數據中心，幫助伺服器降溫，再流經2.5公里的青溪新城中軸溪，作為城市景觀呈現，自然冷卻後又回到千島湖。
2. 阿里雲伺服器是什麼
阿里雲也就是指的雲主機.它可以簡單的理解成是一台虛擬伺服器.是類似VPS的東西.但與VPS還有所不同.VPS是在一台物理伺服器上劃分出來一部分的資源搭建而成.一旦母機出現故障.上面所有的VPS將受影響.而雲主機是在一組集群伺服器上劃分出來的多個類似獨立主機的部分.集群中的每台機器都有雲主機的一個鏡像備份.當其中一台機器出現故障時.系統會自動訪問其他機器上的備份.所以在安全與穩定性方面.雲主機更加強大.
雲主機與伺服器一樣.有獨立的IP.內存.帶寬等.用戶可以根據需要安裝各種操作系統以及配置各種網站運行環境.在功能以及使用上與伺服器一模一樣.同樣因為是虛擬的.費用通常比伺服器要便宜的多.主要是針對中小規模的應用來使用.
3. 阿里雲伺服器價格一年多少錢
1、伺服器租用，像一般的個人網站或者僅做展示型的企業網站，需要的配置不用太高，前期可以選擇虛擬主機類型的雲伺服器，一年下來估計一兩千，再簡單些的，幾百塊就能搞定。
2、雲伺服器一年費用大概在5萬左右。雲伺服器(ElasticComputeService，ECS)是一種簡單高效、安全可靠、處理能力可彈性伸縮的計算服務。其管理方式比物理伺服器更簡單高效。
3、租機也分雲服務和物理服務，雲服務一般是由多台伺服器集群，多個客戶共同使用的，這種價格比較便宜，適合需求量較小的用戶，目前活動價價格在200-300左右。
4、阿里雲伺服器各項配置的推薦：進階類型：2核4GB1M40G系統磁碟825元/年1，260元2年1，650元3年適用於流量適中的網站應用程序，或簡單的開發環境，代碼存儲庫等。
4. 雲伺服器ECS是什麼
雲伺服器 Elastic Compute Service（ECS）是易邁雲提供的一種基礎雲計算服務。使用雲伺服器ECS就像使用水、電、煤氣等資源一樣便捷、高效。您無需提前采購硬體設備，而是根據業務需要，隨時創建所需數量的雲伺服器實例，並在使用過程中，隨著業務的擴展，對雲伺服器進行擴容磁碟、增加帶寬。如果不再需要雲伺服器，也可以方便的釋放資源，節省費用。
雲伺服器 ECS 實例是一個虛擬的計算環境，包含了 CPU、內存、操作系統、磁碟、帶寬等最基礎的伺服器組件，是 ECS 提供給每個用戶的操作實體。一個實例就等同於一台虛擬機，您對所創建的實例擁有管理員許可權，可以隨時登錄進行使用和管理。您可以在實例上進行基本操作，如掛載磁碟、創建快照、創建鏡像、部署環境等。
5. 負載均衡進階：SLB常見問題解決方法
摘要： 在由雲棲社區和阿里雲網路團隊聯合主辦的2017阿里雲網路技術在線高峰論壇上，阿里雲技術專家添毅分享了網路產品部根據客戶和阿里雲運維的反饋提煉出的幾大最主要和最常見的在使用SLB產品中發生的問題，並為大家介紹了針對這些常見問題的相應處理方法。
摘要： 在由雲棲社區和阿里雲網路團隊聯合主辦的2017阿里雲網路技術在線高峰論壇上，阿里雲技術專家添毅分享了網路產品部根據客戶和阿里雲運維的反饋提煉出的幾大最主要和最常見的在使用SLB產品中發生的問題，並為大家介紹了針對這些常見問題的相應處理方法。想知道如何藉助SLB構建高可用系統以及健康檢查是如何實現的，本文不容錯過！
本文內容根據演講嘉賓分享視頻以及PPT整理而成。
本次的分享將會主要圍繞以下5個部分
基本概念回顧
如何構建高可用系統
選擇性能共享型還是性能保障型實例
為什麼健康檢查異常
為什麼負載不均衡
一、基本概念回顧
SLB是什麼
SLB是阿里雲推出的一款雲負載均衡服務，其主要針對於多台雲伺服器進行流量分發，能夠將業務流量分發到由多台雲伺服器所組成的後端伺服器池上去，以此來提升系統的處理能力。負載均衡所解決的問題主要包括兩點：第一點，SLB能夠消除系統的單點故障，這是因為SLB的後面是由多台雲伺服器組成的伺服器池，那麼當其中某一台伺服器出現故障的時候並不會影響整個系統的可服務性。第二點，由於後端的雲伺服器能夠橫向地進行擴展，所以也具有為海量業務提供服務的能力。那麼，為什麼要使用雲上的負載均衡呢？這是因為雲上負載均衡主要有這樣的幾個特點：高可靠、高性能、低成本、安全性、易用性。
SLB基本組件
阿里雲的SLB主要包括了三個基本組件，這里也進行簡單地介紹。第一個基本組件就是實例，每個實例都唯一地標識了雲負載均衡器，並且每個實例都對應一個VIP，VIP唯一地標識了負載均衡實例，也是負載均衡對外提供服務的地址。第二個組件是監聽，監聽是由VIP+埠號來唯一標識的，一個監聽中包含用戶定製的負載均衡策略和轉發規則。最後一個基本組件就是後端掛載的伺服器，也就是雲伺服器ECS，負責處理真正的業務請求。
二、如何構建高可用系統
多層次的高可用
如下圖所示，阿里雲的負載均衡是從四個層面上去構建高可用的。從底層往上層看，分別是應用級別的高可用、集群級別的高可用、可用區級別(AZ)的高可用以及地域級別(Region)的高可用。
應用級別的高可用主要是通過針對SLB後端的ECS實例的健康檢查來實現的。當SLB發現後端不健康的或者不能正常工作的ECS的時候，會將這些不健康的ECS從SLB的轉發路徑中剔除掉，保證業務流量能夠轉發到正常的工作伺服器當中。集群級別的高可用主要是通過集群中LVS機器間的session同步來保障任何一個用戶的業務會話都能夠在所有的LVS機器上是相互同步的，當其中某一台LVS出現故障時，可以由其他的LVS來接替出現故障的機器的工作。同時，由於會話保持的存在，用戶的業務是不會發生中斷的。對於可用區級別的高可用和地域級別的高可用，在本文的後面會進行更加詳細的介紹。
細說可用區級別容災
這里詳細地介紹一下可用區級別的容災。可用區級別容災的設計初衷是在當一個可用區出現重大災情的時候，比如整個可用區的機房發生了掉電、光纜出現了中斷、整個可用區機房中所有的物理機都無法正常工作的時候，也就是整個可用區都宕掉了的情況下，能夠由備可用區來繼續提供服務，這就是可用區級別容災的設計初衷。可用區級別的容災並不是說某一個可用區中的某一個實例或者是某幾個實例出現了故障就會發生可用區的切換，實例自動從可用區A切換到可用區B，這是一個比較常見的誤區。而針對於這樣的誤區，阿里雲也建議用戶在構建可用區級別的高可用的時候採取以下兩個步驟：
首先，建議用戶在SLB實例的後端盡可能地去掛載多個可用區的ECS實例。SLB能夠支持跨可用區地掛載ECS雲伺服器，這樣可以避免某個可用區的ECS都出現故障的情況下，還有其他可用區的ECS能夠接替工作，雖然跨可用區掛在ECS會存在大約2毫秒左右的延遲，但是卻能夠大大地提升服務的可用性。
第二步就是針對於一些特別重要的業務，建議在不同的可用區分別地去購買SLB的實例。比如在可用區A和可用區B各自購買一個SLB實例，在此基礎之上再使用全球負載均衡GSLB來進行實例間的調度。
跨地域容災的實現
跨地域容災這一部分與上面介紹的可用區級別容災的第二步非常相似，也是藉助於GSLB產品實現的，GSLB即 智能DNS實現了針對於後端的健康檢查、路由調度的優化功能，能夠實現在地域之間的負載均衡實例的調度。關於這部分的更詳細的內容請參考：全球負載均衡跨地域容災解決方案(https://promotion.aliyun.com/ntms/act/globalslb.html)。
三、選擇性能共享型還是性能保障型實例
共享型vs保障型-WHY保障型
在如今這個共享經濟的時代，像滴滴打車這樣的模式是非常火的。但是即便是有了滴滴打車，但是還有人會去買車，這是因為會出現如下兩個大家可能曾經都碰到過的場景：
早晚高峰叫不到車？雨雪天氣路邊凍成狗？還大幅提價？
假期想遠離塵囂，找個僻靜曠野放空自我，叫個滴滴？也許有去，但保證無回！
所以說共享和保障都是客戶的需求。出於對於類似需求的考慮，阿里雲的負載均衡也推出了性能保障型實例。以前所推出的SLB共享型實例是因為性能指標沒有辦法實現隔離，因為所有的共享型實例都處於同一個大共享資源池中，所以在高峰期的時候就會出現資源的爭搶，這樣就無法滿足對於性能具有剛性需求的大客戶的訴求。除此之外，還有一些體量特別大的超級用戶，他們對於性能的要求會是非常高的，但是由於共享型實例無法做到性能隔離，也支持不了大顆粒度的性能指標，所以也無法完成這樣的工作。因此，阿里雲推出了性能保障型的負載均衡實例。
超強性能
保障型實例的性能規格如上圖所示，其並發連接數最大可以達到500萬，每秒的新建鏈接數(CPS)可以達到50萬，針對於七層負載均衡系統的QPS可以達到10萬。除此之外，性能保障型實例還具有以下的特點：
超強HTTPS性能。 性能保障型實例針對於七層系統，特別是HTTPS的業務進行了優化，實現了高性能硬加解卡，並且能夠實現使HTTPS的業務單實例可達10萬QPS。
超大並發連接數。 性能保障型實例的單實例的並發連接數可達500萬，所以其可承載物聯網場景的下海量連接，可以支撐共享自行車、智能手錶等存在特別大量長連接的場景。
共享型實例平滑升級。 原有的共享型實例可以平滑升級至性能保障型實例，而無需更換VIP。
完善的業務監控系統。 在推出性能保障型實例之後，因為每個實例都有相應的性能規格和性能指標，所以阿里雲也為用戶提供了完整的業務指標監控系統，並支持電話、簡訊、釘釘企業群等方式的告警。
性能規格
上圖所展現的是阿里雲SLB性能保障型實例的規格參數。圖中的最後兩行規格7、8默認在控制台上是無法購買的，目前只針對企業級用戶，而且需通過客戶經理申請後，通過白名單開放。
如何選擇規格
對於保障型實例而言，主要有如下幾個性能指標：
最大連接數：一個實例可承載的最大連接數。
新建連接數：CPS表示一個實例每秒可以新建的鏈接數。
每秒查詢數：QPS表示一個實例7層的像HTTP或者HTTPS系統的吞吐量。
通常一個4層SLB的性能好壞由最大連接數和新建連接數來衡量，它們表示了一個SLB系統的並發能力和處理突發連接的能力。通常一個7層SLB的性能好壞主要由QPS決定，QPS表示了一個7層系統的吞吐量。這里需要注意的是QPS是7層獨有概念。雖然每個規格都定義了三個性能指標，但是這並不代表這三個性能指標在任何一個性能場景下或者任何一個時刻都能夠同時達到最大值，這里存在一個性能指標的短木板原則。比如在某一個應用系統中，QPS已經達到指標上限，但最大連接數還遠遠沒有達到上限，這時不論怎樣加大客戶端數量，最大連接數都會因為QPS達到上限，而無法達到最大值。
對於規格的選擇而言，需要通過之前提到的業務監控系統來獲取相關指標。如果用戶十分了解自己業務的相關指標，也就是對於高峰期的並發連接數會達到多少以及QPS會達到多少都有非常清晰的了解，也可以直接在控制台上選購。但是如果用戶並不清楚自己的相關業務指標，可以在初期選購按量付費的較高規格的實例，並且在一個業務周期內監控流量的峰值，在峰值確定好之後再通過變配的方式改變到比較合適的實例規格。目前性能保障型實例還處於公測階段，所以現在還沒有對於實例收取規格費用，也就是說在這個階段無論用戶選擇最小規格還是最大規格，實際上都只需要花費IP配置費和帶寬費就可以了，這樣也比較便於用戶去熟悉和使用阿里雲的性能保障型實例。
監控和告警
前面也有所提及，在負載均衡的控制台上面能夠直接地顯示出相應的一些性能指標，但是在這里只能夠實現對於性能指標的監控，卻無法進行告警。如果用戶需要進行監控告警，可以在阿里雲所提供的雲監控控制台進行操作。雲監控平台可以監控阿里雲中的所有產品並且實現業務告警的定製，並且可以選擇包括簡訊郵件、電話、企業釘釘群等方式進行業務的實時告警。
四、為什麼健康檢查異常
健康檢查機制
接下來分享在負載均衡的日常使用中出現的問題，特別是很多用戶都存在疑問的健康檢查部分的問題。
阿里雲的負載均衡一共可以支持四種協議，四層的負載均衡系統主要包括了TCP、HTTP以及UDP協議，而七層的系統則包括了HTTP和HTTPS，而由於目前HTTP和HTTPS都是使用的普通的HTTP方式，所以其實也可以歸結為三類協議。對於TCP而言，健康檢查的過程是通過發送ACK這種TCP的探測報文去探測埠是否仍然存活；對於HTTP而言，則主要使用的是HEAD的請求方式來檢查目標的頁面是否正常；UDP部分則主要借鑒了SMP協議的原理。
健康檢查部分主要會涉及到幾個指標，這些指標需要用戶在控制台上進行設置，上圖中給出了一些默認的建議值，比如響應的超時時間，也就是在每一次進行健康檢查的時候，如果超過一定時間健康檢查還沒有回應就認為這次的健康檢查是失敗的；還有健康檢查間隔，也就是兩次健康檢查之間通常需要間隔2秒鍾；而所謂的不健康閥值和健康閥值就是在網路環境中往往會由於網路的抖動以及其他的因素導致偶爾的一次健康檢查失敗了，但是這時候並不能認為服務是真的失敗了，所以需要設置一個閥值，比如3次就指的是當3次健康檢查都失敗的時候才會認為後端的服務是存在問題的，然後將其從轉發路徑中摘除掉。同樣的，當服務從不健康變為健康的時候，也需要進行連續的幾次探測，當確定處於穩定的健康狀態之後再將其加入到SLB的後端中去。
為啥會失敗(TCP)
TCP的健康檢查也經常會出現一些失敗的情況，這里也為大家提供了簡單的故障排查順序供參考。當出現健康檢查失敗的時候，首先可以檢查一下後端的伺服器是否已經啟動。如果後端伺服器的負載是比較高的，也可能會因為沒有CPU時間去處理健檢查的回應，這樣就有可能導致健康檢查失敗。除此之外，因為對於阿里雲的負載均衡而言，健康檢查使用的都是私網地址實現的，所以如果根本沒有監聽到私網地址或者私網地址本身存在故障也會導致健康檢查的失敗。還有伺服器上可能存在防火牆，將監聽埠屏蔽掉了，導致健康檢查並未通過。此外還可能存在一些配置方面的問題，比如提供服務的埠和做健康檢查的埠不一致也可能存在健康檢查失敗。
針對於TCP的健康檢查而言，很多用戶會經常看到自己的後端伺服器上日誌上面有很多10或者16這些網段的訪問，並且訪問流量還比較大，這是因為之前所提到的健康檢查具有一定的間隔時間，比如2秒或者3秒一次。這時候一些用戶可能就會認為健康檢查會影響伺服器的性能，佔了很多的伺服器的連接數。其實可以從上圖中左側的報文交互情況看到，當SLB對於雲伺服器發起健康檢查的時候首先會發一個SYN的請求，如果伺服器埠是存活的，那麼它會回應一個ACK，這個時候SLB端就會緊接著發送RST報文。也就是說實際上連接是並沒有建立的，所以也不會佔用後端伺服器的連接數的資源，並且對於性能的影響也是極為有限的。
為啥會失敗(HTTP)
HTTP常見的健康檢查失敗原因大概會有這樣的三點：最常見的情況就是有些用戶把伺服器的HEAD請求方式禁掉了，因為默認在使用瀏覽器或者手機等請求一個頁面的時候使用的都是GET方式，有時候可能需要上傳數據則會使用POST方式，雖然很多伺服器都支持HEAD請求方式，但是有些伺服器可能會處於安全或者其他復雜因素的考慮將HEAD請求禁掉。所以在這里建議客戶將伺服器的HEAD請求方式打開，因為阿里雲負載均衡七層健康檢查方案就是使用的HEAD方案。另外一種常見情況就是頁面訪問本身上就存在問題，這樣的情況下健康檢查也是無法通過的。最後一種常見情況就是期望結果配置錯誤，針對於七層的健康檢查是通過使用HEAD請求方式去請求頁面，頁面返回碼可能會是200、300或者400以及500等，用戶可以在健康檢查的配置中設定預期的正常情況下的返回碼值，當健康檢查返回碼值與預期值不一致就會判定健康檢查是失敗的。
為啥會失敗(UDP)
這里介紹一下UDP健康檢查的原理。首先，健康檢查通過SLB向後端發送UDP報文探測來獲取狀態信息。SLB會周期性地給後端ECS發送UDP報文，如果UDP埠的業務處於正常情況，則沒有任何回應。而當服務出現問題，比如指定的UDP服務埠處於不可達的情況或者無服務的狀態的時候，會回復ICMP的不可達報文。這里也會存在一個問題就是如果後端伺服器已經變成了網路中的孤島，比如出現了整個伺服器的掉電、關機情況這樣完全不能工作的狀態，這時候的ICMP不可達報文是永遠不可能收到的，因為後端的伺服器無法收到SLB發來的UDP探測報文，那麼在這種情況下，可能會出現誤認為後端健康的情況，但是實際上這個服務可能已經宕掉了。為了應對這種情況，健康檢查還提供用戶自定義UDP應答報文來實現精確的UDP健康檢查，也就是由用戶自定義指定一個字元串，當後端的雲伺服器收到UDP健康檢查的探測的時候，也回應指定的字元串，之後SLB對於這個字元串進行對比和校驗，如果匹配成功則認為服務一定是健康的，這樣就可以實現非常精確的健康檢查。
而UDP的健康檢查失敗也有很多原因，比如在協議棧裡面有可能會有ICMP限速保護。當頻率達到一定速率的時候，ICMP會被協議棧限制，後端無法回應ICMP不可達報文，進而導致SLB收不到ICMP的報文，出現健康檢查的失敗情況。所以這部分是需要注意的，如果可能盡量將速率限制放大一些。
其他問題
健康檢查時好時壞的可能原因如下：
HTTP類型健康檢查目標URI響應慢。比如本身是動態頁面，會涉及到大量的計算才能夠渲染完成並返回到前端，這樣肯定就會導致健康檢查響應比較慢。如果伺服器負載過高同樣也會出現這樣的問題。
未全部放開對SLB健康檢查源地址的限制導致分布式健康檢查失敗。因為阿里雲的伺服器都是分布式的部署，健康檢查也會是分布式的探測，LVS等機器在後端有不同的源去針對某一個雲伺服器進行探測的，所以如果沒有將這些源地址都放開，實際上也會影響健康檢查的效率，因為對於這么多機器而言，只要有一台機器檢測到是正常的那麼就是正常的。
還可能出現直接訪問正常，但是健康檢查失敗的情況。造成這樣情況的可能原因如下：
防火牆限制。
目的埠不一致。
檢查方法不同，可能使用瀏覽器看頁面是沒問題的，但是健康檢查卻不行，這就是因為剛才所提到的HEAD方法沒有開啟。或者七層的健康檢查配置了URL按照域名轉發，但是在瀏覽器上直接訪問則是使用域名去做的，而健康檢查是使用IP地址做的，這樣也可能出現轉發和預期結果的不同。
檢查頻率不同，ICMP限速。
五、為什麼負載不均衡
調度演算法與會話保持
首先介紹一下負載均衡的調度演算法。阿里雲的負載均衡支持三種演算法，第一種演算法是單純的輪詢(RR)，也就是將業務的請求依次地分發到後端的伺服器。第二種演算法是加權輪詢(WRR)，也就是在處理調度的時候會根據針對於每一台後端伺服器設置權重來進行轉發。這里之所以設置權重是因為後端伺服器的處理能力可能是不同的，如果使用相同的權重進行輪詢可能就會把後端處理能力比較弱的伺服器擠爆，所以需要針對於伺服器的處理能力設置一些權重。第三種演算法是針對於加權最小連接數的輪詢(WLC)，也就是除了根據每台後端伺服器設定的權重值來進行輪詢，同時還考慮後端伺服器的實際負載，也就是連接數。當權重值相同時，當前連接數越小的後端伺服器被輪詢到的次數也越高，這樣就能夠保證負載盡量地均衡。如果不考慮這一點就會造成某些伺服器連接數已經很高了但是流量依然還往上面分發，而另外一些伺服器卻一直處於空閑狀態。
會話保持指的是來自同一用戶請求始終保持分發到同一台後端的雲伺服器上。對於同一用戶而言，使用的是四層的負載均衡和使用七層的負載均衡在理解上是不一樣的。如果是四層負載均衡，則會使用源IP地址標識同一用戶，所以如果在可能會有很多辦公電腦的大型企業中，這些電腦在企業內部是通過區域網的IP進行通信的，在訪問公網的時候都是通過NAT網關處理的，所以在走到Internet的時候，源地址通常會是一個或者很有限的幾個。在這種情況下，如果是四層的負載均衡就會把裡面所有的請求都視為來自同一個用戶的，這種情況下如果開啟了會話保持，就會發生問題。而七層的負載均衡是根據用戶瀏覽器中的Cookie來進行唯一識別的，對於剛才的案例在大型企業裡面因為內網訪問公網的源地址都是一樣的，導致沒有辦法識別到底是不是同一個用戶，此時建議使用七層的負載均衡方案解決，因為Cookie是每個瀏覽器都唯一的。會話的保持時間是可以在控制台上配置的，四層的負載均衡方案最大可達1小時，而七層的方案最大可達24小時。
為何不均衡
最後分享一下不均衡的常見情況。有時候會需要新加一個伺服器進來，這時候往往到新加進來的伺服器上的連接會很少，這是因為可能會存在以下原因：
存在會話保持的情況下，會話保持會讓請求停留在原有的伺服器上，這樣到新加進來的伺服器上的連接自然會少一些。
權重設置不一致，如果在權重的設置上存在區別，而新加進來的伺服器的權重如果很低，連接也過不去。
應用屬於長連接類型，因為需要在TCP上復用，如果客戶端不主動斷開連接，後續所有的請求都會繼續復用當前伺服器上的連接，只有新建連接才有可能到新的伺服器上。
而有時候在業務量或者新建連接較少時，也會出現負載不均衡的問題。這是因為每個Core都是獨立的調度單元，因此可能存在將某個Client的多條業務經過不同core的調度後全部轉發到一台ECS上的情況，同時由於業務量較少，因此出現了不均衡。建議使用輪詢演算法解決，在RR輪詢演算法中加入了擾亂因子，可以更加有效的打散SLB到後端的轉發路徑。
原文鏈接