當(dāng)為大家描述我們的整體服務(wù)架構(gòu)時，最常見的兩個問題是：
創(chuàng)新互聯(lián)公司是一家集網(wǎng)站設(shè)計、成都做網(wǎng)站、網(wǎng)站頁面設(shè)計、網(wǎng)站優(yōu)化SEO優(yōu)化為一體的專業(yè)網(wǎng)絡(luò)公司，已為成都等多地近百家企業(yè)提供網(wǎng)站建設(shè)服務(wù)。追求良好的瀏覽體驗,以探求精品塑造與理念升華,設(shè)計最適合用戶的網(wǎng)站頁面。 合作只是第一步，服務(wù)才是根本,我們始終堅持講誠信，負責(zé)任的原則，為您進行細心、貼心、認真的服務(wù),與眾多客戶在蓬勃發(fā)展的市場環(huán)境中,互促共生。
為什么采用結(jié)構(gòu)化方式將數(shù)據(jù)存儲在SQL數(shù)據(jù)庫中，而不使用NoSQL平臺？
為什么自己維護數(shù)據(jù)中心，而不將Evernote托管到云服務(wù)提供商？
這兩個問題都很有趣，我們先來探討第一個。
對特定的應(yīng)用而言，相比一個單一的SQL實例，一個現(xiàn)代的鍵值存儲引擎具備顯著的性能優(yōu)勢和可擴展性。
CREATE TABLE notebooks ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, name varchar(100) COLLATE utf8_bin NOT NULL, ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE notes ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, notebook_id int UNSIGNED NOT NULL, title varchar(255) NOT NULL, ... FOREIGN KEY (notebook_id) REFERENCES notebooks(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
如果你在Windows客戶端上創(chuàng)建了一個名為“Cooking”的記事本，并立即在其中粘貼了一個名為“Quick Tomato Sauce”的食譜，客戶端會立刻進行如下同步：
調(diào)用NoteStore.createNotebook() 請求服務(wù)器創(chuàng)建記事本，并返回以創(chuàng)建記事本的GUID。
通過指定記事本的GUID，調(diào)用NoteStore.createNote()在記事本中創(chuàng)建筆記。
每次API調(diào)用都通過SQL事物予以實現(xiàn)，可以讓客戶端完全信任服務(wù)器的任何提示。ACID兼容的數(shù)據(jù)庫可以做到這些：
原子性（Atomicity）：如果API調(diào)用成功，那么所有的改動都會保存；如果API調(diào)用失敗，所有的改動都不會提交。
一致性（Consistency）： 在API調(diào)用完成后，所有的賬戶都可用，并能保證內(nèi)部狀態(tài)的一致性。每篇筆記都與記事本相關(guān)聯(lián)，以避免出現(xiàn)孤立項。數(shù)據(jù)庫不允許刪除關(guān)聯(lián)有記事的記事本，這得感謝FOREIGN KEY約束。
持久性（Durability）：當(dāng)服務(wù)器發(fā)送記事本已創(chuàng)建完畢的回執(zhí)后，客戶端會認為它的存在具有持久性，以便進行后續(xù)的操作。變更的持久性，可以讓客戶端知道在任何時刻對服務(wù)狀態(tài)的影響都能保持一致性。
對我們的同步協(xié)議而言，持久性最為重要。如果客戶端不能確定服務(wù)器端的變更具有持久性，那么協(xié)議將會變得復(fù)雜而低效。
“大數(shù)據(jù)”問題
得益于事務(wù)處理的數(shù)據(jù)庫的ACID屬性，同樣使得數(shù)據(jù)集非常難以擴展，以超出單臺服務(wù)器的范圍。數(shù)據(jù)庫集群和多主復(fù)制技術(shù)并不理想，鍵值存儲為實現(xiàn)可擴展性提供了一條捷徑。
所幸，Evernote暫時不需要考慮這個問題。即便是我們有近10億的筆記，和近20億的資源文件，這也并不能稱得上是一個大數(shù)據(jù)集。通過按用戶分區(qū)，它被劃分成了2千萬個獨立的數(shù)據(jù)集。
我們尚未遇到所謂“大數(shù)據(jù)”引發(fā)的問題，倒是遇到了許多“中數(shù)據(jù)”的存儲問題，這就是通過規(guī)整分區(qū)形成的分片存儲架構(gòu)。
也許以后……
我們對新的存儲系統(tǒng)非常感興趣，非常樂意應(yīng)用在哪些對ACID要求不強，但確實需要橫向擴展的新項目中。例如，我們的報告分析系統(tǒng)已經(jīng)逐漸超出了MySQL平臺的承受力，需要被更快、更先進的系統(tǒng)所取代。
我們現(xiàn)在對以Evernote用戶元數(shù)據(jù)為基礎(chǔ)的MySQL分片存儲頗為滿意，盡管這不會引起那些IT弄潮兒的興趣。
nosql是not only sql的意思。是近今年新發(fā)展起來的存儲系統(tǒng)。當(dāng)前使用最多的是key-value模型，用于處理超大規(guī)模的數(shù)據(jù)。
以下是摘自百度百科中的一部分
NoSQL 是非關(guān)系型數(shù)據(jù)存儲的廣義定義。它打破了長久以來關(guān)系型數(shù)據(jù)庫與ACID理論大一統(tǒng)的局面。NoSQL 數(shù)據(jù)存儲不需要固定的表結(jié)構(gòu)，通常也不存在連接操作。在大數(shù)據(jù)存取上具備關(guān)系型數(shù)據(jù)庫無法比擬的性能優(yōu)勢。該術(shù)語在 2009 年初得到了廣泛認同。
當(dāng)今的應(yīng)用體系結(jié)構(gòu)需要數(shù)據(jù)存儲在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲就是為了實現(xiàn)這個需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實現(xiàn)。一些開源的 NoSQL 體系，如Facebook 的Cassandra， Apache 的HBase，也得到了廣泛認同。從這些NoSQL項目的名字上看不出什么相同之處：Hadoop、Voldemort、Dynomite，還有其它很多。
NoSQL與關(guān)系型數(shù)據(jù)庫設(shè)計理念比較
關(guān)系型數(shù)據(jù)庫中的表都是存儲一些格式化的數(shù)據(jù)結(jié)構(gòu)，每個元組字段的組成都一樣，即使不是每個元組都需要所有的字段，但數(shù)據(jù)庫會為每個元組分配所有的字段，這樣的結(jié)構(gòu)可以便于表與表之間進行連接等操作，但從另一個角度來說它也是關(guān)系型數(shù)據(jù)庫性能瓶頸的一個因素。而非關(guān)系型數(shù)據(jù)庫以鍵值對存儲，它的結(jié)構(gòu)不固定，每一個元組可以有不一樣的字段，每個元組可以根據(jù)需要增加一些自己的鍵值對，這樣就不會局限于固定的結(jié)構(gòu)，可以減少一些時間和空間的開銷。
1. 大型網(wǎng)站系統(tǒng)的特點
2. 大型網(wǎng)站架構(gòu)演化歷程
2.1. 初始階段架構(gòu)
問題：網(wǎng)站運營初期，訪問用戶少，一臺服務(wù)器綽綽有余。
特征：應(yīng)用程序、數(shù)據(jù)庫、文件等所有的資源都在一臺服務(wù)器上。
描述：通常服務(wù)器操作系統(tǒng)使用 linux，應(yīng)用程序使用 PHP 開發(fā)，然后部署在 Apache 上，數(shù)據(jù)庫使用 Mysql，通俗稱為 LAMP。匯集各種免費開源軟件以及一臺廉價服務(wù)器就可以開始系統(tǒng)的發(fā)展之路了。
2.2. 應(yīng)用服務(wù)和數(shù)據(jù)服務(wù)分離
問題：越來越多的用戶訪問導(dǎo)致性能越來越差，越來越多的數(shù)據(jù)導(dǎo)致存儲空間不足，一臺服務(wù)器已不足以支撐。
特征：應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器、文件服務(wù)器分別獨立部署。
描述：三臺服務(wù)器對性能要求各不相同：應(yīng)用服務(wù)器要處理大量業(yè)務(wù)邏輯，因此需要更快更強大的 CPU；數(shù)據(jù)庫服務(wù)器需要快速磁盤檢索和數(shù)據(jù)緩存，因此需要更快的硬盤和更大的內(nèi)存；文件服務(wù)器需要存儲大量文件，因此需要更大容量的硬盤。
2.3. 使用緩存改善性能
問題：隨著用戶逐漸增多，數(shù)據(jù)庫壓力太大導(dǎo)致訪問延遲。
特征：由于網(wǎng)站訪問和財富分配一樣遵循二八定律：80% 的業(yè)務(wù)訪問集中在 20% 的數(shù)據(jù)上。將數(shù)據(jù)庫中訪問較集中的少部分數(shù)據(jù)緩存在內(nèi)存中，可以減少數(shù)據(jù)庫的訪問次數(shù)，降低數(shù)據(jù)庫的訪問壓力。
描述：緩存分為兩種：應(yīng)用服務(wù)器上的本地緩存和分布式緩存服務(wù)器上的遠程緩存，本地緩存訪問速度更快，但緩存數(shù)據(jù)量有限，同時存在與應(yīng)用程序爭用內(nèi)存的情況。分布式緩存可以采用集群方式，理論上可以做到不受內(nèi)存容量限制的緩存服務(wù)。
2.4. 使用應(yīng)用服務(wù)器集群
問題：使用緩存后，數(shù)據(jù)庫訪問壓力得到有效緩解。但是單一應(yīng)用服務(wù)器能夠處理的請求連接有限，在訪問高峰期，成為瓶頸。
特征：多臺服務(wù)器通過負載均衡同時向外部提供服務(wù)，解決單一服務(wù)器處理能力和存儲空間不足的問題。
描述：使用集群是系統(tǒng)解決高并發(fā)、海量數(shù)據(jù)問題的常用手段。通過向集群中追加資源，提升系統(tǒng)的并發(fā)處理能力，使得服務(wù)器的負載壓力不再成為整個系統(tǒng)的瓶頸。
2.5. 數(shù)據(jù)庫讀寫分離
問題：網(wǎng)站使用緩存后，使絕大部分數(shù)據(jù)讀操作訪問都可以不通過數(shù)據(jù)庫就能完成，但是仍有一部分讀操作和全部的寫操作需要訪問數(shù)據(jù)庫，在網(wǎng)站的用戶達到一定規(guī)模后，數(shù)據(jù)庫因為負載壓力過高而成為網(wǎng)站的瓶頸。
特征：目前大部分的主流數(shù)據(jù)庫都提供主從熱備功能，通過配置兩臺數(shù)據(jù)庫主從關(guān)系，可以將一臺數(shù)據(jù)庫服務(wù)器的數(shù)據(jù)更新同步到一臺服務(wù)器上。網(wǎng)站利用數(shù)據(jù)庫的主從熱備功能，實現(xiàn)數(shù)據(jù)庫讀寫分離，從而改善數(shù)據(jù)庫負載壓力。
描述：應(yīng)用服務(wù)器在寫操作的時候，訪問主數(shù)據(jù)庫，主數(shù)據(jù)庫通過主從復(fù)制機制將數(shù)據(jù)更新同步到從數(shù)據(jù)庫。這樣當(dāng)應(yīng)用服務(wù)器在讀操作的時候，訪問從數(shù)據(jù)庫獲得數(shù)據(jù)。為了便于應(yīng)用程序訪問讀寫分離后的數(shù)據(jù)庫，通常在應(yīng)用服務(wù)器端使用專門的數(shù)據(jù)訪問模塊，使數(shù)據(jù)庫讀寫分離的對應(yīng)用透明。
2.6. 反向代理和 CDN 加速
問題：中國網(wǎng)絡(luò)環(huán)境復(fù)雜，不同地區(qū)的用戶訪問網(wǎng)站時，速度差別也極大。
特征：采用 CDN 和反向代理加快系統(tǒng)的靜態(tài)資源訪問速度。
描述：CDN 和反向代理的基本原理都是緩存，區(qū)別在于 CDN 部署在網(wǎng)絡(luò)提供商的機房，使用戶在請求網(wǎng)站服務(wù)時，可以從距離自己最近的網(wǎng)絡(luò)提供商機房獲取數(shù)據(jù)；而反向代理則部署在網(wǎng)站的中心機房，當(dāng)用戶請求到達中心機房后，首先訪問的服務(wù)器時反向代理服務(wù)器，如果反向代理服務(wù)器中緩存著用戶請求的資源，就將其直接返回給用戶。
2.7. 分布式文件系統(tǒng)和分布式數(shù)據(jù)庫
問題：隨著大型網(wǎng)站業(yè)務(wù)持續(xù)增長，數(shù)據(jù)庫經(jīng)過讀寫分離，從一臺服務(wù)器拆分為兩臺服務(wù)器，依然不能滿足需求。
特征：數(shù)據(jù)庫采用分布式數(shù)據(jù)庫，文件系統(tǒng)采用分布式文件系統(tǒng)。
描述：分布式數(shù)據(jù)庫是數(shù)據(jù)庫拆分的最后方法，只有在單表數(shù)據(jù)規(guī)模非常龐大的時候才使用。不到不得已時，更常用的數(shù)據(jù)庫拆分手段是業(yè)務(wù)分庫，將不同的業(yè)務(wù)數(shù)據(jù)庫部署在不同的物理服務(wù)器上。
2.8. 使用 NoSQL 和搜索引擎
問題：隨著網(wǎng)站業(yè)務(wù)越來越復(fù)雜，對數(shù)據(jù)存儲和檢索的需求也越來越復(fù)雜。
特征：系統(tǒng)引入 NoSQL 數(shù)據(jù)庫及搜索引擎。
描述：NoSQL 數(shù)據(jù)庫及搜索引擎對可伸縮的分布式特性具有更好的支持。應(yīng)用服務(wù)器通過統(tǒng)一數(shù)據(jù)訪問模塊訪問各種數(shù)據(jù)，減輕應(yīng)用程序管理諸多數(shù)據(jù)源的麻煩。
2.9. 業(yè)務(wù)拆分
問題：大型網(wǎng)站的業(yè)務(wù)場景日益復(fù)雜，分為多個產(chǎn)品線。
特征：采用分而治之的手段將整個網(wǎng)站業(yè)務(wù)分成不同的產(chǎn)品線。系統(tǒng)上按照業(yè)務(wù)進行拆分改造，應(yīng)用服務(wù)器按照業(yè)務(wù)區(qū)分進行分別部署。
描述：應(yīng)用之間可以通過超鏈接建立關(guān)系，也可以通過消息隊列進行數(shù)據(jù)分發(fā)，當(dāng)然更多的還是通過訪問同一個數(shù)據(jù)存儲系統(tǒng)來構(gòu)成一個關(guān)聯(lián)的完整系統(tǒng)。
縱向拆分：將一個大應(yīng)用拆分為多個小應(yīng)用，如果新業(yè)務(wù)較為獨立，那么就直接將其設(shè)計部署為一個獨立的 Web 應(yīng)用系統(tǒng)。縱向拆分相對較為簡單，通過梳理業(yè)務(wù)，將較少相關(guān)的業(yè)務(wù)剝離即可。
橫向拆分：將復(fù)用的業(yè)務(wù)拆分出來，獨立部署為分布式服務(wù)，新增業(yè)務(wù)只需要調(diào)用這些分布式服務(wù)橫向拆分需要識別可復(fù)用的業(yè)務(wù)，設(shè)計服務(wù)接口，規(guī)范服務(wù)依賴關(guān)系。
2.10. 分布式服務(wù)
問題：隨著業(yè)務(wù)越拆越小，存儲系統(tǒng)越來越龐大，應(yīng)用系統(tǒng)整體復(fù)雜程度呈指數(shù)級上升，部署維護越來越困難。由于所有應(yīng)用要和所有數(shù)據(jù)庫系統(tǒng)連接，最終導(dǎo)致數(shù)據(jù)庫連接資源不足，拒絕服務(wù)。
特征：公共業(yè)務(wù)提取出來，獨立部署。由這些可復(fù)用的業(yè)務(wù)連接數(shù)據(jù)庫，通過分布式服務(wù)提供共用業(yè)務(wù)服務(wù)。
3. 大型網(wǎng)站架構(gòu)模式
3.1. 分層
大型網(wǎng)站架構(gòu)中常采用分層結(jié)構(gòu)，將軟件系統(tǒng)分為應(yīng)用層、服務(wù)層、數(shù)據(jù)層：
分層架構(gòu)的約束：禁止跨層次的調(diào)用（應(yīng)用層直接調(diào)用數(shù)據(jù)層）及逆向調(diào)用（數(shù)據(jù)層調(diào)用服務(wù)層，或者服務(wù)層調(diào)用應(yīng)用層）。
分層結(jié)構(gòu)內(nèi)部還可以繼續(xù)分層，如應(yīng)用可以再細分為視圖層和業(yè)務(wù)邏輯層；服務(wù)層也可以細分為數(shù)據(jù)接口層和邏輯處理層。
3.2. 分割
將不同的功能和服務(wù)分割開來，包裝成高內(nèi)聚低耦合的模塊單元。這有助于軟件的開發(fā)和維護，便于不同模塊的分布式部署，提高網(wǎng)站的并發(fā)處理能力和功能擴展能力。
3.3. 分布式
大于大型網(wǎng)站，分層和分割的一個主要目的是為了切分后的模塊便于分布式部署，即將不同模塊部署在不同的服務(wù)器上，通過遠程調(diào)用協(xié)同工作。
分布式意味可以用更多的機器工作，那么 CPU、內(nèi)存、存儲資源也就更豐富，能夠處理的并發(fā)訪問和數(shù)據(jù)量就越大，進而能夠為更多的用戶提供服務(wù)。
分布式也引入了一些問題：
常用的分布式方案：
3.4. 集群
集群即多臺服務(wù)器部署相同應(yīng)用構(gòu)成一個集群，通過負載均衡設(shè)備共同對外提供服務(wù)。
集群需要具備伸縮性和故障轉(zhuǎn)移機制：伸縮性是指可以根據(jù)用戶訪問量向集群添加或減少機器；故障轉(zhuǎn)移是指，當(dāng)某臺機器出現(xiàn)故障時，負載均衡設(shè)備或失效轉(zhuǎn)移機制將請求轉(zhuǎn)發(fā)到集群中的其他機器上，從而不影響用戶使用。
3.5. 緩存
緩存就是將數(shù)據(jù)存放在距離最近的位置以加快處理速度。緩存是改善軟件性能的第一手段。
網(wǎng)站應(yīng)用中，緩存除了可以加快數(shù)據(jù)訪問速度以外，還可以減輕后端應(yīng)用和數(shù)據(jù)存儲的負載壓力。
常見緩存手段：
使用緩存有兩個前提：
3.6. 異步
軟件發(fā)展的一個重要目標(biāo)和驅(qū)動力是降低軟件耦合性。事物之間直接關(guān)系越少，彼此影響就越小，也就更容易獨立發(fā)展。
大型網(wǎng)站架構(gòu)中，系統(tǒng)解耦的手段除了分層、分割、分布式等，還有一個重要手段——異步。
業(yè)務(wù)間的消息傳遞不是同步調(diào)用，而是將一個業(yè)務(wù)操作拆分成多階段，每個階段間通過共享數(shù)據(jù)的方式異步執(zhí)行進行協(xié)作。
異步架構(gòu)是典型的生產(chǎn)者消費模式，二者不存在直接調(diào)用。異步消息隊列還有如下特性：
3.7. 冗余
大型網(wǎng)站，出現(xiàn)服務(wù)器宕機是必然事件。要保證部分服務(wù)器宕機的情況下網(wǎng)站依然可以繼續(xù)服務(wù)，不丟失數(shù)據(jù)，就需要一定程度的服務(wù)器冗余運行，數(shù)據(jù)冗余備份。這樣當(dāng)某臺服務(wù)器宕機是，可以將其上的服務(wù)和數(shù)據(jù)訪問轉(zhuǎn)移到其他機器上。
訪問和負載很小的服務(wù)也必須部署 至少兩臺服務(wù)器構(gòu)成一個集群，目的就是通過冗余實現(xiàn)服務(wù)高可用。數(shù)據(jù)除了定期備份，存檔保存，實現(xiàn) 冷備份 外；為了保證在線業(yè)務(wù)高可用，還需要對數(shù)據(jù)庫進行主從分離，實時同步實現(xiàn) 熱備份。
為了抵御地震、海嘯等不可抗因素導(dǎo)致的網(wǎng)站完全癱瘓，某些大型網(wǎng)站會對整個數(shù)據(jù)中心進行備份，全球范圍內(nèi)部署 災(zāi)備數(shù)據(jù)中心。網(wǎng)站程序和數(shù)據(jù)實時同步到多個災(zāi)備數(shù)據(jù)中心。
3.8. 自動化
大型網(wǎng)站架構(gòu)的自動化架構(gòu)設(shè)計主要集中在發(fā)布運維方面：
3.9. 安全
4. 大型網(wǎng)站核心架構(gòu)要素
架構(gòu) 的一種通俗說法是：最高層次的規(guī)劃，難以改變的決定。
4.1. 性能
性能問題無處不在，所以網(wǎng)站性能優(yōu)化手段也十分繁多：
4.2. 可用性
可用性指部分服務(wù)器出現(xiàn)故障時，還能否對用戶提供服務(wù)
4.3. 伸縮性
衡量伸縮的標(biāo)準(zhǔn)就是是否可以用多臺服務(wù)器構(gòu)建集群，是否容易向集群中增刪服務(wù)器節(jié)點。增刪服務(wù)器節(jié)點后是否可以提供和之前無差別的服務(wù)。集群中可容納的總服務(wù)器數(shù)是否有限制。
4.4. 擴展性
衡量擴展性的標(biāo)準(zhǔn)就是增加新的業(yè)務(wù)產(chǎn)品時，是否可以實現(xiàn)對現(xiàn)有產(chǎn)品透明無影響，不需要任何改動或很少改動，既有功能就可以上線新產(chǎn)品。主要手段有：事件驅(qū)動架構(gòu)和分布式服務(wù)。
4.5. 安全性
安全性保護網(wǎng)站不受惡意攻擊，保護網(wǎng)站重要數(shù)據(jù)不被竊取。
歡迎工作一到五年的Java工程師朋友們加入Java程序員開發(fā)： 721575865
群內(nèi)提供免費的Java架構(gòu)學(xué)習(xí)資料（里面有高可用、高并發(fā)、高性能及分布式、Jvm性能調(diào)優(yōu)、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構(gòu)資料）合理利用自己每一分每一秒的時間來學(xué)習(xí)提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
ngsql？是nosql吧？
ngsql不是通過標(biāo)準(zhǔn)的sql語法進行查詢的，而是類似調(diào)用函數(shù)的方法返回值的。
這種情況下是無法sql注入的
但是緊是無法SQL注入。其他基于程序?qū)用嫔系谋热鏹s注入，php注入都能針對NoSQL數(shù)據(jù)庫進行拼接或者數(shù)組注入。
重慶分公司
重慶分公司
