Spring Boot微服務是一種安全的SOA

banq發表於2018-11-12
Spring Boot微服務

微服務是面向服務架構（SOA）的變體，使用各種相互依賴的模組來標識它們之間的相互關係，並可衡量每個模組之間的松耦合程度。
基於微服務的架構主要關注：
  • 自然地強制執行模組化結構。
  • 適用於持續交付軟體開發過程。 
  • 對應用程式的一小部分進行更改只需要重建和重新部署一個或少量服務
  • 堅持諸如此類的原則 
  • 細粒度介面（可獨立部署的服務）
  • 業務驅動的開發（例如域驅動設計）
  • 雲應用程式架構
  • 多語言程式設計和永續性
  • 輕量級容器部署
  • 分散的持續交付
  • DevOps提供全面的服務監控

將單個App開發為一套小型服務，每個小型服務都在自己的流程中執行，並與輕量級機制（通常是HTTP資源API）進行通訊。這些服務圍繞業務功能構建，可透過全自動部署機制獨立部署。這些服務至少集中管理，可以用不同的程式語言編寫，並使用不同的資料儲存技術。

微服務的優點包括
  • 新技術和流程適應變得更加容易。您可以使用我們建立的新微服務來嘗試新技術。
  • 更快的釋出週期。
  • 可擴充套件到雲。

應用和團隊的兩個方面的功能分解是構建成功的微服務架構的關鍵。這樣才能實現松耦合（REST介面）和高內聚（多個服務可以相互組合以定義更高階別的服務或應用程式）。功能分解提供了敏捷性，靈活性，可伸縮性和其他功能，但業務目標仍然是建立應用程式。

聚合器微服務設計模式
第一種，也許是最常見的是聚合器微服務設計模式。在最簡單的形式中，聚合器可能就是一個簡單的網頁，它呼叫多個服務來實現應用程式所需的功能。由於使用輕量級REST機制公開了每個服務（服務A，服務B和服務C），因此網頁可以檢索資料並相應地處理/顯示資料。

代理微服務設計模式
代理微服務設計模式是聚合器的變體。在這種情況下，不需要在客戶端上進行聚合，但可以根據業務需要呼叫不同的微服務。

鏈式微服務設計模式
鏈式微服務設計模式對請求產生單個合併響應。在這種情況下，來自客戶端的請求由服務A接收，服務A然後與服務B通訊，服務B又可以與服務C通訊。所有服務可能使用同步HTTP請求/響應訊息傳遞。

共享資料微服務設計模式
微服務的設計原則之一是自治。這意味著該服務是全棧並且可以控制所有元件 - UI，中介軟體，永續性，事務。這允許服務是多語言，並使用正確的工具來完成正確的工作。例如，如果可以使用NoSQL資料儲存，則更合適，在SQL資料庫中會干擾資料獨立性。
在這種設計模式中，一些在鏈條中的微服務可能共享快取和資料庫儲存。這隻有在兩個服務之間存在強耦合時才有意義。有些人可能認為這是一種反模式，但在某些情況下可能需要業務需求來遵循這一點。對於基於微服務設計的綠地應用來說，這肯定是一種反模式。

非同步訊息微服務設計模式
雖然REST設計模式非常普遍，並且很好理解，但它具有同步的限制，因此阻塞。可以實現非同步，但這是以特定於應用程式的方式完成的。由於這一點，一些微服務架構可能會選擇使用訊息佇列而不是REST請求/響應。

Spring Boot :
Spring Boot是一個旨在簡化新服務建立的框架。對於最簡單的用例，所需的庫已經捆綁在所謂的Spring starter配件組合和版本中。我們不必將應用程式部署到應用伺服器中，而是獨立執行我們的應用程式或在Docker容器中執行，因為應用已經包含伺服器。Spring Boot可用於設定基於REST的微服務。

Spring Boot針對大多數用例簡化了構建基於Java的微服務。與Dropwizard等框架不同，它更易於使用，並提供更豐富的功能集。Spring Boot提供了大量額外的庫和整合，如Ribbon，Zuul，Hystrix，與MongoDB，Redis，GemFire，Elasticsearch，Cassandra或Hazelcast等資料庫的整合。

藉助Maven和Gradle，Java開發人員可以支援功能強大且受到廣泛支援的構建系統，這些構建系統比Play Framework等框架的專用構建系統更常見，更易於整合到現有結構中。與傳統的Web應用程式相比，Spring Boot很精簡。對於大多數專案，向專案新增依賴項足以從頭開始獲得良好專案起步，無需調整預設配置。
 

相關文章