利用微設計實現可持續高效的基礎設施

瞭解微設計基礎架構（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服務開發無偏見和創造性基礎架構的流程。

原文：dzone.com/articles/ta…

做者：Kai Grotelueschen

譯者：Emma------

送福利啦~ 近期將以前已翻譯文章，整理成了PDF。 ​ 在公衆號後臺回覆：002便可領取哦~ ​ 後續也會不斷更新PDF的內容，敬請期待！