轉(zhuǎn)自： https://mp.weixin.qq.com/s/hY0kGH5YZTA7jZetr8FUFQ

嘉賓 | 張磊竞膳、姜冰寫在前面

近幾年互聯(lián)網(wǎng)服務安全事故的頻發(fā)，使得越來越多的企業(yè)及開發(fā)者意識到數(shù)據(jù)備份诫硕、災備等重要性坦辟，高可用性、高容災性及高可擴展性的系統(tǒng)和架構(gòu)建設(shè)工作也被更多地置于重心章办。

在這個過程中锉走，基于公有云提供的基礎(chǔ)設(shè)施實現(xiàn)高可用已成為多數(shù)技術(shù)團隊的選擇。

而面對跨區(qū)域 + 高可用需求時藕届，許多開發(fā)者卻犯了難挪蹭，一方面業(yè)務場景的不同對架構(gòu)設(shè)計提出了不盡相同的需求，基本上沒有可完全復制的架構(gòu)模版翰舌；另一方面是納入考慮的因素在不斷增多嚣潜，數(shù)據(jù)延遲、成本開銷椅贱、物理隔離懂算、快速的恢復能力……如何能在加法的基礎(chǔ)上做好減法只冻，對技術(shù)團隊創(chuàng)新能力提出了更高要求。

對此计技，InfoQ 專訪了 FreeWheel 架構(gòu)師張磊及 FreeWheel 首席工程師姜冰喜德，探討在服務全球 6 個數(shù)據(jù)中心，日均產(chǎn)生近 10 億廣告投放展示日志的場景下垮媒，做好跨區(qū)域高可用的實踐之道舍悯。

跨區(qū)域、高可用性實踐背景數(shù)據(jù)處理平臺提出的多維挑戰(zhàn)

作為美國 Comcast 旗下領(lǐng)先的視頻廣告管理和投放平臺睡雇，F(xiàn)reeWheel 的數(shù)據(jù)來自于全球 6 大數(shù)據(jù)中心（美國東西海岸各兩個萌衬、歐洲兩個），每天產(chǎn)生 10 億左右的廣告投放展示日志它抱，新增超過 3TB 的數(shù)據(jù)秕豫，并且有至少 18 個月的數(shù)據(jù)可以隨時滿足查詢尋求。

在數(shù)據(jù)應用對實時性和可靠性要求逐漸增加的情況下观蓄， FreeWheel 根據(jù)其自身數(shù)據(jù)特點和應用需求混移，采用了一套以 Kafka，Hadoop 和 HBase 為核心的 Lambda 處理架構(gòu)侮穿。

其中歌径，各個數(shù)據(jù)中心的廣告服務器實時地將廣告數(shù)據(jù)傳輸?shù)奖镜?Kafka 集群。中心化的 Kafka MirrorMaker 將多數(shù)據(jù)中心的數(shù)據(jù)聚集到一個全局的 Kafka 集群亲茅。流式處理框架會從全局 Kafka 集群消費數(shù)據(jù)回铛，處理之后一方面寫回 Kafka（為下游的各類實時應用服務）；一方面寫入 HBase克锣，并由 Hadoop 離線作業(yè)將 HBase 的內(nèi)容聚合轉(zhuǎn)換成 Parquet 文件寫入 HDFS勺届。構(gòu)建于 Presto 之上的 OLAP 服務會同時查詢 HBase 和 HDFS，對外提供數(shù)據(jù)的實時或批量查詢（整體架構(gòu)見下圖）娶耍。

image

FreeWheel 數(shù)據(jù)處理系統(tǒng)架構(gòu)圖

FreeWheel 部署的這一套數(shù)據(jù)處理系統(tǒng)，很好地實現(xiàn)了預期的設(shè)計目標饼酿。但過往幾年里榕酒，隨著數(shù)據(jù)量的不斷增長和業(yè)務變化的需求，這種模式面臨了如下挑戰(zhàn)：

1. 可擴展性：越來越多的數(shù)據(jù)產(chǎn)品接入到新的數(shù)據(jù)平臺故俐，對數(shù)據(jù)處理和查詢服務的擴展性提出了嚴苛的要求想鹰。而在自建的數(shù)據(jù)中心，受限于規(guī)劃和整體容量药版，很難根據(jù)需求靈活地擴展辑舷。 同時，在“超級碗”這樣大型賽事的直播帶來流量瞬時波動的場景下槽片，傳統(tǒng)的數(shù)據(jù)中心也很難滿足對容量的彈性需求何缓。

2. 高可用性：雖然像 Hadoop 這樣的大數(shù)據(jù)基礎(chǔ)設(shè)施本身可以保證一定程度的高可用性肢础，但在遇到數(shù)據(jù)中心整體性故障時，依然會對服務造成影響碌廓。

3. 開發(fā)和測試效率：大數(shù)據(jù)平臺開發(fā)和測試中传轰，基于真實環(huán)境的集成測試和性能測試可以覆蓋單元測試和回歸測試的盲區(qū)，這需要經(jīng)常啟停一些基礎(chǔ)組件甚至整套端到端服務谷婆。但在自有數(shù)據(jù)中心里慨蛙，受到資源限制，很難做到及時滿足需求纪挎，因而也降低了開發(fā)和測試的效率期贫。

理論上，上述挑戰(zhàn)中的一部分可通過在另一個自建數(shù)據(jù)中心里再部署一套數(shù)據(jù)處理系統(tǒng)解決或緩解异袄，但考慮到規(guī)劃通砍、擴容所需時長以及問題根治性等因素，在 2016 年底隙轻，F(xiàn)reeWheel 決定與 AWS 合作埠帕，將數(shù)據(jù)平臺和數(shù)據(jù)處理系統(tǒng)部署到云端。

選型過程并不復雜玖绿，F(xiàn)reeWheel 主要從成熟程度敛瓷、數(shù)據(jù)監(jiān)管、可用區(qū)（AZ）數(shù)以及原生服務的數(shù)量與廣度等方面考量斑匪，最終選擇了 AWS 作為云服務商呐籽。

基于 AWS 原生服務的使用權(quán)衡

整體上，F(xiàn)reeWheel 在 AWS 上也部署了一套 Kafka MirrorMaker蚀瘸，同步所有數(shù)據(jù)中心的數(shù)據(jù)狡蝶，再將數(shù)據(jù)處理平臺基本原樣搬到了 AWS 上。

但如何權(quán)衡是直接使用像 Kinesis贮勃、DynamoDB 這樣的 AWS 原生服務贪惹，還是自己維護 Kafka、HBase 等基礎(chǔ)設(shè)施寂嘉？ FreeWheel 也有一些思考奏瞬。

張磊對此總結(jié)了兩點。一是從平臺需求出發(fā)泉孩。AWS 許多原生服務在某種程度上的確能帶來開發(fā)和維護成本的降低硼端，但對于基礎(chǔ)數(shù)據(jù)平臺這類數(shù)據(jù)量極其龐大并且對穩(wěn)定性要求很高的業(yè)務， AWS 的原生服務能不能滿足需求寓搬，能滿足需求的情況下成本是不是可控珍昨，這些都會是最終影響選型的因素。二是需要考慮開發(fā)者自身對技術(shù)的把控。AWS 的原生服務很多時候?qū)κ褂谜邅碚f還是黑盒镣典。當大家需要花大量時間去了解這些服務的內(nèi)部運作原理兔毙，限制和故障處理時，不一定能降低時間和運維成本骆撇。

涉及到具體權(quán)衡與改造瞒御，姜冰也舉例講解了何時該選擇自身維護：

以 AWS 原生服務 Amazon EMR 和 Amazon Kinesis 為例，映射到 FreeWheel 的數(shù)據(jù)處理系統(tǒng)中相應的是 Hadoop Cluster 和 Kafka神郊‰热梗基于 FreeWheel 以 7*24 小時流計算為主的業(yè)務類型，如果直接使用 EMR 及 Kinesis涌乳，將面臨如下問題：

• 原生服務開放程度較弱蜻懦，因而開發(fā)者缺乏更多的機會維護和管理自身集群。例如從對外兼容性上看夕晓，Kafka 下游接了多樣的開源解決方案宛乃，與 Spark、Flink 等有天然集成蒸辆，但 Kinesis 是閉源的托管服務征炼，下游集成由 AWS 主導，日志記錄的更新和變化將受制于 AWS 內(nèi)部研發(fā)躬贡；

• EMR 適合批處理的工作模式谆奥，在全天候不間斷的運行狀態(tài)下，基于 AWS 基礎(chǔ)計算和存儲資源自建的 Hadoop 集群能夠提供更好的可用性拂玻，從而更好地應對流處理場景酸些。

在上述場景下，F(xiàn)reeWheel 并沒有主動選擇 EMR 或 Kinesis 原生服務檐蚜，而是從成本魄懂、性能、開放程度闯第、規(guī)氖欣酰化和容錯管理等維度與自身維護做了對比實踐。但張磊也提到咳短，在一般的使用場景下肃廓，對于 AWS 的原生服務，比如 RDS诲泌，Athena 等，F(xiàn)reeWheel 會鼓勵并盡可能地使用铣鹏， 這樣才能更有效地滿足高可用需求敷扫，并降低總體開發(fā)維護成本。

截至目前，經(jīng)過測試和調(diào)整葵第，F(xiàn)reeWheel 已逐步把面向客戶的的所有產(chǎn)品都遷移到 AWS 環(huán)境中绘迁，目前自有數(shù)據(jù)中心里只有極少數(shù)對內(nèi)的服務在運行。而最終它們也都會遷移到 AWS 環(huán)境中卒密。

高可用實踐需求及實現(xiàn)方案解析高可用性設(shè)計目標

一個完整的全系統(tǒng)高可用性設(shè)計通常會涉及五大層面：基礎(chǔ)設(shè)施缀台、服務器、數(shù)據(jù)哮奇、應用程序膛腐、系統(tǒng)服務。

在基礎(chǔ)設(shè)施層鼎俘，F(xiàn)reeWheel 更多的是將 AWS 視為一項服務哲身。雖然 AWS 會充分保證其基礎(chǔ)設(shè)施的穩(wěn)定性，F(xiàn)reeWheel 還是會在所有的服務都可能出問題這一假設(shè)下指導設(shè)計贸伐。服務器層也是如此勘天。

數(shù)據(jù)層，如果該數(shù)據(jù)存在于 FreeWheel 自身系統(tǒng)捉邢，其通常會借助于像 Kafka脯丝、HBase 的天然多副本能力，即設(shè)置多個副本提供數(shù)據(jù)容災伏伐。

應用程序?qū)映杞現(xiàn)reeWheel 一般會將它做到無狀態(tài)，從而更容易實現(xiàn)快速恢復和高可用秘案，無論是水平擴展還是垂直擴展都更方便砰苍。

服務層，F(xiàn)reeWheel 采用的是 Failover（故障轉(zhuǎn)移）機制阱高。即應用服務器設(shè)置多臺赚导，彼此之間通過心跳聯(lián)系。數(shù)據(jù)庫赤惊、緩存吼旧、應用服務器等任何位置出現(xiàn)瓶頸就只需增加處理能力。目前未舟，對于服務器的對等可替換性圈暗，主要有三種類型：Active-Active（雙主）、Active-Standby（主備）以及單 Active裕膀。

• 在雙主模式下员串，F(xiàn)reeWheel 通常會通過先綁定 Amazon ELB，再注冊到 Amazon Route 53 的方式昼扛，從而實現(xiàn)自動對應用無感知訪問寸齐。

• 對于主備模式，F(xiàn)reeWheel 通常會將相應的信息注冊到 ZooKeeper，由 ZooKeeper 實現(xiàn) Failover 的分布式協(xié)調(diào)服務渺鹦，從而實現(xiàn) Master 的選舉和對外服務發(fā)現(xiàn)扰法。

• 對于單主模式，一般是一些離線任務毅厚，F(xiàn)reeWheel 會將其綁定在 ASG（Auto Scaling Group）中塞颁，出現(xiàn)問題時可以自動擴展重試。

高可用的整體實現(xiàn)方案

無論是跨 Region（區(qū)域）還是跨 AZ（可用區(qū)）吸耿，數(shù)據(jù)交換都將產(chǎn)生一定的成本開銷祠锣。面對著龐大數(shù)據(jù)量和跨區(qū)域 / 可用區(qū)間的數(shù)據(jù)延遲，在 AWS 多可用區(qū)實踐過程中珍语，F(xiàn)reeWheel 針對數(shù)據(jù)平臺對于高可用的需求及 AWS 自身高可用實踐經(jīng)驗锤岸，采用了多種定制方式——主要對 Hadoop-HBase、Kafka板乙、Zookeeper 及數(shù)據(jù)處理部分實現(xiàn)了不同的高可用解決方案是偷。

Hadoop-HBase 多可用區(qū)

在設(shè)計之初，F(xiàn)reeWheel 就試圖平衡了成本募逞、性能和可用性之間的關(guān)系蛋铆。但是類似數(shù)據(jù)庫系統(tǒng)中的 CAP 理論，這三者很難同時得到滿足放接。例如刺啦，AWS 上很多及其類型和存儲類型都不盡相同。為了提升 HBase 性能需要采用 instance store 這類本地 SSD 存儲方式纠脾，而相應的弊端也隨之產(chǎn)生：一旦掛載這個 instance store 這個實例出現(xiàn)異常玛瘸，相應的存儲就會丟失。尤其是當其真實宿主機發(fā)生大面積故障時苟蹈，可能導致數(shù)據(jù)的徹底丟失糊渊。

因此，F(xiàn)reeWheel 也需要對 HBase 在多個可用區(qū)上實現(xiàn)高可用慧脱。

對于存儲模塊渺绒，F(xiàn)reeWheel 選擇兩個可用區(qū)來部署，通過 HDFS Storage Policy 接口菱鸥，實現(xiàn)數(shù)據(jù)塊副本數(shù)在主可用區(qū)和次可用區(qū)的分布宗兼。 對于無狀態(tài)的數(shù)據(jù)應用優(yōu)先部署在與 Hadoop/HBase 主可用區(qū)同側(cè)，并支持在次可用區(qū)快速部署氮采。應用和數(shù)據(jù)優(yōu)先同側(cè)的策略殷绍，可以有效降低數(shù)據(jù)應用的因為跨可用區(qū)帶來的數(shù)據(jù)延遲，并降低可用區(qū)之間網(wǎng)絡傳輸?shù)某杀鹃_銷鹊漠。借助 AWS 提供不同存儲介質(zhì)的 IOPS 和持久化特點篡帕，實現(xiàn)針對不同業(yè)務的工作負載靈活選擇存儲節(jié)點配置殖侵，并實現(xiàn)業(yè)務之間的物理隔離（原理如下圖）。

image

其中镰烧，隔離思路主要是基于不同的工作負載選用不用的 EC2 實例或 EBS 實例。這樣也可根據(jù)自身的業(yè)務特點楞陷，在 AWS 中選擇不同的硬件怔鳖、實例類型或 EBS 類型來滿足需求。此外固蛾，F(xiàn)reeWheel 也可以在 AWS Hadoop 上實現(xiàn)一組機器的上線及下線结执，而且只把具有某一類標簽的機器上、下線艾凯，而不影響到其他數(shù)據(jù)献幔。

Kafka 多可用區(qū)

Kafka Topic 內(nèi)每個 Partition 有多個副本，多可用區(qū)部署趾诗，需保證在不同可用區(qū)的副本個數(shù)的劃分蜡感。姜冰提到，在正常情況下每個 Partition 里可設(shè)置多個副本恃泪，如果要保證高可用郑兴，意味著需要將多個副本同時被部署到同一可用區(qū)上，但同時贝乎，這樣做的弊端是無法保證可用區(qū)級別高可用情连，如果一個可用區(qū)宕機將導致整個 Partition 不可用。

于是览效，考慮到跨可用區(qū)帶來的數(shù)據(jù)延遲以及成本開銷却舀，F(xiàn)reeWheel 針對數(shù)據(jù)應用和規(guī)模實現(xiàn)了不同的策略。

一種策略是锤灿，對于用于數(shù)據(jù)處理流程的 Kafka Topic挽拔，在次可用區(qū)僅部署 Partition 副本中的 Follower。應用程序和 Kafka 主可用區(qū)同側(cè)衡招，讀寫數(shù)據(jù)的流量全部在同一可用區(qū)完成篱昔，這樣在主從可用之間，僅有 Leader 和 Follower 之間的網(wǎng)絡傳輸開銷始腾。在主可用區(qū)發(fā)生故障時州刽，從可用區(qū)的 Follower 切換成 Leader 對外提供服務（原理如下圖）。

image

在這種情況下浪箭，Kafka 消費者只會在同一可用區(qū)消費穗椅，從而避免跨可用區(qū)間因網(wǎng)絡傳輸帶來的成本消耗，同一可用區(qū)間的延遲性也大大降低奶栖。

而對于以在線服務為主的數(shù)據(jù)匹表，為了提供更強的高可用和更快速的恢復能力门坷，Kafka 采用 3 可用區(qū)對等部署的方案，無差別的對外提供服務：每一個 Partition 的 Leader 和 Follower 以公平的策略隨機分配到不同的可用區(qū)袍镀，在 AWS 出現(xiàn)可用區(qū)級別的故障時默蚌，Kafka 借助 Leader 和 Follower 之間的切換，保證服務的高可用（原理如下圖）苇羡。

image

放在 FreeWheel 的具體業(yè)務場景中绸吸，為保證廣告主預算與廣告競價間反饋回路的可用性高且延時性低，避免出現(xiàn)廣告超量投放或投放價格與預算偏差等問題设江，F(xiàn)reeWheel 即需采用上述第二類這種解決方案锦茁。

Zookeeper 多可用區(qū)部署方案

Zookeeper 集群是由 1 個 leader 和若干個 follower 組成，這些節(jié)點被部署到 3 個 AWS 可用區(qū)叉存。應用通過名字注冊服務將主工作服務（Active）注冊到 Zookeeper码俩。在可用區(qū)發(fā)生故障時吵冒，應用 Active／Standby 角色根據(jù) Zookeeper 名字服務狀態(tài)變化進行切換抹锄，并注冊最新的 Active 服務到 Route53（原理如下圖）。

image

數(shù)據(jù)處理高可用部署方案

目前 FreeWheel DIP（Data Ingestion Pipeline）架構(gòu)由兩部分組成著瓶，一是流處理工作類型甫菠，二是上下游以小時為級別的批處理工作類型挠铲。

流處理消費一次來源于 Kafka，同時會和 HBase 交互寂诱，所以就流處理來說拂苹，如果能解決數(shù)據(jù)和狀態(tài)高可用，其本身是屬于一條無狀態(tài)的數(shù)據(jù)處理流水線痰洒。反觀瓢棒，這也是為什么 FreeWheel 會花更多功夫在 Kafka、Hadoop-Hbase 和 Zookeeper 高可用部署上的原因丘喻，從而進一步確保流式數(shù)據(jù)處理狀態(tài)和高可用脯宿。

流式處理主要通過 Hadoop YARN 部署，采用 ASG 做擴展 / 收縮泉粉，以及采用 ASG 綁定同一 YARN 隊列的方式來保證高可用性连霉。

對于批處理工作類型的解決方案，F(xiàn)reeWheel 也有比較好的 Failover 方案應對異常狀況下的自我修復嗡靡《搴常總的來說，利用分布式的天然架構(gòu)讨彼，F(xiàn)reeWheel 可以通過監(jiān)控措施很快地對其進行恢復歉井。

高可用實踐之切換部署

因為通過對有狀態(tài)數(shù)據(jù)（諸如 Kafka、HBase哈误、Zookeeper）實現(xiàn)多可用區(qū)哩至，從底層向上的各個業(yè)務可形成自我恢復的能力躏嚎，即使在發(fā)生故障時，也已能在極端的情況下為用戶無縫提供完整服務菩貌。

當跨可用區(qū)級別切換時卢佣，F(xiàn)reeWheel 更多貫徹的是 DevOps 理念，即不用專職的運維人員箭阶，通過監(jiān)控和腳本自動化的工具和方式保證服務高可用珠漂。目前在 FreeWheel 內(nèi)部受重視的一種模式是監(jiān)控和報警的代碼化，即通過相應的框架實現(xiàn)監(jiān)控和報警尾膊，用代碼做管理，而非以往那種在站點上做簡單配置的方式荞彼。

對于監(jiān)控和報警冈敛，F(xiàn)reeWheel 用到的主要工具包括 Datadog 及開源工具如 TerraForm（類似于 AWS CloudFormation）和 SaltStack 等。

Datadog 的工作方式是在每一臺需要監(jiān)控的服務器上運行它的 Agent鸣皂。FreeWheel 主要用 Datadog 實現(xiàn) EC2 級別監(jiān)控抓谴，這樣可以基于機器類型、用途等寞缝，分門別類對其服務進行監(jiān)控癌压，一是實現(xiàn)系統(tǒng)級別（如 CPU、內(nèi)存荆陆、磁盤滩届、網(wǎng)絡 I/O）的相關(guān)監(jiān)控，二是實現(xiàn)基于 應用級別的監(jiān)控被啼。

另外帜消，TerraForm 會應對啟動資源、擴展 / 回收和權(quán)限配置之類的場景浓体，從而實現(xiàn) AWS 資源配置泡挺。SaltStack 實現(xiàn)配置的冪等性管理，并針對機器 tag 進行分布式調(diào)用和部署檢查命浴。

當可用區(qū)級別需切換時娄猫，目標是希望能做到讓用戶無感知。但目前如果需從主區(qū)域切換至備用區(qū)域情況下生闲，F(xiàn)reeWheel 當前的設(shè)計方案是允許有一定（分鐘級別）的宕機時間媳溺。因為在一般情況下，一個區(qū)域 3 個或 3 個以上的可用區(qū)（FreeWheel 只會使用有至少 3 個可用區(qū)的區(qū)域）已經(jīng)足夠保證高可用性跪腹。當整個區(qū)域出現(xiàn)整體性故障時褂删，允許有一定的宕機時間是綜合成本和需求的整體考慮。

高可用實踐收效及未來規(guī)劃

張磊在采訪中提到冲茸，伴隨著高可用實踐屯阀，F(xiàn)reeWheel 也獲得了業(yè)務的高彈性缅帘。對于“超級碗”及世界杯這類大型體育賽事開始時，整個架構(gòu)會有更好的擴展能力應對突發(fā)流量难衰，幫助其在 AWS 上實現(xiàn)高度的動態(tài)擴展性钦无。

未來，F(xiàn)reeWheel 一方面會嘗試將一部分系統(tǒng)走向容器化盖袭，比如 Data Ingestion Pipeline失暂。當然，對于 HBase鳄虱、Hadoop 如何更好地結(jié)合 K8S 或利用 Amazon EKS 等工具弟塞，F(xiàn)reeWheel 還需要下一階段的調(diào)研及實驗。

另一方面拙已，針對更大范圍的高可用决记、數(shù)據(jù)安全等問題，F(xiàn)reeWheel 還將持續(xù)探索怎樣在平衡性能和成本的條件下多個區(qū)域提供服務和快速的災難修復的能力倍踪。

受訪嘉賓

張磊系宫，F(xiàn)reeWheel 架構(gòu)師，現(xiàn)負責公司數(shù)據(jù)平臺和數(shù)據(jù)產(chǎn)品的整體技術(shù)把控建车。

姜冰扩借，F(xiàn)reeWheel 首席工程師，現(xiàn)全面負責大數(shù)據(jù)平臺的架構(gòu)和研發(fā)工作缤至。