架構(gòu)的思想是非常寶貴的螃壤，設(shè)計(jì)的基本原理不會因?yàn)樾录夹g(shù)的層出不窮而過時描扯。怎樣以最低成本最大化系統(tǒng)的擴(kuò)展性？怎樣達(dá)到風(fēng)險(xiǎn)利益的平衡點(diǎn)踢械？答案盡在本書中酗电。

第一章 大道至簡

本章圍繞著簡化這個主題，從需求到設(shè)計(jì)内列、實(shí)施撵术、部署再到網(wǎng)絡(luò)設(shè)備。

需求方面的過度設(shè)計(jì)比較容易避免话瞧，控制好項(xiàng)目范圍和需求范圍就可以了嫩与。

想要避免設(shè)計(jì)方面的過度設(shè)計(jì)，最簡單的方法是把設(shè)計(jì)的解決方案展示給其他技術(shù)團(tuán)隊(duì)交排，要求其他團(tuán)隊(duì)能夠快速輕松地理解划滋，如果任何一個團(tuán)隊(duì)不理解這個解決方案，就應(yīng)該思考下埃篓，是否設(shè)計(jì)得過于復(fù)雜处坪。所以歸根結(jié)底，我們在設(shè)計(jì)解決方案時架专，首要考慮的是目前業(yè)務(wù)的增長速度和需求同窘，只做當(dāng)下最好的設(shè)計(jì)。

我想起自己一個實(shí)例部脚，一個小需求——登錄注冊頁底部加廣告位想邦。遺憾的是在兼容性測試中發(fā)現(xiàn)，Android 4.4 以下設(shè)備委刘，底部廣告位不能和底部的軟鍵盤友好兼容案狠，出現(xiàn)了廣告位變形的情況。（且實(shí)踐后發(fā)現(xiàn)钱雷，需要針對 Android 4.2 和 4.3 做不同的兼容）骂铁，采取了一系列解決方案后，我意識到不應(yīng)該為低版本用戶做這種可能會影響性能的特殊監(jiān)聽罩抗，方案的復(fù)雜度也已經(jīng)超出控制了拉庵。立馬和產(chǎn)品協(xié)商，最簡單干脆的方案是低版本用戶不顯示該廣告位套蒂，問題至此解決钞支。

那是不是簡單的設(shè)計(jì)茫蛹，就意味著不需要考慮系統(tǒng)未來的擴(kuò)展性？當(dāng)然不是烁挟！我們可以選擇一開始就設(shè)計(jì)好擴(kuò)展方案婴洼，等待需求規(guī)模的增長，再來實(shí)施這個擴(kuò)展方案撼嗓。雖然一開始就設(shè)計(jì)付出的智力成本比較大柬采，但我們沒有付出更大的技術(shù)和資產(chǎn)成本，智力成本處于可接受的成本范圍且警。并且在現(xiàn)有的方案下粉捻，我們可以隨時快速參考，隨時快速實(shí)施擴(kuò)展斑芜。

DID 成本

在實(shí)施過程中肩刃，推薦使用被廣泛采用的開源或第三方解決方案，最簡單的實(shí)施幾乎總是那些有過實(shí)踐經(jīng)歷并通過實(shí)踐證明了的可擴(kuò)展方案杏头。想想如果采用開源庫盈包，成千上萬的開發(fā)者一起使用，同時找bug醇王，且有專人維護(hù)和更新呢燥。這些都是自己創(chuàng)建方案所不能做到的。當(dāng)然厦画，如果有商業(yè)庫，最好還是采用商業(yè)方案滥朱，任何一個人都不可能是各方面的專家根暑，商業(yè)供應(yīng)商擁有該方案領(lǐng)域的專家（如
OCR 或者推送），我們通常能得到一個高質(zhì)量的方案徙邻，這個方案不單單是高質(zhì)量的編程排嫌，而且是該領(lǐng)域的高性能。

第二章 分而治之

本章圍繞著擴(kuò)展這個主題缰犁，提出了三個簡單規(guī)則：x 軸擴(kuò)展淳地、y 軸拆分、z 軸拆分帅容。

你可以注意到颇象，x 軸是擴(kuò)展，y 軸和 z 軸都屬于拆分并徘，進(jìn)而達(dá)到擴(kuò)展的目的遣钳。

成本最低的就是 x 軸擴(kuò)展，主要手段是復(fù)制數(shù)據(jù)庫和服務(wù)麦乞，來分散高頻事務(wù)處理帶來的負(fù)載蕴茴，CDN 負(fù)載均衡就是這種規(guī)則的體現(xiàn)劝评。

隨著數(shù)據(jù)規(guī)模逐漸擴(kuò)大，數(shù)據(jù)復(fù)制可能會出現(xiàn)瓶頸倦淀，這個時候蒋畜，我們可以著手于擴(kuò)展 y 軸，也就是把數(shù)據(jù)或服務(wù)按名詞（以資源為導(dǎo)向撞叽，如：用戶信息姻成、產(chǎn)品信息）或動詞（以服務(wù)為導(dǎo)向，如：注冊能扒、登陸佣渴、搜索）標(biāo)識拆分。隨著拆分初斑，我們龐大的系統(tǒng)拆分成為子系統(tǒng)辛润，團(tuán)隊(duì)也可以隨之拆分，類似于目前公司的垂直化分組见秤，每個小團(tuán)隊(duì)專門負(fù)責(zé)不同的子系統(tǒng)砂竖，更加專業(yè)的同時也提高了生產(chǎn)力。

當(dāng)數(shù)據(jù)集的用戶基數(shù)（此處以用戶舉例鹃答，實(shí)際上什么都可以進(jìn)行拆分乎澄，思路一致，找到共同點(diǎn)與不同點(diǎn)即可）越來越大测摔，且用戶屬性有明顯不同時（如：地區(qū)置济、行業(yè)等），可以考慮 z 軸拆分锋八。書中介紹到：可以根據(jù)用戶屬性分塊浙于，在應(yīng)用發(fā)布時，可以通過先發(fā)布到含有少量客戶的一小塊來控制風(fēng)險(xiǎn)挟纱，沒有問題后羞酗，再發(fā)布給其他大塊或者全量。這就有點(diǎn)類似于 Android 灰度包的做法紊服，只不過灰度包中檀轨，是用注冊渠道（小米渠道、華為渠道）來標(biāo)識用戶塊欺嗤。我們可以把幾個非常小的渠道合并為一個分塊参萄，減少數(shù)據(jù)塊的碎片化。說到底煎饼，z 軸可以把數(shù)據(jù)分割成容易命中的多塊數(shù)據(jù)拧揽，避免數(shù)據(jù)集過大，需要長時間遍歷的弊端。

第三章 水平拆分

向外擴(kuò)展（復(fù)制或拆分?jǐn)?shù)據(jù)淤袜，分散負(fù)載）痒谴，而不是向上擴(kuò)展（購買更大的硬件來支撐）。

通俗講铡羡，就是小积蔚、簡單、多優(yōu)于大烦周、復(fù)雜尽爆、少。硬件再怎么大读慎，都有個上限漱贱，采購成本也隨之指數(shù)上升。如果是向外擴(kuò)展夭委，設(shè)備可以隨時被替換或丟棄幅狮，擴(kuò)展可以無限。

當(dāng)我們做容災(zāi)時株灸，通常會考慮雙機(jī)備份崇摄。本文提出一個非常棒的設(shè)計(jì)方案——三活數(shù)據(jù)中心。如果想快速擴(kuò)展現(xiàn)有的雙數(shù)據(jù)中心慌烧，可以加個云數(shù)據(jù)中心來作為第三個數(shù)據(jù)中心逐抑，最小化了硬件支出。但是這個方案也不是全是優(yōu)點(diǎn)屹蚊，考慮下數(shù)據(jù)的同步頻率厕氨，額外的連接(N中心就有(N*(N-1))/條雙向連接)，當(dāng)數(shù)據(jù)中心不斷擴(kuò)展時汹粤，這個復(fù)雜度還是很可怕的命斧。

三活數(shù)據(jù)中心

三活數(shù)據(jù)中心 + 三個熱數(shù)據(jù)中心

最后，利用云技術(shù)來處理意外玄括、臨時冯丙、突發(fā)或偶發(fā)的需求肉瓦≡饩可以有效降低硬件成本，提高我們的響應(yīng)速度泞莉，也減少了我們改變產(chǎn)品需求的風(fēng)險(xiǎn)成本哪雕。

第四章 先利其器

本章主要講的是開發(fā)中工具使用的思考，包括：怎樣選擇數(shù)據(jù)庫鲫趁？哪種數(shù)據(jù)庫更適合斯嚎？數(shù)據(jù)存儲是不是非數(shù)據(jù)庫不可？防火墻的意義是什么？是否實(shí)施防火墻的決定因素有哪些堡僻？日志文件怎么有效發(fā)揮作用糠惫？

在了解這些開始前，我們需要避免陷入工具法則钉疫，技術(shù)解決方案可以嘗試多方案硼讽，平時和不同技術(shù)棧的同事多交流，花時間做技術(shù)調(diào)研牲阁，學(xué)習(xí)新事物固阁，主動分析、實(shí)驗(yàn)城菊、采用新工具同時不斷革新工具备燃，使用最適合的工具，避免被自己只熟悉的東西困住凌唬。

日志文件這塊并齐，我想以客戶端的角度詳細(xì)講講。

使用日志的第一步法瑟，是要解決收集日志的問題冀膝。收集可以用 AOP 來插入日志調(diào)用語句，也可以結(jié)合業(yè)務(wù)邏輯手動來調(diào)用霎挟。那么什么時候上報(bào)窝剖？我們可以間隔一段時間，就上報(bào)酥夭，如果考慮到服務(wù)器的負(fù)載赐纱，也可以下次啟動時統(tǒng)一上報(bào)。這種情況下熬北，考慮下如果日志文件太大疙描，上傳過程中進(jìn)程被殺，我們需要支持?jǐn)帱c(diǎn)續(xù)傳讶隐。上報(bào)的具體時機(jī)起胰，按實(shí)時性的需求選擇。

第二步上報(bào)之后巫延，服務(wù)器需要把日志聚合到日志服務(wù)器上統(tǒng)一存儲效五。服務(wù)端需要提供完整的日志分類、即時報(bào)表統(tǒng)計(jì)工具炉峰、監(jiān)控支持和支持全文檢索日志畏妖。

下一步是日志分類，是按用戶維度疼阔？還是按日志等級維度戒劫？日志中的錯誤半夷，可以按機(jī)型或者人數(shù)來統(tǒng)計(jì)，報(bào)錯多的類似日志迅细，我們優(yōu)先排查解決巫橄。

每天產(chǎn)生這么多日志，維護(hù)和存儲成本逐漸上升茵典，最新的數(shù)據(jù)價(jià)值最高嗦随，我們考慮對舊數(shù)據(jù)進(jìn)行歸檔或刪除。

最后書中寫道：引進(jìn)每項(xiàng)新技術(shù)都需要另外一種技能來支持敬尺。盡管工作中使用合適的工具很重要枚尼，但是不要過度強(qiáng)調(diào)專業(yè)化，以至于沒有足夠深度的技能來支持砂吞。

共勉署恍。

第五章 畫龍點(diǎn)睛

本章圍繞著系統(tǒng)擴(kuò)展性主題，羅列出限制了系統(tǒng)擴(kuò)展能力的錯誤設(shè)計(jì)蜻直。

首先是不要復(fù)查剛插入的數(shù)據(jù)——這種成本翻倍又難以維護(hù)的操作盯质。

其次是濫用重定向，這會降低用戶體驗(yàn)概而，影響頁面搜索引擎排行呼巷。

最后，因?yàn)榇蠖鄶?shù)關(guān)系型數(shù)據(jù)庫不擅長保持節(jié)點(diǎn)之間數(shù)據(jù)的一致性赎瑰，所以沒有必要為了場景的一致性王悍，影響了數(shù)據(jù)庫的分布式擴(kuò)展。合理地放寬時間約束餐曼，找到一個系統(tǒng)方便擴(kuò)展压储，用戶又容易接受的時間點(diǎn)。

不管做什么源譬，首要考慮都是最小成本產(chǎn)生最大效益集惋。我們允許某些不同步的小錯誤換取擴(kuò)展性的最大化。

第六章 緩存為王

想提高擴(kuò)展性踩娘，緩存是個很好的手段刮刑。從瀏覽器到網(wǎng)絡(luò)、知道應(yīng)用和數(shù)據(jù)庫每個層次养渴，緩存有無數(shù)選項(xiàng)可以考慮：

1. 通過 CDN 緩存來平緩請求高峰和增長雷绢，提高服務(wù)器負(fù)載。
2. Ajax 提供了豐富的異步動態(tài)交互厚脉，但需要注意頻繁的廢請求习寸。
3. 在網(wǎng)絡(luò)服務(wù)器前面實(shí)施頁面緩存胶惰。
4. 根據(jù)數(shù)據(jù)讀取的邊界或者相關(guān)性傻工，進(jìn)行 y 軸 z 軸拆分，從而提高緩存的命中率。
5. 推薦對 Sql 數(shù)據(jù)集建立對象緩存層，既不影響服務(wù)器性能，又方便獨(dú)立地?cái)U(kuò)展緩存池蜗帜。
6. 推薦通過 HTTP 頭來控制緩存乖酬，如果數(shù)據(jù)結(jié)果沒有包含用戶的隱私數(shù)據(jù)的話，指定 Cache-Control 頭為 public有利于數(shù)據(jù)結(jié)果可以緩存在從客戶端到服務(wù)器之間的任何代理及緩存侣背。（如：瀏覽器、CDN、頁面緩存染厅、應(yīng)用緩存）

第七章 前車之鑒

本章提出了一個有趣的觀點(diǎn)：構(gòu)建高可用性和高可擴(kuò)展性的系統(tǒng)，目的就是防止頻繁失敗津函，因此可以學(xué)習(xí)的機(jī)會也比較少肖粮。經(jīng)常失敗的組織往往有更好的學(xué)習(xí)和成長機(jī)會，如果他們能抓住機(jī)會并從中學(xué)習(xí)尔苦。

引申開來涩馆，在敏捷軟件開發(fā)實(shí)踐中，每個 Sprint 結(jié)束后有回顧總結(jié)會允坚，主要議題就是：在這個 Sprint 里魂那，我們哪些做的比較好的，哪些是需要提高的稠项，下個 Sprint 要采取哪些措施涯雅。這個回顧總結(jié)的本質(zhì)就是復(fù)盤，目的是讓團(tuán)隊(duì)從過去學(xué)習(xí)展运，來提升團(tuán)隊(duì)的整體交付能力斩芭。

最后本章還指出，需要確保所有版本的代碼都有回滾能力乐疆，回滾的成本遠(yuǎn)遠(yuǎn)低于發(fā)布引起的線上故障划乖，也能把風(fēng)險(xiǎn)降低到可控范圍〖吠粒客戶端的話琴庵，效果類似于熱修復(fù)，都是適用于線上緊急情況下實(shí)時高效把損失降到最低仰美。

第八章 重中之重

本章深有體會的一點(diǎn)：實(shí)體間的關(guān)系影響了我們?nèi)绾未鎯γ缘睢z索、更新數(shù)據(jù)和擴(kuò)展拆分?jǐn)?shù)據(jù)咖杂。數(shù)據(jù)的完整性和規(guī)范程度越高庆寺，關(guān)系越緊密，就越難以擴(kuò)展和拆分诉字，我們需要折中考慮懦尝。

第九章 有備無患

本章重點(diǎn)在于提高系統(tǒng)的高可用性知纷，系統(tǒng)的合理故障處理與隔離。

可用性和可擴(kuò)展性具有同等重要性陵霉，可用性不高的系統(tǒng)不需要擴(kuò)展琅轧，不能擴(kuò)展的系統(tǒng)也不會是高可用性的。通過減少故障和頻率和影響范圍踊挠，我們可以提高系統(tǒng)的整體可用性乍桂。

減少故障的手段有以下幾種：

1. 用泳道隔離故障，各泳道之間不共享資源特別是數(shù)據(jù)庫和服務(wù)器效床，并禁止不同泳道之間同步調(diào)用睹酌，避免故障阻塞，如果需要調(diào)用剩檀，推薦采用異步忍疾。異步的調(diào)用非常類似于觀察者的模式，僅僅把事件傳遞出去谨朝，而觀察者有沒有收到卤妒，是否處理了，被觀察者并不關(guān)心字币。我們可以沿 y 軸或 z 軸進(jìn)行拆分则披，這有利于故障隔離，不同服務(wù)間彼此獨(dú)立洗出，有助于我們快速定位問題士复，縮小排查范圍。

2. 當(dāng)使用單例模式時翩活，就要慎重小心了阱洪。如果多個系統(tǒng)都需要共享這個單例，一旦單例失敗菠镇，則會引起系統(tǒng)范圍的故障冗荸。

3. 并聯(lián)而不是串聯(lián)系統(tǒng)（除非有多版本子系統(tǒng)可以隨時取代），避免累積影響利耍。

4. 增加啟用/禁用框架蚌本，可以智能或人為干涉開啟/關(guān)閉服務(wù)。這類似于開關(guān)的概念隘梨，在功能上加開關(guān)來做到一款上線/下線程癌，防范風(fēng)險(xiǎn)。

第十章 超然物外

本章論證了引入狀態(tài)會給我們系統(tǒng)帶來多大的麻煩：耗費(fèi)內(nèi)存和處理能力轴猎、依賴增加嵌莉、故障時狀態(tài)無法恢復(fù)。

所以我們不惜一切代價(jià)避免狀態(tài)捻脖。如果狀態(tài)是必要的锐峭，建議把數(shù)據(jù)存儲在用戶端（如瀏覽器中的 Cookie 機(jī)制中鼠、客戶端的 Token）因?yàn)榇鎯υ谟脩舳耍孕枰龊眉用苤混簦乐怪虚g人竊取憑證偽裝用戶。服務(wù)端雖然可以減少存儲扰肌、檢索成本抛寝，但保險(xiǎn)起見，需要有校驗(yàn)的步驟曙旭，不可完全相信用戶端傳來的憑證盗舰。

如果有些設(shè)計(jì)必須要把狀態(tài)數(shù)據(jù)存在服務(wù)端，就用分布式緩存來作為單層中間層處理桂躏。這里需要考慮下分布式中更新狀態(tài)數(shù)據(jù)和讀取狀態(tài)數(shù)據(jù)的沖突問題钻趋，以及數(shù)據(jù)需不需要持久化。

第十一章 異步通信

本章討論了異步通信的準(zhǔn)則和處理剂习÷唬可以說在開發(fā)中特別是客戶端開發(fā)中，由于主線程的特性鳞绕，異步思想是無處不在失仁。

異步一般可以借助回調(diào)或者事件總線（本質(zhì)上就是觀察者模式）來完成，如果嵌套層次太深们何，或者需要解耦萄焦，或者遇到跨服務(wù)的情況，就要考慮用事件總線了冤竹。

本章引發(fā)我對事件總線擴(kuò)展性的一些思考（畢竟單用戶的客戶端只需要一條總線就足夠了）：

1. 這么多的服務(wù)和系統(tǒng)拂封，用同一條總線，高頻的讀寫會引起堵塞鹦蠕，怎么擴(kuò)展總線冒签？最直接的方式就是按照面向的服務(wù)和屬性拆分（y 軸），這會犧牲一些靈活性钟病，你不能夠跨服務(wù)去通知镣衡；按照客戶邊界拆分成泳道（z 軸），泳道之間也可異步通信档悠。

   
   

2. 總線是否可以擴(kuò)展下優(yōu)先級屬性廊鸥，在同時發(fā)生事件時，優(yōu)先級高的事件優(yōu)先通知辖所。

3. 不需要再處理的觀察者惰说，需要增加自動解綁機(jī)制。

第十二章 意猶未盡

我們怎么應(yīng)對突發(fā)的流量缘回？怎么提高系統(tǒng)高峰時的可用性吆视？

有兩方面可以解決：

1. 利用云或者應(yīng)急的容量典挑，來負(fù)載突發(fā)請求，同時系統(tǒng)要做好這方面的擴(kuò)展啦吧；
2. 建立監(jiān)控體系您觉，存在異常波動，及時報(bào)警授滓。

需要說明的是琳水，雖然我們反復(fù)強(qiáng)調(diào)不要造輪子，優(yōu)先使用被廣泛采用的開源庫或第三方解決方案般堆，但是供應(yīng)商永遠(yuǎn)都不會像你自己一樣在孝，在第一時間處理方案中的 bug 。所以這需要我們做好解耦淮摔，評估擴(kuò)展性和風(fēng)險(xiǎn)點(diǎn)私沮。第三方方案的缺陷我們是否能接受？是否在可控范圍和橙？自己的團(tuán)隊(duì)是否可以方便地?cái)U(kuò)展和修改以適應(yīng)自己的需求仔燕？最差的情況下，第三方方案是否容易隨時替換魔招？這些都是我們在使用第三方前需要考慮的涨享。

在擴(kuò)展時，不要依賴供應(yīng)商的產(chǎn)品仆百、服務(wù)或系統(tǒng)功能來擴(kuò)展厕隧，如果依賴于供應(yīng)商的專有方案，我們將失去主動權(quán)和競爭力俄周。就像攜程沒有開源的React Native優(yōu)化框架吁讨，就是客戶端的競爭力之一。

上面第 2 點(diǎn)的監(jiān)控峦朗，架構(gòu)設(shè)計(jì)之初就應(yīng)該納入考慮建丧，監(jiān)控系統(tǒng)的狀態(tài)比如 CPU、內(nèi)存使用率固然重要波势，更重要的是從業(yè)務(wù)指標(biāo)做監(jiān)控如注冊成功率翎朱、下單轉(zhuǎn)換率、搜索頻率等尺铣，這樣才更直觀地看到業(yè)務(wù)的異常情況拴曲，具體受到什么的影響。文中提出監(jiān)控系統(tǒng)一個有意思的展望：使用控制圖或者機(jī)器學(xué)習(xí)凛忿，來預(yù)測是否會發(fā)生異常澈灼，并支持系統(tǒng)自我修復(fù)，這種自動化自愈系統(tǒng)，將是未來的方向叁熔。

最后委乌，文章提出了對數(shù)據(jù)進(jìn)行梯級存儲策略，畢竟處于大數(shù)據(jù)時代荣回，龐大的數(shù)據(jù)無疑增加了我們的成本遭贸。結(jié)合業(yè)務(wù)，評估數(shù)據(jù)的價(jià)值和訪問頻率心软，使用不同的存儲介質(zhì)和策略壕吹，比如低價(jià)值低頻訪問率的數(shù)據(jù)，是刪除還是遷移到低速存儲中糯累？

我不知道你有沒有留意過算利，跨年的快遞單號已經(jīng)查詢不了物流信息了册踩，因?yàn)橐呀?jīng)簽收了的數(shù)據(jù)泳姐，隨著時間推移慢慢老化，失去價(jià)值暂吉，這部分?jǐn)?shù)據(jù)完全可以刪除掉胖秒。

第十三章 謀定而動

本章用風(fēng)險(xiǎn)收益分析方法，評估了全文提出的50條規(guī)則慕的。

這個評估方法阎肝，也可以運(yùn)用在我們平時的解決方案選定中：這個方案能降低多少風(fēng)險(xiǎn)，解決什么問題肮街？風(fēng)險(xiǎn)出現(xiàn)的頻率怎么樣风题？降低的風(fēng)險(xiǎn)點(diǎn)，對系統(tǒng)和業(yè)務(wù)的影響面多少嫉父，損失會是多少沛硅？如果采用該方案，我們的成本怎么樣绕辖？成本和風(fēng)險(xiǎn)比起來摇肌，我們能得到多少收益？這些都是我們需要思考的仪际，毫無疑問優(yōu)先采用降低風(fēng)險(xiǎn)多又低成本的方案围小。

可擴(kuò)展性與可用性風(fēng)險(xiǎn)分解

總結(jié)

本書的思想和規(guī)則非常寶貴，大概總結(jié)了 12 條設(shè)計(jì)過程中需要遵循的架構(gòu)原則树碱。

1. N+1設(shè)計(jì)肯适。永遠(yuǎn)不少于兩個，通常為三個成榜，當(dāng)故障發(fā)生時疹娶，至少保證有一個冗余的實(shí)例。

2. 回滾設(shè)計(jì)伦连。確保系統(tǒng)可以回滾到以前發(fā)布過的任何版本雨饺。

3. 禁用設(shè)計(jì)钳垮。能夠關(guān)閉任何發(fā)布的功能。

4. 監(jiān)控設(shè)計(jì)额港。在設(shè)計(jì)階段就必須考慮監(jiān)控饺窿，而不是在實(shí)施完成之后補(bǔ)充。

5. 使用成熟的技術(shù)移斩。只用確實(shí)好用的技術(shù)肚医，謹(jǐn)慎使用最新技術(shù)。

6. 異步設(shè)計(jì)向瓷。只有在絕對必要的時候才進(jìn)行同步調(diào)用肠套。

7. 無狀態(tài)系統(tǒng)。只有當(dāng)業(yè)務(wù)確實(shí)需要的時候猖任，才使用狀態(tài)你稚。

8. 設(shè)計(jì)至少要有兩個步驟的前瞻性。在擴(kuò)張性問題發(fā)生前考慮好下一步的行動計(jì)劃朱躺。

9. 非核心則購買刁赖。如果不是你最擅長的，也提供不了差異化的競爭優(yōu)勢則直接購買长搀。

10. 小構(gòu)建宇弛，小發(fā)布，快試錯源请。全部研發(fā)要小構(gòu)建枪芒，不斷迭代，讓系統(tǒng)不斷地成長谁尸。

11. 隔離故障舅踪。實(shí)現(xiàn)故障隔離設(shè)計(jì)，通過斷路保護(hù)避免故障傳播和交叉影響症汹。

12. 自動化硫朦。設(shè)計(jì)和構(gòu)建自動化的過程。如果機(jī)器可以做背镇，就不要依賴于人咬展。

參與了讀書計(jì)劃，所以本書感悟按章分解瞒斩。