如何构建高可用和可伸缩的架构？
發表于2015-09-22 13:42| 4669次閱讀| 來源CSDN| 5 條評論| 作者蒲婧
CTOCTO俱樂部CTO講堂云存儲七牛架構高可用 width="22" height="16" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2015-09-22%2F2825769-CTO&type=3&count=&appkey=&title=%E5%A6%82%E4%BD%95%E6%9E%84%E5%BB%BA%E9%AB%98%E5%8F%AF%E7%94%A8%E5%92%8C%E5%8F%AF%E4%BC%B8%E7%BC%A9%E6%9E%B6%E6%9E%84%EF%BC%9F%E6%9C%89%E5%93%AA%E4%BA%9B%E5%85%B3%E9%94%AE%E7%9A%84%E6%8A%80%E6%9C%AF%E8%8A%82%E7%82%B9%E5%92%8C%E9%9A%BE%E7%82%B9%E6%8C%91%E6%88%98%EF%BC%9F%E5%AF%B9%E4%BA%8E%E5%85%AC%E5%8F%B8%E6%9D%A5%E8%AF%B4%EF%BC%8C%E4%B8%BA%E4%BB%80%E4%B9%88%E6%9C%89%E5%BF%85%E8%A6%81%E8%80%83%E8%99%91%E9%AB%98%E5%8F%AF%E7%94%A8%E5%8F%AF%E4%BC%B8%E7%BC%A9%EF%BC%9F%E6%9C%AC%E6%96%87%E4%B8%BA%E4%B8%83%E7%89%9B%E9%A6%96%E5%B8%AD%E6%9E%B6%E6%9E%84%E5%B8%88%E6%9D%8E%E9%81%93%E5%85%B5%E5%9C%A8CTO%E8%AE%B2%E5%A0%82%E4%B8%AD%E7%9A%84%E7%B2%BE%E5%BD%A9%E5%88%86%E4%BA%AB%E6%95%B4%E7%90%86%E3%80%82&pic=&ralateUid=&language=zh_cn&rnd=1449926446249" frameborder="0" scrolling="no" allowtransparency="true">摘要：如何構建高可用和可伸縮架構？有哪些關鍵的技術節點和難點挑戰？對于公司來說，為什么有必要考慮高可用可伸縮？本文為七牛首席架構師李道兵在CTO講堂中的精彩分享整理。為了幫助IT從業者職業之路擁有更多收獲，在諸多C粉的殷切期待下，由CTO俱樂部打造的CTO線上講堂自登場以來獲得大家好評。本期邀請七牛首席架構師李道兵帶來“如何構建高可用和可伸縮的架構？?”的主題分享。
歡迎加入CTO講堂微信群與業界大咖零距離溝通，每周都有技術大咖進群分享，報名拖至文末查看。
主講人：七牛首席架構師李道兵
嘉賓簡介：李道兵（新浪微博 @lidaobing， 個人博客：http://blog.lidaobing.com/），七牛首席架構師，Debian開發者，ISO-Codes等開源軟件維護者，python-lunardate、apistrano-scm-jenkins作者，原盛大云資深研究員。關注服務安全、架構健壯性（高可用、可測試、可追溯）等領域，參與了多個高壓力項目的結構設計，推崇高可用、可伸縮、低耦合的架構設計。
公司簡介：七牛由國內云存儲領域領軍人物之一許式偉于2011年創立，專注以數據為中心的公有云服務市場，公司核心團隊在海量存儲等領域擁有超過十年的技術積累，核心技術完全自主研發。七牛是全世界第一個提出用存儲、加速和數據處理這三個詞來描述云存儲服務的公司，為了更好地服務平臺上的用戶，七牛用KODO對象存儲服務、FUSION融合CDN管理平臺、DORA就近計算平臺、PILI直播云服務四大產品重新定義了云存儲，志在成為最開放、最完備的數據服務提供商。從成立至今的4年里，七牛已服務超28萬企業用戶，其中不乏很多重量級和明星企業。如新型創業中的美圖、Camera360、窮游、豌豆莢等，也有傳統企業中的順豐、PPTV、步步高、OPPO、海康威視、平安科技等。
以下是9月16日CTO講堂現場完整速記：
主持人：今天的嘉賓是七牛云存儲首席架構師李道兵，請您做下自我介紹。
李道兵：hi, 大家好，我是七牛的李道兵，在七牛擔任首席架構師。我07年開始工作，先后在金山、盛大、七牛工作。在金山加入了金山實驗室，主要方向是存儲和爬蟲。加入盛大后先后參與了盛大網盤和盛大云項目。
中間有一年在一個創業公司（GIGABASE.ORG）工作，之后就加入了七牛。
主持人：那么是在什么情況下您加入了七牛團隊，開始了創業團隊之旅的呢？
李道兵：2013 年還在GIGABASE 的時候，收到七牛CEO老許的邀請，一起吃了個飯，聊了一下。
聊完之后覺得七牛在做的事情就是我想做的事情，我覺得云的存在不應當只是為了降低采購周期，提高利用率，而應該著眼在如何利用云去給開發者和運維構建一個更好的平臺，如何去提高開發者和運維的效率。所以后來就辭去了 GIGABASE 的工作，加入了七牛。
主持人：請介紹一下目前七牛云存儲目前的情況以及技術團隊構成。
李道兵：七牛成立差不多4年了，但作為一家ToB的企業還算很年輕的，我們現在有200多人，圍繞數據這個核心組織了多個產品，包括存儲、分發、富媒體處理、大數據、還有通用計算平臺等。現在前面三個已經正式對外，其余的還在內測當中。
技術團隊的構成：200多人中一半人左右是一線的研發團隊，跟很多互聯網公司一樣，我們都是一個超扁平的結構，團隊小的5個人， 大的10來個人，所有的研發團隊都是平行的，直接匯報給CEO。
主持人：那么請您介紹下云存儲行業目前的具體情況以及未來發展前景吧。
李道兵：云存儲這幾年發展迅速，我覺得主要是幾個方面的原因：
- a.? 首先是數據自然增長，每年全世界創造的數據都在以一個很大的幅度增長；
- b.? 其次是帶寬的增長，導致大家對音頻、視頻等富媒體（當然未來還有VR)的需求大規模增加，當然鏡頭分辨率的提高對需求的增加貢獻也不小；
- c.? 越來越多的智能設備引入，這些設備會自動地產生大量的數據，現在主動產生的數據（比如拍照）占主流，未來可能被動產生的數據會成為主流（比如你的身體狀況監控）；
- d.? 對于中國來講，國家的去 IOE政策，以及推動政府采購云，這些也幫助了云存儲行業的發展；
- e.? 當然最重要的一點是，大家發現數據的價值越來越大，比如 LinkedIn，240億美金的市值，大部分來自于大家對 LinkedIn 擁有的數據的高估值。在電商等行業，數據價值的案例也越來越多
主持人：可否從案例角度來介紹一下七牛的產品服務應用場景？
李道兵：以一個典型的短視頻應用為例。首先是上傳，一個10s左右的視頻在 1-2MB, 60s 的在 10MB 左右，這個大小的文件從手機直接上傳的成功率不高，那么就需要用到的我們的分片上傳技術以及就近上傳技術，前者可以提高成功率，后者提高上傳速度。
由于硬件原因，不是每個視頻的編碼格式都是一致的，比如音頻就有 mp3/aac 等格式，那么轉成一致的格式，再打上水印就是必要的了，這就需要我們提供的視頻轉碼技術。
每個視頻需要一個封面，封面通常從視頻中抽取，那么用我們提供的抽幀服務加上圖片裁剪服務效果就很好。視頻需要審核，這個也需要通過我們的轉碼服務來提供一個超小視頻用來審核。
最后就是視頻分享后需要分發，這個就可以利用我們提供的融合CDN來達到最佳的覆蓋、速度和性價比。當然還有就是數據的分析（不過還在內測階段）。
主持人：那么七牛目前的產品及服務都有哪些？相比其他公司類似產品，競爭力體現在哪些方面？
李道兵：七牛圍繞著數據平臺這一概念組織了一系列的產品，包括存儲、轉碼、分發等業務。未來，我們會圍繞如何讓用戶更方便地管理數據，如何讓用戶的數據價值最大化這幾個方向來開發更多產品。
正如我之前提到的，我們跟 AWS 等云服務最大的不同在于終極目標的不同。AWS的目標是圍繞著降低采購周期，提高使用率這個方向去發展，而我們更多是從如何提高軟件工程師和運維工程師的生產率去考慮。
所以我們會率先引入在 URL 中指定轉碼規格，支持URL轉碼管道，支持靈活的回調策略，分片上傳、鏡像存儲等等功能。我們的售前也會努力和客戶一起來制定解決方案，幫助解決接入時遇到的各種問題。
主持人：我們來聊聊今天的主題~對于公司來說，為什么有必要考慮高可用可伸縮？必要性體現在哪些方面？
李道兵：現在各種應用用戶量起來很快，特別是2C/娛樂業的一些應用（比如逗拍，一個春節就起來了，小咖秀之類的也很快），用戶量起來本來是讓你離成功近了一大步，但如果這時候因單機故障出現不可用，或者因為系統容量不足導致響應不暢，那么你的用戶也會很快離你而去。
更何況，其實我們也可以看到，高可用也好，可伸縮也好，都是有章可循的，成本也不高。
主持人：如何構建高可用和可伸縮架構？有哪些關鍵的技術節點和難點挑戰？
李道兵：我覺得首先一點是分離控制流和數據流，當然如果你的應用不涉及富媒體或者其他大流量的數據那么就可以跳過這步。這么做的好處主要是，控制流其實流量不高，那么我們就可以租8線BGP的機房來提高動態請求的響應速度和覆蓋率，畢竟好機房貴的是流量成本，而不是機架成本。而數據流的高可用和可伸縮的技術門檻高，運維成本也不低，那么最好往云上搬。
對于控制流這邊，我們又可以簡單地把需求分解到入口、業務、數據庫、緩存、消息隊列這幾個子模塊。
- 入口比較簡單，低流量的情況下一對 Nginx，加上心跳就可以滿足。即使是高流量，那么心跳+LVS也是一個漂亮的選擇。當然在 DNS 層先做一次負載均衡也不錯。另外，如果你的應用是有客戶端的，你還可以選擇發送所有入口IP到客戶端，由客戶端來選擇，做負載均衡。
- 業務層牢記一個原則，不要保存狀態，就可以輕易地做到高可用和可伸縮，狀態盡量放到緩存層和數據庫層，而不是自己兜著。初期兩個節點，后來水平加節點就可以了。
- 數據庫這方面的文檔和PPT反而是最多的，高可用方面，MySQL的 master-master方案，MongoDB的 ReplicaSet 方案都不錯，主要是看你的使用場景。伸縮性主要靠水平和垂直拆表，畢竟各種數據庫的集群方案都有很大的缺陷，個人覺得不如放在業務邏輯層來做。另外，數據庫層有條件的話就上 SSD，成本雖然貴一點，但2個數量級左右的性能提升，對你的幫助會非常非常大。
- 緩存層隨著 Redis 3.0 和 Codis 這類方案的推出，反而是率先解決了緩存層的高可用問題，我覺得大家可以直接采用，在業務邏輯層搭也可以，針對不同的情況可以用一致性Hash，主備緩存等多種方式來處理。如果自己搭，那么緩存層的節點數不能少，畢竟要防止緩存失效后對數據庫的沖擊，一個簡單的手法是緩存層和業務邏輯層混合部署，一起水平擴展。
- 消息隊列一般依賴于數據庫或者其他持久化層，自己的高可用和可伸縮倒是比較方便，設計時注意即可，比較值得注意的是，一般這種情況下很難保證消息隊列的順序，這也是設計時需要考慮的，不依賴于消息順序即可。
主持人：那么云存儲作為一個服務端的業務，在實現高可用和可伸縮的時候有什么自己的特點？
李道兵：云存儲也是服務端的業務，所以上面提到的各個點都要考慮。（當然不能再分離數據流了）。
此之外，儲存還要額外考慮幾個點，比如如何優化數據流，降低數據流在內網的傳遞次數，降低內網擁塞的可能性，同時也能提高響應性。還有就是如何避免突發的大規模數據沖擊服務器，也就是說如何避免出現性能毛刺。
主持人：在提升用戶體驗方面七牛做了哪些努力呢？對于用戶反饋都是如何及時解決的？
李道兵：針對用戶體驗，我們是從兩個方面來優化的。
- 首先是產品本身的質量，比如服務的可用性，服務的響應速度，如何減少 bug等，這方面我們有持續的優化措施。
- 另一個方面是如何提升七牛的服務水平。七牛有一個很強的售前團隊，能夠和客戶一起來分析客戶的場景，幫助客戶設計最佳的接入和遷移方案。
七牛的支持團隊也很厲害，絕大部分的工單都可以讓客戶得到滿意的答復，少量比較深的問題則會直接轉發給開發團隊，讓開發團隊來做一個深度剖析。
問題的解決速度則是支持團隊的一個重要考核指標，我們的客戶對這響應速度這點也很在意。
主持人：看到您簡歷中一直在深鉆技術的第一線，結合您的切身體會跟我們分享下一名合格的架構師應該是怎樣的呢？
李道兵：之前在知乎回答過一個類似的問題，我就直接貼過來吧
- 多看書
- 多看文章
- 多做
還有多找人聊天，說出你的想法，等別人反駁，從別人的反駁中吸取知識，再去做驗證。修改。
主持人：您在提升七牛技術團隊方面，有哪些思考呢？
李道兵：首先是招聘，校招要看這個人是否聰明，之前是否努力，之前的努力是否有成果，性格是否適合這個團隊，這個團隊能否給他合適的成長空間。社招要追求這個人能否給你的團隊帶來新知識、新理念、新方法，能否讓你的團隊進一步成長。
其次是學習，團隊如果是忙于工作沒有時間學習是不行的，當然僅僅是有時間學習也不夠，如何創建一個讓大家愿意去學習的環境也很重要，所以我們每周五會有分享講座，每人的季度OKR里邊也要有如何提升自己的內容，我們期望大家成長，也期望大家很嚴肅地看待這份工作，而不僅僅是為了混日子。
主持人：七牛的技術團隊氛圍是怎樣的？公司招人過程中，比較看重新人的哪些特質？
李道兵：首先是平等，大家的角色都是比較類似的，架構設計也不是上面決策下面執行，而是大家一起來討論。
其次是大家都覺得成長比較快，這個可能跟我們 peer review 的機制有點關系，每個人都需要 review 別人的代碼，自己的代碼也需要別人來 review, 那么你可以很快學習到一些很實用的技巧，自己的代碼缺陷也很容易被人指出來，迅速改掉。
最后是擔當，我們公司比較推崇擔當這個詞，一個好的工程師也要有好的推進能力，如何去把一個事情跟進到底是一個必須要掌握的能力。
新人的問題剛才提過，主要是聰明，努力，以及努力沉淀下來的成果。
主持人：對想在技術架構路線上走得更遠的技術人，您都有什么建議嗎？
李道兵：之前知乎那個鏈接講得差不多了，最后再送夫子的一句話，“學而不思則罔，思而不學則殆”。當然對我來講，思我會理解為思考再加討論。
互動環節：如何優化數據流，降低數據流在內網的傳遞次數，降低內網擁塞的可能性，同時也能提高響應性----------對于業務交互較多的平臺來說，數據流在內網傳遞次數很多，我想請教一下，這塊有什么樣的優化經驗？李道兵：1. 控制流不用擔心傳遞次數太多，服務分解細一點是好事；2. 數據流方面一是減少環節，而是用控制流代替數據流。
問：服務分解細，節點就很多
李道兵：比如數據直接發往緩存節點，然后把緩存節點的 URI 直接往下傳遞。節點多，但每個節點的功能內聚和單一，這對你的服務的穩定性是好事，在加上 etcd 這類的工具來降低部署難度就好。 互動環節：您有沒有接觸過 OpenStack？
李道兵：openstack 其實應該算是一個開源的 AWS 實現，特別是主要的虛擬機，存儲，EBS這幾塊。存儲這一塊，openstack 的實現很差，性能不好，運維難度也高，內部的bug也不少。不過最近很多人都在用 ceph 來做 openstack 的存儲，這樣也挺好。
問：您接觸過的話，我想和您請教一下，OpenStack控制節點主機的高可用，都有哪些比較成熟可用的方案？
李道兵：抱歉這個快不太熟，如果我來設計，一般就是兩種方案，如果有內存一致性的需求，那么模仿或者直接使用 zookeeper/etcd。 互動環節：有個問題請教，你們有沒有需要跨機房數據實時同步的場景，如果有，如何保證數據實時和一致的？
李道兵：有，我們走的方案偏保守。首先，如果多個機房要共用一套數據，那么需要保證只有一個節點可以寫入。對于其他機房，則在業務邏輯層重放主機房的操作，并且按照業務邏輯清理緩存。只要保證你的緩存形式滿足: 1. 能夠根據單條數據來清理 2. 列表類的緩存有有效期，并且不會導致業務出錯即可。 互動環節：傳統ERP每天有銷售流水5萬多條，不停插入Oracle，采購和其他業務不停查看歷史銷售記錄一查查兩三年的銷售，各種計算，特別客戶銷售品類多而且雜，計算方法也是千奇百怪， 也做一些優化，效果不明顯。請問您有什么好的建議？
李道兵：每天5萬條其實 qps 很低，峰值應該低于 5qps。計算需要有獨立的數據庫，而不是在線的數據庫。數據庫需要有 admin, 分析大家的慢請求。要么加索引，要么禁止或者遷移到 hadoop/hive 這類適合慢請求的平臺。 互動環節：能否介紹一下糾刪碼在七牛存儲的實現？
李道兵：糾刪碼在七牛存儲的實現：細節不便透漏，但是 EC 也不是一個太新的東西，比如內存，RAID都有過實現，你可以看看他們的實現。 互動環節：能問一個偏業務問題嗎？比如幾萬人秒殺10個產品，怎么做架構保證不出錯和性能穩定
李道兵：秒殺最常見的做法是兩段式，第一段是接受秒殺請求，并且扔進隊列，這個步驟只需保證入口和隊列的容量即可。第二段是后臺從隊列拿到請求，應用在數據庫，然后通知用戶，只一個步驟就是按照數據庫的容量來有序執行即可。 互動環節：為什么很多網站的登錄域名和首頁不是一個域名？passport.jd.com這個是jd的登錄域名，為什么很多站這樣，和分布式架構有關還是其他原因？
李道兵：分拆能降低單個模塊的開發和維護難度，特別是你的開發分到多個團隊以后，多個團隊維護一個模塊是很恐怖的，當然還有不同的域名有不同的部署需求，分拆后部署更靈活。 互動環節：在mysql集群，水平分表的情況下，有幾種方式自動生成表的ID主鍵保證不重復，目前你們是如何處理的？
李道兵：幾個方法, 1. 使用 UUID ；2. 每個數據庫用不同的數列，比如第一個用 1,4,7,10, 第二個用 2,5,8,11, 第三個用 3,6,9,12 ；3. 當然也可以用外部的主鍵生成器。 互動環節：能提供一個，mysql集群架構的方式嗎？
李道兵：數據庫的文檔都比較好找。（例如：How To Set Up MySQL Master-Master Replication）
總結
以上是生活随笔為你收集整理的如何构建高可用和可伸缩的架构？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 支付接入开发的陷阱有多深？
- 下一篇： Growth Hacking背后，数据分