一、架構(gòu)的定義

　　所謂一千個架構(gòu)師中有一千種“最好的架構(gòu)”模式。

　　“架構(gòu)”是我們行業(yè)中非常普遍的詞，表示它也必須是經(jīng)過長時間磨合后形成的詞。 架構(gòu)一詞的含義是什么？ 解決什么問題？ 只有理解了這兩個問題，我們才能設(shè)計出良好的項目結(jié)構(gòu)。

　　我認為架構(gòu)類似于繪制房屋設(shè)計。 當我們第一次建造一間只有一層的小房子時，我們拍了一下片刻。 我們有了一個大概的主意就開始著手建設(shè)。 在某些情況下，它不會出現(xiàn)。 但是，當您要建造架構(gòu)物時，拍打額頭的方法此時可能仍然有用，但是由于尚未仔細考慮，因此建造不可避免地會出現(xiàn)問題。 此外，建造架構(gòu)物和建造一層平房所需的團隊規(guī)?？隙ㄊ遣煌?。 每個人都有不同的標準。 如果沒有統(tǒng)一的規(guī)范，可以想象最終結(jié)果。 因此，結(jié)構(gòu)是設(shè)定規(guī)則和限制。 權(quán)衡各方的得失后，這是“最合理的決定”。 它指導團隊中的每個人在意識形態(tài)水平上達成共識，以便最終產(chǎn)品由一個人完成。 結(jié)果一樣。 此外，它還具有控制復雜性，改善團隊協(xié)作，降低成本等功能。

　　在軟件開發(fā)中，體系結(jié)構(gòu)的意義不僅在于團隊要達成共識，因為我們工作的本質(zhì)是制作支持業(yè)務(wù)發(fā)展的更好的軟件產(chǎn)品，因此體系結(jié)構(gòu)也基于業(yè)務(wù)體系結(jié)構(gòu)。 我認為良好的結(jié)構(gòu)可以提前1到2年預測業(yè)務(wù)發(fā)展。 這樣，可以支付合理的價格來換取技術(shù)領(lǐng)先的業(yè)務(wù)增長的影響。 我相信，大多數(shù)留在中小型公司的人都應(yīng)該經(jīng)歷過被生意推開的時代。 每天，他們都會卡在這里，掛在這里，并在這里報告錯誤。 當我們遇到這些問題時，該花時間考慮當前體系結(jié)構(gòu)是否存在問題了？

　　二、如何開始設(shè)計一個架構(gòu)

　　進行體系結(jié)構(gòu)最重要的一點是上述業(yè)務(wù)適配。 任何不基于業(yè)務(wù)去做異想天開的體系結(jié)構(gòu)的流氓?

　　體系結(jié)構(gòu)不像編寫代碼，對是對，對錯是錯，沒有對錯，這是一個選擇的過程。 當我們從0開始構(gòu)建架構(gòu)時，確實更加困難。 盡管一開始很難做，但是良好的開端等于成功的一半，這將為我們的下一個工作打下堅實的基礎(chǔ)。

　　讓我們解釋一下作者是如何從頭開始親自構(gòu)建架構(gòu)的，以供您參考和研究：

　　1.結(jié)構(gòu)是整個過程->過程的一部分。 首先，有必要弄清楚整個公司/組織為外界提供的服務(wù)是什么？ 這是最高級別的戰(zhàn)略結(jié)構(gòu)，一旦確定，基本上是很難或不可能更改的。

　　2.將解決方案劃分為每個部分(例如SOA的特定服務(wù))。 例如，根據(jù)公司的組織結(jié)構(gòu)或產(chǎn)品。

　　3.找到每個解決方案的核心功能和支持功能。 并形成業(yè)務(wù)概覽圖。

　　4.分開很長時間，再分開很長時間。 根據(jù)當前實際資源情況做出最終決定。 這是整個過程中最耗時的一點。 它決定了體系結(jié)構(gòu)的復雜性和開發(fā)成本。 該方法包括但不限于提取可重用函數(shù)，組合函數(shù)，以更細粒度劃分函數(shù)以提高可重用性等。 所有這些決定必須是“正確的”。 不要盲目跟隨微服務(wù)的風潮！ 不要盲目跟隨微服務(wù)的風潮！ 不要盲目跟隨微服務(wù)的風潮！ 重要的事情說了3遍。 服務(wù)粒度越細，呼叫鏈接越復雜，以及它帶來的開發(fā)成本是否適合團隊，這是需要作為架構(gòu)師考慮的一點。

　　5.在每個功能塊之間建立協(xié)作模式，包括但不限于通信模式，通信協(xié)議，依賴關(guān)系等。

　　6.最后，這些應(yīng)該形成最終的架構(gòu)概述圖，這可以幫助從更高的角度考慮架構(gòu)的演變。 如果要重新架構(gòu)現(xiàn)有項目，那么我們需要在上面的思考過程中對現(xiàn)有項目結(jié)構(gòu)進行整理，作為參考信息的一部分。

　　三、一個好架構(gòu)的特點

　　首先，您必須從心態(tài)上具有手工藝的精神，因為軟件體系結(jié)構(gòu)和房屋建造仍然有所不同。 一開始它沒有到位。 一個好的設(shè)計必須被反復修改，從簡單到復雜的循環(huán)驗證，以及連續(xù)的拋光。

　　在的方向上，我認為有以下幾點：

　　1.文檔：無論是整個生命周期還是整個生命周期的一部分，都必須有充分的文檔記錄。 更改的來源包括但不限于BUG和要求。

　　2.高可用性：為了盡可能提高軟件的可用性，我認為每個操作員都不愿意看到他的工作無法正常進行。 黑盒和白盒測試，單元測試，自動化測試，故障注入測試，提高測試覆蓋率等逐步實現(xiàn)。

　　3.安全性：在組織運營過程中生成的數(shù)據(jù)具有商業(yè)價值，確保數(shù)據(jù)的安全性也是當務(wù)之急。 為了避免諸如XX門等丑聞。 加密，https等是常用方法。

　　4.可擴展：軟件的設(shè)計堅持低耦合的概念，在合理的地方注意抽象。 它促進了功能更改，添加和應(yīng)用技術(shù)的迭代，并支持在適當?shù)臅r候?qū)w系結(jié)構(gòu)進行重構(gòu)。

　　5.快速迭代：擁抱變化并抓住戰(zhàn)略機遇。

　　6.高度自治：為了更好地支持第4點和第5點，每個功能都具有高度自治的好處是可以快速迭代，無論是功能迭代還是技術(shù)迭代，其影響 在整個系統(tǒng)上最小化。

　　7.高重用性：為了避免重復工作并降低成本，我們希望重用先前的代碼和先前的設(shè)計。 這是最依賴于架構(gòu)環(huán)境的。

　　8.可驗證：一個好的框架需要考慮各種特殊情況，并且可以進行具體驗證。

　　四、做架構(gòu)中的誤區(qū)

　　做任何事的時候需要不斷的跳出原來的思維角度重新審視，這樣才能避免陷入泥潭。列出幾個我能想到的誤區(qū)：

　　誤區(qū)1——架構(gòu)專門由架構(gòu)師來做，業(yè)務(wù)開發(fā)人員無需關(guān)注：架構(gòu)的再好，最終還是需要代碼來落地，并且組織越大這個落地的難度越大。不單單是系統(tǒng)架構(gòu)，每個解決方案每個項目也由自己的架構(gòu)，如分層、設(shè)計模式等。如果每一塊磚瓦不夠堅固，那么整個系統(tǒng)還是會有崩塌的風險。所謂“千里之堤，潰于蟻穴”。

　　誤區(qū)2——架構(gòu)師確定了架構(gòu)藍圖之后任務(wù)就結(jié)束了：架構(gòu)不是“空中樓閣”，最終還是要落地的，但是架構(gòu)師完全不去深入到第一線怎么知道“地”在哪？怎么才能落的穩(wěn)穩(wěn)當當。

　　誤區(qū)3——不做出完美的架構(gòu)設(shè)計不開工：世上沒有最好架構(gòu)，只有最合適的架構(gòu)。我們需要的不是一下子造出一輛汽車，而是從單輪車 --> 自行車 --> 摩托車，最后再到汽車。想象一下2年后才能造出的產(chǎn)品，當初市場還存在嗎？

　　五、結(jié)語

　　架構(gòu)之路任重而道遠。程序設(shè)計和架構(gòu)設(shè)計是互通的，每個人都可以從設(shè)計好一個程序往設(shè)計好一個系統(tǒng)架構(gòu)前進。

總結(jié)

以上是生活随笔為你收集整理的软件体系结构设计文档_一个java架构师是如何设计出一个好的架构的的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。