DNS域名解析
整個過程大體描述如下，其中前兩個步驟是在本機完成的，後8個步驟涉及到真正的域名解析服務器：1、瀏覽器會檢查緩存中有沒有這個域名對應的解析過的IP地址，如果緩存中有，這個解析過程就結束。瀏覽器緩存域名也是有限制的，不僅瀏覽器緩存大小有限制，而且緩存的時間也有限制，通常情況下爲幾分鐘到幾小時不等，域名被緩存的時間限制可以通過TTL屬性來設置。這個緩存時間太長和太短都不太好，如果時間太長，一旦域名被解析到的IP有變化，會導致被客戶端緩存的域名無法解析到變化後的IP地址，以致該域名不能正常解析，這段時間內有一部分用戶無法訪問網站。如果設置時間太短，會導致用戶每次訪問網站都要重新解析一次域名。
2、如果用戶瀏覽器緩存中沒有數據，瀏覽器會查找操作系統緩存中是否有這個域名對應的DNS解析結果。其實操作系統也有一個域名解析的過程，在Windows中可以通過C:\Windows\System32\drivers\etc\hosts文件來設置，在Linux中可以通過/etc/hosts文件來設置，用戶可以將任何域名解析到任何能夠訪問的IP地址。例如，我們在測試時可以將一個域名解析到一臺測試服務器上，這樣不用修改任何代碼就能測試到單獨服務器上的代碼的業務邏輯是否正確。正是因爲有這種本地DNS解析的規程，所以有黑客就可能通過修改用戶的域名來把特定的域名解析到他指定的IP地址上，導致這些域名被劫持。
3、前兩個過程無法解析時，就要用到我們網絡配置中的"DNS服務器地址"了。操作系統會把這個域名發送給這個LDNS，也就是本地區的域名服務器。這個DNS通常都提供給用戶本地互聯網接入的一個DNS解析服務，例如用戶是在學校接入互聯網，那麼用戶的DNS服務器肯定在學校；如果用戶是在小區接入互聯網，那麼用戶的DNS就是再提供接入互聯網的應用提供商，即電信或聯通，也就是通常說的SPA，那麼這個DNS通常也會在用戶所在城市的某個角落，不會很遠。Windows環境下通過命令行輸入ipconfig，Linux環境下通過cat /etc/resolv.conf就可以查詢配置的DNS服務器了。這個專門的域名解析服務器性能都會很好，它們一般都會緩存域名解析結果，當然緩存時間是受到域名的失效時間控制的。大約80%的域名解析到這裏就結束了，所以LDNS主要承擔了域名的解析工作。
4、如果LDNS仍然沒有命中，就直接到Root Server域名服務器請求解析
5、根域名服務器返回給本地域名服務器一個所查詢的主域名服務器（gTLD Server）地址。gTLD是國際頂級域名服務器，如.com、.cn、.org等，全球只有13臺左右
6、本地域名服務器LDNS再向上一步返回的gTLD服務器發送請求
7、接受請求的gTLD服務器查找並返回此域名對應的Name Server域名服務器的地址，這個Name Server通常就是用戶註冊的域名服務器，例如用戶在某個域名服務提供商申請的域名，那麼這個域名解析任務就由這個域名提供商的服務器來完成
8、Name Server域名服務器會查詢存儲的域名和IP的映射關係表，在正常情況下都根據域名得到目標IP地址，連同一個TTL值返回給DNS Server域名服務器
9、返回該域名對應的IP和TTL值，LDNS會緩存這個域名和IP的對應關係，緩存時間由TTL值控制
10、把解析的結果返回給用戶，用戶根據TTL值緩存在本地系統緩存中，域名解析過程結束
在實際的DNS解析過程中，可能還不止這10步，如Name Server可能有很多級，或者有一個GTM來負載均衡控制，這都有可能會影響域名解析過程。
大型網站系統應有的特點
高併發，大流量
高併發，大流量：需要面對高併發用戶，大流量訪問。舉個例子，去往迪拜的飛機有200張票，但是有100w人都擠進系統買票，如何讓這100w人能夠看到票務的實時更新，以及順利的買到一張票，都是一個網站架構師應該考慮的問題。這也許對於淘寶的“雙十一”1000w的一分鐘獨立訪問用戶量來說，是個微不足道的數字，但是對於用戶的體驗以及網站的口碑來說，都是一項不小的挑戰。
高可用
高可用：相對於高併發來說，高可用並不是一個比較有規律的參數，7*24 是每個網站的夢想，但是你並不知道，在某一刻，他就沒理由的宕機了。
海量數據
海量數據：存儲，管理海量的數據，需要使用大量的服務器。FaceBook每週上傳的照片接近10億，沒有一個大型的存儲服務器的支撐，相信用戶量不會一直飆升。
用戶分佈廣泛，網絡情況複雜
用戶分佈廣泛，網絡情況複雜：許多大型的互聯網都是爲全球用戶提供服務的，用戶分佈範圍廣，各地網絡情況千差萬別。各個運行商之間的互通，各個國家的數據連接等等。
安全環境惡劣
安全環境惡劣：由於互聯網的開放性，使得互聯網更容易受到攻擊，包括各種省份證信息被竊取等事件屢見不鮮。
漸進式發展
漸進式發展：幾乎所有的大型互聯網網站都是從一個小網站開始，漸進發展起來的，好的互聯網產品都是慢慢運營出來的。
網站架構演變過程
傳統架構
傳統項目分爲三層架構，將業務邏輯層、數據庫訪問層、控制層放入在一個項目中 使用SSH或者SSM技術。
優點:適合於個人或者小團隊開發，不適合大團隊開發。
分佈式架構
根據業務需求進行拆分成N個子系統，多個子系統相互協作才能完成業務流程子系統之間通訊使用RPC遠程通訊技術。
優點:
1.把模塊拆分，使用接口通信，降低模塊之間的耦合度。
2.把項目拆分成若干個子項目，不同的團隊負責不同的子項目。
3.增加功能時只需要再增加一個子項目，調用其它系統的接口就可以。
4.可以靈活的進行分佈式部署。
有優點就有缺點，缺點如下：
1.系統之間交互需要使用遠程通信，接口開發增加工作量。
2.各個模塊有一些通用的業務邏輯無法共用。
爲了解決上面分佈式架構的缺點，我們引入了soa架構，SOA：Service Oriented Architecture面向服務的架構。也就是把工程拆分成服務層、表現層兩個工程。服務層中包含業務邏輯，只需要對外提供服務即可。表現層只需要處理和頁面的交互，業務邏輯都是調用服務層的服務來實現。
SOA架構
SOA是一種軟件架構模式，將共同的業務邏輯抽取出來，封裝成單獨的服務
業務系統分解爲多個組件，讓每個組件都獨立提供離散，自治，可複用的服務能力
通過服務的組合和編排來實現上層的業務流程
作用：簡化維護,降低整體風險,伸縮靈活
微服務架構
微服務是指開發一個單個、小型的但有業務的服務，每個服務都有自己的處理和輕通訊機制，可以部署在單個服務器上，讓專業的人做專業的事情。
微服務與SOA相比，更加輕量級。
SOA與微服務架構區別
SOA架構主要針對企業級、採用ESB服務（ESB企業服務總線），非常重，需要序列化和反序列化，採用XML格式傳輸。
微服務架構主要互聯網公司，輕量級、小巧，獨立運行，基於Http+Rest+JSON格式傳輸。
ESB也可以說是傳統中間件技術與XML、Web服務等技術相互結合的產物。
1.在微服務中，與SOA不同，服務可以獨立於其他服務進行操作和部署，因此更容易經常部署新版本的服務和獨立擴張服務，讓專業的人做專業的事情，快速迭代新的產品。
2.在SOA中服務可能共享數據存儲，而微服務中每個服務都具有獨立的數據存儲。
3.SOA與微服務主要區別在於規模和範圍，SOA是一種思想，是面向服務架構體系，微服務繼承 了SOA的優點，去除傳統的ESB消息總線，採用Http+json格式通訊方式，更加輕量級。
高併發設計原則
系統設計不僅需要考慮實現業務功能，還要保證系統高併發、高可用、高可靠等。同時還應考慮系統容量規劃（流量、容量等）、SLA指定（吞吐量、響應時間、可用性、降級方案等）、監控報警（機器負載、響應時間、可用率等）、應急預案（容災、降級、限流、隔離、切流量、可回滾等）。
緩存
異步併發
連接池
線程池
擴容
消息隊列
分佈式任務
拆分系統
在我們從零開始做一個新系統的時候，會首先進行系統功能模塊架構設計，那麼是直接做一個大而全的垂直的MVC系統，使用一個war包進行發佈管理，還是需要按一些規則進行模塊拆分，設計成SOA或者微服務系統比較好呢？這個筆者認爲需要依據項目具有什麼樣的人力物力條件以及項目需要支撐多少用戶量和交易量爲基礎。一個好的系統設計應該能夠滿足解決當前的需求和問題，把控實現和進度風險，預測和規劃未來，避免過度設計，在上線一個基礎核心版本之後，再進行不斷迭代和完善。
今天我們來談一談進行SOA、微服務系統架構設計時模塊拆分的一些維度和原則。
系統維度：按照系統功能、業務拆分，如、優惠券、購物車，結算，訂單等系統。
功能維度：對系統功能在做細粒度拆分，優惠券系統分爲 優惠券後臺系統、領券系統、發券系統。
讀寫維度：比如商品系統中，如果查詢量比較大，可以單獨分爲兩個服務，分別爲查詢服務和寫服務,
讀寫比例特徵拆分；讀多，可考慮多級緩存；寫多，可考慮分庫分表.
AOP 維度： 根據訪問特徵，按照 AOP 進行拆分，比如商品詳情頁可分爲 CDN、頁面渲染系統，CDN 就是一個 AOP 系統
模塊維度：對整體代碼結構劃分 Web、Service、DAO
服務化
在分佈式系統中，將業務邏輯層封裝成接口形式，暴露給其他系統調用，那麼這個接口我們可以理解爲叫做服務。
當服務越來越多的時候，就會需要用到服務治理，那麼會用到Dubbo、SpringCloud服務治理框架。
服務化演進: 進程內服務-單機遠程服務-集羣手動註冊服務-自動註冊和發現服務-服務的分組、隔離、路由-服務治理
考慮服務分組、隔離、限流、黑白名單、超時、重試機制、路由、故障補償等
實踐：利用 Nginx、HaProxy、LVS 等實現負載均衡，ZooKeeper、Consul 等實現自動註冊和發現服務
消息隊列
消息中間件是一個客戶端與服務器異步通訊框架，消息中間件中分爲點對點與發佈訂閱通訊方式，生產者發送消息後，消費者可以無需等待， 異步接受生產者發送消息。
在電商系統中，會使用消息隊列異步推送消息，注意消息失敗重試冪等性問題。
冪等性問題解決方案，使用持久化日誌+全局id記錄。
緩存技術
瀏覽器端緩存
APP客戶端緩存
CDN(Content Delivery Network)緩存
接入層緩存
應用層緩存
分佈式緩存
對於兜底數據或者異常數據，不應該讓其緩存，否則用戶會在很長一段時間裏看到這些數據。
併發化
改串行爲並行。
高可用設計原則
通過負載均衡和反向代理實現分流。
通過限流保護服務免受雪崩之災。
通過降級實現部分可用、有損服務。
通過隔離實現故障隔離。
通過合理設置的超時與重試機制避免請求堆積造成雪崩。
通過回滾機制快速修復錯誤版本。
降級
對於高可用服務，很重要的一個設計就是降級開關，在設計降級開關時，主要依據如下思路：
1.開關集中化管理：通過推送機制把開關推送到各個應用。
2.可降級的多級讀服務：比如服務調用降級爲只讀本地緩存、只讀分佈式緩存、只讀默認降級數據（如庫存狀態默認有貨）。
3.開關前置化：如架構是Nginx–>tomcat，可以將開關前置到Nginx接入層，在Nginx層做開關，請求流量回源後端應用或者只是一小部分流量回源。
4.業務降級：當高併發流量來襲，在電商系統大促設計時保障用戶能下單、能支付是核心要求，並保障數據最終一致性即可。這樣就可以把一些同步調用改成異步調用，優先處理高優先級數據或特殊特徵的數據，合理分配進入系統的流量，以保障系統可用。
限流
目的: 防止惡意請求攻擊或超出系統峯值
實踐：
惡意請求流量只訪問到 Cache
穿透後端應用的流量使用 Nginx 的 limit 處理
惡意 IP 使用 Nginx Deny 策略或者 iptables 拒絕
切流量
目的：屏蔽故障機器
實踐:
DNS: 更改域名解析入口，如 DNSPOD 可以添加備用 IP，正常 IP 故障時，會自主切換到備用地址; 生效實踐較慢
HttpDNS: 爲了繞過運營商 LocalDNS 實現的精準流量調度
LVS/HaProxy/Nginx: 摘除故障節點
可回滾
發佈版本失敗時可隨時快速回退到上一個穩定版本
業務設計原則
防重設計
頁面請求防止重複提交，可以採用防重key、放重表、Token等
採用圖形驗證，防止機器攻擊。
冪等設計
消息中間件:消息中間件中應該注意因網絡延遲的原因，導致消息重複消費
第三方支付接口:在回調接口中，應該注意網絡延遲，沒有及時返回給第三方支付平臺，注意回調冪等性問題。
分佈式系統中，保證生成的訂單號唯一性，定時Job執行的冪等性問題等。
流程定義
複用流程系統，提供個性化的流程服務。
狀態與狀態機
複用流程系統，提供個性化的流程服務。
後臺系統操作可反饋
設計後臺系統時，考慮效果的可預覽、可反饋。
後臺系統審批化
對於有些重要的後臺功能需要設計審批流，比如調整價格，並對操作進行日誌記錄，從而保證操作可追溯、可審計。
文檔註釋
系統發展的最初階段就應該有文檔庫（設計架構、設計思想、數據字典/業務流程、現有問題），業務代碼合特殊需求都要有註釋。
備份
包括代碼和人員的備份。代碼主要提交到代碼倉庫進行管理和備份，代碼倉庫至少應該具備多版本的功能。人員備份指的是一個系統至少應該有兩名開發人員是瞭解的。