補充基礎知識

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服務治理框架
後續在深入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執行的冪等性問題等。

流程定義

複用流程系統，提供個性化的流程服務。

狀態與狀態機

複用流程系統，提供個性化的流程服務。

後臺系統操作可反饋

設計後臺系統時，考慮效果的可預覽、可反饋。

後臺系統審批化

對於有些重要的後臺功能需要設計審批流，比如調整價格，並對操作進行日誌記錄，從而保證操作可追溯、可審計。

文件註釋

系統發展的最初階段就應該有文件庫（設計架構、設計思想、資料字典/業務流程、現有問題），業務程式碼合特殊需求都要有註釋。

備份

包括程式碼和人員的備份。程式碼主要提交到程式碼倉庫進行管理和備份，程式碼倉庫至少應該具備多版本的功能。人員備份指的是一個系統至少應該有兩名開發人員是瞭解的。

環境準備

CentOS7 7.0 64位 以上+一臺外網伺服器+一個域名+CDN內容分發
電腦配置 16g以上記憶體

CentOS7 關閉防火牆

//臨時關閉
systemctl stop firewalld
//禁止開機啟動
systemctl disable firewalld
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.