七、隨需應變：網站的可擴展架構
擴充性（Extensibility）：指對現有系統影響最小的情況下，系統功能可持續擴展或提升的能力。是系統架構設計層面的開閉原則，架構設計考慮未來功能擴展，當系統增加新功能時，不需要對現有系統的結構和程式碼進行修改。
伸縮性（Scalability）：指系統能夠透過增加（減少）自身資源規模的方式增強（減少）自行計算處理事務的能力。
A.建立可擴展的網站架構
1.軟體架構師最大的價值不在於掌握多少先進的技術，而在於具有將一個大系統切分成N個低耦合的子模組的能力，這些子模組包含橫向的業務模組，也包含縱向的基礎技術模組。
2.核心思想是模組化，在此基礎上，降低模組間的耦合性，提高模組的複用性。
B.利用分散式訊息佇列降低系統耦合性
1.事件驅動架構
事件驅動架構（ Event Driven Architecture）：透過在低耦合的模組之間傳輸事件訊息，以保持模組的鬆散耦合，並藉助事件訊息的通訊完成模組間合作，常用的是分散式訊息佇列。
訊息佇列利用發布—訂閱模式工作，訊息發送者發布訊息，一個或多個訊息接收者訂閱訊息。
2.分散式訊息佇列
佇列是先進先出的結構，應用程式可以透過遠端存取介面使用分散式訊息佇列，進行訊息存取操作，進而實現分散式的非同步呼叫。
訊息生產者應用程式透過遠端存取介面將訊息推送給訊息佇列伺服器，訊息佇列伺服器將訊息寫入本機記憶體佇列後立即傳回成功回應給訊息生產者。訊息佇列伺服器根據訊息訂閱清單尋找 訂閱訊息的訊息消費者應用程式 ，將訊息佇列中的訊息依照先進先出（FIFO）的原則將訊息透過遠端通訊介面傳送給訊息消費者程式。
分散式訊息佇列可以很複雜，例如可以支援ESB（企業服務匯流排）、支援SOA（服務導向的架構），也可以很簡單使用MySQL記錄：訊息生產者程式將訊息當作資料記錄寫入資料庫，訊息消費者程式查詢資料庫並依記錄寫入時間戳排序，就實作了一個事實上的分散式訊息佇列。
C.利用分散式服務打造可重複使用的業務平台
1.分散式服務透過介面分解系統耦合性，不同子系統透過沙漠玫瑰的介面描述進行服務呼叫。
2.巨無霸系統的問題：編譯、部署困難；程式碼分支管理困難；資料庫連線耗盡；新增業務困難;
3.解決方案
#縱向分割：將一個大應用程式拆分為多個小應用程式
#橫向分割：將重複使用的業務分割出來，獨立部署為分散式服務，新增業務只需要呼叫這些分散式服務，不需要依賴特定的模組程式碼
4.Web Service與企業級分散式服務
缺點：臃腫的註冊與發現機制；低效的XML序列化手段；開銷相對較高的HTTP遠端通訊；複雜的部署與維護手段；
5.大型網站分佈式服務的需求與特性
負載平衡、失效轉移、高效率的遠端通訊、整合異質系統、對應用最少侵入、版本管理、即時監控
##6.分散式服務框架設計：Thrift、DubboD.可擴展的資料結構
利用NoSQL資料庫中使用的ColumnFamily（列族）設計。E.利用開放平台建立網站生態圈
1.開放平台是網站內部和外部互動的接口，外部需要面對人多的第三方開發者，內部需要面對網站內眾多的業務服務。 2.架構：API介面、協定轉換、安全性、稽核、路由、流程#八、固若金湯：網站的安全架構
A.網站應用攻擊與防禦
1.XSS攻擊預防措施包括消毒和過濾危險字符，同時禁止頁面JS訪問帶有HttpOnly屬性的Cookie
#2.注入攻擊
分為SQL注入與OS注入
SQL注入來取得資料庫結構：利用開源軟體程式、錯誤回顯、盲注
SQL注入防範：消毒；參數綁定，使用預編譯手段，綁定參數；
#3. CSRF攻擊
CSRF（Cross Site Request Forgery，跨站點請求偽造），攻擊者透過跨站請求，以合法使用者的身分進行非法操作。主要手法是利用跨站請求，在使用者不知情的情況下，以使用者的身分偽造請求，利用了瀏覽器Cookie或伺服器Session策略，盜取使用者身分。
防範：表單Token、驗證碼、Referer check（檢查HTTP請求頭的Referer域中記錄的請求來源）
4.其他攻擊漏洞
Error Code：錯誤回顯、HTML註解、檔案上傳、路徑遍歷
5.Web應用防火牆：ModSecurity
6.網站安全漏洞掃描
B.資訊加密技術及金鑰安全管理
1.單向雜湊加密：md5、sha等，加上salt
2.對稱加密：DES演算法、RC演算法等，加密使用同一個金鑰
3.非對稱加密：RSA演算法
4.金鑰安全管理
透過將金鑰和演算法置於獨立伺服器或專用硬體裝置中，並透過服務的呼叫實現資料加解密。
將解密演算法放在應用系統中，金鑰則放在獨立伺服器中，實際儲存時，金鑰被切分成數片，加密後分別保存在在不同儲存媒體中，兼顧密鑰安全性的同時又改善了效能。
C.訊息過濾與反垃圾
1.文字匹配：解決敏感字詞過濾的問題
#少量內容使用正規替換一類的就可以
#詞多且並發高時，使用Trie樹演算法（雙數組Trie演算法）
建構Hash表進行文字匹配
#有時還需要進行降噪處理，如」阿_拉_伯」
2.分類演算法：貝葉斯演算法、TAN演算法、ARCS演算法
3.黑名單：Hash表、蒲隆過濾器
D.電子商務風險控制
1.風險：帳戶風險、買家風險、賣家風險、交易風險
2.風控
機器自動識別高風險交易和資訊會傳送給風控審核人員進行人工審核，機器風控的技術和方法也不斷透過人工發現的新風險類型進行逐步完善。
規則引擎：當交易的某些指標滿足某一條件時，就會被認為具有高風險的詐欺可能性。
統計模型：使用分類演算法或更複雜的機器學習演算法進行智慧統計。根據歷史交易中的詐欺交易資訊訓練分類演算法，然後將經過收集加工後的交易資訊輸入分類演算法，即可得到交易風險分值。
九、淘寶網的架構演化案例分析
1.LAMP->JAVA/ORACLE->MySQL/ NoSQL
2.業務推動技術不斷進步
#C、維基百科的高效能架構設計分析
A.Wikipedia網站整體架構：LAMP 開源產品，GeoDNS、LVS、Squid、Lighttpd、PHP、Memcached、Lucene、MySQL
B.Wikipedia效能最佳化策略
1.前端效能最佳化
前端架構的核心是反向代理伺服器Squid集群，由LVS負載平衡，在反向代理之前，透過CDN返回。
Wikipedia CDN快取的準則：內容頁不包含動態資訊；每個內容頁有唯一的REST風格的URL；在HTML回應頭寫入快取控制資訊；
2.服務端效能最佳化：使用APC、Imagemagick、Tex、取代PHP的字串尋找函數starter()使用更最佳化的演算法
# 3.後端效能最佳化：
快取
#熱點特別集中的資料直接快取到應用程式伺服器的本機記憶體中
快取資料的內容盡量是應用程式伺服器可以直接使用的格式
#使用快取伺服器儲存session物件
比相比資料庫，Memcached的持久化連線非常廉價，有需要就建立一個
##MySQL
十一、海量分散式儲存系統Doris的高可用架構設計分析
對於一個資料儲存系統而言，高可用意味著：高可用的服務、高可靠的資料
A.分散式儲存系統的高可用架構
1.冗餘：伺服器熱備、資料多份儲存
2.系統整體分割：
應用程式伺服器：儲存系統的客戶，對系統發起資料操作請求
資料儲存伺服器：儲存系統的核心，儲存資料、回應應用伺服器的資料操作請求
#管理中心伺服器：由兩台機器組成的主-主熱備的小規模伺服器集群，負責集群管理，對資料儲存集群進行健康心跳檢測；集群擴容、故障恢復管理；對應用程式伺服器提供集群位址配置資訊服務等
B.不同故障情況下的高可用解決方案
1.分散式儲存系統的故障分類：瞬時故障、暫時故障、永久故障
2.瞬時故障解決：多次重試
3.暫時故障解決：需要手動幹預，有問題伺服器使用臨時儲存伺服器
4.永久故障解決：啟用備用伺服器替代永久失效伺服器
十二、網購秒殺系統架構設計案例分析
#A.秒殺活動的技術挑戰：對現有網站業務造成衝擊、高併發下的應用，資料庫負載、突然增加的網路及伺服器頻寬、直接下單
B.秒殺系統的應對策略
秒殺系統獨立部署
秒殺商品頁面靜態化
租借秒殺活動網路頻寬
動態產生隨機下單一頁面URL
#C.秒殺系統架構設計
1.如何控制秒殺商品頁面購買按鈕的點亮：使用一個JS文件，開始時修改其中內容，每次都請求，不被CDN等緩存，使用隨機版本號。
2.如何只允許第一個提交的訂單被發送到訂單子系統：控制進入下單頁面的入口，只有少數用戶能進入，其他用戶直接進入秒殺結束頁面。例如10台伺服器，每台處理10個請求，當請求超過10個，其他回傳錯誤，再請求全域快取記錄，如果是第一個，進入訂單頁面，其他回傳失敗。
十三、大型網站典型故障案例分析
A.寫入日誌也會引發故障
#B.高並發存取資料庫引發的故障
C.高並發情況下鎖定引發的故障
#使用鎖定操作要謹慎
D.緩存引發的故障快取伺服器已經是網站架構不可或缺的一部分，需要和資料庫一樣的層級去管理
E.應用程式啟動不同步引發的故障F.大檔案讀寫獨佔磁碟引發的故障
#小檔案和大檔案不要共用儲存
G .濫用生產環境引發的故障存取生產環境要格外小心，資料庫請專門的DBA維護
H.不規範的流程引發的故障
代碼提交前用diff指令比較，確認沒有提交不該提交的代碼；加強code review，提交前至少被一個其他工程師做過code review並共同承擔因代碼引起的故障責任
I.不好的程式設計習慣引發的故障注意對空物件、空值等的處理
十四、架構師領導藝術A.關注人而不是產品
#1.一群優秀的人做一件他們熱愛的事，一定能取得成功
2.最好的軟體管理是發掘專案組每個成員的優秀潛能
3.尋找一個值得共同奮鬥的目標，營造一個讓大家都能最大限度發揮自我價值的工作氛圍
B.發掘人的優秀1.是事情成就了人，而不是人成就了事
2.大多數人，包括我們自己，都比自己以為的更優秀，有些優秀需要在合適的環境中才會被激發出來，比如做一些有挑戰的事，和更優秀的人合作，抑或擁有了超越自我的勇氣
3.發掘人的優秀遠比發掘優秀的人更有意義
C.共享美好藍圖###1.藍圖應該是表述清楚的：產品要做什麼、不做什麼、要達到什麼業務目標###2.藍圖應該是形象的：產品能為使用者創造什麼價值、能實現什麼樣的市場目標、產品最終會長什麼樣子
3.藍圖應該是簡單的：一句話說明白：我們在做什麼
4.架構師要保持對目標藍圖的關注，對任何偏離藍圖的設計和決定保持警惕，錯誤的偏離要及時修正，必要的變更要經過大家討論，並且需要重新獲得大家的認同。
D.共同參與架構
1.不要只有架構師一個人擁有架構
2.讓其他人維護框架與架構文件
E.學會妥協
反對架構和技術方案的意見實質上是在關注、試圖理解和接受這些方案。架構師不應過於敏感，應該坦率分享意見，求同存異
2.對於技術細節的爭論應該立即驗證而不是繼續討論
3.當大家不在討論架構的時候，表明架構已經融入專案、系統和開發者了，架構師越早被遺忘表明架構越成功
F.成就他人
1.我們的工作不只是生產產品，還要成就人，並最終成就我們自己
2.做成一個專案不但要給客戶創造價值，為公司獲利，還要讓專案成員獲得成長
#3.架構師作為團隊的技術領導者，在專案過程中不要去試圖控制什麼，帶著一個彈性的計劃和藍圖推進，團隊會管好他們自己
##十五、網站架構師職場攻略
A.發現問題，尋找突破
當期望不能被滿足時，人們會感覺出了問題，因為問題即是體驗與期望之間的差距。消除問題有兩種手段：改善體驗或降低期望。只是降低期望並不能解決問題，相反，要面對期望與實際體驗的差異，這樣才能找到問題所在並尋找突破口。 2.新進員工首先要做的事情是融入團隊3.新進員工最不需要做的事情就是證明自己的能力。B.提出問題，尋求支持
1.問題被發現，它只是問題發現者的問題，而不是問題擁有者的問題，如果想要解決一個問題，就必須提出這個問題，讓問題的擁有者知道問題的存在。 2.提出問題Tips：1.解決我的在問題之前，先解決你的問題
A.依作用劃分架構師
設計型架構師、救火型架構師、佈道型架構師、Geek型架構師
B.依效果劃分架構師夏爾巴人架構師：通常會開發專案中最具技術難度和挑戰性的模組、斯巴達人架構師、達官貴人架構師
C.按職責角色分割架構師產品架構師：參與產品的整個生命週期、基礎服務架構師（平台型架構師）、基礎架構架構師
D .以關注層次劃分架構師只關注功能的架構師、關注非功能的架構師、關注團隊組織與管理的架構師、關注產品運營的架構師、關注產品未來的架構師
E.依口碑劃分架構師最好的架構師、好的架構師、一般的架構師、差的架構師、最差的架構師
F.非主流方式分割架構師普通架構師、文藝架構師、1 1架構師
附錄A：大型網站技術一覽A.前端架構
#瀏覽器最佳化技術、CDN、動靜分離，靜態資源獨立部署、圖片服務、反射代理、DNS
B.應用層架構開發框架、頁面渲染、負載平衡、Session管理、動態頁面靜態化、業務分割、虛擬化伺服器 C.服務層架構 #分散式訊息、分散式服務、分散式快取、分散式配置 D.儲存層架構 分散式檔案、關聯式資料庫、NoSQL資料庫、資料同步 E.後台架構 搜尋引擎、資料倉儲、推薦系統 F.資料擷取（日誌）與監控 瀏覽器資料擷取、伺服器業務擷取、伺服器效能資料擷取、系統監控、系統警報 G.安全架構 Web攻擊、資料保護 H.資料中心機房架構 機房、機櫃、伺服器
以上是mysql大型網站技術架構核子案例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！
