CC++服務器開發】中間件的含義及常?中間件介紹?、中間件的定義中間件這個術語第?次出現是1968年在德國加爾?施帕滕基興舉辦的NATO軟件?程?會結束后發表的?份報告中。這屆?會正式確定了軟件?程(SoftwareEngineering)的概念，同時還探討了軟件設計、?產和分發等主題。中間件（英語：Middleware），?譯中間件、中介層，是?類提供系統軟件和應?軟件之間連接、便于軟件各部件之間的溝通的軟件，應?軟件可以借助中間件在不同的技術架構之間共享信息與資源。中間件位于客戶機服務器的操作系統之上，管理著計算資源和?絡通信。–維基百科我們按照類別來看?些經常會遇到的?些不是中間件的概念-業務平臺不是中間件，業務平臺是從服務的視?抽象的能同時?撐多個業務，業務之間的信息能形成交互和增強的平臺。-營銷?具不是中間件，營銷?具是直接作?于最終消費者?戶的軟件或者插件服務。-??/三??具包不是中間件，??/三??具包是在各種場景的程序開發過程中沉淀的?些常??具類(功能)的集合，包含于軟件代碼本?。-SaaS不是中間件，SaaS(SoftwareasaService)更多的是?種軟件交付模式，?需?戶安裝，通過?絡在線訪問的?種服務模式。-PaaS不是中間件，PaaS(PlatformasaService)將軟件研發的平臺做為?種服務，提供軟件部署平臺(強調的是屏蔽系統和軟件細節的runtime平臺)。從定義可以總結出評判的?個地?1.性質：中間件是軟件。2.作?層級：系統軟件和應?軟件之間、軟件各部件之間；管理客戶機與系統軟件之間的計算資源和?絡通信。3.服務對象：中間件為應?軟件服務，應?軟件為最終?戶服務，最終?戶并不直接使?中間件。中間件能給客戶帶來什么？為上層應?軟件的開發提供便捷的、開箱即?的服務交互和計算的能?，縮短開發周期；屏蔽底層runtime的差異；節省應?本?的系統資源，減少運?成本。什么時候使?中間件基于中間件的定義我們知道中間件是連接軟件與系統之間的服務，那么我們什么時候使?了中間件，在哪些地??到了中間件了。我們不妨假設?個http請求過程來窺視?番。當你在瀏覽器中輸??個?址時，它會通過DNS解析到?標服務注冊的公?IP地址請求到達?標服務的web反向代理服務器Tengine之后，經過?定的過濾轉發到?標服務A上服務A通過RPC框架Dubbo請求服務B的結果做中間計算，并且從Tair緩存中讀取計算因?，計算結果服務A接著使?Druid通過TDDL寫?計算結果到MySQLMaster節點然后返回結果異步過程中Canal通過模擬Binlog主從復制的原理，迅速將這條Binlog消費并下發到消息隊列RocketMQ服務C通過RocketMQ消費到事件之后，通過配置中?ConfigServer拉取到的策略進?對應策略的事件處理。這個過程中我們使?了?系列的中間件來協同各個微服務完成整個流程，如web反向代理服務器Tengine、RPC框架Dubbo、緩存Tair、連接池Driud、數據庫代理層TDDL、Binlog同步?具Canal、消息隊列RocketMQ、配置中?ConfigServer。-路由與web服務器：處理和轉發其他服務器通信數據的服務器。如被業界?泛使?的阿?基于Nginx研發的Tengine、阿?內部的集中式路由服務VipServer-RPC框架：微服務時代的遠程服務調?框架。如grpc,Thrift,阿?的HSF,Dubbo,SOFA-RPC-消息中間件：?持在分布式系統之間發送和接收消息的軟件。如Apachekafka,ApacheRabbitMQ,NSQ,阿?孵化開源的ApacheRocketMQ-緩存服務:分布式的?速數據存儲層，?般是內存存儲。如阿?Tair，業界的Redis,Memcached,Ehcache-配置中?：?來統?管理各個項?中所有配置的系統。如阿?Nacos、攜程Apollo、百度Disconf-分布式事務：事務的參與者、?持事務的服務器、資源服務器以及事務管理器分別位于不同的分布式系統的不同節點之上。如阿?seata、騰訊DTF-任務調度：分布式環境下提供定時、任務編排、分布式跑批等功能的系統。如阿?SchedulerX、業界xxl-job、當當elastic-job、有贊TSP-數據庫層?于?持彈性擴容和分庫分表的TDDL，數據庫連接池Driud,Binlog同步的Canal等。隨著云時代的到來，?量公司的業務向云上遷移；為了云上客戶能夠便捷的使?穩定?效的中間件能?，云?商開始將??沉淀的基礎中間件能?云化，?于?撐各個云上客戶和??業務的快速?長。?、中間件的開發隨著國內軟件?業的發展，國內互聯?公司規模越來越?，業務越來越復雜，隨之使??量的中間件來提?后臺服務性能。由此產?了中間件開發和維護?員。誠然，在?公司，中間件，例如緩存，MQ，RPC等服務，極?可能是由業務開發?員??維護，或者委托第三?云平臺運維（?付?些費?）。但，如果后臺開發超過200?，基本就會組建??的中間件或者基礎架構團隊，?于維護后臺服務器基礎架構和中間件。更?規模的公司，則由于各種各樣的原因（性能，KPI），會??開發中間件，簡稱?研。這要求中間件團隊需要更多的?員。既然需要中間件開發?員，那么中間件開發?員?般從哪?招聘呢？招聘的要求是什么？通常，?個公司在剛開始組建中間件團隊的時候，都會從公司內部挑選精英?才，或者挑選對中間件感興趣的?才。這時候，可能你沒有相關經驗，但你仍然有機會參與到中間件開發中。反之，如果你沒有中間件開發經驗，想通過招聘的?式進?中間件?業，那么相對??，會有些曲折。那么，假設，你想從事中間件開發，但，你沒有中間件開發經驗，且，你的公司也沒有組建中間件團隊的打算。該怎么突破？答：跳槽。跳槽到別的公司的中間件團隊。這?就涉及到了?個中間件團隊需要哪些技能。因為跳槽肯定就要?試，如果你?試的是中間件崗位，那么?然，就需要準備中間件的相關知識。另外，還有?點，在這個分?明確的時代，即使是中間件，也有很多種類，我這?稍微分?下，可能不是很準確。1.服務治理中間件，例如RPC相關中間件，限流熔斷，鏈路追蹤，分布式配置中?等等。你可以從SpringCloud?找到相關的產品。當然國內也有很多優秀的產品。2.存儲中間件，例如緩存，MQ等等，如果存儲涉及到分布式（通常都會涉及），那么要求相對較?。3.各種Proxy，不論是數據庫，還是Cache，還是各種存儲，通常單機?法承載海量數據，?較簡單的辦法就是使?Proxy進?代理，讓應?透明的使?集群。出于性能考慮，這?通常會使?性能較?的產品，例如goLang，C++等。Java的長處——開發效率，在這個地?權重不?。4.各種分布式中間件，例如ZK這種，這個我個?認為難度是較?的。分布式向來是軟件開發中?較困難的?個點。特別是涉及到存儲和?致性。5.回到之前的話題:?個中間件開發者需要哪些素質？1.語?基礎。從Java程序員的?度，基礎通常就是：集合，并發，JVM，Netty，IO、NIO（mmap，sendfile）2.計算機基礎，由于中間件開發?員經常和OS打交道，所以計算機基礎也必不可少，例如?件系統（IO/磁盤），進程線程，內存管理。3.?絡基礎，搞后臺的?員，肯定要對?絡熟悉了，熟悉在Linux下排查?絡問題，熟悉Epoll原理等。4.分布式相關知識，互聯?海量數據背景下，分布式知識必不可少，CAP，Paxos，Raft，zab，2pc，3pc，base等等。最好能根據這些理論寫出實現代碼。5.熟悉開源實現，即使你是業務開發?員，你也100%會接觸開源項?，例如Spring，那么，通常你需要對這種常?的開源代碼有深刻的理解，不僅知曉其原理，也領會其設計。從?的?度看，你得看清整個框架的背景，設計和取舍，從?的?度看，你得看清框架的內部實現細節，有哪些有趣的地?（通常這種框架都會進?性能優化）。6.了解?業風向標，中間件?業和業務開發稍有不同，每個中間件的版本升級都會讓該領域的開發者們側?（類似iPhone發布會），了解其特性，進?了解?業趨勢，最后成為?業引領。好，說完了中間件開發?員需要哪些素質，?然，如何成為中間件開發?員，就不??明了。說?了，以上6個點，都是硬?頭。對于已經開始?作的?來說，需要平時深刻的積累，說的難聽?點，如果你的業務開發任務很重，你很難搞定上門的這些內容。對于還在上學的同學來說，很爽，你可以?學校（不僅僅指?學，據我所知的?神，通常是初中/?學就開始編程，但這不是必須的）??把的時間來學習，?個個的搞定這些知識點，和社招不同，如果你的知識達到上?的?平，那么SPoffer應該是隨便拿了：）我這?重點和那些平時開發任務不重，想搞中間件的同學聊聊。我假設你是?個?作3年以內的Java開發?員，且你可能是培訓?，半路出家，科班?，?專?，初中?，且你不在??，通常在?個后臺開發不超過200?的創業公司，title是“Java開發?程師”，并且有?個程序員的夢想，不想get、set，不想crud，不想html填空，不想和產品同學討論，也不想和測試同學點點點…(感覺這?會得罪?=_=||)你可能想跳槽。那么你?概需要做以下準備：1.鞏固Java基礎，集合源碼，并發源碼，JVM原理，Netty原理源碼，IO相關（涉及到零拷貝?件存儲），這些都是Java基礎，通常是必須的。2.分布式原理，最起碼知曉理論知識，最好能寫?個，哪怕參照開源的也?。3.源碼，SpringMybatisTomcat等等，這些代碼通常是你最先接觸的，不妨從這?開始。RPC中間件相關的，Dubbo，Motan，SOFA，挑?個吧，推薦SOFA。4.再熟悉熟悉（熟悉指源碼和設計）分布式的相關產品，假設你是Java開發，推薦RocketMQ，Apollo配置中?等等中間件，其實都可以，MQ相對復雜。5.操作系統，通常，你在研究上?的內容時，會遇到操作系統的疑問，遇到不要繞過，盡量弄明?。6.??的產品，有就最好了，例如公眾號，博客，教學視頻，GitHub項?等等，總之，是拿得出?的東西。7.加??好友，了解?業風向標。也許你是?個矜持的?，但從事了這個?業，你有必要和?業?優秀的?學習(看看朋友圈就好)。三、和NoSQL之前寫了?篇關于數據庫的基礎博客：下?來看看NoSQL的含義。關系型數據庫建?在關系型數據模型的基礎上，是借助于集合代數等數學概念和?法來處理數據的數據庫。現實世界中的各種實體以及實體之間的各種聯系均可?關系模型來表?，市場上占很?份額的Oracle、、DB2等都是?向關系模型的DBMS。在關系型數據庫中，實體以及實體間的聯系均由單?的結構類型來表?，這種邏輯結構是?張?維表。圖1所?的學?選課系統中，實體和實體間聯系在數據庫中的邏輯結構可通過圖2所?。圖1：關系型數據庫圖2：學?選課系統數據庫邏輯結構關系型數據庫以?和列的形式存儲數據，這?系列的?和列被稱為表，?組表組成了數據庫。圖3所?的員?信息表就是關系型數據庫。圖3：員?信息表屬性說明：?維表：也稱為關系，它是?系列?維數組的集合，?來代表與存儲數據對象之間的關系。它由縱向的列和橫向的?組成。?：也叫元組或記錄，在表中是?條橫向的數據集合，代表?個實體。列：也叫字段或屬性，在表中是?條縱?的數據集合。列也定義了表中的。主屬性：關系中的某?屬性組，若它們的值唯?地標識?個記錄，則稱該屬性組為主屬性或主鍵。主屬性可以是?個屬性，也可以由多個屬性共同組成。在圖1-5中，學號是學?信息表的主屬性，但是課程信息表中，學號和課程號共同唯?地標識了?條記錄，所以學號和課程號?起組成了課程信息表的主屬性。結構化查詢語?關系型數據庫的核?是其結構化的查詢語?（StructuredQueryLanguage,SQL），SQL涵蓋了數據的查詢、操縱、定義和控制，是?個綜合的、通?的且簡單易懂的數據庫管理語?。同時SQL?是?種?度?過程化的語?，數據庫管理者只需要指出做什么，?不需要指出該怎么做即可完成對數據庫的管理。SQL可以實現數據庫全?命周期的所有操作，所以SQL?產?之?起就成了檢驗關系型數據庫管理能?的“試??”，SQL標準的每?次變更和完善都引導著關系型數據庫產品的發展?向。SQL包含以下四個部分。）DDL包括CREATE、DROP、ALTER等動作。在數據庫中使?CREATE來創建新表，DROP來刪除表，ALTER負責數據庫對象的修改。例如，創建學?信息表使?以下命令：CREATETABLEStuInfo(idint(10)NOTNULL,PRIMARYKEY(id),namevarchar(20),femalebool,classvarchar(20));）DQL負責進?數據查詢，但是不會對數據本?進?修改。DQL的語法結構如下：SELECTFROM表名1,表2where查詢條件#可以組合and、or、not、=、between、and、in、like等；groupby分組字段having(分組后的過濾條件)orderby排序字段和規則;）DML負責對數據庫對象運?數據訪問?作的指令集，以INSERT、UPDATE、DELETE三種指令為核?，分別代表插?、更新與刪除。向表中插?數據命令如下：INSERT表名(字段1,字段2,…，字段n,)VALUES(字段1值，字段2值，…，字段n值)where查詢條件；）DCL是?種可對數據訪問權進?控制的指令。它可以控制特定?戶賬戶對查看表、預存程序、?戶?定義函數等數據庫操作的權限，由GRANT和REVOKE兩個指令組成。DCL以控制?戶的訪問權限為主，GRANT為授權語句，對應的REVOKE是撤銷授權語句。關系型數據庫已經發展了數?年，其理論知識、相關技術和產品都趨于完善，是?前世界上應?最?泛的數據庫系統。容易理解：?維表結構?常貼近邏輯世界的概念，關系型數據模型相對層次型數據模型和?狀型數據模型等其他模型來說更容易理解。使??便：通?的SQL使?戶操作關系型數據庫?常?便。易于維護：豐富的完整性??減少了數據冗余和數據不?致的問題。關系型數據庫提供對事務的?持，能保證系統中事務的正確執?，同時提供事務的恢復、回滾、并發控制和死鎖問題的解決。隨著各類互聯?業務的發展，關系型數據庫難以滿?對海量數據的處理需求，存在以下不?。?并發讀寫能?差：?站類?戶的并發性訪問?常?，??臺數據庫的最?連接數有限，且硬盤I/O有限，不能滿?很多?同時連接。對海量數據的讀寫效率低：若表中數據量太?，則每次的讀寫速率都將?常緩慢。擴展性差：在?般的關系型數據庫系統中，通過升級數據庫服務器的硬件配置可提?數據處理的能?，即縱向擴展。但縱向擴展終會達到硬件性能的瓶頸，?法應對互聯?數據爆炸式增長的需求。還有?種擴展?式是橫向擴展，即采?多臺計算機組成集群，共同完成對數據的存儲、管理和處理。這種橫向擴展的集群對數據進?分散存儲和統?管理，可滿?對海量數據的存儲和處理的需求。但是由于關系型數據庫具有數據模型、完整性約束和事務的強?致性等特點，導致其難以實現?效率的、易橫向擴展的分布式架構。數據是當今世界最有價值的資產之?。在時代，?們?產、收集數據的能???提升，但是傳統的關系型數據庫在可擴展性、數據模型和可?性??已遠遠不能滿?當前的數據處理需求，因此，各種數據庫系統應運??。NoSQL數據庫不像關系型數據庫那樣都有相同的特點，遵循相同的標準。NoSQL數據庫類型多樣，可滿?不同場景的應?需求，因此取得了巨?的成功。NoSQL數據庫基本理念是以犧牲事務機制和強?致性機制，來獲取更好的分布式部署能?和橫向擴展能?，創造出新的數據模型，使其在不同的應?場景下，對特定業務數據具有更強的處理性能。NoSQL數據庫最初是為了滿?互聯?的業務需求?誕?的，互聯?數據具有?量化、多樣化、快速化等特點。在信息化時代背景下，互聯?數據增長迅猛，數據集合規模已實現從GB、PB到ZB的飛躍。數據不僅僅是傳統的結構化數據，還包含了?量的?結構化和半結構化數據，關系型數據庫?法存儲此類數據。因此，很多互聯?公司著?研發新型的、?關系型的數據庫，這類?關系型數據庫統稱為NoSQL數據庫，其主要優勢如下。互聯?數據如?站?戶信息、地理位置數據、社交圖譜、?戶產?的內容、機器?志數據以及傳感器數據等，正在快速改變著?們的通信、購物、?告、娛樂等?常?活，沒有使?這些數據的應?很快就會被?戶所遺忘。開發者希望使??常靈活的數據庫，容納新的數據類型，并且不會被第三?數據提供商的變化所影響。關系型數據庫的數據模型定義嚴格，?法快速容納新的數據類型。例如，若要存儲客戶的電話號碼、姓名、地址、城市等信息，則SQL數據庫需要提前知曉要存儲的是什么。這對于敏捷開發模式來說?分不?便，因為每次完成新特性時，通常都需要改變數據庫的模式。NoSQL數據庫提供的數據模型則能很好地滿?這種需求，各種應?可以通過這種靈活的數據模型存儲數據??須修改表；或者只需增加更多的列，?須進?數據的遷移。對企業來說，關系型數據庫?開始是普遍的選擇。然?，在使?關系型數據庫的過程中卻遇到了越來越多的問題，原因在于它們是中?化的，是縱向擴展?不是橫向擴展的。這使得它們不適合那些需要簡單且動態可伸縮性的應?。NoSQL數據庫從?開始就是分布式、橫向擴展的，因此?常適合互聯?應?分布式的特性。在互聯?應?中，當數據庫服務器?法滿?數據存儲和數據訪問的需求時，只需要增加多臺服務器，將?戶請求分散到多臺服務器上，即可減少單臺服務器的性能瓶頸出現的可能性。由于關系型數據庫存儲的是結構化的數據，所以通常采?縱向擴展，即單臺服務器要持有整個數據庫來確保可靠性與數據的持續可?性。這樣做的代價是?常昂貴的，?且擴展也會受到限制。針對這種問題的解決?案就是橫向擴展，即添加服務器?不是擴展單臺服務器的處理能?。NoSQL數據庫通常都?持?動分?，這意味著它們會?動地在多臺服務器上分發數據，?不需要應?程序增加額外的操作。NoSQL數據庫?持?動復制。在NoSQL數據庫分布式集群中，服務器會?動對數據進?備份，即將?份數據復制存儲在多臺服務器上。因此，當多個?戶訪問同?數據時，可以將?戶請求分散到多臺服務器中。同時，當某臺服務器岀現故障時，其他服務器的數據可以提供備份，即NoSQL數據庫的分布式集群具有?可?性與災備恢復的能?。需要通過分布式的集群?式來解決存儲和訪問的問題。分布式系統的核?理念是讓多臺服務器協同?作，完成單臺服務器?法處理的任務，尤其是?并發或者?數據量的任務。分布式數據庫是數據庫技術與?絡技術相結合的產物，它通過?絡技術將物理上分開的數據庫連接在?起，進?邏輯層?上的集中管理。在分布式數據庫系統中，?個應?程序可以對數據庫進?透明操作，數據庫中的數據分別存儲在不同的局部數據庫中，由不同機器上不同的DBMS進?管理，其的體系結構如下圖所?。分布式數據處理使?分?治之的辦法來解決?規模數據管理問題，它處理數據的基本特點如下。在分布式系統中，數據不是存儲在?個場地上，?是存儲在計算機?絡的多個場地上。但邏輯上是?個整體，它們被所有?戶共享，并由?個DBMS統?管理。?戶訪問數據時?須指出數據存放在哪?，也不需要知道由分布式系統中的哪臺服務器來完成。分布式數據的復制有助于提?性能，更易于協調不同??沖突的?戶需求。同時，當某臺服務器出現故障時，此服務器上的數據在其他服務器上還有備份，提?了系統的可?性。這種多副本的?式對?戶來說是透明的，即?戶不需要知道副本的存在，由系統統?管理、協調副本的調?。分布式數據處理具有重復的構成，因此消除了單點故障的問題，即系統中?個或多個服務器發送故障不會使整個系統癱瘓，從?提?了系統的可靠性。但是在分布式系統中，事務是并發的，即不同?戶可能在同?時間對同?數據源進?訪問，這就要求系統?持分布式的并發控制，保證系統中數據的?致。分布式系統可以解決海量數據的存儲和訪問，但是在分布式環境下，數據庫會遇到更為復雜的問題，舉例如下。數據在分布式環境下以多副本?式進?存儲，那么，在為?戶提供數據訪問時如何選擇?個副本，或者?戶修改了某?副本的數據，如何讓系統中每個副本都得到更新。如果正在更新系統所有副本信息時，某個服務器由于?絡或硬、軟件功能出現問題導致其發?故障。在這種情況下，如何確保故障恢復時，此服務器上的副本與其他副本?致。這些問題給分布式數據庫管理系統帶來了挑戰，它們是分布式系統固有的復雜性，但更重要的是對分布數據的管理，控制數據之間的?致性以及數據訪問的安全性。CAP理論是針對分布式數據庫??的，它是指在?個分布式系統中，?致性（Consistency,C）、可?性（Availability,A）、分區容錯性（PartitionTolerance,P）三者不可兼得。）?致性是指“allnodesseethesamedataatthesametime”，即更新操作成功后，所有節點在同?時間的數據完全?致。?致性可以分為客戶端和服務端兩個不同的視?：從客戶端?度來看，?致性主要指多個?戶并發訪問時更新的數據如何被其他?戶獲取的問題；從服務端來看，?致性則是?戶進?數據更新時如何將數據復制到整個系統，以保證數據的?致。?致性是在并發讀寫時才會出現的問題，因此在理解?致性的問題時，?定要注意結合考慮并發讀寫的場景。）可?性是指“readsandwritesalwayssucceed”，即?戶訪問數據時，系統是否能在正常響應時間返回結果。好的可?性主要是指系統能夠很好地為?戶服務，不出現?戶操作失敗或者訪問超時等?戶體驗不好的情況。在通常情況下，可?性與分布式數據冗余、負載均衡等有著很?的關聯。）分區容錯性是指“thesystemcontinuestooperatedespitearbitrarymessagelossorfailureofpartofthesystem”，即分布式系統在遇到某節點或?絡分區故障的時候，仍然能夠對外提供滿??致性和可?性的服務。分區容錯性和擴展性緊密相關。在分布式應?中，可能因為?些分布式的原因導致系統?法正常運轉。分區容錯性?指在部分節點故障或出現丟包的情況下，集群系統仍然能提供服務，完成數據的訪問。分區容錯可視為在系統中采?多副本策略。CAP理論認為分布式系統只能兼顧其中的兩個特性，即出現CA、CP、AP三種情況，如圖所?。P如果不要求PartitionTolerance，即不允許分區，則強?致性和可?性是可以保證的。其實分區是始終存在的問題，因此CA的分布式系統更多的是允許分區后各?系統依然保持CA。A如果不要求可?性，相當于每個請求都需要在各服務器之間強?致，?分區容錯性會導致同步時間?限延長，如此CP也是可以保證的。很多傳統的數據庫分布式事務都屬于這種模式。C如果要可?性?并允許分區，則需放棄?致性。?旦分區發?，節點之間可能會失去聯系，為了實現?可?，每個節點只能?本地數據提供服務，?這樣會導致全局數據的不?致性。在實踐中，可根據實際情況進?權衡，或者在軟件層?提供配置?式，由?戶決定如何選擇CAP策略。CAP理論可?在不同的層?，可以根據CAP原理定制局部的設計策略，例如，在分布式系統中，每個節點??的數據是能保證CA的，但在整體上?要兼顧AP或CP。ACID是關系型數據庫的事務機制需要遵守的原則。事務是?個?致和可靠計算的基本單元，由作為原?單元執?的?系列數據庫操作組成。數據庫庫?般在啟動時會提供事務機制，包括事務啟動、停?、取消或回滾等。關系型數據庫?持事務的ACID原則，即原?性（Atomicity）、?致性（Consistency）、隔離性（Isolation）、持久性（Durability），這四種原則保證在事務過程當中數據的正確性，具體描述如下。）?個事務的所有系列操作步驟被看成?個動作，所有的步驟要么全部完成，要么?個也不會完成。如果在事務過程中發?錯誤，則會回滾到事務開始前的狀態，將要被改變的數據庫記錄不會被改變。）?致性是指在事務開始之前和事務結束以后，數據庫的完整性約束沒有被破壞，即數據庫事務不能破壞關系數據的完整性及業務邏輯上的?致性。）主要?于實現并發控制，隔離能夠確保并發執?的事務按順序?個接?個地執?。通過隔離，?個未完成事務不會影響另外?個未完成事務。）?旦?個事務被提交，它應該持久保存，不會因為與其他操作沖突?取消這個事務。從事務的四個特性可以看到關系型數據庫是要求強?致性的，但是這?點在數據庫中是重點弱化的機制。原因是當數據庫保存強?致性時，很難保證系統具有橫向擴展和可?性的優勢，因此針對分布式數據存儲管理只提供了弱?致性的保障，即。BASE理論是針對數據庫??的，它是對理論中?致性（C）和可?性（A）進?權衡的結果，源于提出者??在?規模分布式系統上實踐的總結。其核?思想是?法做到強?致性，但每個應?都可以根據??的特點，采?適當?式達到最終?致性。）基本可?指分布式系統在出現故障時，系統允許損失部分可?性，即保證核?功能或者當前最重要功能可?。對于?戶來說，他們當前最關注的功能或者最常?的功能的可?性將會獲得保證，但是其他功能會被削弱。）軟狀態允許系統數據存在中間狀態，但不會影響系統的整體可?性，即允許不同節點的副本之間存在暫時的不?致情況。最終?致性（EventuallyConsistent）最終?致性要求系統中數據副本最終能夠?致，?不需要實時保證數據副本?致。例如，銀?系統中的?實時轉賬操作，允許24?時內?戶賬戶的狀態在轉賬前后是不?致的，但24?時后賬戶數據必須正確。最終?致性是BASE原理的核?，也是NoSQL數據庫的主要特點，通過弱化?致性，提?系統的可伸縮性、可靠性和可?性。?且對于?多數Web應?，其實并不需要強?致性，因此犧牲?致性?換取?可?性，是多數分布式數據庫產品的?向。最終?致性可以分為客戶端和服務端兩個不同的視?。從客戶端來看，?致性主要指的是多并發訪問時更新過的數據如何獲取的問題，最終?致性有以下5個變種。說明如果進程A通知進程B它已更新了?個數據項，那么，進程B的后續訪問將返回更新后的值，且?次寫?將保證取代前?次寫?。與進程A?因果關系的進程C的訪問遵守?般的最終?致性規則。讀?之所寫（Read-當進程A??更新?個數據項之后，它總是訪問到更新過的值，且不會看到舊值。這是因果?致性模型的?個特例。這是上?個模型的實?版本，它把訪問存儲系統的進程放到會話的上下?中。只要會話還存在，系統就保證“讀?之所寫”?致性。如果由于某些失敗情形令會話終?，就要建?新的會話，?且系統保證不會延續到新的會話。如果進程已經看到過數據對象的某個值，那么任何后續訪問都不會返回在那個值之前的值。系統保證來?同?個進程的寫操作順序執?。單調寫?致性上述最終?致性的不同?式可以進?組合，例如，單調讀?致性和“讀?之所寫”?致性就可以組合實現。從實踐的?度來看，這兩者的組合讀取??更新的數據，?旦讀取到最新的版本，就不會再讀取舊版本，對基于此架構上的程序開發來說，會減少很多額外的煩惱。從服務端來看，如何盡快地將更新后的數據分布到整個系統，降低達到最終?致性的時間窗?，是提?系統的可?度和?戶體驗度?常重要的??。分布式數據系統有以下特性：N為數據復制的份數。W為更新數據時需要進?寫操作的節點數。R為讀取數據的時候需要讀取的節點數。如果W+R>N，寫的節點和讀的節點重疊，則是強?致性。例如，對于典型的?主?備同步復制的關系型數據庫（N=2,W=2,R=1），則不管讀的是主庫還是備庫的數據，都是?致的。如果W+R≤N，則是弱?致性。例如，對于?主?備異步復制的關系型數據庫（N=2,W=1,R=1），如果讀的是備庫，則可能?法讀取主庫已經更新過的數據，所以是弱?致性。對于分布式系統，為了保證?可?性，?般設置N≥3。設置不同的N、W、R組合，是在可?性和?致性之間取?個平衡，以適應不同的應?場景。如果N=W且R=1，則任何?個寫節點失效，都會導致寫失敗，因此可?性會降低。但是由于數據分布的N個節點是同步寫?的，因此可以保證強?致性。如果N=R且W=1，則只需要?個節點寫?成功即可，寫性能和可?性都?較?。但是讀取其他節點的進程可能不能獲取更新后的數據，因此是弱?致性。在這種情況下，如果W＜(N+1)/2，并且寫?的節點不重疊，則會存在寫沖突。NoSQL關系型數據庫產品很多，如、Oracle、MicrosoftSQLSever等，但它們的基本模型都是關系型數據模型。并沒有統?的模型，?且是?關系型的。常見的NoSQL數據庫包括鍵值數據庫、列族數據庫、?檔數據庫和圖形數據庫，其具體分類和特點如表所?。應?場景數據模型優點缺點鍵值數據庫<key,value>鍵值對，通過散列表來實現擴展性好，靈活性好，?量操作時性能?內容緩存，如會話、配置?件、參數等；頻繁讀寫、擁有簡單數據模型的應?數據?結構化，通常只被當做字符串或者?進制數據，只能通過鍵來查詢值列族以列族式存儲，將同數據模型可擴展性強，查找速優點、分布式數據存儲與管理應?場景功能局限，不?持事務的強?致性缺點相關產品?列數據存在?起度快，復雜性低Cassandra?檔數據庫、<key,value>value靈活，可以根據value構建索引缺乏統?查詢語法圖形數據庫社交?絡、推薦系統，專注構建關系圖譜圖結構?持復雜的圖形算法復雜性?，只能?持?定的數據規模NoSQL數據庫并沒有?個統?的架構，兩種不同的NoSQL數據庫之間的差異程度，遠遠超過兩種關系型數據庫之間的不同。可以說，NoSQL數據庫各有所長，?個優秀的NoSQL數據庫必然特別適?于某些場合或者某些應?，在這些場合中會遠遠勝過關系型數據庫和其他的NoSQL數據庫。常見的NoSQL數據庫分為以下?種。這?類數據庫主要會使?到?個散列表，這個表中有?個特定的鍵和?個指針指向特定的數據。鍵值模型對于IT系統來說，其優勢在于簡單、易部署。鍵值數據庫可以按照鍵對數據進?定位，還可以通過對鍵進?排序和分區，以實現更快速的數據定位。列族數據庫通常?來應對分布式存儲的海量數據。鍵仍然存在，但是它們的特點是指向了多個列，如圖所?。此列族數據庫表中由兩?組成，每??都有關鍵字RowKey，每??由多個列族組成，即Column-Family-1和Column-Family-2，?每個列族由多個列組成。?檔數據庫的靈感來?LotusNotes辦公軟件，它與鍵值數據庫類似。該類型的數據模型是版本化的?檔，?檔以特定的格式存儲，如JSON。?檔數據庫可以看作鍵值數據庫的升級版，允許之間嵌套鍵值，如圖所?。?檔數據庫?鍵值數據庫的查詢效率更?，因為?檔數據庫不僅可以根據鍵創建索引，同時還可以根據?檔內容創建索引。圖形數據庫來源于圖論中的拓撲學，以節點、邊及節點之間的關系來存儲復雜?絡中的數據，如圖所?。這種拓撲結構類似E-R圖，但在圖形模式中，關系和節點本?就是數據，?在E-R圖中，關系描述的是?種結構。內存數據庫主要是把磁盤的數據加載到內存中進?相應操作。與直接讀取磁盤數據相?，內存的數據讀取速度要?出?個數量級，因此，將數據保存在內存中能夠極?地提?應?的性能。內存數據庫改變了磁盤數據管理的傳統?式，基于全部數據都在內存中的特點重新設計了體系結構，并且在數據緩存、快速算法、并?操作??也進?了相應的升級，因此，其數據處理速度?般?傳統數據庫的數據處理速度快??倍。內存數據庫的最?特點是其應?數據常駐內存中，即活動事務只與實時內存數據庫的內存進?數據交流。常見的內存數據庫有Memcached、、SQLite、MicrosoftSQLServerCompact等。Memcached是LiveJournal旗下DangaInteractive公司的布拉德·菲茨帕特?克（BradFitzpatric）開發的?款，現在已被應?于Facebook、LiveJournal等公司?于提?Web服務質量。?前這款軟件流?于全球各地，經常被?來建?緩存項?，并以此分擔來?傳統數據庫的并發負載壓?。Memcached可以輕松應對?量同時出現的數據請求，?且它擁有獨特的?絡結構，在?作機制??，它還可以在內存中單獨開辟新的空間，建?HashTable，并對HashTable進?有效的管理。我們有時會見到Memcache和Memcached兩種不同的說法，為什么會有兩種名稱？其實Memcache是這個項?的名稱，?Memcached是它服務器端的主程序?件名。?個是項?名稱，另?個是主程序?件名。為什么要使?Memcached由于?站的?并發讀寫和對海量數據的處理需求，傳統的關系型數據庫開始出現瓶頸。關系型數據庫本?就是個龐然?物，處理過程?常耗時（如解析SQL語句、事務處理等）。如果對關系型數據庫進??并發讀寫（每秒上萬次的訪問），數據庫系統是?法承受的。對于?型的SNS?站（如Twitter、新浪微博），每天有上千萬條的數據產?。對關系型數據庫??，如果在?個有上億條數據的數據表中查找某條記錄，效率將?常低。使?Memcached就能很好地解決以上問題。多數Web應?都將數據保存到關系型數據庫中（如），Web服務器從中讀取數據并在瀏覽器中顯?。但隨著數據量的增?，訪問的集中，關系型數據庫的負擔就會加重，岀現響應緩慢、?站打開延遲時間長等問題。因此，使?Memcached的主要?的是通過??內存中緩存關系型數據庫的查詢結果，減少數據庫??被訪問的次數，以提?動態Web應?的速度，增強?站架構的并發能?和可擴展性。通過在事先規劃好的系統內存空間中臨時緩存數據庫中的各類數據，以達到減少前端業務服務對關系型數據庫的直接?并發訪問，從?達到提升?規模?站集群中動態服務的并發訪問能?。Web服務器讀取數據時先讀Memcached服務器，若Memcached沒有所需的數據，則向數據庫請求數據，然后Web再把請求到的數據發送到Memcached，如下圖所?。是?個開源的、?性能的、鍵值對。它通過提供多種鍵值數據類型來滿?不同場景下的存儲需求，并借助許多?層級的接?使其可以勝任如緩存、隊列系統等不同的??。本?節將介紹Redis的歷史和特性，以使讀者能夠快速地對Redis有?個全?的了解。2008年，意?利的?家創業公司Merzia推出了?款基于的?站實時統計系統——LLOOGG，然?沒過多久，該公司的創始?薩爾?托·桑菲利普（SalvatoreSanfilippo）便對這個系統的性能感到失望，于是他決定親?為LLOOGG量?定做?個數據庫，并于2009年開發完成，這個數據庫就是Redis。不過薩爾?托并不滿?只將Redis?于LLOOGG這?款產品，?是希望讓更多的?使?它，于是薩爾?托將Redis開源發布，并開始和Redis的另?名主要的代碼貢獻者?特·諾德胡斯（PieterNoordhuis）?起繼續著Redis的開發，直到今天。薩爾?托??也沒有想到，在短短的?年時間內，Redis就擁有了龐?的?戶群體。HackedNews在2012年發布了?份數據庫的使?情況調查，結果顯?有近12%的公司在使?Redis。國內如新浪微博和知乎，國外如GitHub、StackOverflow、Flickr、暴雪和Instagram，都是Redis的?戶。現在使?Redis的?戶越來越多，?多數的互聯?公司都使?Redis作為公共緩存。VMware公司從2010年開始贊助Redis的開發，薩爾?托和?特也分別于同年的3?和5?加?VMware，全職開發Redis。有過腳本語?編程經驗的讀者對字典（或稱映射、關聯數組）?定很熟悉，如在代碼dict[“key”]=“value”中，“diet”是?個字典結構變量，字符串“key”是鍵名，?“value”是鍵值，在字典中可以獲取或設置鍵名對應的鍵值，也可以刪除?個鍵。Redis是RemoteDictionaryServer（遠程字典服務器）的縮寫，它以字典結構存儲數據，并允許其他應?通過TCP讀寫字典中的內容。同?多數腳本語?中的字典?樣，Redis字典中的鍵值除了可以是字符串，還可以是其他數據類型。到?前為?，Redis?持的鍵值數據類型有：字符串類型、散列類型、列表類型、集合類型和有序集合類型。這種字典形式的存儲結構與常見的MySQL等關系數據庫的?維表形式的存儲結構有很?的差異。舉個例?，在程序中使?post變量存儲了?篇?章的數據（包括標題、正?、閱讀量和標簽），如下所?：post["tags"]=["PHP","Ruby","Node.js"]現在希望將這篇?章的數據存儲在數據庫中，并且要求可以通過標簽檢索岀?章。如果使?關系數據庫存儲，?般會將其中的標題、正?和閱讀量存儲在?個表中，?將標簽存儲在另?個表中，然后使?第三個表連接?章和標簽表。需要查詢時還需要連接三個表，不是很直觀。?Redis字典結構的存儲?式和對多種鍵值數據類型的?持使得開發者可以將程序中的數據直接映射到Redis中，數據在Redis中的存儲形式和其在程序中的存儲?式?常相似。使?Redis的另?個優勢是其對不同的數據類型提供了?常?便的操作?式，如使?集合類型存儲?章標簽，Redis可以對標簽進?如交集、并集等集合運算操作。Redis數據庫中的所有數據都存儲在內存中。由于內存的讀寫速度遠?于硬盤，因此Redis在性能上與其他基于硬盤存儲的數據庫相?有?常明顯的優勢。在?臺普通的筆記本電腦上，Redis可以在?秒內讀寫超過10萬個鍵值。將數據存儲在內存中也有問題，例如，程序退出后內存中的數據會丟失。不過Redis提供了對持久化的?持，即可以將內存中的數據異步寫?硬盤中，同時不影響其繼續提供服務。Redis雖然是作為數據庫開發的，但由于其提供了豐富的功能，越來越多的?將其?作緩存、隊列系統等。Redis可謂是名副其實的多??。Redis可以為每個鍵設置?存時間（TimeToLive,TTL），?存時間到期后鍵會?動被刪除。這?功能配合出?的性能讓Redis可以作為緩存系統來使?，?且由于Redis?持持久化和豐富的數據類型，使其成為另?個?常流?的緩存系統Memcached的有?競爭者。討論Redis和Memcached的優劣?直是?個熱門的話題。由于Redis是單線程模型，?Memcached?持多線程，所以在多核服務器上后者的性能更??些。然?，前?已經介紹過，Redis的性能已經?夠優異，在絕?部分場合下其性能都不會成為瓶頸。所以在使?時更應該關?的是?者在功能上的區別，如果需要?到?級的數據類型或持久化等功能，Redis將會是Memcached很好的替代品。作為緩存系統，Redis還可以限定數據占?的最?內存空間，在數據達到空間限制后可以按照?定的規則?動淘汰不需要的鍵。除此之外，Redis的列表類型鍵可以?來實現隊列，?持阻塞式讀取，并且可以很容易地實現?個?性能的優先級隊列。同時，在更?層?上，Redis還?持“發布/訂閱”的消息模式，?戶可以基于此構建聊天室等系統。如果?個?具使?起來太復雜，即使它的功能再豐富也很難吸引?。Redis直觀的存儲結構使其通過程序與Redis交互?分簡單。在Redis中使?命令來讀寫數據，命令語句之于Redis就相當于SQL之于關系數據庫。例如，在關系數據庫中要獲取posts表內id為1的記錄的title字段的值，可以使?如下SQL語句實現：SELECTtitleFROMpostsWHEREid=1LIMIT1相對應的，在Redis中要讀取鍵名為post:1的散列類型鍵的title字段的值，可以使?如下命令語句實現：HGETpost:1title其中，HGET就是?個命令。Redis提供了100多個命令，但是常?的只有??個，并且每個命令都很容易記住。Redis提供了??種不同編程語?的客戶端庫，這些庫都封裝了Redis的命令，這樣在程序中與Redis進?交互變得很容易。有些庫還提供了可以將編程語?中的數據類型直接以相應的形式存儲到Redis中（如將數組直接以列表類型存?Redis）的簡單?法，使?起來?常?便。Redis使?C語?開發，代碼量只有3萬多?。這降低了?戶通過修改Redis源代碼來使之更適合??項?需要的門檻。對于希望“榨?”數據庫性能的開發者??，這?疑具有很?的吸引?。Redis是開源的，有將近100名開發者為Redis貢獻了代碼。良好的開發氛圍和嚴謹的版本發布機制使得Redis的穩定版本的性能?常可靠，如此多的公司選擇使?Redis也可以印證這?點。與Memcached與Redis的?較見下表。數據庫MemcachedRedisCPU?持多核單核內存利?率持久性數據結構簡單?作環境Linux/WindowsLinux??低（壓縮?Memcached?）有（硬盤存儲，主從同步）復雜四、分布式系統分布式系統是由?組通過?絡進?通信、為了完成共同的任務?協調?作的計算機節點組成的系統。分布式系統的出現是為了?廉價的、普通的機器完成單個計算機?法完成的計算、存儲任務。其?的是利?更多的機器，處理更多的數據。?先需要明確的是，只有當單個節點的處理能??法滿??益增長的計算、存儲任務的時候，且硬件的提升（加內存、加磁盤、使?更好的CPU）?昂到得不償失的時候，應?程序也不能進?步優化的時候，我們才需要考慮分布式系統。因為，分布式系統要解決的問題本?就是和單機系統?樣的，?由于分布式系統多節點、通過?絡通信的拓撲結構，會引?很多單機系統沒有的問題，為了解決這些問題?會引?更多的機制、協議，帶來更多的問題。。。在很多?章中，主要講分布式系統分為分布式計算（computation）與分布式存儲（storage）。計算與存儲是相輔相成的，計算需要數據，要么來?實時數據（流數據），要么來?存儲的數據；?計算的結果也是需要存儲的。在操作系統中，對計算與存儲有?常詳盡的討論，分布式系統只不過將這些理論推?到多個節點罷了。那么分布式系統怎么將任務分發到這些計算機節點呢，很簡單的思想，分?治之，即分?（partition）。對于計算，那么就是對計算任務進?切換，每個節點算?些，最終匯總就?了，這就是MapReduce的思想；對于存儲，更好理解?下，每個節點存?部分數據就?了。當數據規模變?的時候，Partition是唯?的選擇，同時也會帶來?些好處：（1）提升性能和并發，操作被分發到不同的分?，相互獨?（2）提升系統的可?性，即使部分分?不能?，其他分?不會受到影響理想的情況下，有分?就?了，但事實的情況卻不?理想。原因在于，分布式系統中有?量的節點，且通過?絡通信。單個節點的故障（進程crash、斷電、磁盤損壞）是個?概率事件，但整個系統的故障率會隨節點的增加?指數級增加，?絡通信也可能出現斷?、?延遲的情況。在這種?定會出現的“異常”情況下，分布式系統還是需要繼續穩定的對外提供服務，即需要較強的容錯性。最簡單的辦法，就是冗余或者復制集（Replication），即多個節點負責同?個任務，最為常見的就是分布式存儲中，多個節點復雜存儲同?份數據，以此增強可?性與可靠性。同時，Replication也會帶來性能的提升，?如數據的locality可以減少?戶的等待時間。下?這種來?的圖形象?動說明了Partition與Replication是如何協作的。Partition和Replication是解決分布式系統問題的?記組合拳，很多具體的問題都可以?這個思路去解決。但這并不是銀彈，往往是為了解決?個問題，會引?更多的問題，?如為了可?性與可靠性保證，引?了冗余（復制集）。有了冗余，各個副本間的?致性問題就變得很頭疼，?致性在系統的?度和?戶的?度?有不同的等級劃分。如果要保證強?致性，那么會影響可?性與性能，在?些應?（?如電商、搜索）是難以接受的。如果是最終?致性，那么就需要處理數據沖突的情況。CAP、FLP這些理論告訴我們，在分布式系統中，沒有最佳的選擇，都是需要權衡，做出最合適的選擇。分布式系統挑戰分布式系統需要?量機器協作，?臨諸多的挑戰：第?，異構的機器與?絡：分布式系統中的機器，配置不?樣，其上運?的服務也可能由不同的語?、架構實現，因此處理能?也不?樣；節點間通過?絡連接，?不同?絡運營商提供的?絡的帶寬、延時、丟包率?不?樣。怎么保證?家齊頭并進，共同完成?標，這四個不?的挑戰。第?，普遍的節點故障：雖然單個節點的故障概率較低，但節點數?達到?定規模，出故障的概率就變?了。分布式系統需要保證故障發?的時候，系統仍然是可?的，這就需要監控節點的狀態，在節點故障的情況下將該節點負責的計算、存儲任務轉移到其他節點第三，不可靠的?絡：節點間通過?絡通信，??絡是不可靠的。可能的?絡問題包括：?絡分割、延時、丟包、亂序。相?單機過程調?，?絡通信最讓?頭疼的是超時：節點A向節點B發出請求，在約定的時間內沒有收到節點B的響應，那么B是否處理了請求，這個是不確定的，這個不確定會帶來諸多問題，最簡單的，是否要重試請求，節點B會不會多次處理同?個請求。總??之，分布式的挑戰來?不確定性，不確定計算機什么時候crash、斷電，不確定磁盤什么時候損壞，不確定每次?絡通信要延遲多久，也不確定通信對端是否處理了發送的消息。?分布式的規模放?了這個不確定性，不確定性是令?討厭的，所以有諸多的分布式理論、協議來保證在這種不確定性的情況下，系統還能繼續正常?作。?且，很多在實際系統中出現的問題，來源于設計時的盲?樂觀，覺得這個、那個應該不會出問題。很有意思，介紹了分布式系統新?可能的錯誤的假設：Thenetworkissecure.Topologydoesn’tchange.Thereisoneadministrator.Transportcostiszero.Thenetworkishomogeneous.劉杰在《分布式系統原理介紹》中指出，處理這些異常的最佳原則是：在設計、推導、驗證分布式系統的協議、流程時,最重要的?作之?就是思考在執?流程的每個步驟時?旦發?各種異常的情況下系統的處理?式及造成的影響。Adistributedsystemisacollectionofindependentcomputersthatappearstoitsusersasasinglecoherentsystem.可擴展性：分布式系統的根本?標就是為了處理單個計算機?法處理的任務，當任務增加的時候，分布式系統的處理能?需要隨之增加。簡單來說，要?較?便的通過增加機器來應對數據量的增長，同時，當任務規模縮減的時候，可以撤掉?些多余的機器，達到動態伸縮的效果可?性與可靠性：?般來說，分布式系統是需要長時間甚?7*24?時提供服務的。可?性是指系統在各種情況對外提供服務的能?，簡單來說，可以通過不可?時間與正常服務時間的必知來衡量；?可靠性?是指計算結果正確、存儲的數據不丟失。?性能：不管是單機還是分布式系統，?家都?常關注性能。不同的系統對性能的衡量指標是不同的，最常見的：?并發，單位時間內處理的任務越多越好；低延遲：每個任務的平均時間越少越好。這個其實跟操作系統CPU的調度策略很像?致性：分布式系統為了提?可?性可靠性，?般會引?冗余（復制集）。那么如何保證這些節點上的狀態?致，這就是分布式系統不得不?對的?致性問題。?致性有很多等級，?致性越強，對?戶越友好，但會制約系統的可?性；?致性等級越低，?戶就需要兼容數據不?致的情況，但系統的可?性、并發性很?很多。假設這是?個對外提供服務的?型分布式系統，?戶連接到系統，做?些操作，產??些需要存儲的數據，那么在這個過程中，會遇到哪些組件、理論與協議呢?戶使?Web、APP、SDK，通過HTTP、TCP連接到系統。在分布式系統中，為了?并發、?可?，?般都是多個節點提供相同的服務。那么，第?個問題就是具體選擇哪個節點來提供服務，這個就是負載均衡（loadbalance）。負載均衡的思想很簡單，但使??常?泛，在分布式系統、?型?站的????都有使?，或者說，只要涉及到多個節點提供同質的服務，就需要負載均衡。通過負載均衡找到?個節點，接下來就是真正處理?戶的請求，請求有可能簡單，也有可能很復雜。簡單的請求，?如讀取數據，那么很可能是有緩存的，即分布式緩存，如果緩存沒有命中，那么需要去數據庫拉取數據。對于復雜的請求，可能會調?到系統中其他的服務。承上，假設服務A需要調?服務B的服務，?先兩個節點需要通信，?絡通信都是建?在TCP/IP協議的基礎上，但是，每個應?都?寫socket是?件冗雜、低效的事情，因此需要應?層的封裝，因此有了HTTP、FTP等各種應?層協議。當系統愈加復雜，提供?量的http接?也是?件困難的事情。因此，有了更進?步的抽象，那就是RPC（