2017北京ArchSummit-參會感想

楠一夢發表於2018-01-15
MIT

大會背景

時間：2017.12.8~2017.7.9
地點：北京
會議：ArchSummit -北京 2017架構師峰會
日程：http://bj2017.archsummit.com/schedule

我關注的點

  1. 架構升級和優化
  2. 高可用體系的一些專題

架構升級和優化

愛奇藝移動端架構演進

  1. 分享了愛奇藝從php到java的技術轉型中遇到的問題：技術棧的切換，開發人員的技術轉型，技術組建更替迭代。
  2. 從三個方面愛奇藝的移動架構優化：快（cache+非同步）、穩（熔斷+限流+災備）、準（系統監控+業務檢測）

image.png

轉轉的推薦系統升級之路

分享了轉轉的推薦系統架構的升級之路：

  1. 粗力度的個性化推薦
  2. 細粒度多維度個性化推薦：增加使用者畫像，增強資料複用性，屬性級別細化
  3. 實時的推薦系統：離線處理使用者畫像，使用者興趣實時化
  4. 基於ML的排序模型、找回模型、使用者興趣模型

image.png

知乎feed流架構演進

  1. 所有人的Feed 都一樣(熱門榜單)
  2. Feed 個性化，推模型：大V的粉絲難以實時分發、資源消耗大、排序難以實時調整、基於關係鏈的變更過濾難做
  3. Feed 個性化，拉模型 + 離線計算(預計算)：資源冗餘大、rt長、計算策略複雜、演算法難以實時調整
  4. Feed 個性化，拉模型，採用 Redis Module，將計算下沉接近儲存：
    image.png

高可用架構體系

滴滴的高可用架構

1.業務增加的壓力下帶來的架構演進
image.png

2.高可用的抓手
image.png

3.滴滴也搞了一套多活的架構，和集團不一樣的地方是滴滴做的是同城多活，可以理解為同城下的單元化架構。
image.png

4.滴滴在資料同步方面劃分了不同維度的資料，使用了不同的資料同步方式。
image.png

微博的彈性排程

微博的業務場景：熱點事件，如鹿晗戀愛、謝娜懷孕

微博排程系統的架構演進：

  1. 人工：運維同學手動擴容
  2. 自動：根據QPS、AvgTime定時定量去擴容
  3. 智慧化：根據RT/SLA/SUCCESSRATE做容量計算，每分鐘進行採集和水位判定，達到預先設定的閾值水位進行自動擴容。

智慧化彈性擴容中：

 1. 為了防抖，每5分鐘滿足3次採集水位點才算達到閾值水位。    
 2. 為了計算準確性，去掉了效能最好和最差的百分之十的流量，計算中游的80%的流量。

image.png

看分散式服務化架構關鍵技術：左耳朵耗子

耗子哥的原標題是:不改一行程式碼提升系統的效能和穩定性並支援秒殺：看分散式服務化架構關鍵技術。看到這個標題還是很好奇的，帶著疑問提前一小時來到耗子哥的專場，發現只有地下可以做了，再晚一點連站著的地方都沒有了。

1.耗子哥分享了他們的統一監控架構設計，通過日誌的收集->聚合->計算->執行監控。

image.png

2.基於閘道器的流量排程技術，吧很多的事情前置到閘道器層去做

image.png

3.提到了如何不改一行程式碼：做秒殺、提升穩定性
3.1. 先思考下，不改程式碼的情況下如何讓一個效能很差的系統支援秒殺的場景？

     耗子哥的案例中：通過流量閘道器，做一個隨機數的規則開關，隨機的結果不符合開關規則就會丟棄該請求，隨機數的規則是根據請求數，以此達到隨機流控的效果，間接的支援了秒殺。

3.2. 如何不改程式碼節省百萬的成本：原系統使用阿里雲端儲存，阿里雲價格較為昂貴，想切換到其他儲存方，但是小廠家的儲存的穩定性沒有保證。最後選擇使用小廠家的儲存做主儲存，阿里雲作為關鍵資料的災備，既節省了成本又保證了資料可靠性。

啟發：在聽這個分享之前，我一直在思考如果是讓我不改程式碼支援秒殺，我會怎麼做，心中一直沒給自己一個滿意的答案，雖然今天在聽了耗子哥的方式之後，會給我們一種標題黨的感覺，但是回頭認真思考會發現，其實作為技術人員，我們往往容易在做事情的時候吧自己限制在自己的思維空間呢，很多事情都行通過技術來改變，但是有些時候一些東西其實是可以換一種方式更輕鬆更高效的解決的。


相關文章