宏觀問題的微觀解決方法？

微服務的炒作無處不在，盡管業界似乎無法就確切的定義達成共識，但我們一再被告知，從單一應用程序轉向由小型服務組成的面向服務的架構（SOA）是正確的方法。構建和發展軟件系統。 但是，當前沒有傳統的“企業”組織談論采用微服務。 這篇博客文章是較大文章的預覽，該文章探討了企業中微服務的使用。

界面–良好的合同造就了好鄰居

無論您是開始新建的微服務項目，還是要負責將現有的整體解構為服務的任務，首要任務都是定義新組件的邊界和相應的應用程序編程接口（API）。

與使用傳統的面向企業服務的體系結構（SOA）方法通常實現的服務相比，微服務體系結構中服務的建議粒度要更好，但是可以說SOA的初衷是創建可重用業務功能的內聚單元，甚至如果實施歷史講述了一個不同的故事。

新建微服務項目通常具有更大的靈活性，并且初始設計階段可以使用服務提供者和消費者之間的明確責任和合同（例如，使用消費者驅動的合同 ）來定義域驅動設計（DDD ）啟發的有限上下文。

但是，典型的棕地項目必須尋求在現有應用程序中創建“ 接縫 ”，并實現與接縫接口集成的新（或提取）服務。 目標是使每個服務具有高凝聚力和松散耦合； 服務接口的設計是這些原則的種子。

通信–同步與異步

實際上，我們發現許多企業將需要在其服務中同時提供同步和異步通信。 值得注意的是，盡管這些框架所解決的許多挑戰仍然存在，但行業內仍有相當大的動力要擺脫人們認為的“重量級” WS- *通信標準（例如WSDL，SOAP，UDDI）。服務發現，服務描述和合同協商（如greg Young在muCon微服務會議上的最新演講中非常簡潔地闡述 ）。

中間件–傳統企業如何應對？

盡管許多重量級的Enterprise Service Bus ESB可以執行一些非常巧妙的路由，但它們經常被部署為黑匣子。 吉姆·韋伯（Jim Webber）曾開玩笑說ESB應該代表“ Egregious Spaghetti Box”，因為在專有ESB中執行的操作并不透明，而且通常很復雜。

如果要求指示使用ESB（例如，消息拆分或基于策略的路由），則應考慮使用開源輕量級ESB實現（例如Mule ESB或Fuse ESB） 。

我通常會發現輕量級的MQ平臺（例如RabbitMQ或ActiveMQ ）更合適，因為我們認為SOA通信的當前趨勢是朝著“ 啞管道和智能端點 ”邁進，除了消除潛在的供應商費用和鎖定外，其他好處使用輕量級的MQ技術可以簡化部署，管理和簡化測試。

部署微服務–有多難？

無論您選擇構建微服務，使用連續集成樣式的構建管道都是至關重要的，該管道包括針對功能需求，容錯，安全性和性能的嚴格自動化測試。 可以說，手動QA和分階段評估的經典SOA方法在“ 速度取勝 ”且快速創新和試驗的能力是競爭優勢的經濟中不再適用（如精益創業運動所體現的那樣）。

您的應用程序的行為可能會在基于微服務的平臺中浮現出來，盡管沒有什么可以替代對生產堆棧中的全面而普遍的監視，但是在您的組件暴露給客戶之前進行鍛煉（或折磨 ）的構建管道似乎是高度有益。 正如我在幾場會議的演講中所討論的那樣 ，一個好的構建管道應盡可能早地在目標部署環境中使用服務。

摘要– API，輕量級的comms和正確的部署

無論您是否訂閱了微服務炒作，這種架構風格似乎都在幾乎所有軟件開發領域中得到了關注。 本文試圖為理解這個不斷發展的空間中的關鍵概念提供入門知識，并希望提醒讀者，經典企業SOA之前已經見過許多這些問題和解決方案。 我們明智的做法是不要重新發明眾所周知的“面向服務”的輪子。

請單擊此處，以獲取完整的原始文章 ，該文章提供了有關JVM平臺上微服務實現選項的更多信息，并討論了持續交付的要求。 本文的一個版本最初發布在DZone 2014 Enterprise Integration Guide中 。

參考文獻

參考文獻的完整列表和推薦閱讀的內容也可以在原始文章和最近討論微服務業務含義的文章中找到。

翻譯自: https://www.javacodegeeks.com/2015/01/microservices-in-the-enterprise-friend-or-foe.html

總結

以上是生活随笔為你收集整理的企业中的微服务：敌是友？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。