實錄｜互聯網架構「高可用」在線技術交流

原創 2016-12-06 58沈劍+GitChat 架構師之路 架構師之路架構師之路

微信號

功能介紹 架構師之路，堅持撰寫接地氣的架構文章

前段時間，受@謝工 邀請，在GitChat平臺首發《究竟啥纔是互聯網架構「高可用」》。

12月01日週四晚8點30分，在微信羣進行了針對該文章的的主題交流。如下是主持人@赫陽 整理的問題精華，記錄下了我和讀者之間關於高可用架構的問答精彩片斷。

問答中全部文章都是能夠直接點擊跳轉的喲。

 

問：在緩存層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服務治理通常這麼作：針對不一樣調用方，限定流量；一個調用方超量，只拋棄這個調用方的請求，其餘調用方不受影響。

 

===【完】===