當前位置：首頁 > 编程语言 > java >内容正文

java

java int不将0忽略_Java微服务：蛋糕是骗人的，但您不能忽略它

發(fā)布時間：2023/12/3 java 28 豆豆

生活随笔收集整理的這篇文章主要介紹了 java int不将0忽略_Java微服务：蛋糕是骗人的，但您不能忽略它小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

java int不將0忽略

構建微服務實際上意味著什么？ 通過微服務框架的眼光回答

忽略微服務的趨勢已變得不可能。有些人會說這只是另一個難以忍受的流行語，而另一些人會背誦打破巨石的優(yōu)勢或采取逆勢方法并關注負面因素。

在本文中，我們將全面了解我們擁有的框架，重點是Java生態(tài)系統，以實際實現微服務并了解它們的全部含義。讓我們潛入。

蛋糕是一個謊言

我想到的第一個問題是，我們真的需要一個專門的框架來構建微服務嗎？答案是不。您可以使用微服務框架構建整體嗎？是。因此，如果真正由您決定并且要使用它，那么微服務框架相對于Java EE或Spring有什么好處？什么使它值得采用？它們是否同時解決內部架構和外部運維架構？

在接下來的幾節(jié)中，我們將仔細研究Java EE及其新的微型配置計劃，Spring和Spring Boot，帶有Lagom的Lightbend堆棧以及其他開源解決方案，例如Spotify的Apollo。

在繼續(xù)前進之前，值得一提的是，關于微服務架構的定義還不是很明確。 ThoughtWorks的首席科學家Martin Fowler在他有關微服務的第一篇文章中試圖對其進行定義：

“微服務架構風格是一種將單個應用程序開發(fā)為一組小型服務的方法，每個小型服務都在自己的進程中運行并與輕量級機制（通常是HTTP資源API）進行通信。這些服務圍繞業(yè)務功能構建，并且可以通過全自動部署機制獨立部署?！?

這篇文章與微服務的優(yōu)缺點無關，它假定您只是對支持它的底層技術感興趣。另一篇值得探討這些問題的文章涵蓋了調試微服務的主要挑戰(zhàn) -這是許多人在考慮微服務體系結構時并未想到的常見陷阱。

讓我們開始并逐一檢查以下技術/平臺/框架。

1. Java企業(yè)版

用于構建應用程序的經典Java EE方法是針對整體的，隨著時間的流逝，這些整體往往會變成……意大利面條式代碼怪物。傳統上，企業(yè)應用程序將被打包到單個EAR（企業(yè)歸檔）部署單元中，該單元包含WAR（網絡歸檔）文件和JAR（Java歸檔）。

但是，“ Vanilla” Java EE也可以用于微服務架構。有關將Java EE整體重構為微服務體系結構的步驟的深入研究示例，請查看 Arun Gupta的這篇文章，他在其中通過購物車的示例應用程序介紹了此過程中所需的步驟。

即使Java EE 8的開發(fā)有所放緩，但背后的“非官方”社區(qū)仍然活躍而且活躍。 Java EE Microprofile背后的人們提出了一項針對微服務架構優(yōu)化企業(yè)Java的新計劃。您可以在此處加入討論。

考慮Java EE微服務時要考慮的另一個有趣項目是Kumuluz 。該框架可以利用您現有的Java EE知識，并為您提供一種輕松選擇應用程序所需組件的方法，而不會浪費太多時間在配置上。

底線： Java EE及其周圍的項目非常適合微服務，但不涉及操作方面，而是將其用法和最佳實踐留給您個人解釋。

2. Lightbend：Play，Akka，ConductR和Lagom

Lightbend（以前稱為Typesafe）為我們提供了更多選擇。與Kumuluz相對于普通Java EE的優(yōu)勢類似，Lagom將Lightbend堆棧與Play，Akka和ConductR包裹在一起，并提供了構建微服務的簡便方法。它的基礎組件還包括Cassandra，Guice，Jackson，slf4j，Logback和其他Lightbend組件。

Lagom （瑞典語中“恰到好處的數量”）仍處于早期階段，但對于Lightbend堆棧而言，這似乎是一個有希望的方向。 Lightbend的首席技術官Jonas Boner在接受InfoQ采訪時說：“目前，大多數微服務框架都集中在簡化單個微服務的構建上，這很容易。 Lagom將其擴展到微服務系統，大型系統–這是困難的部分，因為在這里我們面臨著分布式系統的復雜性。

底線： Lagom將Lightbend的功能集成到一個框架中，以及ConductR提供的操作功能。不僅關注單個微服務，而且關注整個系統。

3，Spring，Spring Boot和Spring Cloud

盡管Spring和Spring Boot并不稱自己為微服務框架，并且Spring站點的首頁上沒有提及微服務，但這并不意味著它們不在循環(huán)之中。幾乎似乎他們似乎是故意不稱其為微服務，以遠離流行語。

Spring Stack與Spring Cloud一起，利用Netflix Eureka和Ribbon來支持分布式系統的開發(fā)（該術語通常與“微服務”重疊）。這些功能包括配置管理，服務發(fā)現，智能路由，控制總線，領導者選舉，分布式會話等。

要深入了解如何使用Spring以及其他一些Netflix和其他開源項目構建微服務，請查看InfoQ的這篇文章。

底線： Spring在微服務開發(fā)方面處于有利位置，并且圍繞著解決了運營角度的外部開源項目提供了產品。

4. Dropwizard

與Spring類似， Dropwizard也沒有太多談論微服務。這是一個用于開發(fā)對ops友好的高性能RESTful Web服務的Java框架。經過認真研究的Java庫集合，使構建易于生產的Java應用程序更加容易。

Dropwizard模塊允許連接Dropwizards核心所沒有的其他項目，并且社區(qū)還開發(fā)了一些模塊來連接類似Netflix Eureka的項目，類似于Spring Cloud。

之前，我們還對Dropwizard和Spring Boot進行了正面對比，并比較了它們的功能。

底線：由于Dropwizard是一個社區(qū)項目，沒有像Spring和Pivotal，Java EE和Oracle，Lagom和Lightbend這樣的大型公司的支持，因此它的開發(fā)速度可能會較慢，但是背后有一個強大的社區(qū)，因此可以大公司和較小項目的框架。

5. Spotify Apollo，VertX和其他“ Microframeworks”

除了我們在這里提到的4個主要參與者之外，還有很多其他項目值得一提，它們也可以用于編寫微服務：

Vertx ，一個用于在JVM上構建響應式應用程序的工具包。有人可能會認為它應該在四大巨頭中占有一席之地。

Spotify Apollo ，Spotify在編寫Java微服務時使用的一組Java庫。 Apollo包括HTTP服務器和URI路由系統等功能，使實現RESTful服務變得輕而易舉。

其他框架包括Spark，Ninja和Jodd以及Restlet 。

底線： Java微服務的競爭空間很大，值得一試的是較小的參與者。

6.微服務先決條件

正如馬丁·福勒（Martin Fowler）在其微服務先決條件博文中所說：“重要的是要確保您的監(jiān)控指示問題時能夠Swift做出React。特別是，任何事件管理都需要開發(fā)團隊和運營部門參與，以解決緊迫的問題和根本原因分析，以確?；締栴}得到解決?！?同樣，如果您還沒有準備好使用微服務體系結構，那么此帖子和Hackernews上的帖子會共享更多的問題。

在OverOps ，我們正在構建一個工具來解決這一難題，并顯示何時，何地以及為什么在生產中導致代碼中斷。它是唯一為您顯示整個調用堆棧中每個異常，已記錄警告和錯誤的完整源代碼和變量狀態(tài)的工具。檢查一下。

OverOps錯誤分析屏幕

最重要的是：微服務要付費，而且并非每個系統都適合。如果您選擇微服務架構，則應該深入了解成本并確定應改進的流程。

最后的想法

不管使用哪種框架或平臺，構建微服務都與它們緊密結合。這是一種思維定勢和一種體系結構的方法，您可能應該選擇自己覺得會更有效率的任何一種選擇。

話雖如此，成功實現微服務架構并不僅限于應用程序本身。圍繞它的大部分成本來自所謂的DevOps流程，監(jiān)視，CI / CD，日志更改，服務器配置等。將來，我們將在博客上介紹這些方面，并很高興聽到您對此的想法，并在我們的下一篇文章中進行介紹。隨時通過hello@overops.com和@overopshq進行聯系。

翻譯自: https://www.javacodegeeks.com/2016/11/java-microservices-cake-lie-cant-ignore.html