架構(gòu)學(xué)習(xí)筆記

?概述篇o為什么開發(fā)人員要學(xué)習(xí)架構(gòu)？?無架構(gòu)，不系統(tǒng)?現(xiàn)在的軟件系統(tǒng)規(guī)模越來越大，業(yè)務(wù)上和技術(shù)上都非常地復(fù)雜，大一點的互聯(lián)網(wǎng)公司，技術(shù)人員都有幾千號人。那么，如何開發(fā)這么復(fù)雜的系統(tǒng)？如何有效地組織他們的工作呢？在這里，一個好的架構(gòu)設(shè)計無疑是至關(guān)重要的，無論你是有一定經(jīng)驗的開發(fā)人員，還是已經(jīng)開始從事系統(tǒng)設(shè)計的架構(gòu)師，深入學(xué)習(xí)和理解架構(gòu)都是必不可少的，掌握好架構(gòu)設(shè)計，可以讓你輕松應(yīng)對技術(shù)和業(yè)務(wù)的挑戰(zhàn)。但是很多技術(shù)人員，由于個人項目經(jīng)驗有限，又缺乏很好的學(xué)習(xí)途徑，對架構(gòu)設(shè)計一知半解。在實際工作中，不能把握好架構(gòu)設(shè)計的度，要么設(shè)計不足，要么過度設(shè)計，導(dǎo)致系統(tǒng)變來變?nèi)?，嚴重影響開發(fā)效率和質(zhì)量。?拓展你的職業(yè)發(fā)展空間?此外，對于技術(shù)人員來說，公司通常會提供兩個職業(yè)發(fā)展通道供你選擇：管理路線和技術(shù)路線。現(xiàn)實中，大部分同學(xué)應(yīng)該都是走技術(shù)路線的，很多程序員的職業(yè)發(fā)展目標，也都是想要成為一名優(yōu)秀的架構(gòu)師。這不僅僅意味著更優(yōu)渥的薪水和更持久的職業(yè)生涯，更因為在架構(gòu)師這個舞臺上，你可以憑借個人出色的架構(gòu)能力，為項目的落地發(fā)揮巨大的作用，你會有更大的成就感。所以說，無論從軟件發(fā)展的趨勢，還是從個人職業(yè)發(fā)展方向上考慮，你都應(yīng)該擁抱架構(gòu)，主動學(xué)習(xí)，盡快成長為一個能力全面的架構(gòu)師。?需要克服的挑戰(zhàn)?而這些，無疑都是非?？简炄?，也非常鍛煉人的，需要你能夠快速成長起來。如果你在走向架構(gòu)師這條路上，完全靠自己摸索，找不到正確的方向，不斷地犯錯，你很可能會半途而廢。?系統(tǒng)角度?你需要跳出當前的小模塊，站在系統(tǒng)整體的角度來考慮問題?業(yè)務(wù)角度?你不僅要從技術(shù)的角度考慮問題，也要學(xué)會從業(yè)務(wù)的角度來考慮問題，深入理解系統(tǒng)的挑戰(zhàn)在哪里，不要在錯誤的地方發(fā)力。?資源平衡?你需要做好各方面的平衡，能在現(xiàn)有的各項資源約束下，尋求一個最優(yōu)?如何找到一個好的學(xué)習(xí)方式呢？?理論?在架構(gòu)學(xué)習(xí)這方面，并沒有十分系統(tǒng)的理論指導(dǎo)，教你如何一步步進階。?實戰(zhàn)o架構(gòu)本質(zhì)?通過合理的內(nèi)部編排，保證系統(tǒng)高度有序，能夠不斷擴展，滿足業(yè)務(wù)和技術(shù)的?架構(gòu)的出發(fā)點是業(yè)務(wù)和技術(shù)在不斷復(fù)雜化，引起系統(tǒng)混亂，需要通過架構(gòu)來保證有序?架構(gòu)實現(xiàn)從無序到有序，是通過合理的內(nèi)部編排實現(xiàn)的，基本的手段，就是“分”與“合”，先把系統(tǒng)打散，然后將它們重新組合，形成更合理的關(guān)系。o?架構(gòu)的分類?業(yè)務(wù)架構(gòu)o從概念層面幫助我們理解系統(tǒng)面臨哪些問題以及如何處理o講清楚核心業(yè)務(wù)的處理過程，定義各個業(yè)務(wù)模塊的相互關(guān)系?應(yīng)用架構(gòu)o從邏輯層面幫助我們理解系統(tǒng)內(nèi)部是如何分工與協(xié)作的。o講清楚系統(tǒng)內(nèi)部是怎么組織的，有哪些應(yīng)用，相互間是怎么調(diào)用的?技術(shù)架構(gòu)o技術(shù)架構(gòu)從物理層面幫助我們理解系統(tǒng)是如何構(gòu)造的，以及如決穩(wěn)定性的問題。o講清楚系統(tǒng)由哪些硬件、操作系統(tǒng)和中間件組成，它們是如何和我們開發(fā)的應(yīng)用一起配合，應(yīng)對各種異常情況，保持系統(tǒng)的?好的架構(gòu)要求?業(yè)務(wù)復(fù)雜性o業(yè)務(wù)可擴展、可復(fù)用?技術(shù)復(fù)雜性o系統(tǒng)的高可用、高性能和可伸縮，并盡量采用低成本的方式落地?好的架構(gòu)師要求?能力模型圖o?出色的程序員，寫的一手好代碼?架構(gòu)師要有技術(shù)的廣度(多領(lǐng)域知識)和深度(技術(shù)前瞻)?思維的高度，具備抽象思維能力，善于把實物概念化并?思維的深度，能夠透過問題看本質(zhì)?良好的溝通能力(感性)?良好的平衡取舍能力(理性)?業(yè)務(wù)架構(gòu)篇o概述?從架構(gòu)角度看，業(yè)務(wù)架構(gòu)是源頭，然后才是技術(shù)架構(gòu)。?業(yè)務(wù)架構(gòu)師和產(chǎn)品經(jīng)理區(qū)別?產(chǎn)品經(jīng)理o他要實現(xiàn)什么o目標：定義系統(tǒng)的外觀，滿足了用戶?業(yè)務(wù)架構(gòu)師o職責：把業(yè)務(wù)流程和節(jié)點打散，按照業(yè)務(wù)域的維度來劃分系統(tǒng)模塊，并定義這些模塊之間的關(guān)系，最終形成一個高度結(jié)構(gòu)化o目標：定義系統(tǒng)的外觀、滿足了用戶、定義系統(tǒng)的內(nèi)部模塊結(jié)構(gòu)，滿足了開發(fā)人員?架構(gòu)目標?業(yè)務(wù)的可擴展o業(yè)務(wù)架構(gòu)設(shè)計要能支持打造一個柔性系統(tǒng)，通過提供良好的業(yè)務(wù)擴展性，允許業(yè)務(wù)不斷調(diào)整和快速生長。o特點：業(yè)務(wù)的主題是變化和創(chuàng)新，系統(tǒng)的主題是穩(wěn)定和可靠。??我們把業(yè)務(wù)平臺和業(yè)務(wù)線剝離開，讓業(yè)務(wù)平臺封裝基礎(chǔ)通用的功能，這樣，它就變得相當?shù)胤€(wěn)定；讓各個業(yè)務(wù)線包含自己的個性化需求，業(yè)務(wù)線只依賴業(yè)務(wù)平臺，業(yè)務(wù)線彼此之間互相獨立，可以自由變化。這樣的業(yè)務(wù)架構(gòu)設(shè)計，就同時保證了系統(tǒng)的相對穩(wěn)定和業(yè)務(wù)的快速創(chuàng)新。o案例??在支付寶一代的業(yè)務(wù)架構(gòu)中，前臺的業(yè)務(wù)和后臺的業(yè)務(wù)直接耦合，形成了多對多的網(wǎng)狀結(jié)構(gòu)，如果修改一個后臺業(yè)務(wù)線，就會影響到很多前臺業(yè)務(wù)線；如果增加一條新的前臺業(yè)務(wù)線，需要同時和很多后臺業(yè)務(wù)線對接，這樣的架構(gòu)無疑是對業(yè)務(wù)的擴展非常不利的。而在支付寶二代業(yè)務(wù)架構(gòu)中，你會發(fā)現(xiàn)，他們在前后臺業(yè)務(wù)線之間，構(gòu)建了獨立的支付清算平臺，從而實現(xiàn)了前臺業(yè)務(wù)和后臺業(yè)務(wù)的解還是后臺業(yè)務(wù)，都只需要對接中間的支付清算平臺，把系統(tǒng)的變化收斂到一個點，而?常見問題業(yè)務(wù)線之間相互不影響，這樣的方式，自然可以很好地支?業(yè)務(wù)的可復(fù)用o按照業(yè)務(wù)域來劃分業(yè)務(wù)，把業(yè)務(wù)流程中的節(jié)點拆分到各個業(yè)務(wù)域，按照業(yè)務(wù)域構(gòu)造系統(tǒng)模塊o業(yè)務(wù)域是相對固定的，它有明確的數(shù)據(jù)模型和業(yè)務(wù)規(guī)則，這樣一來，系統(tǒng)模塊也就比較固定和通用，也就具備比較好的復(fù)用基o系統(tǒng)模塊要求?模塊的職責定位要非常清晰?對于模塊來說，在定位范圍內(nèi)的職責要全部涵蓋到，而不在這個范圍的職責全部不要。?模塊的數(shù)據(jù)模型和接口設(shè)計要保證通用?架構(gòu)師需要歸納業(yè)務(wù)場景，通過抽象提煉，形成通用化的設(shè)計，以此來滿足多個類似場景的需求。?做好業(yè)務(wù)的層次劃分?越是底層的業(yè)務(wù)，它就相對更固定。舉個例子，同樣是訂單業(yè)務(wù)域，對于底層訂單的增刪改查功能，不同類型的訂單都是一樣的，但對于上層的訂單生命周期管理，外賣訂單和堂食訂單可能就不一樣。所以，在做高復(fù)用設(shè)計時，我們可以嘗試把一個業(yè)務(wù)域按照層次拆分得更細，比如，把訂單模塊拆分為多個上層訂單模塊和一個基礎(chǔ)訂單模塊，這樣，基礎(chǔ)訂單模塊對于所有類型的訂單，都能夠提o可擴展架構(gòu)?目標：如何打造一個善變的柔性系統(tǒng)？?如何設(shè)計一個具有良好擴展性的系統(tǒng)，能夠快速支持業(yè)務(wù)變化落地??快：如何快速地上線新業(yè)務(wù)？老板很可能明天就想看到效果。?穩(wěn)：對某個功能進行修改，如何不影響到系統(tǒng)其它的功能？?案例?電商平臺架構(gòu)是如何演變的？o發(fā)展過程??單體?分布式?soao傳統(tǒng)的SOA架構(gòu)：解決的是企業(yè)內(nèi)部大量異構(gòu)系統(tǒng)集成的問題??新的SOA架構(gòu)：解決的是系統(tǒng)重復(fù)建設(shè)的問題o?首先，它通過服務(wù)化思想，提供更好的業(yè)務(wù)封裝性，并通過標準技術(shù)，能更友好地對外輸出業(yè)務(wù)能力；o其次，SOA服務(wù)不依附于某個具體應(yīng)用，它可以獨立地部署和擴展，這樣避免了直接影響現(xiàn)有的系統(tǒng)；o最后，服務(wù)通過封裝通用的業(yè)務(wù)邏輯，共享，解決了重復(fù)造輪o微服務(wù)?微服務(wù)=小應(yīng)用+小服務(wù)。o中臺o1號店App服務(wù)端架構(gòu)改造?V1.0架構(gòu)?架構(gòu)圖o????V2.0架構(gòu)?架構(gòu)圖o??優(yōu)點：架構(gòu)比較簡單，App的服務(wù)端整體上就一個應(yīng)用，由移動團隊來維護所有對外接口，服務(wù)端內(nèi)部有很多Jar包，比如商品搜索、商品詳情、購物車等等，這些Jar包包含了各個業(yè)務(wù)線的業(yè)務(wù)邏輯及數(shù)據(jù)庫訪問，它們由各個業(yè)務(wù)線的開發(fā)者負責提供。缺點?移動服務(wù)端對Jar包的緊密依賴?移動團隊的職責過分復(fù)雜?團隊并行開發(fā)困難優(yōu)點：每塊業(yè)務(wù)由不同的團隊負責，可以很好地支持團隊之間的并行開發(fā)；同時，移動接口和PC端共享底層業(yè)務(wù)邏輯，有助于快速把PC端的功能完整地復(fù)制到App端。業(yè)務(wù)線團隊的生產(chǎn)力就被完全釋放了，App的功能也就快速豐富起來了。缺點?移動端和PC端互相干擾的問題?重復(fù)開發(fā)的問題：系統(tǒng)級的功能，比如說，安接口都需要這些通用功能。?V3.0架構(gòu)?架構(gòu)圖o?o嗎？??回顧o前臺??o后臺??穩(wěn)定性的問題：于這種直連方式，只要一個后端系統(tǒng)出問題，就會直接影響到App的可用性，使得App整體上非常的脆弱。效果?App端和PC端徹底獨立了?通過架構(gòu)改造，實現(xiàn)了核心業(yè)務(wù)的復(fù)用?這個架構(gòu)強化了系統(tǒng)級功能?團隊分工也更明確了定義：面向C端的應(yīng)用，比如像微信、淘寶這樣的應(yīng)用。不過，你要注意，前臺不僅僅是指前端，它還包含和前端配套的服務(wù)端前臺對外，我們知道，消費者的需求快速多變，所以前臺需要能快速響應(yīng)，做到低成本試錯；管理系統(tǒng)等等，主要是面向企業(yè)內(nèi)部人員使用。對于傳統(tǒng)企業(yè)來說，之前只有線下場景，通過內(nèi)部的后臺就能完成所有業(yè)務(wù)流程；而對于互聯(lián)網(wǎng)企業(yè)，或者逐步開展線上業(yè)務(wù)的傳統(tǒng)企業(yè)來說，同時需要前臺和后臺，一起協(xié)作，完成業(yè)務(wù)的閉環(huán)。?后臺對內(nèi)，企業(yè)內(nèi)部的業(yè)務(wù)流程不能經(jīng)常變，所以后臺需要穩(wěn)定，不能隨意調(diào)整，一旦改動，影響面廣，成本很高?前臺要快，后臺要穩(wěn)，業(yè)務(wù)擴展時，常遇到以下兩類挑戰(zhàn)o這個營銷思路很棒，老板希望能馬上驗證，前臺好改，但后臺調(diào)整起來需要好幾個月，互聯(lián)網(wǎng)行業(yè)比較普遍o后臺系統(tǒng)技術(shù)舊，性能差，接口不開放，前臺對接起來很麻煩，而且一有促銷活動，后臺立馬就掛。傳統(tǒng)行業(yè)比較普通?如何實現(xiàn)前后臺的平滑對接，這是一個巨大的挑戰(zhàn)，中臺架構(gòu)因此而?中臺定位o例子?Windows系統(tǒng)??麥當勞?背景o歷史?前臺?傳統(tǒng)的線下業(yè)務(wù)?后臺o總部使用的ERP、門店使用的收銀系統(tǒng)等等開辟新業(yè)務(wù)，新零售轉(zhuǎn)型?外賣?小程序點餐服務(wù)o改造?改造圖??改造步驟?對內(nèi)部老系統(tǒng)進行包裝，對外提供標準的API，這樣就能把舊的IT基礎(chǔ)設(shè)施，轉(zhuǎn)換成面向互聯(lián)網(wǎng)的業(yè)務(wù)平臺?新的C端應(yīng)用可以快速基于這個業(yè)務(wù)平臺來構(gòu)建，而不用關(guān)心底層老系統(tǒng)的實現(xiàn)細節(jié)。這個中間層就是中臺?傳統(tǒng)行業(yè)?中臺相當于企業(yè)的商業(yè)操作系統(tǒng)，通過對后臺的包裝，為前臺提供全方位的支持。需要注意的是，中臺不僅僅是前后臺之間簡單的適配器，中臺本身也會落業(yè)務(wù)數(shù)據(jù)，有完整的業(yè)務(wù)規(guī)則，就像Windows操作系統(tǒng)一樣，它在適配硬件的基礎(chǔ)上，進一步提供內(nèi)存管理、進程調(diào)度等功能，為上層應(yīng)用提供體系化的支持。?互聯(lián)網(wǎng)行業(yè)?前后臺雖然是同時建設(shè)的，它們在功能上能夠銜接起來，但前臺求據(jù)，和前臺構(gòu)成C端業(yè)務(wù)的小閉環(huán)，支持業(yè)務(wù)的快速創(chuàng)新，等業(yè)務(wù)模式驗證后，中臺和后臺再進一步徹底打通，構(gòu)成業(yè)務(wù)的大閉環(huán)。o中臺的適用性?o中臺實現(xiàn)了通用基礎(chǔ)業(yè)務(wù)的平臺化的作用?通過有限而比較固定的基礎(chǔ)業(yè)務(wù)，來滿足無限而快速變化的上層業(yè)務(wù)場景?從變化速度來看，企業(yè)基礎(chǔ)的業(yè)務(wù)是相對固定的，而具體上層業(yè)務(wù)場景是相對多變的；?從數(shù)量來看，基礎(chǔ)業(yè)務(wù)數(shù)量是有限的，而具體業(yè)務(wù)場景是無限的。?企業(yè)級業(yè)務(wù)能力的快速復(fù)用業(yè)務(wù)規(guī)則?從系統(tǒng)角度看，中臺相當于操作系統(tǒng)，對外提供標準接口，屏蔽了底層系統(tǒng)的復(fù)雜性?從數(shù)據(jù)角度看，中臺收斂了數(shù)據(jù)，比如使用同一套訂單數(shù)據(jù)模型，讓所有渠道的訂單使用相同的訂單模型，所有訂單數(shù)據(jù)落到同一個訂單?概念?中臺是微服務(wù)的升級版o在微服務(wù)架構(gòu)下，我們搭建的是一個個離散的服務(wù)，如商品服務(wù)、訂單服務(wù)等等。而在中臺里，這些微服務(wù)升級為了商品中心、訂單中心，每個中心更強調(diào)體系化，包括更好的業(yè)務(wù)通用能力，更好的系統(tǒng)運營能力(如監(jiān)控、穩(wěn)定性、性能的強化)，更好的業(yè)務(wù)運營能力(比如商品中心自帶配套的商品管理后臺)o每個服務(wù)中心都圍繞核心業(yè)務(wù)，自成體系，成為一個微內(nèi)核，這些微內(nèi)核形成一個有機整體，共同構(gòu)成了基礎(chǔ)業(yè)務(wù)平臺，也服務(wù)架構(gòu)向中臺架構(gòu)的演進過程。?業(yè)務(wù)中臺三層結(jié)構(gòu)o?基礎(chǔ)業(yè)務(wù)能力由通用基礎(chǔ)業(yè)務(wù)平臺來實現(xiàn)?通用聚合服務(wù)對基礎(chǔ)業(yè)務(wù)進行組合，進一步提升了業(yè)務(wù)能力的易用性?通用中間件平臺，通過技術(shù)手段保證了業(yè)務(wù)中臺的穩(wěn)定性，三者一起實現(xiàn)了企業(yè)整體業(yè)務(wù)能力的復(fù)用?落地化到中臺，更多的是各個基礎(chǔ)服務(wù)點上的強化和面上的整合?系統(tǒng)構(gòu)成?對于傳統(tǒng)企業(yè)來說，系統(tǒng)基本上是“川”字型的結(jié)構(gòu)，大量獨立的商業(yè)套件組成遺留系統(tǒng)，落地中臺是一個革命性的動作。o傳統(tǒng)企業(yè)中臺架構(gòu)設(shè)計圖?渠道&應(yīng)用?整個系統(tǒng)的對外部分，包括了各個應(yīng)用的前端，如App、小程序、公眾號等等，這些是需要定制的部分。同時，在對外部分，我們還會?應(yīng)用平臺?是各個具體應(yīng)用的母體，它包含了各個應(yīng)用的等，這些服務(wù)端會針對具體場景，做流程編排和信息的聚合?業(yè)務(wù)中臺?是中臺架構(gòu)的核心，它包括一系列的通用基礎(chǔ)服務(wù)，以及它上面的通用聚合服務(wù)和下面的技術(shù)平臺?后臺?第一部分是適配插件，用于連接商戶內(nèi)部系統(tǒng)和中臺基礎(chǔ)服務(wù)，比如，在中臺的商品服務(wù)和后臺ERP之間同步商品數(shù)據(jù)，在中臺的會員服務(wù)和后臺CRM之間同步會員信息。一般針對每個內(nèi)部系統(tǒng)，都有一個適配插件，它起到了類似硬件驅(qū)動程序的作用，這個一般是定制化的?第二部分是企業(yè)內(nèi)部系統(tǒng)，這個是企業(yè)的IT基o關(guān)系o系統(tǒng)的構(gòu)成：模塊+關(guān)系?模塊是系統(tǒng)的基本組成部分，它泛指子系統(tǒng)、應(yīng)用、服務(wù)或功能模塊。關(guān)系指模塊之間的依賴關(guān)系，簡單地講，就是模塊之間有調(diào)用，我們知道，調(diào)用區(qū)分發(fā)起方和服務(wù)方，因此，依賴關(guān)系是有方向性的。o模塊?概念?模塊定義系統(tǒng)都有哪些基本的“玩家”，分別承擔什么職責。從業(yè)務(wù)的角度看，每個模塊都代表了某個業(yè)務(wù)概念，或者說業(yè)務(wù)領(lǐng)域。?模塊內(nèi)部由數(shù)據(jù)和業(yè)務(wù)邏輯組成，其中數(shù)據(jù)是核心，業(yè)務(wù)邏輯圍繞著數(shù)據(jù)，對數(shù)據(jù)做進一步加工，方便外部使用。?打造可擴展要求?定位明確，概念完整。o定位：保證模塊業(yè)務(wù)概念的完整性。數(shù)據(jù)上，模塊需要覆蓋對應(yīng)業(yè)務(wù)領(lǐng)域的全部數(shù)據(jù)，比如一個訂單模塊，它要覆蓋所有渠的訂單等，這些不同類型訂單的數(shù)據(jù)模型和實際數(shù)據(jù)，都由訂。o功能：模塊要包含業(yè)務(wù)領(lǐng)域的全部功能，比如訂單模塊包含所有訂單相關(guān)的功能，包括訂單數(shù)據(jù)的增刪改查、訂單業(yè)務(wù)規(guī)則校驗、訂單的狀態(tài)和生命周期管理等。o自成體系：模塊的業(yè)務(wù)邏輯盡量圍繞自身內(nèi)部數(shù)據(jù)進行處理，對外部依賴越小，模塊的封裝性越好，穩(wěn)定性也越強，不會隨著外部模塊的調(diào)整而調(diào)整。o粒度適中：不能為了追求定位清晰，把粒度劃分得很小，導(dǎo)致系統(tǒng)的碎片化。?關(guān)系定義了模塊如何協(xié)作，一起完成業(yè)務(wù)流程，依賴關(guān)系實質(zhì)上體現(xiàn)的是模塊?簡化模塊的依賴關(guān)系?簡化依賴的方向o單向關(guān)系?減少依賴的數(shù)量o網(wǎng)狀結(jié)構(gòu)轉(zhuǎn)化為層次結(jié)構(gòu)?借鑒做法?我們按照模塊定位的不同，把模塊劃分為不同層次，比如劃分為上面的應(yīng)用層和下面的資源層。這樣，一個層通過把多個模塊組織在一起，就形成了概念上更大粒度的模塊。有了層以后，我們理解業(yè)務(wù)時，因為模塊定位相同，往往關(guān)注這個更大粒度的層就可以，依賴關(guān)系只要指向這個層，而不是層里面的各個模塊。這樣，從人理解業(yè)務(wù)的角度，依賴的數(shù)量大幅?具體例子?MVC架構(gòu)：表示層、應(yīng)用層、聚合服務(wù)層、基礎(chǔ)服務(wù)層o?擴展性的本質(zhì)o表象?業(yè)務(wù)總在變化，要求架構(gòu)設(shè)計給系統(tǒng)提供良好的擴展性。o深層o通過構(gòu)建合理的模塊體系，有效地控制系統(tǒng)復(fù)雜度，最小化業(yè)務(wù)變化引起的系統(tǒng)調(diào)整。?打造可擴展的模塊體系o拆分：實現(xiàn)模塊劃分??水平拆分o定義：從上到下把系統(tǒng)分為多層，按照系統(tǒng)處理的先后順序，個步驟。o優(yōu)點?使每一塊職責都比較明確，功能內(nèi)聚，每個模塊管理自己內(nèi)部的復(fù)雜性?模塊之間相互松耦合，一個模塊的修改不影響另一個模塊?很好地滿足現(xiàn)有業(yè)務(wù)做深度擴展，當業(yè)務(wù)有變化時，系統(tǒng)在特定層做調(diào)整，對其他層影響有限，這樣把變化局限在一個小范圍?垂直拆分o定義：是按照不同的業(yè)務(wù)線拆分，按照不同的業(yè)務(wù)場景，自上而下進行豎切，讓每個業(yè)務(wù)都自成體系，形成自己的業(yè)務(wù)閉o優(yōu)點?滿足業(yè)務(wù)廣度上的擴展?一般做業(yè)務(wù)架構(gòu)時，我們先考慮垂直拆分，從大方向上，把不同業(yè)務(wù)給區(qū)分清楚，然后再針對具體業(yè)務(wù)，按照業(yè)務(wù)處理流程進行水平拆分。o整合：優(yōu)化模塊依賴關(guān)系?通用化似功能的模塊?優(yōu)點：模塊的數(shù)量減少了，模塊的定位更清晰，概念更完整，職責更聚焦。在實踐中，當不同業(yè)務(wù)線對某個功能需求比較類似時，我們經(jīng)?平臺化?定義：把定位相同的模塊組織在一起，以組團的方式對外提供服務(wù)。對于外部系統(tǒng)來說，我們可以把這些模塊看成是一個整體，一起對業(yè)全面的支撐。??可復(fù)用架構(gòu)o問題?好不容易搞定了一個項目，接著又有新的類似項目過來，我們又要從頭再來?項目的代碼是定制的，項目結(jié)束后，系統(tǒng)維護的噩夢剛剛開始o復(fù)用的分類?技術(shù)復(fù)用：代碼復(fù)用和技術(shù)組件復(fù)用?業(yè)務(wù)復(fù)用：業(yè)務(wù)實體復(fù)用、業(yè)務(wù)流程復(fù)用和產(chǎn)品復(fù)用?業(yè)務(wù)實體復(fù)用個業(yè)務(wù)領(lǐng)域的數(shù)據(jù)和業(yè)務(wù)規(guī)則進行封裝，將它變成上層應(yīng)用系統(tǒng)可以直接使用的業(yè)務(wù)組件?業(yè)務(wù)流程的復(fù)用o針對的是業(yè)務(wù)場景，它可以把多個業(yè)務(wù)實體串起來，完成一個端到端的任務(wù)。比如說，下單流程需要訪問會員、商品、訂單、庫存等多個業(yè)務(wù)，如果我們把這些調(diào)用邏輯封裝為一個下單流程服務(wù)，那下單頁面就可以調(diào)用這個流程服務(wù)來完成下單，而不需要去深入了解下單的具體過程。?產(chǎn)品復(fù)用o系統(tǒng)的復(fù)用，比如說一個SaaS系統(tǒng)(Software-as-a-Service)，它在內(nèi)部做了各種通用化設(shè)計，允許我們通過各種參數(shù)配置，得到我們想要的功能；o復(fù)用程度排序?產(chǎn)品復(fù)用>業(yè)務(wù)流程復(fù)用>業(yè)務(wù)實體復(fù)用>組件復(fù)用>代碼復(fù)用?o從技術(shù)復(fù)用到業(yè)務(wù)復(fù)用，越往上，復(fù)用程度越高，復(fù)用產(chǎn)生的價值也越大，但實現(xiàn)起來也越復(fù)雜，它能復(fù)用的場景就越有o如果我們能進一步打造業(yè)務(wù)中間件，并在這個基礎(chǔ)上，形成業(yè)務(wù)平臺，這樣，我們就能實現(xiàn)更高的業(yè)務(wù)級復(fù)用，可以更高效的快速落地。o基礎(chǔ)服務(wù)邊界劃分?定義?要解決“我是誰”的問題，它實現(xiàn)了服務(wù)和周邊環(huán)境的清晰切割口是服務(wù)的對外視圖，它封裝了服務(wù)的業(yè)務(wù)數(shù)據(jù)和規(guī)則?原則個完整的業(yè)務(wù)領(lǐng)域o品基本信息，還需要包含商品擴展信息(標簽)，最后還要包含復(fù)雜商品類型 (組合商品、套餐商品等)o服務(wù)功能的完整性，對于服務(wù)使用者來說，他們是以業(yè)務(wù)的角度看服務(wù)，而不是純粹的數(shù)據(jù)角度。比如一個套餐商品，在服務(wù)內(nèi)部，它是多個單品的復(fù)雜組合，但從服務(wù)調(diào)用者的角度來?服務(wù)的一致性原則：服務(wù)的數(shù)據(jù)和職責要一致，誰擁有信息，誰就負責提供相應(yīng)的功能o服務(wù)內(nèi)部的業(yè)務(wù)邏輯要盡量依賴內(nèi)部數(shù)據(jù)，而不是接口輸入的數(shù)據(jù)，否則會造成數(shù)據(jù)和業(yè)務(wù)規(guī)則的脫節(jié)(一個在外面，一個在里面)o舉例：訂單里的優(yōu)惠信息，如：商品原價多少、滿減優(yōu)惠多少、特價減多少?促銷服務(wù)負責促銷規(guī)則的維護，以及對應(yīng)的優(yōu)惠計算功能?訂單服務(wù)負責優(yōu)惠結(jié)果數(shù)據(jù)落地，以及后續(xù)的查詢功能?正交原則o基礎(chǔ)服務(wù)，它們就處于調(diào)用鏈的底層，服務(wù)之間不會有任何的調(diào)用關(guān)系，也就是說基礎(chǔ)服務(wù)相互之間是正交的。比如說會員服務(wù)和商品服務(wù)，它們代表不同維度的基礎(chǔ)業(yè)務(wù)域，彼此之間不會有調(diào)用關(guān)系o服務(wù)之間有數(shù)據(jù)的依賴關(guān)系，但沒有接口的調(diào)用關(guān)系，如：訂單明細里包含商品ID信息，但訂單服務(wù)內(nèi)部不會調(diào)用商品服務(wù)來獲取商品詳情。如果頁面需要展示訂單的商品詳情，針對這個具體的業(yè)務(wù)場景，我們可以在上層的聚合服務(wù)里，通過聚合訂單服務(wù)和商品服務(wù)來實現(xiàn)o案例?如何設(shè)計一個基礎(chǔ)服務(wù)?落地共享服務(wù)核心o服務(wù)邊界的劃分?服務(wù)邊界確定了這個服務(wù)應(yīng)該“做什么”o功能的抽象設(shè)計?抽象設(shè)計確定了這個服務(wù)應(yīng)該“怎么做”?訂單服務(wù)o訂單業(yè)務(wù)架構(gòu)?o訂單服務(wù)邊界劃分?包含的服務(wù)?基本信息管理?訂單優(yōu)惠管理o從最開始的商品金額，到最后需要用戶實際支付的金額，中間會有一系列的折扣和減免，這些都是屬于訂單信息的一部分。這些信息我們需要展示給用戶看，如果后續(xù)要進行訂單成本的分攤，?訂單生命周期管理o負責管理訂單的狀態(tài)變化?不包含的服務(wù)?作為基礎(chǔ)服務(wù)，訂單服務(wù)不主動調(diào)用其他服務(wù)o訂單的用戶詳情、商品詳情等等，這應(yīng)該由上層應(yīng)用通過調(diào)用相應(yīng)的服務(wù)來實現(xiàn)，然后和訂單信息組裝在一起，而不是在訂單服務(wù)內(nèi)部直接調(diào)用其他服務(wù)，否則會導(dǎo)致基礎(chǔ)服務(wù)之間相互依賴，職責模糊。?訂單服務(wù)不負責和第三方系統(tǒng)的集成o第三方系統(tǒng)，太不具有通用性?訂單服務(wù)不提供優(yōu)惠計算或成本分攤邏輯?不提供履單詳情，不負責詳細物流信息的存儲o功能抽象設(shè)計?訂單數(shù)據(jù)模型??訂單狀態(tài)通用化?開放訂單狀態(tài)定義o優(yōu)點：訂單狀態(tài)及規(guī)則是完全由外部負責管理的，自己負責屬性存儲，訂單服務(wù)很穩(wěn)定o弊端：上層應(yīng)用的負擔會很重，不但要負責定義有哪些狀態(tài)，而且還要維護狀態(tài)的轉(zhuǎn)換規(guī)則，一不小心，訂單可能從A狀態(tài)B，導(dǎo)致業(yè)務(wù)出問題?應(yīng)用和服務(wù)共同管理狀態(tài)o主狀態(tài)，由訂單服務(wù)負責定義??子狀態(tài)，開放給各個應(yīng)用來定義o比如，一個訂單處于配送中，實際情況可能是“倉庫已發(fā)貨”，“貨已到配送站”，或者是“快遞員正在送貨中”等等o訂單服務(wù)接口定義?同步的服務(wù)接口調(diào)用?設(shè)計查詢接口，來滿足各種場景需求o粗粒度接口o中粒度接口o細粒度接口?異步的消息通知息+查詢接口?瘦消息o1號店庫存服務(wù)化改造?背景和目標?背景o?所有商品相關(guān)的表都存在產(chǎn)品庫里面，有產(chǎn)品的表(產(chǎn)品、分類、品牌、組合關(guān)系、屬性等)、商品SKU的表、商家和供應(yīng)商的表、庫存和價格的表等等，這些表加起來，數(shù)量超過了上百張。?系統(tǒng)是類似分布式的，但數(shù)據(jù)庫是集中式，前后臺系統(tǒng)都需要訪問產(chǎn)品庫?痛點o從應(yīng)用方面來說，各個系統(tǒng)功能重復(fù)建設(shè)，比如很多系統(tǒng)都會直接訪問庫存相關(guān)的表，類似的庫存邏輯散布在很多地方；另外，如果修改了庫存表的某個字段，這些系統(tǒng)同時會受影響，正所謂牽一發(fā)而動全身o從數(shù)據(jù)庫方面來說，數(shù)據(jù)庫的可用性是比較差的，如果某個系統(tǒng)有慢查詢，它就很可能拖垮整個產(chǎn)品數(shù)據(jù)庫，導(dǎo)致它不可用；還有，這么多系統(tǒng)同時訪問產(chǎn)品庫，數(shù)據(jù)庫的連接數(shù)也經(jīng)常不夠用?目標o對這個大數(shù)據(jù)庫按照業(yè)務(wù)維度進行垂直拆分，比如分成產(chǎn)品數(shù)據(jù)庫、庫存數(shù)據(jù)庫、價格數(shù)據(jù)庫等等o方式來支持數(shù)據(jù)庫表的訪問o將各個業(yè)務(wù)系統(tǒng)統(tǒng)一接入微服務(wù)，最終完成整個商品體系的微服務(wù)化改造?庫存微服務(wù)改造?挑選庫存改造原因o業(yè)務(wù)價值大o改動小?過程o?準備階段?圈表o確定庫存微服務(wù)具體包含哪些表?表的要求：既容易拆分數(shù)據(jù)庫，又能控制服務(wù)的粒度，保證功能聚焦?滿足所有的庫存訪問需求o表的數(shù)量不能太多?確定服務(wù)的數(shù)據(jù)模型??確定服務(wù)的邊界劃分o收集SQL?收集所有業(yè)務(wù)系統(tǒng)訪問這些表的SQL語句，包括它的業(yè)務(wù)場景說明、訪問頻率o拆分SQL?SQL拆分，會涉及一定的業(yè)務(wù)系統(tǒng)改造及性能影響，需要評估?實施階段o構(gòu)建庫存微服務(wù)?接口設(shè)計、代碼開發(fā)、功能測試等步驟，服務(wù)開發(fā)團隊會對業(yè)務(wù)方提供的SQL進行梳理，然后對接口做一定的通用化設(shè)計，避免為每個SQL定制一個單獨的接?o接入庫存微服務(wù)o數(shù)據(jù)庫獨立?效果圖o??中臺是如何煉成的o系統(tǒng)架構(gòu)是否需要升級的判斷依據(jù)?業(yè)務(wù)上有什么重大變化，導(dǎo)致當前系統(tǒng)的弊端已經(jīng)很明顯，不能適應(yīng)業(yè)務(wù)發(fā)展?架構(gòu)改造時，如何在業(yè)務(wù)、系統(tǒng)、資源三者之間做好平衡，對系統(tǒng)進行分步式o背景?為大型餐飲連鎖企業(yè)打造O2O交易平臺，包括三方聚合外賣、自有小程序、App點餐，這些線上用戶的訂單最終會落到門店的收銀系統(tǒng)，由門店進行履o系統(tǒng)升級過程的架構(gòu)?只有聚合外賣服務(wù)v1版??增加小程序版本v2版?方案選擇o小程序訂單和外賣訂單的處理類似，收銀系統(tǒng)除了對接外賣系要同時對接兩套訂單接口，它需要做大的改造。由于這是第三很難落地。o我們把小程序訂單當作一個特殊的外賣渠道，把小程序訂單推就是相當于小程序訂單直接借用了外賣訂單的履單通道。?統(tǒng)一訂單服務(wù)架構(gòu)v3版??中臺架構(gòu)v4版??技術(shù)架構(gòu)篇o概述?面對一個復(fù)雜的系統(tǒng)的困惑?不清楚系統(tǒng)整體的處理過程，當系統(tǒng)出問題時，不知道如何有針對性地去排查問題?系統(tǒng)設(shè)計時，經(jīng)常忽視非業(yè)務(wù)性功能的需求，也不清楚如何實現(xiàn)這些目標，經(jīng)常是付出慘痛的教訓(xùn)后，才去亡羊補牢?系統(tǒng)的物理模型??技術(shù)架構(gòu)的職責?負責系統(tǒng)所有組件的技術(shù)選型?確保這些組件可以正常運行?技術(shù)架構(gòu)的挑戰(zhàn)?硬件的問題o硬件的處理能力有限?垂直擴展：升級硬件來提升處理能力?水平擴展：增加機器數(shù)量來提升處理能力o硬件不是100%的可靠，它本身也會出問題?軟件的問題o軟件組件?中間件?系統(tǒng)級軟件o軟件是硬件的延伸，給系統(tǒng)的優(yōu)勢?彌補了硬件的缺陷。比如Redis集群，通過數(shù)據(jù)分片，解決了單臺服務(wù)器內(nèi)存和帶寬的瓶頸問題，實現(xiàn)服務(wù)器處理能力的水平擴展；?封裝讓我們可以更高效地訪問系統(tǒng)資源。比如說，數(shù)據(jù)庫是對文件系統(tǒng)的加強，使數(shù)據(jù)的存取更高效；oCAP理論?技術(shù)架構(gòu)的目標?技術(shù)架構(gòu)就要選擇和組合各種軟硬件，再結(jié)合我們開發(fā)的應(yīng)用代碼，統(tǒng)非功能性需求。?非功能性需求o系統(tǒng)的高可用?可用性出問題常見場景?軟硬件本身有故障，比如機器斷電，網(wǎng)絡(luò)不通。通過容錯機制解決?高并發(fā)引起的系統(tǒng)處理能力的不足，通過優(yōu)o系統(tǒng)的高性能?保證合理的性能分兩種情況?常規(guī)的流量進來，但系統(tǒng)內(nèi)部處理比較復(fù)雜，我們就需要運用技術(shù)手段進行優(yōu)化。比如針對海量商品的檢索，我們就需要構(gòu)建復(fù)雜的搜索系統(tǒng)來支持。?高并發(fā)的流量進來，系統(tǒng)仍舊需要在合理的時間內(nèi)提供響應(yīng)，這就更強調(diào)我們做架構(gòu)設(shè)計時，要保證系統(tǒng)的處理能力能夠整體上做水平擴展，而不僅僅是對某個節(jié)點做絕對的性能優(yōu)。o系統(tǒng)的可伸縮和低成本o可監(jiān)控性?故障不可避免，但如何能第一時間發(fā)現(xiàn)問題，快速進行恢復(fù)保障業(yè)務(wù)的連續(xù)性是非常重要的。?做技術(shù)架構(gòu)設(shè)計時，不能不顧一切地要求達到所有目標，而是要根據(jù)業(yè)務(wù)特點，選擇最關(guān)鍵的目標予以實現(xiàn)。比如說，一個新聞閱讀系統(tǒng)，它和訂單、錢沒有關(guān)系，即使短時間不可用，對用戶影響也不大。但在出現(xiàn)熱點新聞時，系統(tǒng)要能支持高并發(fā)的用戶請求。因此，這里的設(shè)計，主要是考慮滿足高性能，而不用太過于追求4個9或5o高可用架構(gòu)?故障點?o資源不可用?網(wǎng)絡(luò)和服務(wù)器出故障，網(wǎng)絡(luò)出故障表明節(jié)點連接不上，服務(wù)器出故障表明該節(jié)點本身不能正常工作。o資源不足發(fā)的情況o節(jié)點的功能有問題?這個主要體現(xiàn)在我們開發(fā)的代碼上，比如它的內(nèi)部業(yè)務(wù)邏輯有問題，或者是接口不兼容導(dǎo)致客戶端調(diào)用出了問?高可用的總體解決思路??架構(gòu)設(shè)計原則?o正面保障?冗余無單點?無單點設(shè)計針對的是節(jié)點本身的故障?水平擴展?針對的是節(jié)點處理能力的不足o減少損失?柔性事務(wù)?柔性事務(wù)保證功能的基本可用和數(shù)據(jù)的最終一致?系統(tǒng)可降級：通過損失非核心功能來保證核心功能的可用?限流?降級?熔斷?功能禁用o系統(tǒng)可監(jiān)控?通過監(jiān)控，我們可以實時地了解系統(tǒng)的當前狀態(tài)?高可用手段o客戶端到服務(wù)端通常是遠程訪問，需要解決網(wǎng)絡(luò)的可用性問題oHA如Nginx、HAProxy、LVS等負載均衡軟件，能很好地支持雙節(jié)點+Keepalived部oWeb節(jié)點的水平擴展o自動故障轉(zhuǎn)移o系統(tǒng)的可降級(限流)o反爬蟲WeboWeb節(jié)點的水平擴展o自動故障轉(zhuǎn)移o系統(tǒng)的可降級(限流、業(yè)務(wù)開關(guān))?訪問基礎(chǔ)資源o關(guān)系數(shù)據(jù)庫?主從部署?讀寫分離?MHA方案?VIP漂移o緩存o消息系統(tǒng)?處理事故有三板斧?回滾?重啟?加機器?高可用案例?如何實現(xiàn)O2O平臺日訂單500萬？o項目背景介紹?大型餐飲公司的小程序點餐平臺?用戶在小程序上點餐并支付完成后，訂單會先落到訂單庫，然后進一步推送到門店的收銀系統(tǒng)；收銀系統(tǒng)接單后，推送給后廚系統(tǒng)進行生產(chǎn)；同時返回小程序取餐碼，用戶可以憑取餐碼去門店取餐或收取外賣。?促銷活動?前端小程序請求將會達到每秒10萬QPS?首日的訂單數(shù)量會超過500萬?保證用戶的體驗，系統(tǒng)整體的可用性要達到99.99%。?系統(tǒng)架構(gòu)?o高可用系統(tǒng)改造措施??前端接入改造o小程序端的CDN優(yōu)化?儲存靜態(tài)的商品數(shù)據(jù)、圖片?Nginx負載均衡?收銀端的通信線路備份?應(yīng)用和服務(wù)的水平擴展?訂單水平分庫?異步化處理?主動通知，避免輪詢?如何第一時間知道系統(tǒng)哪里有問題？?監(jiān)控的分類o?用戶體驗監(jiān)控?指的是從前端用戶的訪問速度出發(fā)，來監(jiān)測系統(tǒng)的可用性，包括頁面能否打開、關(guān)鍵接口的響應(yīng)時間等等，用戶體驗監(jiān)控一般結(jié)合前端的埋點來實現(xiàn)?業(yè)務(wù)監(jiān)控?它是從業(yè)務(wù)結(jié)果的角度來看，比如說訂單數(shù)、交易金額等等，業(yè)務(wù)監(jiān)控也是最直觀的，我們知道，如果業(yè)務(wù)數(shù)據(jù)沒問題，系統(tǒng)整體也就沒里定時拉取業(yè)務(wù)數(shù)據(jù)，然后以曲線的方式展示業(yè)務(wù)指標隨著時間的變化過程。除了當前的曲線，一般還有同比和環(huán)比曲線。同比是和前一天的數(shù)據(jù)進行比較，環(huán)比是和一周前的數(shù)據(jù)進行比較，兩方面結(jié)合起來，我們就能知道當前有問題。?應(yīng)用監(jiān)控?指的是對自己開發(fā)的代碼進行監(jiān)控，比如接口在一段時間內(nèi)的調(diào)用次數(shù)、響應(yīng)時間、出錯次數(shù)等等。更深入一點的應(yīng)用監(jiān)控還包含了調(diào)用鏈監(jiān)控，我們知道，一個外部請求的處理過程包含了很多環(huán)節(jié)，比如說網(wǎng)關(guān)、應(yīng)用、服務(wù)、緩存和數(shù)據(jù)庫，我們可以通過調(diào)用鏈監(jiān)控把這些環(huán)節(jié)串起來，當系統(tǒng)有問題時，我們可以一步步地排查。有很多APM工具可以實現(xiàn)調(diào)用?中間件監(jiān)控?指的是對標準中間件進行監(jiān)控，它是第三方開等，這些組件對應(yīng)的是系統(tǒng)的PaaS層。這些中間件往往帶有配套的監(jiān)控系統(tǒng)，比如，RabbitMQ就有自帶的監(jiān)控后臺。?基礎(chǔ)平臺監(jiān)控?指的是對系統(tǒng)底層資源進行監(jiān)控，如操作系系統(tǒng)的IaaS層。Zabbix就是典型的基礎(chǔ)設(shè)施監(jiān)控工具，它可以監(jiān)控CPU、內(nèi)存和磁盤的使用情況。?監(jiān)控的痛點o不同的節(jié)點，它的監(jiān)控的方式是不一樣的，相應(yīng)地，監(jiān)控的結(jié)同的系統(tǒng)里輸出。o系統(tǒng)不同部分的監(jiān)控都是由不同的人負責的，比如說，運維負責的是基礎(chǔ)平臺監(jiān)控，開發(fā)負責的是應(yīng)用系統(tǒng)監(jiān)控。而監(jiān)控信息往往專門的人才能解讀，比如應(yīng)用監(jiān)控，它需要對應(yīng)的開發(fā)人員才能判斷當前的接口訪問是否有問題o系統(tǒng)作為一個整體，需要上下游各個環(huán)節(jié)的人一起協(xié)作，進行大量的溝通，才能最終找到問題。?常見問題o?發(fā)現(xiàn)問題慢?業(yè)務(wù)監(jiān)控的曲線一般1分鐘更新一次，有時候因為正常的業(yè)務(wù)抖動，Monitor還需要把這種情況排除掉。因此，他會傾向于多觀察幾分鐘，這樣就導(dǎo)致問題的確認有很大的滯后性?定位問題慢于節(jié)點依賴復(fù)雜，需要反復(fù)溝通才能把信息串起來，因此很多時候，這種排查方式是串行或者說無序的。一方面，無關(guān)的人會卷入進來，造成人員的浪費；另一方面排查效率低，定位問題的時間長?解決問題慢?當定位到問題，對系統(tǒng)進行調(diào)整后，驗證問題是否已經(jīng)得到解決，也不是一件很直觀的事情，需要各個研發(fā)到相應(yīng)的監(jiān)控系統(tǒng)里去進行觀察，通過滯后的業(yè)務(wù)曲線觀察業(yè)務(wù)是否恢?解決思路o對系統(tǒng)的監(jiān)控要求?系統(tǒng)能夠自動地判斷每個節(jié)點是否正常，并直觀地給出結(jié)果，不需要經(jīng)過專業(yè)人員的分析。?系統(tǒng)能夠自動把各個節(jié)點的監(jiān)控信息有機地串起來，從整體的角度對系統(tǒng)進行監(jiān)控，不需要很多人反復(fù)地進行o監(jiān)控效果?要實時?需要第一時間知道系統(tǒng)當前是否有問題?要直觀?節(jié)點是否有問題，我們需要很直觀地就能判斷出來，就像交通圖上的紅黃綠顏色標識一樣。?整體監(jiān)控?針對系統(tǒng)做整體監(jiān)控，就像交通圖一樣，它是針對周邊整體的道路情況進行展示，我們也需要把系統(tǒng)的各個節(jié)點放在一起，清晰地給出節(jié)點依賴關(guān)系。系統(tǒng)真正出問題的地方往往只有一個，其他地方都是連帶的，如果監(jiān)控系統(tǒng)能夠給出節(jié)點的上下游依賴關(guān)系，對于定位真正的問題源是非常有用的。o監(jiān)控方式?系統(tǒng)中的每個節(jié)點對應(yīng)交通圖的一條道路?節(jié)點的健康狀況對應(yīng)道路的擁堵情況，節(jié)點同樣也有紅黃綠三種不同的顏色，來展示該節(jié)點是否正常；?節(jié)點之間的調(diào)用關(guān)系對應(yīng)道路的方位關(guān)系?目標o構(gòu)建一個實時的、直觀的、一體化的監(jiān)控系統(tǒng)，類似交通圖一樣，可以一眼就看出系統(tǒng)的問題所在。o終極目標：故障自動定位(自動發(fā)現(xiàn)問題、通知故障處理、自動定位問題、故障處理、故障恢復(fù))?監(jiān)控系統(tǒng)的整體架構(gòu)o?如何打造一體化的監(jiān)控系統(tǒng)？?節(jié)點信息采集?接入監(jiān)控系統(tǒng)?前端信息展示?高性能和可伸縮架構(gòu)o常見場景?系統(tǒng)的TPS很低，只要流量一大，系統(tǒng)就掛，加機器也沒用；?機器的資源利用率很低，造成資源嚴重浪費o常用的性能數(shù)據(jù)?o高性能的策略和手段?加快單個請求處理?優(yōu)化處理路徑上每個節(jié)點的處理速度?并行處理單個請求，MapReduce思想?同時處理多個請求?請求處理異步化o