一、架構的定義

　　所謂一千個架構師中有一千種“最好的架構”模式。

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

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

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

　　二、如何開始設計一個架構

　　進行體系結構最重要的一點是上述業務適配。 任何不基于業務去做異想天開的體系結構的流氓?

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

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

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

　　2.將解決方案劃分為每個部分(例如SOA的特定服務)。 例如，根據公司的組織結構或產品。

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

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

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

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

　　三、一個好架構的特點

　　首先，您必須從心態上具有手工藝的精神，因為軟件體系結構和房屋建造仍然有所不同。 一開始它沒有到位。 一個好的設計必須被反復修改，從簡單到復雜的循環驗證，以及連續的拋光。

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

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

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

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

　　4.可擴展：軟件的設計堅持低耦合的概念，在合理的地方注意抽象。 它促進了功能更改，添加和應用技術的迭代，并支持在適當的時候對體系結構進行重構。

　　5.快速迭代：擁抱變化并抓住戰略機遇。

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

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

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

　　四、做架構中的誤區

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

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

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

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

　　五、結語

　　架構之路任重而道遠。程序設計和架構設計是互通的，每個人都可以從設計好一個程序往設計好一個系統架構前進。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。