[[273780]]

【51CTO.com快譯】新興技術的下一波浪潮正向我們涌來，人工智能、可穿戴設備、物聯網及更多技術變得普及開來。許多組織現面臨著管理這些整體式應用程序這個難題。當下，速度和靈活性必不可少。Netflix、Twitter、eBay和亞馬遜等大型互聯網公司采用的下一個架構創新是微服務。據互聯網服務器供應商NGINX聲稱，68%的組織在使用或調查這種方法。

微服務架構正在IT行業備受追捧，因為它相比許多傳統架構方法有諸多優勢。比如在醫療保健領域，這種架構對新的解決方案來說大有希望，比如遠程患者監控、使用物聯網設備數據的預測建模、醫療工作流程自動化和面向精準醫療的生物信息學分析等。隨著組織采用現代微服務架構，這六個因素可以幫助它們取得成功，同時補充現有的云和DevOps基礎設施。

微服務架構如何補充云和DevOps?

微服務是一種軟件開發和架構方法，它將應用程序構建為一組松散耦合、自治且可獨立部署的服務。這些小型的業務驅動服務有明確定義的通信接口，這使得應用程序模塊化、更易于構建和測試，并可以高效地獨立部署。

微服務方法與云和DevOps相輔相成。多年來，云計算已趨于成熟，可以提供高效的基礎設施解決方案，用于快速構建原型、支持龐大的數據處理和生產需求，并帶來比內部IT部門更高的服務水平。與此同時，DevOps有助于更快地交付優質軟件，同時彌補開發團隊和運營團隊之間的差距。

結合微服務架構與成熟的DevOps實踐有助于分散的團隊更快地創新、控制自己的技術堆棧和標準、管理性能指標、管理開發和發布周期，最終縮短產品上市時間。與此同時，微服務可以通過將整體式應用程序分解成微服務并部署到云平臺上，從而便于逐步遷移到云。通過這種方法，團隊更容易模擬生產工作負載，確保軟件的可用性、可擴展性和質量，同時提高發布頻次。

微服務架構設計方面的六個考量因素

下列六個考量因素有助于使組織確保成功，同時補充現有的云和DevOps基礎設施：

• 服務發現：在復雜的分布式系統中，團隊根據負載大小擴展服務實例，這意味著服務實例的數量及其位置可能動態變化。擁有適當的服務發現機制可確保客戶可以基于服務注冊中心與合適的服務進行通信。
• 服務間通信：在微服務架構中，服務以同步或異步方式進行通信以完成事務。服務間通信機制協調這種通信。如果設計不力，服務間的過多通信會導致“繁瑣”的應用程序和糟糕的性能。想進行優化，請使用這些經過驗證的設計模式：

▲Saga模式：由某個事件或消息觸發的一連串事務。

▲API網關：借助API網關，通過單個API調用來抽象處理針對多個API的調用。

▲命令查詢職責分離(CQRS)：使用物化視圖將讀寫分開來，并通過訂閱事件來更新視圖。

▲事件溯源：存儲事件而不是狀態;通過重放事件來獲得狀態。

▲服務網格：將服務間的網絡通信卸載到某個軟件組件，以確保彈性和服務發現等。

• 數據完整性：由于每個微服務都有自己的數據庫，因此確保數據在涉及多個服務的事務之間具有一致性可能是個挑戰。上述模式(如事件溯源、CQRS和Saga)有助于實現數據一致性。
• 安全性：加密機制以及強大的身份驗證和授權工具可以確保靜態數據和傳輸中數據的安全性。一些組織采用身份即服務和授權即服務解決方案。此外需要在API網關后面保護API，確保未經授權的用戶無法使用令牌獲得訪問權限。
• 監控和運行狀況檢查：隨著微服務架構中服務數量越來越多，確定和排查問題變得具有挑戰性。比如說，單單一個事務可能跨多個服務調用，因此很難確定性能瓶頸的確切原因。使用分布式事務跟蹤和運行狀況檢查API監控系統可確保應用程序在高效運行。借助合適的監控和檢測，團隊可以為關鍵指標創建可視化元素，收集歷史數據以了解性能趨勢，并在問題出現時收到警報。
• 質量保證：微服務通過在服務之間傳遞消息來處理請求。隨著服務數量增加，自動化測試對于確保所有交互和通信都經過全面測試非常重要，包括單元測試、集成測試、組件測試和合約測試。此外，每個級別的全面測試確認服務可以獨立于其他服務運行或與其他服務一起運行，以支持分布式事務。最后，測試表明整體架構足夠靈活，可根據需要支持另外的數據源、框架或庫。

更快的創新是目標

微服務架構是當今一個重要的IT趨勢，這有充分的理由。與傳統的架構方法相比，它有許多優勢，并且大有希望。雖然要克服諸多挑戰，但如果企業組織擁有精心設計的方法、全面組織的分布式團隊以及可靠的DevOps流程，可以借助現代微服務架構更快地進行創新，只需構建新產品，并更新改造現有應用程序。

原文標題：Six Considerations for Adopting a Microservices Architecture，作者：Vinil Menon和Khushboo Shah

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】