架構(gòu)設(shè)計原則
常見架構(gòu)設(shè)計方案質(zhì)量屬性點有：性能蟹略、可用性挖炬、硬件成本、項目投入、復(fù)雜度空闲、安全性碴倾、可擴展性等掉丽。在評估這些質(zhì)量屬性時捶障，需要遵循架構(gòu)設(shè)計原則：1.合適原則项炼，2簡單原則示绊，避免貪大求全面褐，基本上某個質(zhì)量屬性能夠滿足以 一定時期業(yè)務(wù)發(fā)展就可以了取胎。
屬性 | 集群方案 | 拆分方案 | 備注 ---|---|---|--- 性能 | 中闻蛀，繼續(xù)擴展下去循榆，MySQL會成為瓶頸 | 高，系統(tǒng)拆分為子系統(tǒng)映挂，子系統(tǒng)又可以做成集群方案 | 拆分方案優(yōu) | 復(fù)雜度 | 低柑船，只需要引入Nginx做負載均衡 | 高鞍时，需要對系統(tǒng)和數(shù)據(jù)庫進行拆分 | 集群方案優(yōu) 成本 | 中扣蜻，需要增加web服務(wù)器 | 中莽使，需要增加web服務(wù)器和MySQL服務(wù)器芳肌，單MySQL服務(wù)器物流上可以共用亿笤，邏輯上分開即可| 集群方案稍微優(yōu)一點 可擴展 | 低，所有的功能繼續(xù)在同一個系統(tǒng)實現(xiàn)汪榔，系統(tǒng)會越來越復(fù)雜揍异，擴展越來越難 | 高，系統(tǒng)按照追責(zé)拆分為多個字系統(tǒng)辱姨，每個子系統(tǒng)可單獨擴展 | 拆分方案優(yōu) 可用性| 中雨涛，web服務(wù)器是集群模式替久，單MySQL是單點的躏尉，MySQL故障回你導(dǎo)致整個業(yè)務(wù)不可用 | 高胀糜，子系統(tǒng)是獨立的教藻，某個子系統(tǒng)故障不會導(dǎo)致整個業(yè)務(wù)不可用 | 拆分方案優(yōu)
Eg:架構(gòu)師選擇了Elasticsearch作為全文搜索解決方案括堤，前提必須是架構(gòu)師自己對Elasticsearch的設(shè)計原理有深入的理解，比如索引讥电、副本允趟、集群等技術(shù)點；而不能道聽途說Elasticsearch很牛分唾，所以你選擇它绽乔，更不能成為把“細節(jié)我們不討論”這句話掛在嘴邊的“PPT架構(gòu)師”碳褒。
架構(gòu)設(shè)計流程總結(jié)：
設(shè)計架構(gòu)的時候，首先要分析出系統(tǒng)的復(fù)雜性两芳。
架構(gòu)師根據(jù)自己對業(yè)務(wù)的理解怖辆，挑選合適的架構(gòu)模式進行組合竖螃，再對組合后的方案進行修改和調(diào)整逗余。
新技術(shù)都是在現(xiàn)有技術(shù)的基礎(chǔ)上發(fā)展起來的录粱，現(xiàn)有技術(shù)又源于先前的技術(shù)关摇。
備選方案的數(shù)量以3～5個備選方案為最佳输虱。
備選方案的差異要比較明顯。
備選方案的技術(shù)不要只局限于已經(jīng)熟悉的技術(shù)愁茁。
通過360度環(huán)評的方式來評估備選方案鹅很。
按照質(zhì)量屬性的優(yōu)先級來判斷備選方案的優(yōu)劣促煮。
架構(gòu)師需要對技術(shù)的細節(jié)和原理有較深入的理解，避免成為“PPT架構(gòu)師”整袁。
通過分步驟菠齿、分階段、分系統(tǒng)等方式坐昙，盡量降低方案復(fù)雜度绳匀。
采取設(shè)計團隊的方式來進行設(shè)計，可以博采眾長，匯集團隊經(jīng)驗疾棵，減少思維和經(jīng)驗盲區(qū)戈钢。
存儲高性能總結(jié)：
高性能數(shù)據(jù)庫集群的第一種方式是“讀寫分離”，其本質(zhì)是將訪問壓力分散到集群中的多個節(jié)點殉了，但是沒有分散存儲壓力。
數(shù)據(jù)庫讀寫分流需要考慮“復(fù)制延遲”帶來的復(fù)雜性嗜历。
數(shù)據(jù)庫讀寫分離的分配機制有兩種方式：程序代碼封裝和中間件封裝宣渗。
高性能數(shù)據(jù)庫集群的第二種方式是“分庫分表”，就可以分散訪問壓力梨州，又可以分散存儲壓力痕囱。
業(yè)務(wù)分庫指的是按照業(yè)務(wù)模塊將數(shù)據(jù)分散到不同的數(shù)據(jù)庫服務(wù)器。
業(yè)務(wù)分庫會引起join操作問題暴匠、事務(wù)問題鞍恢、成本問題三個復(fù)雜度相關(guān)的問題。
數(shù)據(jù)庫分表分為垂直分表和水平分表每窖。
垂直分表引入的復(fù)雜性主要體現(xiàn)在表操作的數(shù)量要增加帮掉。
水平分表引入了路由、join操作窒典、count()操作蟆炊、order by操作等復(fù)雜度問題。
K-V存儲在數(shù)據(jù)結(jié)構(gòu)方面相比關(guān)系型數(shù)據(jù)庫具備較大優(yōu)勢瀑志。
文檔數(shù)據(jù)庫最大的特點就是no-schema涩搓，可以存儲和讀取任意的數(shù)據(jù)。
列式存儲在某些場景下能夠大大節(jié)省I/O劈猪。
列式存儲具備很高的壓縮比昧甘，能夠節(jié)省存儲空間。
全文搜索引擎的基本源流是倒排索引战得。
為了讓全文搜索引擎支持關(guān)系型數(shù)據(jù)的全文搜索充边，需要做一些轉(zhuǎn)換操作，即將關(guān)系型數(shù)據(jù)轉(zhuǎn)換為文檔數(shù)據(jù)常侦。
緩存穿透是指業(yè)務(wù)系統(tǒng)查詢的數(shù)據(jù)在緩存系統(tǒng)中沒有的時候浇冰，每次查詢都會訪問存儲系統(tǒng)。
緩存雪崩是指當(dāng)緩存失效（過期）后引起系統(tǒng)性能急劇下降的情況聋亡。
緩存熱點指大部分甚至所有業(yè)務(wù)請求都命中同一份緩存數(shù)據(jù)湖饱。
計算高性能總結(jié)：
RPC模型：每次有新的連接就新建一個進程去專門處理這個連接請求。
TPC模型：每次有新的連接就新建一個線程去專門處理這個連接的請求杀捻。
Reactor模型的基礎(chǔ)是I/O多路復(fù)用。
Proactor模型是非阻塞異步網(wǎng)絡(luò)模式。
常見的負載均衡系統(tǒng)有3種：DNS負載均衡致讥、硬件負載均衡和軟件負載均衡仅仆。
硬件負載均衡用于實現(xiàn)集群級別的負載均衡。
軟件負載均衡用于實現(xiàn)機器級別的負載均衡垢袱。
負載均衡算法分為：任務(wù)平分類墓拜、負載均衡類、性能最優(yōu)類和Hash類请契。
CAP總結(jié)：
CAP理論三個核心要素：一致性咳榜、可用性和分區(qū)容忍性。
CAP理論指分布式系統(tǒng)中涉及讀寫操作時爽锥，一致性涌韩、可用性、分區(qū)容忍性三個要素只能保證兩個氯夷，另外一個必須被犧牲臣樱。
分布式系統(tǒng)理論上不可能選擇CA架構(gòu)，只能選擇CP或AP架構(gòu)腮考。
CAP關(guān)注的粒度是數(shù)據(jù)雇毫，而不是整個系統(tǒng)。
CAP是忽略網(wǎng)絡(luò)延遲的踩蔚。
正常運行的情況下棚放，不存在CP和AP的選擇，可以同時滿足CA馅闽。
CAP中放棄某個要素并不等于什么都不做飘蚯，需要為分區(qū)恢復(fù)后做準(zhǔn)備。
ACID的應(yīng)用場景是數(shù)據(jù)庫事務(wù)捞蛋，CAP關(guān)注的是分布式系統(tǒng)數(shù)據(jù)讀寫孝冒。
BASE是CAP理論中的AP方案的延伸。
FMEA總結(jié)：
FMEA是一種在各行各業(yè)都有廣泛應(yīng)用的可用性分析方法拟杉，通過對系統(tǒng)范圍內(nèi)潛在的故障模式加以分析庄涡，并按照嚴(yán)重程度進行分類，以確保失效對于系統(tǒng)的最終影響搬设。
FMEA分析方法很簡單穴店，就是一個FMEA分析表。
FMEA分析中的“功能點”是從用戶的角度來看的拿穴，而不是從系統(tǒng)各個模塊功能點劃分來看的泣洞。
FMEA分析中的“故障模式”的描述要盡量精確，多使用量化描述默色，避免使用泛化的描述球凰。
FMEA分析中的“嚴(yán)重程序”指站在業(yè)務(wù)的角度，故障的影響程度一般分為“致命/高/中/低/無“五個檔次。
FMEA分析中不同的”故障原因“發(fā)生概率呕诉、檢測手段和處理措施可能不同缘厢。
FMEA分析中的”風(fēng)險程度“就是綜合嚴(yán)重程度和故障概率來一起判斷某個故障的最終等級。
FMEA分析中不一定所有的問題都要解決甩挫，采取規(guī)避措施也可以贴硫。
存儲高可用總結(jié)：
主備架構(gòu)中的”備機“主要還是起一個備份作用，并不承擔(dān)實際的業(yè)務(wù)讀寫操作伊者。
主從架構(gòu)中的主機負責(zé)讀寫操作英遭，從機只負責(zé)讀操作，不負責(zé)寫操作亦渗。
主備倒換和主從倒換架構(gòu)的復(fù)雜點主要體現(xiàn)在：狀態(tài)判斷挖诸、倒換決策和數(shù)據(jù)沖突修復(fù)三方面。
主主復(fù)制架構(gòu)必須保證數(shù)據(jù)能夠雙向復(fù)制央碟，而很多數(shù)據(jù)是不能雙向復(fù)制的税灌。
根據(jù)集群中機器承擔(dān)的不同角色來劃分，集群可以分為兩類：數(shù)據(jù)集中集群亿虽、數(shù)據(jù)分散集群菱涤。
數(shù)據(jù)集中集群可以看作一主多備或一主多從，但復(fù)雜度比主備或主從要高出很多洛勉。
數(shù)據(jù)分散集群中每臺服務(wù)器都會負責(zé)存儲一部分?jǐn)?shù)據(jù)和同時也會備份一部分?jǐn)?shù)據(jù)粘秆。
數(shù)據(jù)分區(qū)主要應(yīng)對地理級別的故障。
數(shù)據(jù)分區(qū)的復(fù)制規(guī)則分為集中式收毫、互備式和獨立式攻走。
計算高可用總結(jié)：
主備架構(gòu)時計算高可用最簡單的架構(gòu)，可以細分為冷備結(jié)構(gòu)和溫備架構(gòu)此再，常用溫備架構(gòu)昔搂。
計算高可用的主備架構(gòu)也比較適合與內(nèi)部管理系統(tǒng)、后臺管理系統(tǒng)這類使用人數(shù)不多输拇、使用頻率不高的業(yè)務(wù)摘符，不太適合在線的業(yè)務(wù)。
主從架構(gòu)與主備架構(gòu)相比策吠，發(fā)揮了硬件的性能逛裤，但設(shè)計要復(fù)雜一些。
高可用計算的集群根據(jù)集群中服務(wù)器節(jié)點角色的不同猴抹，可以分為對稱集群和非對稱集群带族。
對稱集群中每臺服務(wù)器的角色都是一樣的，都可以執(zhí)行所有任務(wù)蟀给。
非對稱集群中的服務(wù)器分為多個不同的角色蝙砌，不同角色執(zhí)行不同的任務(wù)阳堕。
非對稱集群相比負載均衡集群，設(shè)計復(fù)雜度主要體現(xiàn)在任務(wù)分配策略和角色分配策略會更加復(fù)雜择克。
業(yè)務(wù)高可用總結(jié)：
異地多活架構(gòu)的關(guān)鍵點就是異地嘱丢、多活，其中異地就是指地理位置上不同的地方祠饺，多活就是指不同地理位置上的系統(tǒng)都能夠提供業(yè)務(wù)服務(wù)。
異地多活雖然功能很強大汁政，但也不是每個業(yè)務(wù)不管三七二十一都要上異地多活道偷。
如果業(yè)務(wù)規(guī)模很大，能夠做異地多活的情況下盡量實現(xiàn)異地多活记劈。
異地多活架構(gòu)可以分為同城異區(qū)勺鸦、跨城異地、跨國異地目木。
異地多活設(shè)計技巧：保證核心業(yè)務(wù)的異地多活换途、保證核心數(shù)據(jù)最終以執(zhí)行、采用多種手段同步數(shù)據(jù)刽射、只保證絕大部分用戶的異地多活军拟。
接口級故障的主要應(yīng)對方案：降級、熔斷誓禁、限流懈息、排隊。
降級的核心思想就是丟車保帥摹恰，優(yōu)先保證核心業(yè)務(wù)辫继。
限流指只允許系統(tǒng)能夠承受的用戶量進來訪問，超出系統(tǒng)訪問能力的用戶將被拋棄俗慈。
排隊實際上是限流的一個變種姑宽，限流是直接拒絕用戶，排隊是讓用戶等待很長水間闺阱。
可擴展模式總結(jié)：
軟件系統(tǒng)與硬件和建筑系統(tǒng)最大的差異在于軟件是可擴展的炮车。
真正有生命力的軟件系統(tǒng)都是在不斷迭代和發(fā)展的。
所有可擴展性架構(gòu)設(shè)計馏颂，背后的基本思想都可以總結(jié)為一個字：拆示血。
面向流程拆分：分層架構(gòu)
面向服務(wù)拆分：SOA、微服務(wù)救拉。
面向功能拆分：微內(nèi)核架構(gòu)难审。
不同的拆分方式將得到不同的系統(tǒng)架構(gòu)。
分層架構(gòu)總結(jié)：
分層架構(gòu)是很常見的架構(gòu)模式亿絮，也叫N層架構(gòu)告喊，通常情況下麸拄，N至少是2層，一般不超過5層黔姜。
C/S架構(gòu)拢切、B/S架構(gòu)劃分的對象是整個業(yè)務(wù)系統(tǒng)，劃分的維度是職責(zé)秆吵，將不同的職責(zé)劃分到獨立層淮椰。
MVC架構(gòu)、MVP架構(gòu)劃分的對象是單個業(yè)務(wù)子系統(tǒng)纳寂，劃分的維度是職責(zé)主穗，將不同的職責(zé)劃分到獨立層。
邏輯分層架構(gòu)劃分的對象可以是單個業(yè)務(wù)子系統(tǒng)毙芜，也可以是整個業(yè)務(wù)系統(tǒng)忽媒，劃分的維度也是職責(zé)。
無論采用何種分層維度腋粥，分層架構(gòu)設(shè)計最核心的一點就是需要保證各層之間的差異足夠清晰晦雨，邊界足夠明顯。
分層架構(gòu)之所以能夠較好地支撐系統(tǒng)擴展隘冲，本質(zhì)在于：隔離關(guān)注點闹瞧。
分層架構(gòu)的一個特點就是層層傳遞。
分層架構(gòu)一個典型的缺點就是性能对嚼。
SOA架構(gòu)總結(jié)：
SOA提出的背景是企業(yè)內(nèi)部的IT系統(tǒng)重復(fù)建設(shè)且效率低下夹抗。
SOA更多是在傳統(tǒng)企業(yè)（例如，制造業(yè)纵竖、金融業(yè)等）落地和推廣漠烧，在互聯(lián)網(wǎng)行業(yè)并沒有多大規(guī)模的時間和推廣。
SOA三個關(guān)鍵概念：服務(wù)靡砌、ESB和松耦合已脓。
SOA架構(gòu)中，每項業(yè)務(wù)功能都是一項服務(wù)通殃，服務(wù)就意味著對外提供開放的能力度液。
SOA使用ESB來屏蔽異構(gòu)系統(tǒng)對外提供各種不同的接口方式，以此來達到服務(wù)間高效的互聯(lián)互通画舌。
SOA解決了傳統(tǒng)IT系統(tǒng)重復(fù)建設(shè)和擴展效率低的問題堕担，但其本身也引入了更多的復(fù)雜性，SOA最廣為人詬病的就是ESB曲聂。
SOA的ESB設(shè)計也是無奈之舉霹购，企業(yè)在應(yīng)用SOA時，各種異構(gòu)的IT系統(tǒng)都已經(jīng)踩在很多年了朋腋，完全重寫或者按照統(tǒng)一標(biāo)準(zhǔn)進行改造的成本是非常大的齐疙，只能通過ESB方式其適配已經(jīng)存在的各種異構(gòu)系統(tǒng)膜楷。
微服務(wù)架構(gòu)總結(jié)
微服務(wù)概念的歷史要早得多，也不是Martin Flower創(chuàng)造出來的贞奋，Martin只是將微服務(wù)進行了系統(tǒng)的闡述赌厅。
微服務(wù)是一種和SOA相似但本質(zhì)上不同的架構(gòu)理念。
微服務(wù)的三個關(guān)鍵詞 : small（微小的）轿塔、lightweight(輕量的)特愿、automated（自動化）。
微服務(wù)和SOA不存在孰優(yōu)孰劣勾缭，只是應(yīng)用場景不同洽议。
微服務(wù)并不是沒有代價，而是會帶來系統(tǒng)復(fù)雜度漫拭、運維復(fù)雜度、性能下降等問題混稽。
微服務(wù)拆分的粒度遵循“三個火槍手”原則采驻。
真正決定微服務(wù)成敗的，恰恰是那個被大部分人都忽略的“automated”匈勋，而不是“l(fā)ightweight”和“small”礼旅。
微服務(wù)并不是很多人認為的那樣又簡單又輕量級，要做好微服務(wù)洽洁，基礎(chǔ)設(shè)施是必不可少的痘系。
微內(nèi)核架構(gòu)總結(jié)
微內(nèi)核架構(gòu)也被稱為插件化架構(gòu)(Plug-in-Architecture)，是一種面向功能進行拆分的可擴展性架構(gòu)饿自。
微內(nèi)核架構(gòu)通常用于實現(xiàn)基于產(chǎn)品的應(yīng)用
微內(nèi)核架構(gòu)包含兩類組件:核心系統(tǒng)(core system) 和插件模塊(plug-in modules)汰翠。
微內(nèi)核的核心系統(tǒng)設(shè)計的關(guān)鍵技術(shù)有幾部分: 插件管理、插件連接和插件通信昭雌。
Eclipse采用OSGi標(biāo)準(zhǔn)后复唤，OSGi更是成為首選的插件化標(biāo)準(zhǔn)。
