<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          人人都是架構(gòu)師???談何容易!!

          共 3978字,需瀏覽 8分鐘

           ·

          2021-06-13 07:52

          軟件架構(gòu)跟蓋樓有異曲同工之妙。首先建筑師(軟件行業(yè):稱之為架構(gòu)師)在圖紙上把大樓外觀、主體結(jié)構(gòu)、材料工藝、施工流程等設(shè)計好。施工隊根據(jù)圖紙,打好地基,并開始建設(shè)能滿足抗地震、抗臺風、抗沉降(高并發(fā)、高性能、高可用)等必備條件的大樓主體結(jié)構(gòu),然后再澆筑墻體、封頂、室內(nèi)裝飾。

          建筑師對主體結(jié)構(gòu)的設(shè)計,在軟件工程中便是架構(gòu)設(shè)計;大樓的主體結(jié)構(gòu)在軟件工程中就是架構(gòu),它主要處理軟件的子系統(tǒng)和組件的開發(fā)和部署方式、技術(shù)指標和規(guī)范,以及它們之間的相互關(guān)系。

          很多人多架構(gòu)師可能有誤解,認為只是做了好多很炫的PPT,各種的架構(gòu)圖、UML圖、流程圖、模塊拆分、組件拆分、部署圖等,感覺完全是紙上談兵,一行代碼沒寫,夸夸其談。

          其實不然,古代帶兵打仗,講究兵馬未動糧草先行,正式開拔前一定要先把準備工作做好。畢竟做設(shè)計比寫代碼推翻重來的成本要低得多。


          成為一名優(yōu)秀的架構(gòu)師需要具備很多條件:

          • 業(yè)務(wù)理解轉(zhuǎn)化能力
          • 思維抽象能力
          • 軟件建模能力
          • 高并發(fā)、高性能、高可用的分布式系統(tǒng)架構(gòu)設(shè)計能力
          • 前沿技術(shù)選型把控能力
          • 系統(tǒng)重構(gòu)能力
          • 快速學習能力
          • 此外,還要懂分布式緩存、消息隊列、負載均衡、數(shù)據(jù)庫、NoSQL、搜索、RPC、容器、分庫分表、注冊中心、分布式配置、鏈路跟蹤、服務(wù)治理、系統(tǒng)監(jiān)控、微服務(wù)等等。此處省略1萬字。。。

          兵法有云,“戰(zhàn)略上藐視敵人,戰(zhàn)術(shù)上重視敵人!”


          有一個自信的意識,意味著你一只腳已經(jīng)邁入成功的大門。

          低頭走路,時不時也要抬頭看天。要想做好、做精一件事,不能只局限某一個細節(jié)點,要做到既有點也有面。放眼全局,才能更好驗證細節(jié)做的好不好,在整體架構(gòu)中是否合理。否則,很容易導(dǎo)致木桶效應(yīng)

          如何做好架構(gòu)設(shè)計,有哪些經(jīng)驗可以遵循,我們簡單來學習下

          ?? 一、“拆分” ,降低架構(gòu)復(fù)雜度


          世上沒有無緣無故的愛,也沒有無緣無故的恨,一切皆有因果。那為什么要做拆分呢?

          人類大腦神經(jīng)信號傳遞靠的是離子,通過透過鈉與鉀等離子來傳輸,其速度被限制在化學擴散的速率,所以我們的大腦內(nèi)大部分神經(jīng)信號是以約 30m/s 的速度傳播。

          由于人腦處理問題的能力是有限的,當面對復(fù)雜問題時,會主動去尋找一些方法提升效率(這也是人與動物的最大區(qū)別,人具有思考能力)。神器就是拆分,將復(fù)雜問題拆解為多個相對簡單的小問題。分而治之、各個擊破,這樣做極大地提高了解決復(fù)雜問題的可能性和效率。

          簡單歸納:應(yīng)用拆分、服務(wù)拆分、數(shù)據(jù)拆分、應(yīng)用解耦。

          比如常見的電商領(lǐng)域,當用戶發(fā)展到一定規(guī)模后,會拆分成一系列的業(yè)務(wù)子域:商戶、商品、庫存、權(quán)限、訂單、支付、履約、結(jié)算、售后、財務(wù)、會員、營銷、采購、倉儲等眾多模塊,項目實戰(zhàn)中可以結(jié)合DDD,來幫助我們理清、劃分各個子系統(tǒng)的邊界。


          拆分帶來的好處:

          • 需求不斷疊加導(dǎo)致并行開發(fā)和上線時,通過拆分可以減少相互影響。
          • 降低系統(tǒng)的復(fù)雜度,讓研發(fā)人員適當聚焦,提升專業(yè)度。
          • 弱化各個模塊間的耦合性,降低整體系統(tǒng)風險
          • 大家分工更加明確,各司其職,工作效率更高
          • 拆分微服務(wù)后,無狀態(tài)化部署,更容易橫向擴容,方便我們有針對性補齊某塊性能短板,提升整體系統(tǒng)吞吐量


          拆分需注意事項:

          • 最好是從頂層按業(yè)務(wù)及業(yè)務(wù)流程來垂直拆分,而不是純技術(shù)視角維度。畢竟研發(fā)更多是跟著產(chǎn)品節(jié)奏來走
          • 對于拆分得到的具體模塊,可以按讀寫分離在線離線分離快慢分離場景分離等方式做進一步的水平拆分。
          • 隨著業(yè)務(wù)的升級演化,不斷調(diào)整策略,將易變與穩(wěn)定共性與非共性進行水平拆分

          拆分是架構(gòu)設(shè)計大型復(fù)雜系統(tǒng)的第一步,對降低系統(tǒng)復(fù)雜性有著決定性的意義,它也是架構(gòu)師的必備技能之一。


          ?? 二、認知抽象,架構(gòu)模式有通用性


          認知很重要,認知很重要,認知真的重要,重要的話說三遍。大家應(yīng)該聽過一個成語:“一通百通”,出自明·吳承恩《西游記》。

          原文:這猴王也是他一竅通時百竅通,當時習了口訣,自習自練,將七十二般變化,都學成了。


          翻譯過來:一個主要的弄通了,其他的自然也都會弄通。

          相信很多人都面試過別人,或者被別人面試過。大家有沒有發(fā)現(xiàn)一個現(xiàn)象,簡歷中項目經(jīng)驗很重要,但是有時想招到一個對口業(yè)務(wù)的人真的很難,這時考量標準就會轉(zhuǎn)變?yōu)閷η舐氄叩幕A(chǔ)技術(shù)能力(比如算法)、表達能力、歸納能力、抽象思維能力。正所謂“一通百通”,你在一個行業(yè)積累了成功的項目經(jīng)驗,那么再換一個賽道也不會有問題。

          現(xiàn)如今,互聯(lián)網(wǎng)行業(yè)快速發(fā)展,各種垂直化業(yè)務(wù)如雨后春筍般涌現(xiàn)出來,騰訊的IM即時通訊、阿里巴巴的電商、滴滴的打車、百度的搜索、餓了么的O2O外賣。


          看似形態(tài)各異,但細細一想,是不是也可以歸納為:讀業(yè)務(wù)、寫業(yè)務(wù)、扣減業(yè)務(wù)。

          • 讀業(yè)務(wù):對于讀的SLA(服務(wù)等級協(xié)議)要求非常高。但考慮到數(shù)據(jù)更改的頻率低,通常采用數(shù)據(jù)盡量前置應(yīng)對性能要求。
          • 寫業(yè)務(wù):對寫的SLA要求高,寫業(yè)務(wù)的特點是寫入的數(shù)據(jù)是用戶私有的而不是共享的,同時寫入不需要依賴已有的數(shù)據(jù)。對于 UGC 寫業(yè)務(wù),只要盡最大可能將數(shù)據(jù)存儲下來即可。
          • 扣減業(yè)務(wù):與上面寫業(yè)務(wù)類似,但是寫入的內(nèi)容要少很多,但是對單個數(shù)值的并發(fā)修改能力要求很高,可以考慮將大庫存拆分N份小庫存,從而降低并發(fā)寫壓力。

          假如你在微博工作做,知道微博的熱搜事件(讀事件)如何架構(gòu),緩存的熱點問題如何解決。那么同樣切到電商業(yè)務(wù),對一些爆款商品的展示,我們也是有很多共性化的技術(shù)方案可以參考,我們要學會舉一反三。


          ?? 三、一圖勝千言,畫各種類型圖


          為什么架構(gòu)師都喜歡畫圖呢,一圖勝千言啊。人的生理結(jié)構(gòu)更容易接受視覺型知識輸入。

          《五視圖法》描述架構(gòu):

          • 邏輯視圖:對應(yīng)邏輯架構(gòu),主要關(guān)注功能需求,以及系統(tǒng)職責和行為的劃分。邏輯視圖不僅包括用戶可見的功能,還包括相應(yīng)的輔助功能。比如秒殺系統(tǒng)中的活動場次切換、商品列表、用戶登錄、活動管理、后臺權(quán)限等功能

          • 開發(fā)視圖:對應(yīng)開發(fā)架構(gòu),主要關(guān)注系統(tǒng)開發(fā)過程中的質(zhì)量屬性。它包括軟件源碼的組織方式、引入開源框架、配置方式、編譯打包方式以及與第三方包的依賴關(guān)系等。

          • 運行視圖:對應(yīng)運行架構(gòu),主要關(guān)注軟件運行過程中的質(zhì)量屬性,它包括進程、線程、協(xié)程、對象之間的并發(fā)、同步、通信的問題等。

          • 物理視圖:對應(yīng)物理架構(gòu),主要關(guān)注安裝和部署需求。它包括軟件運行時的系統(tǒng)、網(wǎng)絡(luò)、服務(wù)器等基礎(chǔ)設(shè)施和相關(guān)配置,以及如何利用基礎(chǔ)設(shè)施來實現(xiàn)應(yīng)用程序的高可用、可伸縮等。

          • 數(shù)據(jù)視圖:對應(yīng)數(shù)據(jù)架構(gòu),通常用 E-R 圖(Entity Relationship Diagram,實體-聯(lián)系圖)表示。主要關(guān)注數(shù)據(jù)需求,它包括數(shù)據(jù)的格式、屬性、關(guān)系等。


          ?? 四、系統(tǒng)是演化來的,切勿初期就翻天覆地


          隨著公司業(yè)務(wù)的擴大,系統(tǒng)也會經(jīng)歷一個演化過程。大致分為這么幾個階段:煙囪式架構(gòu) --> 平臺化 --> 中臺化

          就像人一樣,每個階段也都有自己的優(yōu)點和不足,業(yè)務(wù)早期追求速度,講究快速落地,搶占市場,時間就是生命,我們可能采用集中式架構(gòu),系統(tǒng)快速落地,后期在慢慢優(yōu)化、架構(gòu)升級。

          早期的系統(tǒng)很多都是煙囪式架構(gòu),自上而下一體化,存在大量的模塊重復(fù),導(dǎo)致維護成本很高。另外模塊割裂對業(yè)務(wù)也有很大影響,比如:會員模塊,每個渠道都有自己的獨立用戶體系,用戶登錄網(wǎng)站系統(tǒng)時需要記住多套賬號,體驗較差。也不利于數(shù)據(jù)互通、共享,無法最大化發(fā)揮數(shù)據(jù)的價值。此時,便有了從煙囪式架構(gòu)朝著平臺化演化。


          平臺化是從降低技術(shù)重復(fù)的角度出發(fā),將重復(fù)模塊進行融合,從而提升效率。


          中臺化,也稱為企業(yè)級的能力復(fù)用平臺。從業(yè)務(wù)復(fù)用的角度出發(fā),進一步提升業(yè)務(wù)落地的效率。

          中臺的搭建思路:

          • 從平臺化到中臺化演化升級,可以從業(yè)務(wù)能力可視化業(yè)務(wù)能力在線配置化的方法進行落地改造。
          • 開發(fā)建設(shè)一套業(yè)務(wù)可視化平臺,將業(yè)務(wù)平臺中的代碼流程可視化地登記到可視化系統(tǒng)中,按照一定的連線規(guī)則流程引擎規(guī)則,形成業(yè)務(wù)流。另外要保證可視化平臺能夠在業(yè)務(wù)代碼修改后,實時感知更新相對應(yīng)的流程。


          可視化之后,業(yè)務(wù)邏輯可以直接在可視化平臺上展現(xiàn)出來,業(yè)務(wù)方和產(chǎn)品經(jīng)理不需要頻繁和研發(fā)溝通確認需求,可以極大地減少溝通時間,有助于業(yè)務(wù)快速落地

          中臺價值:當面對不斷出現(xiàn)的新的業(yè)務(wù)場景和形態(tài)時(如電商里新出現(xiàn)的社區(qū)團購等),中臺需要快速地復(fù)用已有能力,去滿足業(yè)務(wù)新建站點或不斷擴寬業(yè)務(wù)邊界的訴求。


          ?? 最后,聊聊關(guān)于 “道” 認知

          不管是設(shè)計什么樣的系統(tǒng),在做技術(shù)方案前一定要充分了解業(yè)務(wù)背景、客戶需求,否則很容易走偏。最終開發(fā)出來的系統(tǒng)不是客戶想要的。

          除了分析功能需求外,還要深入挖掘背后的非功能需求,如:面向的客戶群體是哪些?有多少用戶?一般什么時候訪問系統(tǒng)?可能會做出哪些危害系統(tǒng)的操作?

          有針對性的加固系統(tǒng),如果是秒殺性質(zhì),要思考系統(tǒng)如何不被瞬間洪峰流量沖垮。提前準備降級方案,舍小保大。在保證系統(tǒng)的高并發(fā)輸出外,也要兼顧系統(tǒng)的穩(wěn)定性。

          架構(gòu)和歷史也是一樣,分久必合合久必分,但在分分合合的過程中一定要結(jié)合業(yè)務(wù)現(xiàn)狀來設(shè)計演化。千萬不要脫離業(yè)務(wù),純技術(shù)或心性自由發(fā)揮,這樣很容易受挫。

          最后,這個世界上沒有什么是完美的,架構(gòu)設(shè)計也是一樣的,比如拆分后帶來的分布式事務(wù)、調(diào)用鏈路變長、模塊變多,線上服務(wù)器增多,排查問題復(fù)雜,跨團隊溝通成本增加等問題。不管怎樣,滿足當前業(yè)務(wù)發(fā)展,且預(yù)留一定的擴展性,滿足未來短期內(nèi)的發(fā)展需要,這樣的架構(gòu)設(shè)計就是合格的架構(gòu)設(shè)計。





          推薦閱讀:
          億級系統(tǒng)的Redis緩存如何設(shè)計
          學會這10個設(shè)計原則,離架構(gòu)師又進一步
          知乎高贊:為什么Kafka需要Leader而Redis不需要
          由淺入深逐步講解Java并發(fā)的半壁江山AQS
          再有人問你MySQL索引原理,就把這篇文章甩給他!

          關(guān)互聯(lián)網(wǎng)全棧架構(gòu)

          瀏覽 33
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  日韩少妇视频 | 伊人中文| 91AV综合网 | 夜夜干天天操 | 在线观看欧美一区二区 |