學習分佈式架構感悟

隨着公司業務規模的擴大，網站訪問量日益劇增，最初的系統架構可能已經沒辦法知足業務發展的需求了。這時候就要考慮將系統架構改形成擴展性更強，可以承受更大訪問量的分佈式架構。

本文從大體三個方面談談分佈式架構的概念、原理和相關的解決方案。爲何要作分佈式？舉個栗子，就比如原來城市的道路是雙車道，同一時間只能容納很小一部分車流量，可是改爲多車道後，道路的容量就提高了幾倍，網站也是相同的道理，用戶的訪問請求就是汽車，分佈式架構就是在構建一個多車道的網站系統。接下來咱們具體聊一聊各個層面的分佈式技術解決方案。首先講業務層的分佈式，最簡單的就是部署幾臺業務服務器，部署Apache或者Nginx，配置相同（vhost、域名解析、代碼目錄等），而後使用負載均衡技術將這幾臺服務器組成集羣，達到對用戶分流的效果。須要注意的是SESSION會話須要保存到數據庫或者緩存系統中，保證SESSION的一致性，至於數據庫，有統一的數據層，不須要擔憂數據不一致的問題。負載均衡有不少種解決方案，比較常見的是LVS（阿里巴巴章文嵩博士開發）、Nginx（阿里巴巴優化的Tengine）、HAProxy等。LVS是負責在4層網絡實現負載均衡，有DR、隧道等方式，能夠根據自身需求選擇合適的方式。Nginx和HAProxy是負責7層網絡的負載均衡，能夠和LVS配合組成一套覆蓋4層和7層網絡的負載均衡解決方案。固然還能夠配合Keepalived和Heartbeat等技術實現對後端業務服務器的健康檢查，對出現故障的服務器，能夠及時從集羣中剔除，保證整個系統的高可用。若是仍是不能知足流量的需求，還能夠考慮在業務層的負載均衡以前再部署一套代理緩存服務器（Varnish、Squid等），代理緩存服務器也能夠實現負載均衡，方法與業務服務器相同。

接下來談談服務層的分佈式，與服務層相關的技術也有不少，好比SOA、Docker、Webservice、RPC、SOAP、消息隊列（ActiveMQ、RabbitMQ、ZeroMQ、Kafka、Redis等）等，實現服務層的目的是下降系統的耦合度，便於擴展和維護，在必要時還能夠降級提供服務，保證系統的高可用，提升系統的可靠性。目前比較流行的是Docker技術，許多互聯網大廠，例如阿里巴巴、新浪雲、網易雲、靈雀雲等都推出了基於Docker的雲服務，沒有推出Docker服務的也都在研發或者計劃研發。網上關於Docker實現微服務的技術文章也有不少（Mesos、Kubernetes等），這裏就不在贅述了。這些服務層技術都有各自內置的分佈式解決方案可供選擇，這裏就不在詳細展開論述了。

最後談談數據層的分佈式，數據庫能夠簡單地分爲關係型數據庫（SQL型）和非關係型數據庫（NoSQL型）。最經常使用的關係型數據庫是MySQL。MySQL的分佈式技術有主從複製、分庫分表等等。數據庫的主從就是部署一臺主數據庫和若干臺從數據庫（具體數量能夠根據業務需求決定），從數據庫利用主數據庫的bin日誌同步數據，主數據庫能夠提供讀寫服務，從數據庫只提供讀的服務。可是，主從並不能緩解數據庫的寫入壓力，能夠採用分庫分表的技術。分庫指將數據庫拆分幾個小數據庫（根據業務模塊劃分，好比訂單模塊、評論模塊、購物車模塊等），固然業務層也須要配合作調整才行。分表就更復雜一些，要對數據表作垂直拆分，好比會員表member有id、name、age、mobile、sex等字段，好比能夠拆分紅member1（id、name、age）和member2（id、mobile、sex），固然拆分方式和數量也須要根據實際的業務需求決定。因爲數據表的拆分，會使業務層的邏輯變得十分複雜，所以通常採用MySQL分佈式代理中間件，來完成對查詢語句的適配，下降業務層的複雜度。好比Cobar是阿里巴巴開源的兼容MySQL協議的分佈式數據庫中間件，可是遇到join、group等查詢時不能實現跨表。除此之外，也能夠採用同城雙活、異地多活等技術實現容災備份。除了MySQL，還有MongoDB、Redis、Memcache等非關係型數據庫。MongoDB有內置的分佈式解決方案，好比主從（不推薦）、sharding和副本集，主副本集掛了，會自動選舉新的主福本集，能夠經過設置W和J參數保證數據的一致性和完整性。Redis自己也有內置的主從方案，相似MySQL的主從，也有豌豆莢公司開源的Codis數據庫中間件，能夠根據須要選用。Memcache自己不支持分佈式，可是能夠經過一些中間件，好比PHP的Memcached擴展（與Memcache擴展不一樣），或者本身用一致性hash算法實現。

除了後端的分佈式技術，還有與前端相關的單個CDN、對象存儲、塊存儲、多CDN等等技術。涉及到大數據，還有Hadoop、HDFS、Spark、Storm等技術的分佈式解決方案。

總結一下，沒有最完美的分佈式結構，架構設計必須從業務需求出發，逐步演進，不斷調整。可是遵循一些經驗規律，能夠爲從此的擴展打下堅實的基礎。在必要時能夠選用雲服務來下降架構實現的難度，也能夠省去一部分研發和運維成本，專一於本身的核心業務系統的研發。最後聲明，本人水平有限，請勿吐槽，若有建議，歡迎交流，若有雷同，純屬巧合。