微服務架構——面向服務架構結構風格的一種變體——是一種架構模式，它將應用程序安排為松耦合、細粒度服務的集合，通過輕量級協議進行通信。 它的目標之一是團隊可以獨立于其他人開發和部署他們的服務。 這是通過減少代碼庫中的幾個依賴項來實現的，允許開發人員在用戶有限的限制下發展他們的服務，并向用戶隱藏額外的復雜性。 因此，組織能夠開發具有快速增長和規模的軟件，以及更容易地使用現成的服務。 通信要求降低。 這些好處是以維持解耦為代價的。 需要仔細設計接口并將其視為公共 API。 使用的一種技術是在同一個服務上有多個接口，或者同一個服務有多個版本，以免干擾代碼的現有用戶。

微服務沒有單一的定義。 隨著時間的推移，業界形成了一種共識。 一些經常被引用的定義特征包括：

• 微服務架構中的服務通常是通過網絡進行通信以使用與技術無關的協議（例如 HTTP）實現目標的進程。
• 服務是圍繞業務能力組織的。
• 可以使用不同的編程語言、數據庫、硬件和軟件環境來實施服務，具體取決于最適合的情況。
• 服務規模小、支持消息傳遞、受上下文限制、自主開發、可獨立部署、去中心化以及通過自動化流程構建和發布。

微服務不是單體應用程序（例如，Web 控制器或前端后端）中的一個層。 相反，它是一個獨立的業務功能塊，具有清晰的接口，并且可以通過其自己的內部組件實現分層架構。 從戰略的角度來看，微服務架構本質上遵循的是 Unix 哲學，Do one thing and do it well。 Martin Fowler 將基于微服務的架構描述為具有以下屬性：

• 適合持續交付軟件開發流程。 對應用程序一小部分的更改只需要重建和重新部署一個或少量服務。
• 遵守細粒度接口（獨立可部署服務）、業務驅動開發（例如領域驅動設計）等原則。

云原生應用程序、無服務器計算和使用輕量級容器部署的應用程序通常采用微服務架構。 根據 Fowler 的說法，由于服務數量眾多（與整體應用程序實施相比），分散式持續交付和具有整體服務監控的 DevOps 是有效開發、維護和運營此類應用程序所必需的。 遵循這種方法的結果（和理由）是可以單獨擴展各個微服務。 在單體方法中，支持三個功能的應用程序必須整體擴展，即使這些功能中只有一個具有資源限制。 使用微服務，只需要擴展支持資源受限功能的微服務，從而提供資源和成本優化收益。

關于微服務一詞的起源有許多說法。2004 年擔任 ThoughtWorks 副總裁期間，Fred George 開始研究基于他所謂的以 Jeff Bay 命名的 Baysean 原則的原型架構。

早在 2005 年，Peter Rodgers 在 Web Services Edge 會議的演講中就引入了術語微 Web 服務。 與傳統思維相反，在 SOAP SOA 架構炒作曲線的頂峰，他主張 REST 服務，并在會議演示文稿的幻燈片 #4 上討論了軟件組件是微 Web 服務。

他接著說，微服務是使用類 Unix 管道組成的（Web 遇到 Unix = 真正的松散耦合）。 服務可以調用服務（+多語言運行時）。 復雜的服務程序集被抽象為簡單的 URI 接口。 可以公開任何粒度的任何服務。 他描述了一個設計良好的微服務平臺如何應用 Web 和 REST 服務的基礎架構原則以及類 Unix 調度和管道，以在面向服務的架構中提供根本的靈活性和改進的簡單性。

Rodgers 的工作起源于 1999 年惠普實驗室的 Dexter 研究項目，其目的是使代碼不那么脆弱，并使大規模、復雜的。