第1章 架構(gòu)基礎(chǔ)
系統(tǒng)泛指由一群有關(guān)聯(lián)的個(gè)體組成，根據(jù)某種規(guī)則運(yùn)作蹦漠，能完成個(gè)別元件不能單獨(dú)完成的工作的群體椭员。它的意思是“總體”“整體”或“聯(lián)盟”。
子系統(tǒng)也是由一群有關(guān)聯(lián)的個(gè)體所組成的系統(tǒng)笛园，多半是更大的系統(tǒng)中的一部分隘击。
軟件模塊（Module）是一套一致而互相緊密關(guān)聯(lián)的軟件組織。它分別包含了程序和數(shù)據(jù)結(jié)構(gòu)兩部分研铆。
軟件組件定義為自包含的埋同、可編程的、可重用的棵红、與語言無關(guān)的軟件單元凶赁，軟件組件可以很容易被用于組裝應(yīng)用程序中。
軟件框架（Software Framework）窄赋，通常指的是為了實(shí)現(xiàn)某個(gè)業(yè)界標(biāo)準(zhǔn)或完成特定基本任務(wù)的軟件組件規(guī)范哟冬，也指為了實(shí)現(xiàn)某個(gè)軟組件規(guī)范時(shí)，提供規(guī)范所要求之基礎(chǔ)功能的軟件產(chǎn)品忆绰。
軟件架構(gòu)指軟件系統(tǒng)的頂層結(jié)構(gòu)浩峡。
同一款軟件系統(tǒng)從不同的角度進(jìn)行分解，會(huì)得到不同的架構(gòu)错敢。
架構(gòu)設(shè)計(jì)的主要目的是為了解決軟件系統(tǒng)復(fù)雜度帶來的問題翰灾。
主要的軟件系統(tǒng)復(fù)雜度有高性能、高可用稚茅、可擴(kuò)展纸淮、低成本、安全亚享、規(guī)模幾種咽块。
第2章 架構(gòu)設(shè)計(jì)原則
架構(gòu)設(shè)計(jì)原則1：適合原則，適合的架構(gòu)優(yōu)于業(yè)界領(lǐng)先的架構(gòu)欺税。
真正優(yōu)秀的架構(gòu)都是在企業(yè)當(dāng)前人力侈沪、條件揭璃、業(yè)務(wù)等各種約束下設(shè)計(jì)出來的，能夠合理地將資源整合在一起并發(fā)揮出最大功效亭罪，并且能夠快速落地瘦馍。
架構(gòu)設(shè)計(jì)原則2：簡單原則，簡單的架構(gòu)優(yōu)于復(fù)雜的架構(gòu)应役。
軟件領(lǐng)域的復(fù)雜性體現(xiàn)在兩方面：結(jié)構(gòu)的復(fù)雜性情组、邏輯的復(fù)雜性。
架構(gòu)設(shè)計(jì)原則3：演化原則箩祥，架構(gòu)需要隨著業(yè)務(wù)的發(fā)展而不斷演化院崇。
對(duì)應(yīng)建筑來說，永恒是主題滥比；而對(duì)于軟件來說亚脆，變化才是主題。
軟件架構(gòu)設(shè)計(jì)類似于生物演化盲泛。
第3章 架構(gòu)設(shè)計(jì)流程
架構(gòu)設(shè)計(jì)的時(shí)候濒持，首先要分析出系統(tǒng)的復(fù)雜性。
架構(gòu)師根據(jù)自己對(duì)業(yè)務(wù)的理解寺滚，挑選適合的架構(gòu)模式進(jìn)行組合柑营，再對(duì)組合后的方案進(jìn)行修改和調(diào)整。
新技術(shù)都是在現(xiàn)有技術(shù)的基礎(chǔ)上發(fā)展起來的村视，現(xiàn)有技術(shù)又來源于先前的技術(shù)官套。
備選方案的數(shù)量以 3~5 個(gè)備選方案為最佳。
備選方案的差異要比較明顯蚁孔。
備選方案的技術(shù)不要只局限于已經(jīng)熟悉的技術(shù)奶赔。
通過 360 度環(huán)評(píng)的方式來評(píng)估備選方案。
按照質(zhì)量屬性的優(yōu)先級(jí)來判斷備選方案的優(yōu)劣杠氢。
架構(gòu)師需要對(duì)技術(shù)的細(xì)節(jié)和原理有較深入的理解站刑，避免成為“PPT架構(gòu)師”。
通過分析步驟鼻百、分階段绞旅、分系統(tǒng)等方式，盡量降低方案復(fù)雜度温艇。
采取設(shè)計(jì)團(tuán)隊(duì)的方式來進(jìn)行設(shè)計(jì)因悲，可以博采眾長，匯集團(tuán)隊(duì)經(jīng)驗(yàn)勺爱，減少思維和經(jīng)驗(yàn)盲區(qū)晃琳。
第4章 存儲(chǔ)高性能
高性能數(shù)據(jù)庫集群的第一種方式是“讀寫分離”，其本質(zhì)是講訪問壓力分散到集群中的多個(gè)節(jié)點(diǎn)，但是沒有分散存儲(chǔ)壓力蝎土。
數(shù)據(jù)庫讀寫分離需要考慮“復(fù)制延遲”帶來的復(fù)雜性视哑。
數(shù)據(jù)庫讀寫分離的分配機(jī)制有兩種實(shí)現(xiàn)方式：程序代碼封裝和中間件封裝。
高性能數(shù)據(jù)庫集群的第二種方式是“分庫分表”誊涯，既可以分散訪問壓力，又可以分散存儲(chǔ)壓力蒜撮。
業(yè)務(wù)分庫指的是按照業(yè)務(wù)模塊講數(shù)據(jù)分散到不同的數(shù)據(jù)庫服務(wù)器暴构。
業(yè)務(wù)分庫會(huì)引入 join 操作問題、事務(wù)問題段磨、成本問題三個(gè)復(fù)雜度相關(guān)的問題取逾。
數(shù)據(jù)庫分表分為垂直分表和水平分表。
垂直分表引入的復(fù)雜性重要體現(xiàn)在表操作數(shù)據(jù)要增加苹支。
水平分表引入了路由砾隅、join 操作、count() 操作债蜜、order by 操作等復(fù)雜問題晴埂。
K-V 存儲(chǔ)在數(shù)據(jù)結(jié)構(gòu)方面相比關(guān)系型數(shù)據(jù)庫具備較大的優(yōu)勢。
文檔數(shù)據(jù)庫最大的特點(diǎn)就是 no-schema寻定，可以存儲(chǔ)和讀取任意的數(shù)據(jù)儒洛。
列式存儲(chǔ)在某些場景下能夠大大節(jié)省 I/O。
列式存儲(chǔ)具備很高的壓縮比狼速，能夠節(jié)省存儲(chǔ)空間琅锻。
全文搜索引擎的基本原理是倒排索引。
為了讓全文索引引擎支持關(guān)系型數(shù)據(jù)的全文搜索向胡，需要做一些轉(zhuǎn)換操作恼蓬，即將關(guān)系型數(shù)據(jù)轉(zhuǎn)換為文檔數(shù)據(jù)。
緩存穿透是指當(dāng)業(yè)務(wù)系統(tǒng)查詢的數(shù)據(jù)在存儲(chǔ)系統(tǒng)中沒有的時(shí)候僵芹，每次查詢都會(huì)訪問存儲(chǔ)系統(tǒng)处硬。
緩存雪崩是指當(dāng)緩存失效（過期）后引起系統(tǒng)性能急劇下降的情況。
緩存熱點(diǎn)是指大部分甚至所有業(yè)務(wù)請求都命中同一份緩存數(shù)據(jù)淮捆。
第5章 計(jì)算高性能
PPC 模型：每次有新的連接就新建一個(gè)進(jìn)程去專門處理這個(gè)連接的請求郁油。
TPC 模型：每次有新的連接就新建一個(gè)線程去專門處理這個(gè)連接的請求。
Reactor 模型的基礎(chǔ)是 I/O多路復(fù)用攀痊。
Proactor 模型是非阻塞異步網(wǎng)絡(luò)模式桐腌。
常見的負(fù)載均衡系統(tǒng)有3種：DNS 負(fù)載均衡、硬件負(fù)載均衡和軟件負(fù)載均衡苟径。
DNS 是最簡單的也是最常見的負(fù)載均衡方式案站，一般用來實(shí)現(xiàn)地理級(jí)別的均衡。
硬件負(fù)載均衡用于實(shí)現(xiàn)集群級(jí)別的負(fù)載均衡棘街。
軟件負(fù)載均衡用于實(shí)現(xiàn)機(jī)器級(jí)別的負(fù)載均衡蟆盐。
負(fù)載均衡的算法分為：任務(wù)平分類承边、負(fù)載均衡類、性能最優(yōu)類和 Hash 類石挂。
第6章 CAP
CAP 理論三個(gè)核心要素：一致性博助、可用性、和分區(qū)容忍性痹愚。
CAP 理論指分布式系統(tǒng)中涉及讀寫操作時(shí)富岳，一致性、可用性拯腮、分區(qū)容忍性三個(gè)要素只能保證兩個(gè)窖式，另外一個(gè)必須被犧牲。
分布式系統(tǒng)理論上不可能選擇 CA 架構(gòu)动壤，只能選擇 CP 或 AP 架構(gòu)萝喘。
CAP 關(guān)注的粒度是數(shù)據(jù)，而不是整個(gè)系統(tǒng)琼懊。
CAP 是忽略網(wǎng)絡(luò)延遲的阁簸。
正常運(yùn)行情況下，不存在 CP 和 AP 的選擇肩碟，可以同時(shí)滿足 CA强窖。
CAP 中放棄某個(gè)要素并不等于什么都不做，需要為分區(qū)恢復(fù)后做準(zhǔn)備削祈。
ACID 的應(yīng)用場景是數(shù)據(jù)庫事務(wù)翅溺，CAP 關(guān)注的是分布式系統(tǒng)數(shù)據(jù)讀寫。
BASE 是 CAP 理論中 AP 方案的延伸髓抑。
第7章 FMEA
FMEA 是一種在各行各業(yè)都有廣泛應(yīng)用的可用性分析方法咙崎，通過對(duì)系統(tǒng)范圍內(nèi)潛在的故障模式加以分析，并按照嚴(yán)重程度進(jìn)行分類吨拍，以確定失效對(duì)于系統(tǒng)的最終影響褪猛。
FMEA 分析方法很簡單，就是一個(gè) FMEA 分析表羹饰。
FMEA 分析中的“功能點(diǎn)”是從用戶的角度來看的伊滋，而不是從系統(tǒng)各個(gè)模塊功能點(diǎn)劃分來看的。
FMEA 分析中的“故障模式”的描述要盡量精確队秩，多使用量化描述笑旺，避免使用泛化的描述。
FMEA 分析中“嚴(yán)重程序”指站在業(yè)務(wù)的角度馍资，故障的影響程度一般分為“致命/高/中/低/無”五個(gè)檔次筒主。
FMEA 分析中不同的“故障原因”發(fā)生概率、檢測手段和處理措施可能不同。
FMEA 分析中的“風(fēng)險(xiǎn)程度”就是綜合嚴(yán)重程度和故障概率來一起判斷某個(gè)故障的最終等級(jí)乌妙。
FMEA 分析中不一定所有的問題都要解決使兔，采取規(guī)避措施也可以。
第8章 存儲(chǔ)高可用
主備架構(gòu)中的“備機(jī)”主要還是起一個(gè)備份作用藤韵，并不承擔(dān)實(shí)際的業(yè)務(wù)讀寫操作虐沥。
主從架構(gòu)中的主機(jī)負(fù)責(zé)讀寫操作，從機(jī)只負(fù)責(zé)讀操作荠察，不負(fù)責(zé)寫操作置蜀。
主備倒換和主從倒換架構(gòu)的復(fù)雜點(diǎn)主要體現(xiàn)在：狀態(tài)判斷、倒換決策和數(shù)據(jù)沖突修復(fù)三個(gè)方面悉盆。
主主復(fù)制架構(gòu)必須保證數(shù)據(jù)能夠雙向復(fù)制，而很多數(shù)據(jù)是不能雙向復(fù)制的馋吗。
根據(jù)集群中機(jī)器承擔(dān)的不同角色來劃分焕盟，集群可以分為兩類：數(shù)據(jù)集中集群、數(shù)據(jù)分散集群宏粤。
數(shù)據(jù)集中集群可以看作一主多備或一主多從脚翘，但復(fù)雜度比主備或主從要高出很多。
數(shù)據(jù)分散集群中每臺(tái)服務(wù)器都會(huì)負(fù)責(zé)存儲(chǔ)一部分?jǐn)?shù)據(jù)绍哎，同時(shí)也會(huì)備份一部分?jǐn)?shù)據(jù)来农。
數(shù)據(jù)分區(qū)主要應(yīng)對(duì)地理級(jí)別的故障。
數(shù)據(jù)分區(qū)的復(fù)制規(guī)則分為集中式崇堰、互備式和獨(dú)立式沃于。
第9章 計(jì)算高可用
主備架構(gòu)是計(jì)算高可用最簡單的架構(gòu)，可以細(xì)分為冷備架構(gòu)和溫備架構(gòu)海诲，常用溫備架構(gòu)繁莹。
計(jì)算高可用的主備架構(gòu)也比較適合與內(nèi)部管理系統(tǒng)、后臺(tái)管理系統(tǒng)這類使用人數(shù)不多特幔、使用頻率不高的業(yè)務(wù)咨演，不太適合在線的業(yè)務(wù)。
主從架構(gòu)與主備架構(gòu)相比蚯斯，發(fā)揮了硬件的性能薄风，但設(shè)計(jì)要復(fù)雜一些。
高可用計(jì)算的集群根據(jù)集群中服務(wù)器節(jié)點(diǎn)角色的不同拍嵌，可以分為對(duì)稱集群和非對(duì)稱集群遭赂。
對(duì)稱集群中每個(gè)服務(wù)器的角色都一樣的，都可以執(zhí)行所有任務(wù)撰茎。
非對(duì)稱集群中的服務(wù)器分為多個(gè)不同的角色嵌牺，不同角色執(zhí)行不同的任務(wù)。
非對(duì)稱集群比負(fù)載均衡集群，設(shè)計(jì)復(fù)雜度主要體現(xiàn)在任務(wù)分配策略和角色分配策略會(huì)更加復(fù)雜逆粹。
第10章 業(yè)務(wù)高可用
異地多活架構(gòu)的關(guān)鍵點(diǎn)就是異地募疮、多活，其中異地就是指地理位置上不同的地方僻弹，多活就是指不同地理位置上的系統(tǒng)都能提供業(yè)務(wù)服務(wù)阿浓。
異地多活雖然功能強(qiáng)大，但也不是每個(gè)業(yè)務(wù)不管三七二十一都要上異地多活蹋绽。
如果業(yè)務(wù)規(guī)模很大芭毙，能夠做異地多活的情況盡量實(shí)現(xiàn)異地多活。
異地多活架構(gòu)可以分為同城異地卸耘、跨城異地退敦、跨國異地。
同城異區(qū)指的是將業(yè)務(wù)部署在同一個(gè)城市不同區(qū)的多個(gè)機(jī)房蚣抗。
同城異區(qū)的兩個(gè)機(jī)房能夠?qū)崿F(xiàn)和同一個(gè)機(jī)房內(nèi)幾乎一樣的網(wǎng)絡(luò)傳輸速度侈百，這就意味著雖然是兩個(gè)不同地理位置上機(jī)房，但邏輯上我們可以將它們看作是同一個(gè)機(jī)房翰铡。
跨城異地指的是業(yè)務(wù)部署在不同城市的多個(gè)機(jī)房钝域，而且距離最好遠(yuǎn)一些。
跨城異地距離較遠(yuǎn)帶來的網(wǎng)絡(luò)傳輸延遲問題锭魔，給業(yè)務(wù)多活架構(gòu)設(shè)計(jì)帶來了復(fù)雜性例证。
跨國異地指的是將業(yè)務(wù)部署在不同國家的多個(gè)機(jī)房。
跨國異地主要適應(yīng)兩種場景：為不同地區(qū)的用戶提供服務(wù)迷捧，為全球用戶提供只讀服務(wù)织咧。
異地多活設(shè)計(jì)技巧一：保證核心業(yè)務(wù)的異地多活。
異地多活設(shè)計(jì)技巧二：保證核心數(shù)據(jù)最終一致性党涕。
異地多活設(shè)計(jì)技巧三：采用多種手段同步數(shù)據(jù)烦感。
異地多活設(shè)計(jì)技巧四：只保證絕大部分用戶的異地多活。
接口級(jí)故障的主要應(yīng)對(duì)方案：降級(jí)膛堤、熔斷手趣、限流、排隊(duì)肥荔。
降級(jí)的核心思想就是丟車保帥绿渣，優(yōu)先保證核心業(yè)務(wù)。
限流指只允許系統(tǒng)能夠承受的用戶量進(jìn)來訪問燕耿，超出系統(tǒng)訪問能力的用戶將被拋棄中符。
排隊(duì)實(shí)際上是限流的一種變種，限流是直接拒絕用戶誉帅，排隊(duì)是讓用戶等待很長時(shí)間淀散。
第11章 可擴(kuò)展模式
軟件系統(tǒng)與硬件系統(tǒng)和建筑系統(tǒng)最大的差異在于軟件是可擴(kuò)展的右莱。
真正有生命力的軟件系統(tǒng)都是在不斷迭代和發(fā)展的。
所有可擴(kuò)展性架構(gòu)設(shè)計(jì)档插，背后的基本思想都可以總結(jié)為一個(gè)字：拆慢蜓。
拆分軟件系統(tǒng)的方式有三種：面向流程拆分、面向服務(wù)拆分和面向功能拆分郭膛。
不同的拆分方式將得到不同的系統(tǒng)架構(gòu)晨抡。
第12章 分層架構(gòu)
分層架構(gòu)是很常見的架構(gòu)模式，也叫N層架構(gòu)则剃，通常情況下耘柱，N至少是2層，一般不超過5層棍现。
C/S架構(gòu)寂玲、B/S架構(gòu)劃分的對(duì)象是整個(gè)業(yè)務(wù)系統(tǒng)搞隐，劃分的維度是用戶交互遥倦。
MVC架構(gòu)孝治，MVP架構(gòu)劃分的對(duì)象是單個(gè)業(yè)務(wù)子系統(tǒng)省咨，劃分的維度是職責(zé)想鹰，將不同的職責(zé)劃分到獨(dú)立層黔牵。
邏輯分層架構(gòu)劃分的對(duì)象可以是單個(gè)業(yè)務(wù)子系統(tǒng)斗蒋，也可以是整個(gè)業(yè)務(wù)系統(tǒng)坚洽，劃分的維度也是職責(zé)戈稿。
無論采用何種分層維度，分層架構(gòu)設(shè)計(jì)最核心的一點(diǎn)就是需要保證各層之間的差異足夠清晰讶舰，邊界足夠明顯鞍盗。
分層架構(gòu)之所以能夠較好地支撐系統(tǒng)擴(kuò)展，本質(zhì)在于：隔離關(guān)鍵點(diǎn)跳昼。
分層架構(gòu)的一個(gè)特點(diǎn)就是層層傳遞般甲。
分成架構(gòu)一個(gè)典型的缺點(diǎn)就是性能。
第13章 SOA 架構(gòu)
SOA 提出的背景是企業(yè)內(nèi)部的IT系統(tǒng)重復(fù)建設(shè)且效率低下鹅颊。
SOA 更多的是在傳統(tǒng)企業(yè)（例如敷存，制造業(yè)、金融業(yè)等）落地和推廣堪伍，在互聯(lián)網(wǎng)行業(yè)并沒有大規(guī)模的實(shí)踐和推廣锚烦。
SOA 三個(gè)關(guān)鍵概念：服務(wù)、ESB和松耦合帝雇。
SOA 架構(gòu)中涮俄，每項(xiàng)業(yè)務(wù)功能都是一項(xiàng)服務(wù)，服務(wù)就意味著要對(duì)外提供開發(fā)的能力尸闸。
SOA 使用 ESB 來屏蔽異構(gòu)系統(tǒng)對(duì)外提供各種不同的接口方式彻亲，以此來達(dá)到服務(wù)間高效的互聯(lián)互通孕锄。
SOA 解決了傳統(tǒng) IT 系統(tǒng)重復(fù)建設(shè)和擴(kuò)展效率低的問題，但其本身也引入了更多的復(fù)雜性苞尝，SOA 最廣為人詬病的就是 ESB畸肆。
SOA 的 ESB 設(shè)計(jì)也是無奈之舉，企業(yè)在應(yīng)用 SOA 時(shí)野来，各種異構(gòu)的IT系統(tǒng)都已經(jīng)存在很多年了恼除，完全重寫或按照統(tǒng)一標(biāo)準(zhǔn)進(jìn)行改造的成本是非常大的，只能通過 ESB 方式去適應(yīng)已經(jīng)存在的各種異構(gòu)系統(tǒng)曼氛。
第14章 微服務(wù)
微服務(wù)概念的歷史要早得多豁辉，也不是 Martin Flower 創(chuàng)造出來的，Martin 只是將微服務(wù)進(jìn)行了系統(tǒng)的闡述舀患。
微服務(wù)是一種和SOA相似但本質(zhì)上不同的架構(gòu)理念徽级。
微服務(wù)的三個(gè)關(guān)鍵詞：small、lightweight聊浅、automated餐抢。
微服務(wù)和SOA不存在孰優(yōu)孰劣，只是應(yīng)用場景不同低匙。
微服務(wù)并不是沒有代價(jià)旷痕，而且會(huì)帶來系統(tǒng)復(fù)雜度、運(yùn)維復(fù)雜度顽冶、性能下降等問題欺抗。
微服務(wù)拆分的粒度遵循“三個(gè)火槍手”原則。
真正決定微服務(wù)成敗的强重，恰恰是那個(gè)被大部分人都忽略的“automated”绞呈，而不是“small”和“l(fā)ightweight”。
微服務(wù)并不是很多人認(rèn)為的那樣又簡單又輕量級(jí)间景，要做好微服務(wù)佃声，基礎(chǔ)設(shè)施是必不可少的。
第15章 微內(nèi)核架構(gòu)
微內(nèi)核架構(gòu)也被稱為插件化架構(gòu)(Plug-in Architecture),是一種面向功能進(jìn)行拆分的可擴(kuò)展性架構(gòu)倘要。
第16章 消息隊(duì)列設(shè)計(jì)實(shí)戰(zhàn)
識(shí)別復(fù)雜度對(duì)架構(gòu)師來說是一項(xiàng)挑戰(zhàn)圾亏，因?yàn)樵嫉男枨笾胁]有哪個(gè)地方會(huì)明確地說復(fù)雜度在哪里，需要架構(gòu)師在理解需求的基礎(chǔ)上進(jìn)行分析碗誉。
有經(jīng)驗(yàn)的架構(gòu)師可能一看需求就知道復(fù)雜度大概在哪里召嘶，如果經(jīng)驗(yàn)不足，則只能采取“排查法”哮缺，從不同的角度逐一進(jìn)行分析弄跌。
架構(gòu)師關(guān)注的不是一天的數(shù)據(jù)，而是一秒的數(shù)據(jù)尝苇，即 TPS 和 QPS铛只。
備選方案的選擇和很多因素相關(guān)埠胖，并不單單考慮性能高低、技術(shù)是否優(yōu)越這些純技術(shù)因素淳玩，業(yè)務(wù)的需求特點(diǎn)直撤、運(yùn)維團(tuán)隊(duì)的經(jīng)驗(yàn)、已有的技術(shù)體系蜕着、團(tuán)隊(duì)人員的技術(shù)水平都會(huì)影響備選方案的選擇谋竖。
架構(gòu)設(shè)計(jì)的目的不是證明自己（參考架構(gòu)設(shè)計(jì)原則1：適合原則），而是更快更好地滿足業(yè)務(wù)需求承匣。
第17章 互聯(lián)網(wǎng)架構(gòu)演進(jìn)
產(chǎn)品類業(yè)務(wù)：技術(shù)創(chuàng)新推動(dòng)業(yè)務(wù)發(fā)展蓖乘。
“服務(wù)”類業(yè)務(wù)：業(yè)務(wù)發(fā)展推動(dòng)技術(shù)的發(fā)展。
架構(gòu)師需要基于業(yè)務(wù)發(fā)展階段判斷出系統(tǒng)當(dāng)前面臨的主要復(fù)雜度韧骗。
互聯(lián)網(wǎng)業(yè)務(wù)千差萬別嘉抒，但都具有“規(guī)模決定一切”的特點(diǎn)。
互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展一般分為幾個(gè)時(shí)期：初創(chuàng)期袍暴、快速發(fā)展期些侍、競爭期、成熟期政模。
互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展第一個(gè)主要方向就是“業(yè)務(wù)越來越復(fù)雜”岗宣。
互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展的第二個(gè)主要方向就是“用戶量越來越大”。
互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展帶來復(fù)雜度的本質(zhì)原因其實(shí)都是“量變帶來質(zhì)變”淋样。
第18章 物聯(lián)網(wǎng)架構(gòu)模板
NoSQL 不是 No SQL狈定，而是 Not Only SQL，即 NoSQL 是 SQL 的補(bǔ)充习蓬。
NoSQL 發(fā)展到一定規(guī)模后，一般都是走集群路線措嵌。
在開源方案的基礎(chǔ)上封裝一個(gè)小文件存儲(chǔ)平臺(tái)并不是太難的事情躲叼。
大數(shù)據(jù)存儲(chǔ)和處理反而是最簡單的，因?yàn)槟銊e無選擇企巢，只能用這幾個(gè)流行的開源方案枫慷。
框架的選擇，有一個(gè)總的原則：優(yōu)選成熟的框架浪规，避免盲目追逐新技術(shù)或听！
互聯(lián)網(wǎng)行業(yè)基本上都是“拿來主義”，挑選一個(gè)流行的開源服務(wù)即可笋婿。
配置中心主要為了解決系統(tǒng)數(shù)量增多后配置管理復(fù)雜和效率低下的問題誉裆。
服務(wù)中心目的是解決跨系統(tǒng)依賴的“配置”和“調(diào)度”問題。
消息隊(duì)列目的是為了實(shí)現(xiàn)跨系統(tǒng)異步通知缸濒。
DNS 是最簡單也是最常見的負(fù)載均衡方式足丢，一般用來實(shí)現(xiàn)地理級(jí)別的均衡粱腻。
Nginx & LVS & F5 用于同一地點(diǎn)內(nèi)機(jī)器級(jí)別的負(fù)載均衡。
CDN 是為了解決用戶網(wǎng)絡(luò)訪問時(shí)的“最后一公里”效應(yīng)斩跌，本質(zhì)上是一種“以空間換時(shí)間”的加速策略绍些。
多機(jī)房設(shè)計(jì)最核心的設(shè)計(jì)因素就是如何處理時(shí)延帶來的影響。
多中心必須以多機(jī)房為前提耀鸦，但從設(shè)計(jì)的角度來看柬批，多中心相比多機(jī)房是本質(zhì)上的飛越，難度也高出一個(gè)等級(jí)袖订。
用戶管理系統(tǒng)兩個(gè)核心職責(zé)：單點(diǎn)登錄和第三方授權(quán)登錄氮帐。
消息推送主要包含 3 個(gè)功能：設(shè)備管理（唯一標(biāo)識(shí)、注冊和注銷）著角、連接管理和消息管理揪漩。
除非 BAT 級(jí)別，一般不建議自己再重復(fù)造輪子了吏口，直接買圖片云和存儲(chǔ)云服務(wù)可能是最快又最經(jīng)濟(jì)的方式奄容。
業(yè)務(wù)層降低復(fù)雜性最好的方式就是“拆”，化整為零产徊、分而治之昂勒，將整體復(fù)雜性分散到多個(gè)子業(yè)務(wù)或子系統(tǒng)里面去。
運(yùn)維平臺(tái)核心的職責(zé)分為四大塊：配置舟铜、部署戈盈、監(jiān)控和應(yīng)急。
測試平臺(tái)的核心目的是提升測試效率谆刨，從而提升產(chǎn)品質(zhì)量塘娶，其設(shè)計(jì)關(guān)鍵就是自動(dòng)化。
數(shù)據(jù)平臺(tái)的核心職責(zé)主要包括三個(gè)部分：數(shù)據(jù)管理痊夭、數(shù)據(jù)分析和數(shù)據(jù)應(yīng)用刁岸。
管理平臺(tái)的核心職責(zé)就是權(quán)限管理。
第19章 架構(gòu)重構(gòu)
期望通過架構(gòu)重構(gòu)來解決所有問題當(dāng)然是不現(xiàn)實(shí)的她我。
架構(gòu)師的首要任務(wù)是從一大堆紛繁復(fù)雜的問題中識(shí)別出真正要通過架構(gòu)重構(gòu)來解決的問題虹曙，集中力量快速解決，而不是想著通過架構(gòu)重構(gòu)來解決所有問題番舆。
真正推動(dòng)一個(gè)架構(gòu)重構(gòu)項(xiàng)目啟動(dòng)酝碳，需要花費(fèi)大量的精力進(jìn)行游說和溝通。
架構(gòu)重構(gòu)溝通協(xié)調(diào)時(shí)恨狈，將技術(shù)語音轉(zhuǎn)換為通俗語言疏哗，以事實(shí)說話，以數(shù)據(jù)說話禾怠，是溝通的關(guān)鍵沃斤。
架構(gòu)重構(gòu)涉及關(guān)聯(lián)方配合時(shí)圣蝎，有效的溝通策略是“換位思考、合作雙贏衡瓶、關(guān)注長期”徘公。
架構(gòu)重構(gòu)需要采取“分段實(shí)施”策略，將要解決的問題根據(jù)優(yōu)先級(jí)哮针、重要性关面、實(shí)施難度等劃分為不同階段，每個(gè)階段聚焦于一個(gè)整體的目標(biāo)十厢。
真正的架構(gòu)師等太，必須具備一定的項(xiàng)目經(jīng)理技能，但更重要的還是技術(shù)能力蛮放。
第20章 開源系統(tǒng)
選開源方案時(shí)缩抡，聚焦于是否滿足業(yè)務(wù)，而不需要過于關(guān)注開源方案是否優(yōu)秀包颁。
選擇開源項(xiàng)目時(shí)瞻想，盡量選擇成熟的開源項(xiàng)目。
選擇開源項(xiàng)目時(shí)娩嚼，除了關(guān)注技術(shù)指標(biāo)蘑险，還要關(guān)注運(yùn)維能力。
開源項(xiàng)目不能簡單“拿來主義”岳悟，而要深入研究和仔細(xì)測試佃迄。
使用開源項(xiàng)目時(shí)對(duì)線上環(huán)境和風(fēng)險(xiǎn)要有敬畏之心，小心應(yīng)用贵少，灰度發(fā)布呵俏。
無論什么開源方案，都需要考慮應(yīng)急的備選方案滔灶。
如果需要修改開源系統(tǒng)柴信，不要改動(dòng)原系統(tǒng)，而是要開發(fā)輔助系統(tǒng)宽气。
選與不選開源項(xiàng)目，核心還是成本和收益問題潜沦，并不是說選擇開源項(xiàng)目就一定是最優(yōu)的方案萄涯。
