感覺像是對微服務的炒作正在慢慢地落到實處，并且我們的行業開始意識到，僅通過在現有組件之上公開一些HTTP接口就無法輕松創建根據微服務背后的體系結構范式的系統。 我們似乎確實同意必須進行服務優化的基礎架構，文化和組織變革，最后但并非最不重要的是這些架構的外部架構或業務流程。 許多Java開發人員似乎仍在苦苦掙扎的部分是具體的系統體系結構，以及事實上，微服務就是分布式系統。 不幸的是，正是這些知識領域決定了項目失敗的成功。 對于一些背景知識，我建議您閱讀

丹尼爾·布萊恩特（Daniel Bryant） 對Uwe和Adrian進行的InfoQ精彩采訪 。

為什么要再次使用微服務？ 我不能只是高興地編寫EJB和Servlet嗎？

微服務的關鍵思想是支持其余應用程序環境的獨立性和快速可擴展性的屬性。 此外，與基于應用程序服務器的應用程序相比，它們應獨立擴展并需要更少的資源。 在不斷變化的業務需求和不斷增長的應用程序客戶端數量的世界中，集中式基礎架構的運營成本日益高昂，并朝著無法預測的負載或負載高峰擴展。 如果所有人都被應用服務器所困擾，那么就不會有Netflix，Twitter或Amazon。 所以：不。您不能只呆在原地。

微服務是分布式系統。 他們有什么特別之處？

分布式系統的原始定義是：“分布式系統是一種模型，其中位于聯網計算機上的組件通過傳遞消息來通信和協調其動作。” （ Wikipedia ）這正是基于微服務的架構中發生的事情。 各個服務被部署到物理上在某個地方運行的云實例，并且它們交換消息。 這與我們用來構建集中式應用程序的方式有很大的不同。 現在，我們不再擁有代表我們處理各種同步，事務和故障轉移場景的服務器，而是擁有獨立發展且彼此不捆綁的獨立服務。 分布式計算存在一些獨特的基本挑戰。 其中包括容錯，同步，自我修復，背壓，網絡分裂等。

分布式系統不是每個人都稱為反應式系統嗎？

比這更復雜。 老實說，這些天“反應性”這個詞本身有很多事情。 要使用單個微服務構建應用程序或系統，您需要使用一組設計原則，使它們具有響應性，彈性，彈性和消息驅動性。 如果聽起來很熟悉，那么您可能是對的。 來自的定義
反應式宣言 。 實現反應式宣言的四個特征的分布式系統應該被稱為
反應系統 。 您可以在Jonas的書中閱讀有關反應式微服務系統設計原理的更多信息。 Lagom框架是基于這些原則構建的，但是讓我清楚一點，您不一定需要特定的框架或產品來構建此類應用程序。 其中一些只是使您的地獄生產率更高，并且您的運營會更有效。 休·麥基（Hugh McKee）有一本關于基于Actor的系統的設計原理的免費書籍 。

構建基于微服務的系統有哪些選擇？

我個人看到解決今天與微服務有關的問題的兩種不同趨勢。 首先是將問題歸結為業務流程或數據中心操作或云系統，如DC / OS，OpenShift，Cloudfoundry等。 第二種解決方案是在應用程序或框架級別上本機處理它們（Akka，Vert.x等）。

每次服務一個容器，或者為什么水蟒 不應該 吞下馬匹。

讓我們更詳細地介紹第一種方法。 編寫微服務，將其與運行時一起打包在一個小容器中，然后將其推送到云中。 如今，DevOps開發人員已經全堆了，因此創建基于云的運行時所需的元信息很容易。 多虧了我的引導性服務，所有相關的監視信息已經公開，并且我可以輕松地檢測到失敗的服務并重新啟動它們。 這肯定可以工作。 您甚至可以將功能齊全的應用程序服務器用作微服務運行時。 此外，還有許多魔術框架（NetflixOSS）可幫助應對分布式系統的挑戰。 對我個人而言，缺點是在這種情況下與基礎架構緊密耦合。 您所選擇的平臺之外的系統將無法在其他任何平臺上運行。 此外，他們建議您只需要使用容器來解決微服務領域中的所有問題。 回顧響應式宣言，這些類型的系統將無法幫助您滿足在服務之間使用消息傳遞的要求。

沒有容器的微服務？ 那就是沒有黃油的花生！

真正。 容器可以很好地完成一件事。 將整個堆棧以可控制的方式打包到可部署的單元中。 它們是基礎架構級別的隔離機制。 擁有容器標準實際上可能是一件好事。 因此，請保留您的容器。 但是，您還需要更多。
因此，構建具有復原力的自我修復系統的關鍵是允許對故障進行以下處理：將故障包含在內，將其分類為消息，發送給其他組件（充當主管）并從發生故障的組件外部的安全上下文中進行管理。 在這里，以消息為驅動力是推動力：擺脫每個人都受到痛苦或忽略的強耦合，易碎，深度嵌套的同步呼叫鏈。 這個想法是將故障管理與呼叫鏈分離，使客戶端從處理服務器故障的責任中解放出來。 沒有容器或業務流程編制工具可以幫助您將其集成。 您正在尋找事件源。 的
使用事件源的事件驅動架構的設計概念與微服務架構模式非常一致。

響應式編程，系統和流：不是全部一樣嗎？

反應性已經成為一個超負荷的術語，并且現在正與與不同人相關的幾項不同的事物相關聯—在好的公司中，諸如“流”，“輕量”和“實時”之類的詞。 “響應式編程通過性能和資源效率，在組件級別上為內部邏輯和數據流管理提高了開發人員的生產率。 Reactive Systems在系統級別上通過彈性和彈性為架構師和DevOps提供生產力，用于構建Cloud Native或其他大規模分布式系統。 您應該真正花時間閱讀一下JonasBonér和Viktor Klang如何解釋他們之間的個體差異 。

在哪里可以了解有關如何設計反應式微服務的更多信息？

詹姆斯·羅珀（James Roper）在去年的反應性峰會上做了精彩的演講，并親手研究了系統的體系結構（包括數據流，所用的通信類型以及將系統分解為組件的方式）如何需要在將整體分解為基于反應式微服務的系統時進行更改。

我在CJUG上進行了有關Java開發人員的CQRS的演講 ，向您進行了介紹。 如果您有感興趣的特定主題，請在評論中讓我知道。

為您提供更多閱讀

• JonasBonér和Viktor Klang 在20分鐘內介紹了反應式編程與反應式系統
• Konrad最近進行了一次網絡研討會，內容涉及Java 8中的Akka Streams，Alpakka和Kafka中的Reactive Integrations。
• 傳統Java企業的反應式系統設計基礎
• Duncan DeVore 在不到12分鐘的時間內進行了反應式架構，設計和編程

翻譯自: https://www.javacodegeeks.com/2017/02/microservices-distributed-systems-survival-guide-java-developers.html

總結

以上是生活随笔為你收集整理的从微服务到分布式系统-Java开发人员生存指南的全部內容，希望文章能夠幫你解決所遇到的問題。

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