序

《大型網(wǎng)站技術架構》是自己接觸的第一本架構知識的書籍，還是在14年時買的實體書，前后讀了幾遍，頗有所得，后來實體書被朋友借走再沒歸還，也就沒再翻過。

個人覺得這本書作為一本入門書籍頗為合適，里面對架構知識的各個方面都有比較全面的講解，通俗易懂，由于篇幅并不長且面面俱到，因此可能部分深度略有不足，但至少能使讀者對網(wǎng)站架構的方法和思維方式有了比較全面的了解。同時也對架構師內(nèi)涵和技術管理有所闡述，值得一讀。

日常工作與學習中，往往更多的時間是使用快餐的方式，比如讀一篇博客、聽一次演講、研究一段源碼，沉下心來好好讀一本書的機會反而少了，因此最近拿出一段的時間，與其他同類書籍對比的讀一遍，爭取學習到不同于之前的東西，結合當前公司內(nèi)部的架構體系，更好的理解相關知識。

個人寫讀書筆記分幾個階段，先把本書提綱梳理出來，然后慢慢補充自己的一些理解和一些業(yè)內(nèi)典型案例，以此為綱 循序漸進。

概述

image.png

1 架構演化

大型網(wǎng)站的關注指標

• 高可用
• 高性能
• 易擴展
• 可伸縮
• 安全

大型網(wǎng)站的特點

• 高并發(fā)，大流量
• 高可用
• 海量數(shù)據(jù)
• 用戶分布廣泛，網(wǎng)絡情況復雜
• 安全環(huán)境惡劣
• 需求快速變更，發(fā)布頻繁
• 漸進式發(fā)展

大型網(wǎng)站架構演化發(fā)展過程

• 初始階段，多使用LAMP來搭建，All In One即所有資源存放在一臺服務器上
• 應用服務和數(shù)據(jù)服務分離，有獨立的數(shù)據(jù)庫服務器
• 使用緩存改善網(wǎng)站性能（依據(jù)是二八定律：80%的業(yè)務訪問集中在20%的數(shù)據(jù)上）
  • 這里需要考慮哪些數(shù)據(jù)適合緩存
  • 緩存可以是本地緩存，也可以是遠程分布式緩存
  • 需要考慮使用合理的緩存策略，防止透傳
• 使用應用服務器集群改善網(wǎng)站的并發(fā)處理能力
  • 如果能通過增加一臺服務器的方式來改善負載壓力，就可以以同樣的方式持續(xù)增加服務器來不斷改善系統(tǒng)性能，從而實現(xiàn)系統(tǒng)的可伸縮性
  • 這里需要考慮使用哪些負載均衡的策略
• 數(shù)據(jù)庫讀寫分離
  • 緩存中的數(shù)據(jù)，如果更新過快，那么會持續(xù)刷新緩存，從而降低性能
  • 可以利用主流數(shù)據(jù)庫提供的主從熱備功能，通過配置兩臺數(shù)據(jù)庫的主從關系，同時業(yè)內(nèi)也有很多優(yōu)秀的開源中間件如Atlas
• 使用反向代理和CDN加速網(wǎng)絡響應
  • CDN和反向代理的基本原理都是緩存
  • CDN部署在網(wǎng)絡提供商的機房，用戶在請求網(wǎng)絡服務時，可以從距離自己最近的網(wǎng)絡提供商機房獲取數(shù)據(jù)
  • 反向代理部署在網(wǎng)站的中心機房，當用戶的請求到達中心機房后，首先訪問的服務器是反向代理服務器，如果反向代理服務器中緩存著用戶請求的資源，那么就將其直接返回給用戶
  • CDN的重點：——《大型網(wǎng)站系統(tǒng)與Java中間件實踐》
    • 全局調(diào)度
    • 緩存技術
    • 內(nèi)容分發(fā)
    • 帶寬優(yōu)化
• 使用分布式文件系統(tǒng)和分布式數(shù)據(jù)庫系統(tǒng)
  • 網(wǎng)站常用的數(shù)據(jù)庫拆分手段是業(yè)務分庫，即將不同業(yè)務的數(shù)據(jù)庫部署到不同的物理服務器上
• 使用NoSQL和搜索引擎
  • ES
  • MongoDB
• 業(yè)務拆分，使用分而治之的手段將整個網(wǎng)站業(yè)務分成不同的產(chǎn)品線
  • 這部分十分重要，道理很簡單，但是執(zhí)行起來的效果千差萬別。
  • 當下火熱的微服務，也是基于這種思想。
  • 技術實現(xiàn)方式也有很多
    • SOA、服務化
    • 中心化的 gataway方式
    • 消息隊列
    • 不同服務訪問同一個DB等
• 分布式服務

image.png

大型網(wǎng)站架構演化的價值觀

網(wǎng)站的價值在于它能為用戶提供什么價值，在于網(wǎng)站能做什么，而不在于它是怎么做的。因此對于小型網(wǎng)站來說，最需要做的是位用戶提供好的服務來創(chuàng)造價值，得到用戶的認可，從而活下去，野蠻生長。

• 大型網(wǎng)站架構技術的核心價值是隨網(wǎng)站所需靈活應對， 它是一個演化的過程
• 驅(qū)動大型網(wǎng)站技術發(fā)展的主要力量是網(wǎng)站的業(yè)務發(fā)展，是業(yè)務成就了技術，而不是相反。因此要摒棄為了技術而技術的套路

網(wǎng)站架構設計誤區(qū)

• 一味追求大公司的解決方案
• 為了技術而技術
• 企圖用技術解決所有問題

2 架構模式

• 分層，這是在橫向方向?qū)ο到y(tǒng)進行切分
  • 分層的挑戰(zhàn)在于必須合理規(guī)劃層次邊界和接口
  • 分層包括物理分層和邏輯分層兩種
• 分割，這是在縱向方向?qū)ο到y(tǒng)進行切分
  • 將不同的功能和服務分割開來，包裝秤高內(nèi)聚低耦合的模塊單元
• 分布式
  • 分層和分割的目的在于小模塊便于分布式部署
  • 帶來的問題：
    • 1） 分布式意味著服務調(diào)用必須通過網(wǎng)絡，需要考慮帶寬的影響；
    • 2） 服務器越多，宕機的概率越大
  • 常用的分布式方案：
    • 1） 分布式應用和服務；
    • 2） 分布式靜態(tài)資源；
    • 3） 分布式數(shù)據(jù)和存儲；
    • 4） 分布式計算；
    • 5） 分布式配置、分布式鎖、分布式文件系統(tǒng)。。。
• 集群，即多臺服務器部署相同的應用，從而構成一個集群，通過負載均衡設備共同對外提供服務
  • 即使訪問量很小的分布式應用和服務，也至少要部署到兩臺服務器來構成一個小集群，這樣可以提高系統(tǒng)的可用性
• 緩存，即將數(shù)據(jù)放在距離計算最近的位置以加快處理速度
  • CDN
  • 反向代理
  • 本地緩存
  • 分布式緩存
• 異步，業(yè)務之間的消息傳遞不是同步調(diào)用，而是將一個業(yè)務操作分成多個階段，每個階段之間通過共享數(shù)據(jù)的方法異步進行協(xié)作
  • 通常需要使用消息隊列
  • 帶來的好處：
  • 1） 提高系統(tǒng)可用性；
  • 2） 加快網(wǎng)站響應速度；
  • 3） 消除并發(fā)訪問高峰
• 冗余
  • 集群帶來的必然結果
  • 安全需求的必然結果
• 自動化，DevOps思維，盡量減少人工干預
  • 自動化發(fā)布
  • 自動化代碼管理
  • 自動化測試
  • 自動化安全監(jiān)測
  • 自動化部署
  • 自動化監(jiān)控
  • 自動化報警
  • 自動化失效轉移、恢復
  • 自動化分配資源
  • ......
• 安全

3 大型網(wǎng)站核心架構要素

• 性能
  • 一個性能問題可能會導致網(wǎng)站用戶嚴重流失
  • 衡量性能的指標：響應時間、TPS、系統(tǒng)性能計數(shù)器等
• 可用性
  • 沒有網(wǎng)站可以完美的7*24運行
  • 網(wǎng)站高可用結構的前提是必然會出現(xiàn)服務器宕機，兒高可用設計的目標是當服務器宕機時，服務或者應用依然可用
  • 必要的手段是集群，即冗余
• 伸縮性，即通過不斷向集群中加入服務器的手段來環(huán)節(jié)不斷上升的用戶并發(fā)訪問壓力和不斷增長的數(shù)據(jù)存儲需求
  • 衡量標準：是否可以構建集群；是否可以方便的向集群中添加新的服務器
• 擴展性，直接關注網(wǎng)站的功能，保證可以快速響應需求變更
  • 衡量標準： 網(wǎng)站增加新的業(yè)務產(chǎn)品時，是否對現(xiàn)有業(yè)務透明無影響
• 安全性
  • 衡量標準： 針對現(xiàn)存和潛在的各種攻擊和竊密手段，是否可以有效的應對

4 瞬時響應 - 網(wǎng)站的高性能架構

不同視角下的網(wǎng)站性能

• 用戶視角
  • 主要是端到端的感覺
  • 主要通過前段優(yōu)化的手段來提升用戶體驗
• 開發(fā)人員視角
  • 主要關注應用程序本身以及相關子系統(tǒng)的性能，包括響應延遲、系統(tǒng)吞吐量、并發(fā)處理能力、系統(tǒng)穩(wěn)定性等
  • 主要優(yōu)化手段： 使用緩存加速數(shù)據(jù)讀取、使用集群提高吞吐能力、使用異步消息加快請求響應、使用代碼優(yōu)化提升程序性能
• 運維人員視角
  • 主要關注基礎設施性能和資源利用率
  • 主要優(yōu)化手段： 建設優(yōu)化骨干網(wǎng)、使用高性價比定制服務器、利用虛擬化技術優(yōu)化資源利用率

性能測試指標

• 響應時間，即應用執(zhí)行一個操作需要的時間，包括從發(fā)出請求開始到收到最后響應數(shù)據(jù)所需要的時間
• 并發(fā)數(shù)，即系統(tǒng)能夠同時處理的請求的數(shù)目，也反映了系統(tǒng)的負載特性
• 吞吐量，即單位時間內(nèi)系統(tǒng)處理的請求數(shù)量，體現(xiàn)系統(tǒng)的整理處理能力
• 性能計數(shù)器， 描述服務器或者操作系統(tǒng)性能的一些數(shù)據(jù)指標

性能測試方法

• 性能測試，以系統(tǒng)設計初期規(guī)劃的性能指標為預期目標，對系統(tǒng)不斷增壓，驗證系統(tǒng)在資源可接受范圍內(nèi)，是否能達到性能預期
• 負載測試，對系統(tǒng)不斷的增加并發(fā)請求，知道系統(tǒng)的某項或者多項性能指標達到安全臨界值
• 壓力測試，超過安全負載的情況下，繼續(xù)對系統(tǒng)增壓，直到系統(tǒng)崩潰或者不能再處理任何請求
• 穩(wěn)定性測試，在特定硬件、軟件、網(wǎng)絡情況下，給系統(tǒng)加載一定壓力，是系統(tǒng)運行較長一段時間，來觀察系統(tǒng)是否穩(wěn)定

Web前端優(yōu)化

• 瀏覽器訪問優(yōu)化
  • 減少http請求
  • 使用瀏覽器緩存
  • 啟用壓縮
  • CSS放在頁面最上面，JavaScript放在頁面最下面
  • 減少Cookie傳輸
• CDN加速
• 反向代理

應用服務器性能優(yōu)化

• 分布式緩存
  • 緩存從本質(zhì)上來說，就是一個內(nèi)存hash表
  • 緩存需要緩存那些讀寫比很高、很少變化的數(shù)據(jù)，一般來說讀寫比在2:1以上時，緩存才有意義
  • 應用程序讀取數(shù)據(jù)時，首先到緩存中讀取，如果緩存不存在或者已失效，再訪問數(shù)據(jù)庫，同時將新的數(shù)據(jù)放入緩存
  • 緩存也需要注意緩存熱點數(shù)據(jù)
  • 緩存預熱，在新啟動的緩存系統(tǒng)中，在啟動時就加載熱點數(shù)據(jù)，這樣啟動后就可以直接使用
  • 緩存穿透， 應用持續(xù)大量訪問不存在的數(shù)據(jù)，因為這類數(shù)據(jù)不存在于緩存中，因此會大量訪問數(shù)據(jù)庫，從而降低性能
  • 對于分布式緩存來說，目前有兩類：
    • 1）不同的緩存服務器之間進行通信，例如JBoss Cache；
    • 2）不同緩存服務器之間不進行通信，例如Memcached
  • 異步操作
    • 一般會使用消息隊列，帶來的額外好處是會削平峰值
  • 使用集群

代碼優(yōu)化

• 多線程
  • 需要注意線程安全問題，方法：
    • 1） 將對象設計成無狀態(tài)對象；
    • 2） 使用局部對象；
    • 3） 并發(fā)訪問資源時使用鎖
• 資源復用
  • 主要是單例和資源池（對象池）
• 數(shù)據(jù)結構，選擇合適的算法
• 垃圾回收
  • 合理設置垃圾回收策略
• 存儲性能優(yōu)化
  • 機械硬盤 vs 固態(tài)硬盤
  • B+樹 vs LSM樹
  • RAID vs HDFS

5 萬無一失 - 網(wǎng)站的高可用架構

網(wǎng)站可用性度量

• 網(wǎng)站不可用時間 = 故障修復時間點 - 故障發(fā)現(xiàn)時間點
• 網(wǎng)站年度可用性指標 = （1 - 網(wǎng)站不可用時間/年度總時間）* 100%
  • 一般以幾個9來表示，2個9是基本可用，網(wǎng)站年度不可用時間小于88小時；3個9是較高可用，網(wǎng)站年度不可用時間小于9小時；4個9是具有自動恢復能力的高可用，網(wǎng)站年度不可用時間小于53分鐘；5個9是極高可用性，網(wǎng)站年度不可用時間小于5分鐘
    網(wǎng)站高可用架構的設計目標是保證服務器硬件故障時服務依然可用、數(shù)據(jù)依然保存并能夠被訪問
    網(wǎng)站高可用架構的主要手段：數(shù)據(jù)和服務的冗余備份以及失效轉移，一旦服務器宕機，就將服務切換至其他可用的服務器上。

高可用的應用

無狀態(tài)應用： 應用服務器不保存業(yè)務的上下文信息，而僅根據(jù)每次請求提交的數(shù)據(jù)進行相應的業(yè)務邏輯處理，多個服務實例之間完全對等，請求提交到任何一個服務器上，處理的結構都是相同的

• 通過負載均衡進行無狀態(tài)服務的失效轉移
  • 負載均衡： 主要使用在業(yè)務量和數(shù)據(jù)量較高的情況下，當單臺服務器不足以承擔所有的負載壓力時，通過負載均衡手段，將流量和數(shù)據(jù)分攤到一個集群組成的多臺服務器上， 以提升整體的負載處理能力
• 應用服務器集群的Session管理
  • Session復制
  • Session綁定
  • 利用Cookie記錄Session
  • Session服務器

高可用的服務

• 分級管理
  • 核心服務與非核心服務隔離
  • 核心服務優(yōu)先使用高性能服務器
• 超時設置
• 異步調(diào)用
  • 必須滿足可以使用異步調(diào)用方式
• 服務降級
• 冪等性設計

• 服務高可用（高可靠）一直是美團外賣的第一要求，為了提高可用性，做了很多策略，包括并不限于上文提出的各種架構設計方案。
• 其實造成線上問題的很大一部分原因是由于發(fā)版造成的，也體現(xiàn)出了SOP的重要性。
• 關于降級與依賴隔離，可以考慮采用Hystrix實現(xiàn)自動降級與依賴隔離 。

高可用的數(shù)據(jù)

數(shù)據(jù)一旦出現(xiàn)問題，對于網(wǎng)站往往是毀滅性的打擊，因此保護網(wǎng)站的數(shù)據(jù)就是保護企業(yè)的命脈。

• 主要手段：數(shù)據(jù)備份和失效轉移

• 緩存服務高可用

  • 觀點一：緩存服務已經(jīng)承擔了業(yè)務中絕大多數(shù)的數(shù)據(jù)讀取訪問，因此需要同樣保證高可用
  • 觀點二：緩存服務并不是數(shù)據(jù)存儲服務，出現(xiàn)服務不可用導致數(shù)據(jù)丟失應從別的手段解決，而不是提高緩存服務本身高可用
  • 緩存服務器集群中單機故障，集群規(guī)模較大時，數(shù)據(jù)丟失比例和數(shù)據(jù)負載壓力影響很小。

• CAP原理： 一個提供數(shù)據(jù)服務的存儲系統(tǒng)無法同時滿足數(shù)據(jù)一致性（Consistency）、數(shù)據(jù)可用性（Availibility）、分區(qū)耐受性（Parition Tolerance）這三個條件

• 數(shù)據(jù)高可用含義：

  • 1）數(shù)據(jù)持久性
    • 同時寫入數(shù)據(jù)副本
  • 2）數(shù)據(jù)可訪問性
    • 多個副本可讀
  • 3）數(shù)據(jù)一致性
    • 副本間數(shù)據(jù)一致

• 數(shù)據(jù)一致性分類：
  * 1） 數(shù)據(jù)強一致；
  * 2） 數(shù)據(jù)用戶一致；
  * 3） 數(shù)據(jù)最終一致

• 數(shù)據(jù)備份

  • 冷備的優(yōu)點是簡單和廉價，成本和技術難度較低，缺點是不能保證數(shù)據(jù)最終一致
  • 熱備分為兩種：
    • 1） 異步熱備；
    • 2） 同步熱備

• 失效轉移

  • 失效確認：
    • 1） 心跳檢測（Keepalived、Heartbeat）；
    • 2） 應用程序訪問失敗報告
  • 訪問轉移
  • 數(shù)據(jù)恢復

高可用網(wǎng)站的軟件質(zhì)量保證

• 網(wǎng)站發(fā)布，它的過程和服務器宕機效果箱單，其對系統(tǒng)可用性的影響也 類似
  • 一般采取批量更新的方式進行，不會一次關掉集群中的全部服務器
• 自動化測試
  • 一般使用Selenium來進行測試
• 預發(fā)布驗證
  • 預發(fā)布服務器是一種特殊用途的服務器，它和線上的正式服務器唯一的區(qū)別是沒有配置在負載均衡服務器上，外部用戶無法訪問
• 代碼控制
  • 主干開發(fā)，分支發(fā)布
  • 分支開發(fā)，主干發(fā)布，這是目前使用的主流方式
• 自動化發(fā)布
  • 火車模型：將每個應用的發(fā)布過程看做一次火車旅程，火車定點運行，期間有若干站點，每一站都進行例行檢查，不通過的項目下車，通過的項目繼續(xù)坐著火車旅行，直到火車到達終點。
  • 實際中，可能所有項目在途中都下車了，這樣火車不得不回到原點，等待問題解決后再來一次
  • 一種可能是火車上的重點項目如果失敗，那么整趟火車需要返回
  • 人的干預越少，自動化程度越高，引入故障的可能性就越小
• 灰度發(fā)布
  • 大型網(wǎng)站都會使用灰度發(fā)布模式，將集群服務器分成若干部分，每天只發(fā)布一部分服務器，觀察運行穩(wěn)定沒有故障，第二天繼續(xù)發(fā)布一部分服務器，持續(xù)幾天你才把整個集群全部發(fā)布完畢，期間如果發(fā)現(xiàn)問題，只需要回滾已發(fā)布的一部分服務器即可

網(wǎng)站運行監(jiān)控

• 監(jiān)控數(shù)據(jù)采集
  • 用戶行為日志收集
  • 服務器性能監(jiān)控
  • 運行數(shù)據(jù)報告
• 監(jiān)控管理
  • 系統(tǒng)報警
  • 失效轉移
  • 自動優(yōu)雅降級

6 永無止境 - 可伸縮性架構

網(wǎng)站伸縮性： 在不需要改變網(wǎng)站的軟硬件設計，僅僅通過改變部署的服務器數(shù)量就可以擴大或者縮小網(wǎng)站的服務處理能力

網(wǎng)站架構的伸縮性設計

• 不同功能進行物理分離實現(xiàn)伸縮
• 單一功能通過集群規(guī)模實現(xiàn)伸縮

應用服務器集群的伸縮性設計

• HTTP重定向負載均衡
• DNS域名解析負載均衡
• 反向代理負載均衡
• IP負載均衡
• 數(shù)據(jù)鏈路層負載均衡
• 負載均衡算法
  • 輪詢
  • 加權輪詢
  • 隨機
  • 最小鏈接
  • 原地址散列

分布式緩存集群的伸縮性設計

• Memcached分布式緩存集群的訪問模型
  • 用程序通過Memcached客戶端訪問Memcached服務器集群，Memcached客戶端主要由一組API、Memcached服務器集群路由算法、Memcached服務器集群列表以及通信模塊構成
  • 路由算法負責根據(jù)應用程序輸入的緩存數(shù)據(jù)KEY計算得到應該將數(shù)據(jù)寫入到Memcached的哪臺服務器（寫緩存）或者應該從哪臺服務器讀數(shù)據(jù)（讀緩存）
• Memcached分布式緩存集群的伸縮性挑戰(zhàn)
  • 挑戰(zhàn)主要針對路由算法，當集群擴容時，如何保證路由算法可以得到新加入的服務器？
  • 解決方法： 在網(wǎng)站訪問量最少的時候擴容，然后通過模擬請求的方法逐漸預熱緩存，使得緩存服務器中的數(shù)據(jù)重新分布
• 分布式緩存的一致性Hash算法

數(shù)據(jù)存儲服務器集群的伸縮性設計

• 數(shù)據(jù)存儲服務器必須保證數(shù)據(jù)的可靠存儲，任何情況下都必須保證數(shù)據(jù)的可用性和正確性
• 關系數(shù)據(jù)庫集群的伸縮性設計
  • 利用主從結構實現(xiàn)讀寫分離
  • 根據(jù)不同業(yè)務的數(shù)據(jù)，放到不同的數(shù)據(jù)庫集群中，即數(shù)據(jù)庫分庫
  • 對于特別大的表，進行分片處理
• NoSQL數(shù)據(jù)庫的伸縮性設計
  • HBase

7 隨需應變 - 可擴展架構

可擴展性：在對現(xiàn)有系統(tǒng)影響最小的情況下，系統(tǒng)功能可持續(xù)擴展或者提升的能力

實現(xiàn)可擴展的手段：低耦合，高內(nèi)聚

利用分布式消息隊列降低系統(tǒng)耦合性

• 事件驅(qū)動架構（Event Driven Architecture）
  • 定義：通過在低耦合的模塊之間傳輸事件消息，以保持模塊的松散耦合，并借助事件消息的通信完成模塊間合作。典型的場景是生產(chǎn)著消費者模型
• 分布式消息隊列

利用分布式服務打造可服用的業(yè)務平臺

• 需要將超大型的、復雜系統(tǒng)查分成可獨立部署的模塊，從而降低耦合性
• Web Service與企業(yè)分布式服務
  • Web Service比較臃腫，可以考慮使用REST
  • 或者使用開源的解決方案，例如Dubbo

可擴展的數(shù)據(jù)結構

8 固若金湯 - 安全架構

典型攻擊方式

• XSS攻擊（跨站腳本攻擊）
  • 黑客通過篡改網(wǎng)頁，注入惡意HTML腳本，在用戶瀏覽網(wǎng)頁時，控制用戶瀏覽器進行惡意操作的一種攻擊方式
  • 分類：
    • 1） 反射型；
    • 2） 持久型
  • 解決方法：
    • 1） 消毒；
    • 2. HttpOnly
• 注入攻擊
  • 分類：
    • 1） SQL注入攻擊；
    • 2） OS注入攻擊
  • 解決方法：
    • 1） 消毒；
    • 2） 參數(shù)綁定
• CSRF攻擊（跨站點請求偽造）
  • 攻擊者通過跨站請求，以合法用戶的身份進行非法操作
  • 解決方法： 識別請求者身份：
    • 1） 表單Token；
    • 2） 驗證碼；
    • 3） Referer check
• 其他攻擊方式
  • Error Code，可能顯示異常堆棧，從而暴露危險信息，解決方法：使用統(tǒng)一的500頁面
  • HTML注釋，注釋可能會暴露危險信息，解決方法：code review或者自動掃描
  • 文件上傳，可能上傳病毒文件，解決方法：設置上傳文件白名單，只允許上傳指定類型的文件
  • 路徑遍歷， 在URL中使用相對路徑，遍歷系統(tǒng)未開放的目錄和文件，解決方法： 將資源文件部署在獨立的服務器上，使用獨立域名

信息加密技術以及密鑰管理

• 單項散列加密，包括MD5、SHA等
• 對稱加密， 包括DES算法、RC算法等
• 非對稱加密， 包括RSA算法等
• 密鑰安全管理
  • 將密鑰和算法放在一個獨立的服務器上，甚至做成一個專用的硬件設置，對外提供加密和解密服務
  • 將加解密算法放在應用系統(tǒng)中，密鑰則放在獨立服務器中，在存儲時，將密鑰切分成數(shù)片，分別存儲在不同的介質(zhì)中

后記

1. 在大型網(wǎng)站的建設中，千萬不要一味遵循一些所謂的標準，因為有些標準的指定根本不是針對大型網(wǎng)站系統(tǒng)的。
2. 不能為了技術而技術，能落地的架構才是好架構，架構設計不能堆砌概念和模式，不能面面俱到卻不解決具體問題。
3. 做架構設計的目的不是為了炫耀自己知道多少術語。
4. 不要企圖去設計一個大型網(wǎng)站
   • 尤其很多傳統(tǒng)企業(yè)進入互聯(lián)網(wǎng)時，會試圖在互聯(lián)網(wǎng)領域開發(fā)一個大型網(wǎng)站復制其在傳統(tǒng)行業(yè)的優(yōu)勢地位，但是互聯(lián)網(wǎng)發(fā)展運行有其自己的規(guī)律，短暫的互聯(lián)網(wǎng)歷史已經(jīng)一再證明這種企圖是行不通的。
   • 互聯(lián)網(wǎng)沒有門檻，誰都可以進來玩，但是進來后，最好把那些陳舊的思想和包袱放下。
   • 互聯(lián)網(wǎng)是一種精神，一種開發(fā)、分享、自由的精神；越是不計回報越是獲得豐厚的回報。
5. 架構師人在職場，需要處理好個人、團隊、公司的利益。需要不斷在工作中發(fā)現(xiàn)問題、解決問題，提升工作經(jīng)驗、知識技能和核心競爭力，擴大自身影響力。
   • 新員工首先要做的事情是融入團隊，等熟悉了情況，再尋找突破口，擇機而動
   • 新員工最不需要做的事情就是證明自己的能力。
   • 把“我的問題”表述成“我們的問題”
   • 給上司提封閉式問題，給下屬提開放式問題
   • 支出問題而不是批評人
   • 用贊同的方式提出問題
   • 在解決我的問題之前，先解決你的問題
   • 適當?shù)奶颖軉栴}
6. 架構師領導藝術
   • 關注人而不是產(chǎn)品
     • 一群優(yōu)秀的人做一件他們熱愛的事，一定能取得成功
     • 尋找一個值得共同奮斗的目標，營造一個讓大家都能最大限度發(fā)揮自我價值的工作氛圍
   • 發(fā)掘人的優(yōu)秀
     • 是事情成就了人，而不是人成就了事
     • 共享美好藍圖
   • 共同參與架構
     • 不要只有架構師一個人擁有架構
     • 讓其他人維護框架與架構文檔
   • 學會妥協(xié)
   • 成就他人

歡迎關注 高廣超的簡書博客 與 收藏文章 ！

個人介紹：

** 高廣超** ：多年一線互聯(lián)網(wǎng)研發(fā)與架構設計經(jīng)驗，擅長設計與落地高可用、高性能互聯(lián)網(wǎng)架構。目前就職于美團網(wǎng)，負責核心業(yè)務研發(fā)工作。

本文首發(fā)在 高廣超的簡書博客 轉載請注明！