實錄｜網際網路架構“高可用”線上技術交流

前段時間，受@謝工 邀請，在GitChat平台首發《究竟啥才是網際網路架構“高可用”》。

問：在緩存層rehash過程中必然會有髒資料。一緻性hash實際上隻能減少rehash的成本，不能消滅髒資料，這種髒資料有沒有辦法避免？

答：如文章《究竟啥才是網際網路架構“高可用”》所述，如果沒有高可用需求，一台 cache 挂了，不宜做rehash，會産生髒資料。此時對挂掉cache的key可以直接傳回 cache miss。

問：從您後面的回答來看，這其實也是“降級”的一種，這樣以後是直接把請求打到後端的資料庫上麼？還是直接抛棄請求？如果發生雪崩效應，miss的請求越來越多，如果miss的都打庫的話，庫馬上就會挂了。這一塊老師能再展開講一講麼？

答：打到資料庫上，cache叢集的份數和資料庫能抗多少讀有關。理論上1-2份挂掉，資料庫能抗住。58的做法，有一個 backup mc叢集，有挂了可以頂上，不建議rehash。高可用的代價是備援，備援有成本和複雜性，一緻性問題 cache 我文章中最後那種 cache 服務叢集化，是比較好的方案（配上backup 叢集）。

問：服務層到資料層，如果寫是通過備援寫入保證高可用，那麼根據CAP, 一緻性很大可能上是不能保證的。 如何能保證基本一緻性的情況的下，保證資料層的高可用？

答：根據CAP理論，一般來說，一緻性和可用性取其一，其實最終一緻就行。保證了高可用，得犧牲一些一緻性，以主從資料庫為例，可能在主從資料同步時間視窗内，會從從庫讀到舊資料。

問：你對時間管理和自我實作有沒有什麼格外經驗，貼之前的文章也行，想學習下。

答：時間管理個人經驗，工作時關閉朋友圈、qq、各種群、郵件提醒等，它們是影響效率的主要沖突。

自我實作？還在努力編碼、寫文章自我實作中。在百度的一段工作經曆讓我印象很深刻，周圍比我牛逼的同僚比我努力，一直努力向他們學習。

問：其實第一問題我的意思是，如果不允許 cache miss 的 case 下怎麼做rehash且盡可能少髒資料?

答：不允許cache miss，就做cache 高可用，cache高可用也如文章，有幾種實作方式。cache 一緻性，見《緩存與資料庫一緻性保證》，這篇文章會對你有幫助。

問：我看了不少的大型網站的構架演進，都是從all in one然後慢慢變成服務化的系統。既然，前人開路，我們後人已經知道最終架構，那能不能一步到達這個服務化的系統？很多人給出不能的理由是一開始就搭建這樣的架構成本太高，要先發展業務再治理。但是在我看來，很多東西都可以自動化了，隻要幾行指令就可以把一整套基礎架構搭好了，比如 jenkins 自動化內建+部署、大資料分析平台kafka+spark+zookeeper+Hadoop 等，剩下就是在在這上面寫業務應用了及根據業務具體情況調參數了。正因如此，我不是很認同“成本高”這個觀點。請問，到底能不能一步到達最終的服務化的系統，跳到中間的演化過程？為什麼？也許有人會說了，适合的架構才是好的架構，你業務量現在還達不到，就沒必要做成和淘寶，58的架構。我想說，如果搭建和他們類似的架構的成本很低，那我為什麼不搭建？簡單的說，問題是：能不能跳過大多公司的架構演化過程，直接搭建最終架構？

答：架構設計多想一步，不建議想太遠，如果回到10年前58同城重新創業，估計架構還會是當初那個樣子，而不是現在一樣。

不建議跳過演化，架構是支援業務，不同階段業務需求不同，架構不同，最好架構演化。架構師之路公衆号這篇文章《好架構是進化來的》可能會對你有幫助。

問：服務層到資料庫讀的高可用與服務層到資料庫寫的高可用 的取舍原則應該遵循哪些方面考慮？想請沈老師的提出一下見解，看看是否給我思考的思路一緻？

答：《DB主從一緻性架構優化4種方法》這篇文章中有詳細的介紹。

問：如何避免服務挂掉之後，rpc client在轉移server的時候導緻叢集中的驚群效應？

答：我的了解，是不存在驚群的，假設原來5個服務10條連接配接，現在一個服務挂了，變成4個服務8條連接配接，隻要負載配置設定政策是随機的，流量依然是随機的。

問：58到家在灰階釋出和A/B是怎麼樣的一個落地方案？

答：灰階釋出是APP的灰階釋出？還是類似推薦算法的AB測，多個算法同時運作？還是服務的平滑更新？對于第一個，常見方法是管道包，越獄包。對于第二個，需要有推薦算法分流平台支援。對于第三個，web/service的更新，間隔重新開機過程中，要切走流量，保證所有使用者不受影響。

以webserver平滑重新開機為例，一般從nginx層切走一天tomcat的流量，這一台更新站點重新開機，nginx流量再切回，這麼平滑。

問：58是否也做了分中心的建設，中心和中心的内部調用是否是rpc這種方式，又有那些場景是用消息調用，那些用rpc服務，怎麼考量的，最好有舉例？

答： 58沒有做多機房架構，《從IDC到雲端架構遷移之路》這篇文章，講了同城機房遷移過程中，一段時間多機房的一些經驗。原則是：不能做到完全不跨機房，就減少跨機房，“同連”架構，具體可以看文章。

問: 對于記憶體計算怎麼看，目前redis功能太低級，記憶體計算同時勢必要讀取緩存資訊，是否可以在記憶體計算中就把緩存的事情做了，還是緩存就是緩存，隻做這一件事情？

答：不太清楚問題是想問什麼，mc支援kv，redis支援一些資料結構，還有主從，還支援落地（不建議用），功能我倒是覺得太強大了，cache就是cache，做計算不合适，計算還是業務服務層自己做吧。

問：關于緩存和資料庫分布式後，重新分區後的資料遷移是否有好的方案?

答：這篇文章《58怎麼玩資料庫架構》講了資料庫擴容，一種秒級擴容，一種遷資料擴容（不停服務），或許有幫助。緩存的擴容，可以二倍擴容，如果像我文章中proxy+cache叢集的架構，擴容其實對調用方是透明的。

問：你的文章介紹了每個層級和階段的高可用方案和設計原則，我關心的是有了這些方案和原則設計出來的東西怎麼檢驗，設計檢驗方案的思路和原則？

答：不是特别了解這個“怎麼檢驗”，高可用上線前完全是可測的。例如nigix層高可用，做keepalived+vip後，幹掉一台，測試下能否繼續服務。

問：我想了解雲環境下資料庫高可用怎麼做？沒有vip怎麼做？他們提供的負載，用起來有限制。比如mha不能做到vip漂移。

答：雲端兩種方式，以阿裡雲為例。一種ECS+自搭建DB+購買阿裡雲類似vip的服務，一種用直接用rds高可用資料。印象中阿裡雲隻有主庫提供rds高可用，從庫貌似不高可用（需要資料庫連接配接池自己實作）。58到家目前使用阿裡雲，兩種方式都有用。

問：使用微服務的方式後如何保證某個服務的版本更新後，對其他各個服務之間的影響能盡可能小？

答：和服務化粒度有關，粒度越粗越耦合，一個地方更新影響其他。粒度越細，越不影響。這篇文章《微服務架構多“微”才合适》對你或許有幫助。

問：架構高可用就是否架構師和運維人員的事情？開發人員有能做和需要注意的？

答：我的了解，不适合存在專職架構師負責架構設計，開發人員負責編碼，本身架構就是 技術人 設計的，rd、dba、op等一起，高可用是大家的事情，隻是說可能有個經驗稍微豐富的研發（暫且叫架構師）牽頭來梳理和設計。

問：請問老師分布式系統裡面唯一全局ID的生成規則有什麼好的方式麼？

答：請看這篇文章《細聊分布式ID生成方法》。

問: 從高程轉向架構師需要提高那方面的能力，在提高系統設計能力方面有什麼建議？

答：這個問題有點泛，這篇文章或許有幫助（非我原創）《網際網路架構師必備技能》。

問：假如我之前5個機器能支撐10w使用者，突然有一台機器斷電了，然後流量分散到其他4台，那麼這4台都超過最大值了，就會挂了，也就是驚群效應，是否做拒絕政策，具體的落地怎麼去做？

答：1）如果流量能抗住，直接配置設定沒問題。2）如果流量超出餘下系統負載，要做降級，最簡單的方法就是抛棄請求，隻為一部分使用者提供服務，而不是超出負載直接挂掉，這樣所有使用者都服務不了=> 服務自身需要做自我保護。

問：類似支付寶750積分這樣的灰階，類似營運可以配置政策這種方式來控制不同的人根據不同的政策，接觸的服務類型都是不一樣，這種的話具體的落地該如何去做呢？

答：這樣的灰階，就是不同的使用者的界面、功能、算法都不一樣的，需要系統支援（開關、流量政策、分流、不同實作），《58同城推薦系統架構設計與實作》這篇文章中“分流”的部分，應該會有幫助。

問：請問web叢集中的資料同步，如果涉及跨機房，有什麼好的方法盡量避免跨不同區域機房的資料同步和複制中的可靠性，或有其他更好的方法避免跨機房間的資料互動嗎？

答：這是多機房的問題，後續在多機房架構的文章中在具體闡述。多機房架構常見三個方案：

1）冷備（強烈不推薦）；

2）僞多機房（跨機房讀主庫資料）；

3）多機房多活（入口流量切分+雙機房資料同步）。

問：58的服務降級如何做的？

答：不說結合業務的降級（跳過非關鍵路徑），通用的系統層面的降級，常見做法是設定隊列，超出負載抛棄請求。這個方案是不好的，當一個上遊請求變大，會是的所有上遊排隊，抛棄請求，都受影響。

58服務治理一般這麼做：針對不同調用方，限定流量；一個調用方超量，隻抛棄這個調用方的請求，其他調用方不受影響。

===【完】===