你好，哈布爾。 今天，我繼續出版專門為課程新流的開始而撰寫的一系列出版物。 .
介紹
架構風格的選擇是建構資訊系統時的基本技術決策之一。 在本系列文章中，我建議分析建築應用中最受歡迎的建築風格，並回答何時最優選哪種建築風格的問題。 在演示過程中，我將嘗試繪製一條邏輯鏈來解釋架構風格從單體到微服務的發展。
上次我們討論了不同類型的單體以及使用元件來建置它們，包括建置元件和部署元件。 我們了解服務導向的架構。
現在我們最終將定義微服務架構的主要特徵。
架構關係
需要理解的是，根據前面文章給出的定義，任何服務都是組件，但並不是每個服務都是微服務。
微服務架構的特點
微服務架構的主要特點是：
- 圍繞業務能力組織
- 產品而非項目
- 智慧端點和啞管道
- 去中心化治理
- 分散資料管理
- 基礎設施自動化
- 為失敗而設計
- 進化發展的架構（進化設計）
第一點來自於服務導向的架構，因為微服務是服務的一種特例。 其他要點值得單獨考慮。
圍繞業務能力組織
現在有必要記住康威定律：創造系統的組織組織其架構，複製這些組織內的互動結構。 作為一個例子，我們可以回想一下創建編譯器的情況：一個七人團隊開發了一個七遍編譯器，一個五人團隊開發了一個五遍編譯器。
如果我們談論單體和微服務，那麼如果開發是由職能部門（後端、前端、資料庫管理員）組織的，那麼我們就會得到一個經典的單體。
為了獲得微服務，團隊必須以業務能力（訂單、出貨、目錄團隊）來組織。 該組織將允許團隊專注於建立應用程式的特定部分。
產品而非項目
一個團隊將開發的功能轉移給其他團隊的專案方法在微服務架構的情況下是完全不合適的。 團隊必須在系統的整個生命週期中支援系統。 微服務實施領域的領導者之一亞馬遜表示：“你構建，你運行它。” 產品方法讓團隊能夠感受到業務的需求。
智慧端點和啞管道
SOA架構非常注重通訊通道，特別是企業服務總線。 這往往會導致錯誤的意大利麵條盒，即單體的複雜性變成了服務之間連接的複雜性。 微服務架構僅使用簡單的通訊方式。
去中心化治理
有關微服務的關鍵決策應該由實際開發微服務的人員來做出。 在這裡，關鍵決策意味著選擇
程式語言、部署方法、公共介面契約等。
分散資料管理
應用程式依賴單一資料庫的標準方法無法考慮每個特定服務的具體情況。 MSA 涉及分散式資料管理，包括使用各種技術。
基礎設施自動化
MSA 支援持續部署和交付流程。 這只能透過自動化流程來實現。 同時，部署大量服務看起來不再是一件可怕的事。 部署過程應該會變得無聊。 第二個面向與產品環境中的服務管理有關。 如果沒有自動化，管理在不同操作環境中運作的流程就變得不可能。
為失敗而設計
許多 MSA 服務很容易出現故障。 同時，分散式系統中的錯誤處理並不是一項簡單的任務。 應用程式架構必須能夠適應此類故障。 Rebecca Parsons 認為，我們甚至不再使用服務之間的進程內通信，這一點非常重要；相反，我們採用 HTTP 進行通信，而這幾乎不那麼可靠。
進化發展的架構（進化設計）
MSA系統的架構應該要不斷演進。 建議限制單一服務邊界的必要更改。 也必須考慮對其他服務的影響。 傳統的方法是嘗試透過版本控制來解決這個問題，但 MSA 建議在
作為最後的手段。
結論
完成上述所有內容後，我們可以明確指出什麼是微服務。 微服務架構是一種將單一應用程式開發為小型服務集合的方法，每個服務都在自己的進程中運行，並透過輕量級機制（通常是 HTTP 資源 API）進行互動。 這些服務建立在業務能力之上，完全可以獨立部署
自動化部署機制。 這些服務有最低層級的集中管理，可以用不同的程式語言編寫並使用不同的資料儲存技術。
來源： www.habr.com