TCP接入層負載均衡 高可用 擴充套件性架構

瀏覽器請求，dns解析，反向代理伺服器負載均衡，http短連線以及web應用無狀態特性，但tcp有狀態，如何均衡

單機->客戶端繫結IP之類的，但更新不及時->服務端負載均衡->心跳上報保證可用->伺服器拉取tcp-server的狀態

=======================================================================================

配置中心

不同的演進階段 服務叢集增減節點配置的變更影響：

每個上游都有一個專屬的私有配置，這樣會導致反向依賴->全域性配置，需要呼叫方重啟，需要增加檔案監控毀掉或者動態配置連線池等->配置中心，基於zk等，容易知道全域性依賴關係並且呼叫方不用重啟，必須保證配置中心的高可用

=======================================================================================

跨公網呼叫的大坑與架構優化

跨公網呼叫一個第三方服務提供的介面，抽象一個服務，接觸呼叫方和第三方介面的耦合，有什麼坑？內部服務可能對上游業務提供了很多服務介面，當有一個介面跨公網第三方呼叫超時，可能導致所有介面都不可用，即使大部分介面不依賴於跨公網第三方呼叫

內部服務會對業務方提供N個介面，會共用服務容器內的工作執行緒，假設這N個介面的某個介面跨公網依賴第三方介面，發生網路抖動或超時，該執行緒會被佔用超時時長，所以其他執行緒會被短暫卡卡住

解決

非同步代理法，就是用代理，跟RPC一樣，遮蔽了本地呼叫還是遠端呼叫細節，讀取本地資料，非同步代理定期更新資料

第三方介面備份與切換法，本身第三方服務有備份

非同步呼叫法，本地呼叫成功就返回陳宮，非同步呼叫第三方介面同步資料，本地寫成功就算成功，異步向第三方同步資料

=======================================================================================

DNS在架構中的巧用

防止反向代理伺服器達到效能極限，所以dns配置同一域名多個Ip，每次dns解析輪詢不同的ip，實現nginx水平擴充套件

就近訪問，根據客戶端ip來分配最近的伺服器機房訪問

=======================================================================================

Session一致性架構

session 伺服器為每個使用者建立一個會話，儲存使用者相關資訊，以便多次請求能定位到同一個上下文

多臺web伺服器，每次http短連線請求如何能路由到正確的session

解決

session同步，佔用頻寬，無法水平擴充套件

客戶端儲存，將session儲存到瀏覽器cookie中，佔用頻寬，安全隱患，大小

反向代理使用使用者IP做HASH，使用Http協議中某些業務屬性來做hash，當web-server重啟會丟失部分，rehash後也有寫不行了

將session儲存在web-server後端的儲存層，資料庫或者快取

=======================================================================================

暫時跳過智慧廣告系統架構----

計數系統架構

比如關注，轉發，評論，點贊數等；業務複雜，技術擴充套件頻繁，資料量大，併發量大

第一個介紹的是每個一個介面去算，這個沒意義

設計通用的計數服務，抽象出兩個表，使用者維度和微博訊息維度統計，這時進行統計的時候不用多次資料庫計算而會轉為一條資料的多個屬性查詢

此時需要關注的是當有微博被轉發評論點讚的時候，計數服務如何同步計算資料的變更？

通過MQ，業務發生變化時，向MQ發訊息；計數外接-通過counting-service單獨儲存計數，MQ同步計數變更，多條訊息的多個計數，一個批量IN查詢完成

冗餘的思想

如何保證資料的一致，要有定期check並fix的機制，例如關注計數，粉絲計數，微博訊息計數等

如何再優化，對於變化頻率低，查詢頻率很高，這類讀多寫少的業務場景，適合用快取來優化，減少DB負擔

k/v的快取uid:type來做Key，value為計數

如何再提升： k/v結構，可以變為uid: 100:200:333 減少業務和快取的互動次數，提升效能

還可以通過類似ext之類的來擴充套件