引言
利用微設計實現可持續高效的基礎設施
瞭解微設計基礎架構（MDI）的概念，它們如何幫助開發，以及它們與DevOps和微服務等技術的關係。
技術決策既困難又嚴肅，可以決定項目的成敗。如何找到合適的技術棧？“微設計基礎架構”（MDI）是一種新方法，它使用“設計思維”中的回憶來開發最佳，易於理解且是公司範圍內公認的基礎架構或技術堆棧。
技術和基礎設施決策具有挑戰性，因爲必須結合不同的要求（公司，應用，未來的安全等），找到合適的解決方案。在某些情況下，項目的複雜性如此之高，以至於應用了類似項目的最佳實踐方法，但這些方法具有不同的背景。這可能導致做出最終不適合應用程序或公司的決策。管理層對成本和速度的期望未得到滿足，部署或移交IT運營成爲絆腳石。如何防止這種情況？
1.原則
解決複雜問題的方法有兩種：解決問題的結構化流程，將大問題分解成更小的部分，每個部分都更容易，更清晰地解決。
1.1 解決方案的結構化發展：設計思維
設計思維是基於這樣的假設：當來自不同學科的人在鼓勵創造力的環境中一起工作時，問題會得到更好的解決。他們共同瞭解人們的需求和動機，以便得出經過多次測試的概念和解決方案。
這個過程的一部分是共鳴，定義，構思，原型設計和測試。例如，設計思維用於開發應用程序或業務單元的數字化。
1.2 分解問題：微塊
IT服務和應用程序的問題在於需求的複雜性，從開發，集成和部署流程開始，到數據備份，IT安全和數據保護結束。如果將IT服務劃分爲單個部分，則特定要求變得更易於管理。
在軟件開發中使用類似的方法與微服務一起使用。所謂的垂直將應用程序劃分爲鬆散耦合的功能塊。這簡化了軟件開發並提高了解決方案的彈性。但是，不考慮企業，IT操作和數據上下文。
Microblock（參考微服務命名）是與其他塊分離的IT服務的一部分，它實現了特殊功能。該塊必須滿足以下要求：
- 明確功能的定義。
- 不依賴於其他塊的技術和基礎設施。
- 標準化界面REST，HTML，SQL，DNS等
- 可以獨立於其他塊進行更改/安裝
1.3 設計思維+微塊=微設計基礎設施
“微設計基礎設施（MDI）將設計思維應用於IT服務的基礎設施設計。任何形式的模塊化應用程序或IT功能都被視爲IT服務。這種IT服務被分解爲微塊。這些構成了技術決策的基礎（在設計思維中稱爲：Persona）。
具體的基礎設施和技術要求源自微塊的背景。由於需求較少但必不可少，因此更容易做出合適的技術決策。重要的是要考慮IT服務的每個功能部分，不僅是應用程序模塊（微服務）等顯而易見的部分，還包括訪問或PKI管理，DNS，服務發現，監視，日誌記錄和數據備份。
MDI流程使用基於設計思維的流程步驟：理解，定義，構思，原型設計和測試。在自由展開的意義上，步驟不必按此順序完全處理，創建一個涵蓋儘可能多的解決方案的框架更爲重要。
2.過程
2.1.建立：選擇團隊和環境
MDI團隊的組成基於不同的IT學科。目的是能夠理解和評估服務和單個微塊的所有上下文和要求。這包括IT管理，架構，開發和運營，信息安全和數據保護。該團隊應由多種的人才組成，他們在各自的學科和廣泛的跨學科方面具有出色的專業知識。
2.2.理解問題
此階段的目的是瞭解流程和數據流，並將IT服務分爲微塊。此階段應與軟件架構團隊並行執行。 MDI團隊成員共享，討論和記錄他們看到微塊的上下文。
2.3.定義：分析要求
接口（類型，協議），數據（輸入，靈敏度，數量，輸出），處理（並行化，編程語言），監視（監視，KPI，日誌數據）是定義需求的微塊的一部分。此外，還有開發和運營流程（部署和集成）。最後，添加了公司特定的要求（數據保護，信息安全，成本規範）。
2.4.構思：開發可能的解決方案
對於每個單獨的微塊，開發了幾種技術解決方案的想法，唯一的要求是必須滿足規範。通過不斷詢問，檢查技術的選擇是否客觀和明智。例如，5-Why方法是一種很好的方法。
2.5.原型設計：創建原型
在開發原型時，應從一開始就使用自動化，因爲它簡化了微塊原型的可重用性和配置。對於每個原型，必須實施運行狀況檢查和自動安全檢查。
2.6.測試：服務的功能檢查
在最後一步中，服務由微塊組裝而成。功能測試和性能測試顯示每個單獨的微塊是否正確結合。如果此處發生錯誤，則必須對其進行詳細分析以找出原點（例如，忽略的要求，不合適的技術，原型結構中的錯誤等）。它會跳回到相應的流程步驟並進行更正。如果一切都符合要求，那麼沒有什麼能阻礙上線。
3.摘要
“微設計基礎架構”的目標是通過一組創意專家爲IT服務開發最佳基礎架構。由於模塊化結構，專注於單個塊的分離和高度自動化，所需軟件環境的數量可以減少到最小，並且可以降低服務成本。
如果在公司中始終如一地應用此方法，則會創建基於相同技術的微塊集羣，因爲上下文只會稍微改變（通常只是應用程序上下文），因此決策很可能會導致相同的技術。這也是高效的核心技術的基礎設施。
4.差異
4.1.軟件架構
軟件架構是指軟件系統的基本結構和創建這種結構和系統的學科。
每個結構包括軟件元素，它們之間的關係，以及元素和關係的屬性。軟件系統的體系結構是一種隱喻，類似於建築物的體系結構。它作爲系統和開發項目的藍圖，規劃了由設計團隊執行的必要任務。
Wikipedia
軟件架構設計了軟件組件的大致輪廓，不考慮技術方面。 MDI將這方面添加到軟件架構中。這意味着Micro Design Infrastructures不是一種替代方案，而是一種應該並行運行的補充流程。
4.2.微服務
微服務是一種軟件開發技術，它將應用程序構建爲鬆散耦合服務的集合。在微服務架構中，服務是細粒度的，協議是輕量級的。將應用程序分解爲不同的較小服務的好處是它可以提高模塊性。這使得應用程序更易於理解，開發，測試，並且對架構入侵更具彈性。
Wikipedia
微服務主要涉及應用程序開發。在垂直和水平可伸縮性方面，基於應用程序上下文分解應用程序。微設計基礎架構（MDI）考慮了一個更全面的上下文，用於定義和分區應用程序，並定義了一個可理解和企業範圍內可接受決策的過程。
4.3.獨立系統架構（ISA）
ISA是基於經驗的最佳實踐的集合，特別是微服務和自包含系統以及這些項目所面臨的挑戰。
ISA Principles
ISA中定義的原則與MDI中的MicroBlocks概念非常相似。此外，Micro Designed Infrastructures定義了一個在上下文中根據這些原則開發IT服務基礎架構的過程。
4.4.DevOps
DevOps是兩個主要相關趨勢碰撞中出現的新術語。第一個也被稱爲“敏捷基礎設施”或“敏捷運營”;它源於將敏捷和精益方法應用於運營工作。第二是對發展和運營人員之間合作價值的更廣泛理解[...]。
The agile admin
DevOps描述了一種更好合作的文化。這種文化是IT領域任何建設性合作的基礎，包括微設計基礎設施。然而，MDI提供了有關如何通過此協作解決特定問題的具體流程和原則。
4.5.領域驅動設計（DDD）
DDD是一種通過將實現連接到不斷髮展的模型來滿足複雜需求的軟件開發方法。域驅動設計的前提如下：
- 將項目的主要重點放在覈心域和域邏輯上;
- 在域的模型上進行復雜的設計;
- 啓動技術專家和領域專家之間的創造性協作，以迭代方式完善解決特定領域問題的概念模型。
- Wikipedia
DDD在解決問題方面也有類似的方法，特別是通過關注功能和背景。主要地，DDD中的元素是基於域的，與MDI使用的基於功能的微塊相反。這意味着Micro Design Infrastructure不是替代方案，而是DDD的補充流程。
4.6.自包含系統（SCS）
SCS方法是一種架構，專注於將功能分離到許多獨立系統中，使完整的邏輯系統成爲許多小型軟件系統的協作。這避免了大型單塊體不斷增長並最終變得不可維護的問題。在過去幾年中，我們已經看到它在許多中型和大型項目中的優勢。
scs-architecture.org
SCS將各個模塊視爲包含數據邏輯和應用程序邏輯的自治Web應用程序。每個Web應用程序都有自己的用戶界面，由不同的團隊處理。 Micro Designed Infrastructures純粹從功能角度來看待技術決策。沒有理由組合幾個功能。此外，MDI定義了一個爲IT服務開發無偏見和創造性基礎架構的流程。
總結
歡迎關注CSDN:JAVA編程大飛哥
覺得收穫的話可以點個關注評論轉發一波喔，謝謝大佬們支持！
微服務、分佈式、高併發、高可用，性能優化丶源碼分析等等一些技術乾貨等着你來探討學習！