英文原文：Scaling Pinterest – From 0 to 10s of Billions of Page Views a Month in Two Years 編譯:oschina
Pinterest正經(jīng)歷了指數(shù)級曲線般的增長，每隔一個半月就翻番。在這兩年里，Pinterest，從 每月PV量0增長到100億，從兩名c創(chuàng)始人和一個工程師成長為四十個工程師，從一臺MySQL 服務(wù)器增長到180臺Web 服務(wù)器(Web Engine)，240臺接口服務(wù)器(API Engine), 88臺MySQL 數(shù)據(jù)庫 (cc2.8xlarge) ，并且每臺DB有一個備份服務(wù)器，110臺Redis 實例服務(wù)（Redis Instance），200臺 Memcache 實例服務(wù)（Memcache Instance）。
令人嘆為觀止的增長。想一探Pinterest的傳奇嗎？我們請來了Pinterest的兩位創(chuàng)始人Yashwanth Nelapati 和 Marty Weiner，他們將以 Scaling Pinterest為題講述關(guān)于Pinterest架構(gòu)的充滿戲劇化的傳奇故事。他們說如果能在一年半前飛速發(fā)展時能看到有人做類似題材的演講的話，他們就會有更多的選擇，以避免自己在這一年半里做出的很多錯誤的決定。
這是一個很不錯的演講，充滿了令人驚訝的細(xì)節(jié)。同時這個演講也是很務(wù)實的，歸根結(jié)底，它帶來了可讓大家選擇的策略。極度推薦！
這篇演講中有兩個我最為看重的經(jīng)驗：
1.強(qiáng)大的架構(gòu)在處理增長時通過簡單增加相同的東西(服務(wù)器)來應(yīng)對，同時還能保證系統(tǒng)的正確性。當(dāng)遇到某種（性能）問題時，你想通過砸錢來擴(kuò)容指的是你可以簡單增加服務(wù)器(boxes)。如果你的架構(gòu)能夠做到這一點，那它就如金子一般強(qiáng)大而珍貴！
2. 當(dāng)某些（性能問題）快到極限時大多數(shù)技術(shù)都會以他們自己的方式失敗。這導(dǎo)致他們在審核工具時要考慮以下一些特性：成熟，好且簡單，有名氣且用的人多，良好的支持，持續(xù)的優(yōu)異性能，很少失敗，開源。按照這樣的標(biāo)準(zhǔn)，他們選擇了：MySQL, Solr, Memcache, and Redis，放棄了Cassandra ，Mongo。
這兩點經(jīng)驗是相互聯(lián)系的。遵循（2）中提到的標(biāo)準(zhǔn)的工具可以在擴(kuò)容時簡單增加服務(wù)器(boxes).當(dāng)負(fù)載增加了，成熟的產(chǎn)品更少會有問題。當(dāng)你遇到問題時，你至少希望它的社區(qū)團(tuán)隊能夠幫助解決。當(dāng)你使用的工具過于技巧化和過于講究時，你會發(fā)現(xiàn)你遇到一堵無法逾越的墻。
在這段演講里，碎片化（sharding）優(yōu)于集群(clusterting)的觀點是我認(rèn)為最好的一部分。為了應(yīng)對增長，通過增加資源，更少失敗的模式，成熟，簡單，良好的支持，最終圓滿完成。請注意他們選擇的工具以sharding的方式增長，而不是clustering。關(guān)于他們?yōu)槭裁催x擇sharding和他們?nèi)绾巫鰏harding是很有趣的事，這很可能觸及到你以前未考慮過的場景。
現(xiàn)在，讓我們看看Pinterest如何擴(kuò)容：
基本概念
- Pins是一幅關(guān)于其他信息的集合的圖片，描述了為什么它對于用戶來說很重要，可以鏈回到他們發(fā)現(xiàn)它的地方。
- Pinterest是一個社交網(wǎng)絡(luò)。你可以追蹤人或者板報(boards).
- Database:它包含了擁有pins的板報（boards）和擁有板報（boards）的人 ，可以追蹤或重新建立（repin）聯(lián)系，還包含認(rèn)證信息。
啟動于2010年三月–自我發(fā)現(xiàn)時期
此時此刻，你甚至不知道你在做的這個產(chǎn)品將要做什么。你有想法，迭代開發(fā)更新產(chǎn)品的頻率很高。最終因遇到一些在現(xiàn)實生活中永遠(yuǎn)不會遇到的奇怪的簡短的MySQL查詢而結(jié)束。
早期的一些數(shù)字：
- 兩個創(chuàng)始人
- 一個工程師
- Rackspace托管服務(wù)器
- 一個小型web引擎
- 一個小型MySQL數(shù)據(jù)庫
2011年1月
扔在潛伏前進(jìn)中，產(chǎn)品得到了一些用戶反饋。以下是數(shù)據(jù)：
- Amazon EC2 + S3 + CloudFront云服務(wù)
- 一臺NGinX，4臺Web 引擎（作冗余用，不是真正為了負(fù)載）
- 一臺MySQL數(shù)據(jù)庫+一臺讀備份服務(wù)器（防止主服務(wù)器宕機(jī)）
- 一個任務(wù)隊列+兩個任務(wù)處理
- 一臺MongoDB（為了計數(shù)）
- 兩個工程師
至2011年9月–試運行階段
每一個半月翻翻的瘋狂增長階段。
- 當(dāng)高速發(fā)展時每個晚上每個星期都會有技術(shù)失敗的情況發(fā)生
- 這時，你閱讀大量白皮書，它會告訴你把這個增加進(jìn)來就行了。當(dāng)他們添加了大量技術(shù)時，毫無例外都失敗了。
- 最終你得到一個極為復(fù)雜的架構(gòu)圖：
- Amazon EC2 + S3 + CloudFront
- 2NGinX, 16 Web Engines + 2 API Engines
- 5 Functionally Sharged MySQL DB + 9 讀備份
- 4 Cassandra 節(jié)點
- 15 Membase 節(jié)點(分成三個單獨的集群)
- 8 Memcache 節(jié)點
- 10 Redis 節(jié)點
- 3 任務(wù)路由（Task Routers）+ 4 Task Processors
- 4 ElasticSearch 節(jié)點
- 3 Mongo集群
- 3名工程師
- 5種主要的數(shù)據(jù)庫技術(shù)只為了應(yīng)付他們自己的數(shù)據(jù)
- 增長極快以至MySQL負(fù)載很高，而其他一些技術(shù)都快到達(dá)極限
- 當(dāng)你把某些技術(shù)的應(yīng)用推至極限時，他們又以自己的方式宣告失敗。
- 放棄一些技術(shù)并問它們到底能做什么。對每一件事情重新構(gòu)架，海量工作量。
架構(gòu)成熟 2012 1月
重新設(shè)計的系統(tǒng)架構(gòu)如下：
為什么是Amazon EC2/S3
- 相當(dāng)?shù)目煽?。?shù)據(jù)中心也會宕機(jī)， Multitenancy 加入了不少風(fēng)險，但不是壞處。
- 良好的匯報和支持。他們確實有很不錯的架構(gòu)師而且他們知道問題在哪里。
- 良好的額外服務(wù)支持（peripherals），特別是當(dāng)你的應(yīng)用處于增長時期。你可能在App Engine中轉(zhuǎn)暈，你不用親自去實現(xiàn)，只需要簡單和他們的服務(wù)打交道，例如maged cache，負(fù)載均衡，映射和化簡，數(shù)據(jù)庫和其他所有方面。Amazon的服務(wù)特別適合起步階段，之后你可以招聘工程師來優(yōu)化程序。
- 分秒鐘獲得新的服務(wù)實例。這是云服務(wù)的威力。特別是當(dāng)你只有兩名工程師，你不用擔(dān)心容量規(guī)劃或者為了10臺memcache服務(wù)器等上兩周。10臺memcache服務(wù)器幾分鐘內(nèi)就能加完。
- 反對的理由：有限的選擇。直到最近你才能用SSD而且還沒高內(nèi)存配置的方案。
- 贊成的理由：還是有限的選擇。你不需要面對一大堆配置迥異的服務(wù)器。
為什么是 MySQL？
- 非常成熟
- 非常耐用。從不宕機(jī)且不會丟失數(shù)據(jù)。
- 招聘方便，一大堆工程師懂MySQL.
- 反應(yīng)時間和請求數(shù)量（requies rate，我認(rèn)為是request rate參考下面）是線性增長的。有些數(shù)據(jù)庫技術(shù)的反應(yīng)時間在請求飆升時不是很好。
- 很好的軟件支持– XtraBackup, Innotop, Maatkit
- 很好的社區(qū)，問的問題總能輕易獲取到答案
- 很好的廠商支持，譬如Percona
- 開源–這一點很重要，特別是你剛開始沒有很多資金支持時。
為什么選擇Memcache?
- 非常成熟
- 非常簡單。它就是一個socket的哈希表。
- 性能一直很好
- 很多人知道并喜歡
- 從不崩潰
- 免費
為什么選擇Redis?
- 還不成熟，但它是非常好并且相當(dāng)簡單。
- 提供了各種的數(shù)據(jù)結(jié)構(gòu)。
- 可以持久化和復(fù)制，并且可以選擇如何實現(xiàn)它們。你可以用MySQL風(fēng)格持久化，或者你可以不要持久化，或者你只要3小時的持久化。
- Redis上的數(shù)據(jù)只保存3個小時，沒有3小時以上的復(fù)本。他們只保留3個小時的備份。
- 如果存儲數(shù)據(jù)的設(shè)備發(fā)生故障，而它們只是備份了幾個小時。這不是完全可靠的，但它很簡單。你并不需要復(fù)雜的持久化和復(fù)制。這是一個更簡單，更便宜的架構(gòu)。
- 很多人知道并喜歡
- 性能一直很好
- 很少的一些故障。你需要了解一些小故障，學(xué)習(xí)并解決它們，使它越來越成熟。
- 免費
Solr
- 只需要幾分鐘的安裝時間，就可以投入使用
- 不能擴(kuò)展到多于一臺的機(jī)器上（最新版本并非如此）
- 嘗試彈性搜索，但是以Pinterest的規(guī)模來說，可能會因為零碎文件和查詢太多而產(chǎn)生問題。
- 選擇使用Websolr，但是Pinterest擁有搜索團(tuán)隊，將來可能會開發(fā)自己的版本。
集群vs.分片
- 在迅速擴(kuò)展的過程中，Pinterest認(rèn)識到每次負(fù)載的增加，都需要均勻的傳播他們的數(shù)據(jù)。
- 針對問題先確定解決方案的范圍，他們選擇的范圍是集群和分片之間的一系列解決方案。
集群 —— 所有事情都是自動化的
- 示例: Cassandra, MemBase, HBase
- 結(jié)論: 太可怕了，不是在現(xiàn)在，可能在將來，但現(xiàn)在太復(fù)雜了，有非常多的故障點
- 屬性:
- 自動化數(shù)據(jù)分布
- 可移動數(shù)據(jù)
- 可重新進(jìn)行分布均衡
- 節(jié)點間可通訊，大量的握手、對話
- 有點:
- 自動伸縮數(shù)據(jù)存儲，至少白皮書上是這么說的
- 安裝簡單
- 在空間中分布存儲你的數(shù)據(jù)，可在不同區(qū)域有數(shù)據(jù)中心
- 高可用性
- 負(fù)載均衡
- 沒有單點故障
- 缺點 (來自用戶一手的體驗):
- 還是相當(dāng)年輕不成熟
- 還是太復(fù)雜，一大堆節(jié)點必須對稱的協(xié)議,這是一個在生產(chǎn)環(huán)境中難以解決的問題。
- 很少的社區(qū)支持，有一個沿著不同產(chǎn)品線的分裂社區(qū)會減少每個陣營的支持。
- 很少工程師有相關(guān)的知識，可能是很多工程師都沒用過 Cassandra.
- 復(fù)雜和和可怕的升級機(jī)制
- 集群管理算法是一個 SPOF 單點故障，如果有個 bug 影響每個節(jié)點，這可能會宕機(jī) 4 次。
- 集群管理器編碼復(fù)雜，有如下一些失敗的模式：
- 數(shù)據(jù)重新均衡中斷：當(dāng)一個新機(jī)器加入然后數(shù)據(jù)開始復(fù)制,它被卡住了。你做什么工作?沒有工具來找出到底發(fā)生了什么。沒有社會的幫助,所以他們被困。他們又回到了MySQL。
- 所有節(jié)點的數(shù)據(jù)損壞. What if there’s a bug that sprays badness into the write log across all of them and compaction or some other mechanism stops? Your read latencies increase. All your data is screwed and the data is gone.
- 均衡不當(dāng)而且很難修復(fù). 非常常見，如果你有10個節(jié)點，你會注意到所有節(jié)點都在一個節(jié)點上，有一個手工處理方式，但會將所有負(fù)載分布到一個單節(jié)點上
- 權(quán)威數(shù)據(jù)失效. 集群方案是很智能的。In one case they bring in a new secondary. At about 80% the secondary says it’s primary and the primary goes to secondary and you’ve lost 20% of the data. Losing 20% of the data is worse than losing all of it because you don’t know what you’ve lost.
分片(sharding) – 全憑人手
- 裁決: 分片是贏家。我覺得他們分片的方案與Flicker非常相似。
- 特點:
- 如果去掉集群方式下所有不好的特點，就得到了分片。
- 人工對數(shù)據(jù)進(jìn)行分布。
- 不移動數(shù)據(jù)。
- 通過切分?jǐn)?shù)據(jù)來分擔(dān)負(fù)荷。
- 節(jié)點不知道其它節(jié)點的存在。某些主節(jié)點控制一切。
- 優(yōu)點:
- 可以通過切分?jǐn)?shù)據(jù)庫來擴(kuò)大容量。
- 在空間上分布數(shù)據(jù)。
- 高可用。
- 負(fù)載均衡。
- 放置數(shù)據(jù)的算法十分簡單。這是最主要的原因。雖然存在單點(SPOF)，但只是很小的一段代碼，而不是復(fù)雜到爆的集群管理器。過了第一天就知道有沒有問題。
- ID的生成很簡單。
- 缺點:
- 無法執(zhí)行大多數(shù)連接。
- 沒有事務(wù)功能?？赡軙霈F(xiàn)寫入某個數(shù)據(jù)庫失敗、而寫入其它庫成功的情況。
- 許多約束只能轉(zhuǎn)移到應(yīng)用層實現(xiàn)。
- schema的修改需要更多的規(guī)劃。
- 如果要出報表，必須在所有分片上分別執(zhí)行查詢，然后自己把結(jié)果合起來。
- 連接只能轉(zhuǎn)移到應(yīng)用層實現(xiàn)。
- 應(yīng)用必須應(yīng)付以上所有的問題。
何時選擇分片？
- 當(dāng)有幾TB的數(shù)據(jù)時，應(yīng)該盡快分片。
- 當(dāng)Pin表行數(shù)達(dá)到幾十億，索引超出內(nèi)存容量，被交換到磁盤時。
- 他們選出一個最大的表，放入單獨的數(shù)據(jù)庫。
- 單個數(shù)據(jù)庫耗盡了空間。
- 然后，只能分片。
分片的過渡
- 確認(rèn)分片該達(dá)到什么樣的效果——希望盡少的執(zhí)行查詢以及最少數(shù)量的數(shù)據(jù)庫去呈現(xiàn)一個頁面。
- 剔除所有的MySQL join，將要做join的表格加載到一個單獨的分片去做查詢。
- 1 DB + Foreign Keys + Joins
- 1 DB + Denormalized + Cache
- 1 DB + Read Slaves + Cache
- Several functionally sharded DBs+Read Slaves+Cache
- ID sharded DBs + Backup slaves + cache
- 早期的只讀奴節(jié)點一直都存在問題，因為存在slave lag。讀任務(wù)分配給了奴節(jié)點，然而主節(jié)點并沒有做任何的備份記錄，這樣就像一條記錄丟失。之后Pinterest使用緩存解決了這個問題。
- Pinterest擁有后臺腳本，數(shù)據(jù)庫使用它來做備份。檢查完整性約束、引用。
- 用戶表并不進(jìn)行分片。Pinterest只是使用了一個大型的數(shù)據(jù)庫，并在電子郵件和用戶名上做了相關(guān)的一致性約束。如果插入重復(fù)用戶，會返回失敗。然后他們對分片的數(shù)據(jù)庫做大量的寫操作。
如何進(jìn)行分片?
- 可以參考Cassandra的ring模型、Membase以及Twitter的Gizzard。
- 堅信：節(jié)點間數(shù)據(jù)傳輸?shù)脑缴?，你的架?gòu)越穩(wěn)定。
- Cassandra存在數(shù)據(jù)平衡和所有權(quán)問題，因為節(jié)點們不知道哪個節(jié)點保存了另一部分?jǐn)?shù)據(jù)。Pinterest認(rèn)為應(yīng)用程序需要決定數(shù)據(jù)該分配到哪個節(jié)點，那么將永遠(yuǎn)不會存在問題。
- 預(yù)計5年內(nèi)的增長，并且對其進(jìn)行預(yù)分片思考。
- 初期可以建立一些虛擬分片。8個物理服務(wù)器，每個512DB。所有的數(shù)據(jù)庫都裝滿表格。
- 為了高有效性，他們一直都運行著多主節(jié)點冗余模式。每個主節(jié)點都會分配給一個不同的可用性區(qū)域。在故障時，該主節(jié)點上的任務(wù)會分配給其它的主節(jié)點，并且重新部署一個主節(jié)點用以代替。
- 當(dāng)數(shù)據(jù)庫上的負(fù)載加重時：
- 先著眼節(jié)點的任務(wù)交付速度，可以清楚是否有問題發(fā)生，比如：新特性，緩存等帶來的問題。
- 如果屬于單純的負(fù)載增加，Pinterest會分割數(shù)據(jù)庫，并告訴應(yīng)用程序該在何處尋找新的節(jié)點。
- 在分割數(shù)據(jù)庫之前，Pinterest會給這些主節(jié)點加入一些奴節(jié)點。然后置換應(yīng)用程序代碼以匹配新的數(shù)據(jù)庫，在過渡的幾分鐘之內(nèi)，數(shù)據(jù)會同時寫入到新舊節(jié)點，過渡結(jié)束后將切斷節(jié)點之間的通道。
ID結(jié)構(gòu)
- 分片ID：16位
- Type：10位—— Board、User或者其它對象類型
- 本地ID——余下的位數(shù)用于表中ID，使用MySQL自動遞增。
- Twitter使用一個映射表來為物理主機(jī)映射ID，這將需要備份；鑒于Pinterest使用AWS和MySQL查詢，這個過程大約需要3毫秒。Pinterest并沒有讓這個額外的中間層參與工作，而是將位置信息構(gòu)建在ID里。
- 用戶被隨機(jī)分配在分片中間。
- 每個用戶的所有數(shù)據(jù)（pin、board等）都存放在同一個分片中，這將帶來巨大的好處，避免了跨分片的查詢可以顯著的增加查詢速度。
- 每個board都與用戶并列，這樣board可以通過一個數(shù)據(jù)庫處理。
- 分片ID足夠65536個分片使用，但是開始Pinterest只使用了4096個，這允許他們輕易的進(jìn)行橫向擴(kuò)展。一旦用戶數(shù)據(jù)庫被填滿，他們只需要增加額外的分片，然后讓新用戶寫入新的分片就可以了。
查找
- 如果存在50個查找，舉個例子，他們將ID分割且并行的運行查詢，那么延時將達(dá)到最高。
- 每個應(yīng)用程序都有一個配置文件，它將給物理主機(jī)映射一個分片范圍。
- “sharddb001a”: : (1, 512)
- “sharddb001b”: : (513, 1024)——主要備份主節(jié)點
- 如果你想查找一個ID坐落在sharddb003a上的用戶：
- 將ID進(jìn)行分解
- 在分片映射中執(zhí)行查找
- 連接分片，在數(shù)據(jù)庫中搜尋類型。并使用本地ID去尋找這個用戶，然后返回序列化數(shù)據(jù)。
對象和映射
- 所有數(shù)據(jù)都是對象（pin、board、user、comment）或者映射（用戶由baord，pin有l(wèi)ike）。
- 針對對象，每個本地ID都映射成MySQL Blob。開始時Blob使用的是JSON格式，之后會給轉(zhuǎn)換成序列化的Thrift。
- 對于映射來說，這里有一個映射表。你可以為用戶讀取board，ID包含了是時間戳，這樣就可以體現(xiàn)事件的順序。
- 同樣還存在反向映射，多表對多表，用于查詢有哪些用戶喜歡某個pin這樣的操作。
- 模式的命名方案是：noun_verb_noun: user_likes_pins, pins_like_user。
- 數(shù)據(jù)不會向集群中那樣跨數(shù)據(jù)的移動，舉個例子：如果某個用戶坐落在20分片上，所有他數(shù)據(jù)都會并列存儲，永遠(yuǎn)不會移動。64位ID包含了分片ID，所以它不可能被移動。你可以移動物理數(shù)據(jù)到另一個數(shù)據(jù)庫，但是它仍然與相同分片關(guān)聯(lián)。
- 所有的表都存放在分片上，沒有特殊的分片，當(dāng)然用于檢測用戶名沖突的巨型表除外。
- 因為鍵對應(yīng)的值是blob，所以你不需要破壞模式就可以添加字段。因為blob有不同的版本，所以應(yīng)用程序?qū)z測它的版本號并且將新記錄轉(zhuǎn)換成相應(yīng)的格式，然后寫入。所有的數(shù)據(jù)不需要立刻的做格式改變，可以在讀的時候進(jìn)行更新。
- 巨大的勝利，因為改變表格需要在上面加幾個小時甚至是幾天的鎖。如果你需要一個新的索引，你只需要建立一張新的表格，并填入內(nèi)容；在不需要的時候，丟棄就好。
呈現(xiàn)一個用戶文件界面
- 從URL中取得用戶名，然后到單獨的巨型數(shù)據(jù)庫中查詢用戶的ID。
- SELECT body from users WHERE id = <local_user_id>
- SELECT board_id FROM user_has_boards WHERE user_id=<user_id>
- SELECT body FROM boards WHERE id IN (<boards_ids>)
- SELECT pin_id FROM board_has_pins WHERE board_id=<board_id>
- SELECT body FROM pins WHERE id IN (pin_ids)
- 所有調(diào)用都在緩存中進(jìn)行（Memcache或者Redis），所以在實踐中并沒有太多連接數(shù)據(jù)庫的后端操作。
腳本相關(guān)
- 當(dāng)你過渡到一個分片架構(gòu)，你擁有兩個不同的基礎(chǔ)設(shè)施——沒有進(jìn)行分片的舊系統(tǒng)和進(jìn)行分片的新系統(tǒng)。腳本成為了新舊系統(tǒng)之間數(shù)據(jù)傳輸?shù)臉蛄骸?/li>
- 不要輕視項目中的這一部分，Pinterest原認(rèn)為只需要2個月就可以完成數(shù)據(jù)的安置，然而他們足足花了4至5個月時間，別忘了期間他們還凍結(jié)了一項特性。
- 應(yīng)用程序必須同時對兩個系統(tǒng)插入數(shù)據(jù)。
- 一旦確認(rèn)所有的數(shù)據(jù)都在新系統(tǒng)中就位，就可以適當(dāng)?shù)脑黾迂?fù)載來測試新后端。
- 建立一個腳本農(nóng)場，雇傭更多的工程師去加速任務(wù)的完成。讓他們做這些表格的轉(zhuǎn)移工作。
- 設(shè)計一個Pyres副本，一個到GitHub Resque隊列的Python的接口，這個隊列建立在Redis之上。支持優(yōu)先級和重試，使用Pyres取代Celery和RabbitMQ更是讓他們受益良多。
- 處理中會產(chǎn)生大量的錯誤，用戶可能會發(fā)現(xiàn)類似丟失board的錯誤；必須重復(fù)的運行任務(wù)，以保證在數(shù)據(jù)的處理過程中不會出現(xiàn)暫時性的錯誤。
動態(tài)
- 最初試圖給開發(fā)者一個分片系統(tǒng)。每個開發(fā)者都能擁有自己的MySQL服務(wù)器，但事情發(fā)生了快速的變化，導(dǎo)致不能工作。變
- 去了Facebook的模式：每個人可以獲得一切。所以，你不得不非常謹(jǐn)慎
未來發(fā)展方向
- 基于服務(wù)的架構(gòu)。
- 當(dāng)他們開始看到了很多的數(shù)據(jù)庫負(fù)載，便像產(chǎn)卵一樣，導(dǎo)致了很多的應(yīng)用服務(wù)器和其他服務(wù)器堆在一起。所有這些服務(wù)器連接到MySQL和Memcache。這意味著有30K上的memcache連接了一對夫婦演出的RAM引起的memcache守護(hù)進(jìn)程交換。
- 作為一個修補(bǔ)程序，這些都是移動的服務(wù)架構(gòu)。有一個跟隨服務(wù)，例如，將只回答跟隨查詢。此隔離的機(jī)器數(shù)目至30訪問數(shù)據(jù)庫和高速緩存，從而減少了連接。
- 幫助隔離功能。幫助組織，解決和支持這些服務(wù)的團(tuán)隊。幫助開發(fā)人員，為了安全開發(fā)人員不能訪問其他服務(wù)。
學(xué)到的知識
- 讓其變的有趣。只要應(yīng)用程序還在使用，就會有很多的工程師加入，過于復(fù)雜的系統(tǒng)將會讓工作失去樂趣。讓架構(gòu)保持簡單就是大的勝利，新的工程師從入職的第一周起就可以對項目有所貢獻(xiàn)。
- 當(dāng)你把事物用至極限時，這些技術(shù)都會以各自不同的方式發(fā)生故障。
- 如果你的架構(gòu)應(yīng)對增長所帶來的問題時，只需要簡單的投入更多的主機(jī)，那么你的架構(gòu)含金量十足。
- 集群管理算法本身就用于處理SPOF，如果存在漏洞的話可能就會影響到每個節(jié)點。
- 為了快速的增長，你需要為每次負(fù)載增加的數(shù)據(jù)進(jìn)行均勻分配。
- 在節(jié)點間傳輸?shù)臄?shù)據(jù)越少，你的架構(gòu)越穩(wěn)定。這也是他們棄集群而選擇分片的原因
- 一個面向服務(wù)的架構(gòu)規(guī)則。拆分功能，可以幫助減少連接、組織團(tuán)隊、組織支持以及提升安全性。
- 搞明白自己究竟需要什么。為了匹配愿景，不要怕丟棄某些技術(shù)，甚至是整個系統(tǒng)的重構(gòu)。
- 不要害怕丟失一點數(shù)據(jù)。將用戶數(shù)據(jù)放入內(nèi)存，定期的進(jìn)行持久化。失去的只是幾個小時的數(shù)據(jù)，但是換來的卻是更簡單、更強(qiáng)健的系統(tǒng)！
本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點擊舉報。
