java int不将0忽略_Java微服务：蛋糕是骗人的，但您不能忽略它
java int不將0忽略
構建微服務實際上意味著什么？ 通過微服務框架的眼光回答
忽略微服務的趨勢已變得不可能。 有些人會說這只是另一個難以忍受的流行語，而另一些人會背誦打破巨石的優勢或采取逆勢方法并關注負面因素。
在本文中，我們將全面了解我們擁有的框架，重點是Java生態系統，以實際實現微服務并了解它們的全部含義。 讓我們潛入。
蛋糕是一個謊言
我想到的第一個問題是，我們真的需要一個專門的框架來構建微服務嗎？ 答案是不。 您可以使用微服務框架構建整體嗎？ 是。 因此，如果真正由您決定并且要使用它，那么微服務框架相對于Java EE或Spring有什么好處？ 什么使它值得采用？ 它們是否同時解決內部架構和外部運維架構？
在接下來的幾節中，我們將仔細研究Java EE及其新的微型配置計劃，Spring和Spring Boot，帶有Lagom的Lightbend堆棧以及其他開源解決方案，例如Spotify的Apollo。
在繼續前進之前，值得一提的是，關于微服務架構的定義還不是很明確。 ThoughtWorks的首席科學家Martin Fowler在他有關微服務的第一篇文章中試圖對其進行定義：
“微服務架構風格是一種將單個應用程序開發為一組小型服務的方法，每個小型服務都在自己的進程中運行并與輕量級機制（通常是HTTP資源API）進行通信。 這些服務圍繞業務功能構建，并且可以通過全自動部署機制獨立部署。”
這篇文章與微服務的優缺點無關，它假定您只是對支持它的底層技術感興趣。 另一篇值得探討這些問題的文章涵蓋了調試微服務的主要挑戰 -這是許多人在考慮微服務體系結構時并未想到的常見陷阱。
讓我們開始并逐一檢查以下技術/平臺/框架。
1. Java企業版
用于構建應用程序的經典Java EE方法是針對整體的，隨著時間的流逝，這些整體往往會變成……意大利面條式代碼怪物。 傳統上，企業應用程序將被打包到單個EAR（企業歸檔）部署單元中，該單元包含WAR（網絡歸檔）文件和JAR（Java歸檔）。
但是，“ Vanilla” Java EE也可以用于微服務架構。 有關將Java EE整體重構為微服務體系結構的步驟的深入研究示例， 請查看 Arun Gupta的這篇文章 ，他在其中通過購物車的示例應用程序介紹了此過程中所需的步驟。
即使Java EE 8的開發有所放緩，但背后的“非官方”社區仍然活躍而且活躍。 Java EE Microprofile背后的人們提出了一項針對微服務架構優化企業Java的新計劃。 您可以在此處加入討論 。
考慮Java EE微服務時要考慮的另一個有趣項目是Kumuluz 。 該框架可以利用您現有的Java EE知識，并為您提供一種輕松選擇應用程序所需組件的方法，而不會浪費太多時間在配置上。
底線： Java EE及其周圍的項目非常適合微服務，但不涉及操作方面，而是將其用法和最佳實踐留給您個人解釋。
2. Lightbend：Play，Akka，ConductR和Lagom
Lightbend（以前稱為Typesafe）為我們提供了更多選擇。 與Kumuluz相對于普通Java EE的優勢類似，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站點的首頁上沒有提及微服務，但這并不意味著它們不在循環之中。 幾乎似乎他們似乎是故意不稱其為微服務，以遠離流行語。
Spring Stack與Spring Cloud一起，利用Netflix Eureka和Ribbon來支持分布式系統的開發（該術語通常與“微服務”重疊）。 這些功能包括配置管理，服務發現，智能路由，控制總線，領導者選舉，分布式會話等。
要深入了解如何使用Spring以及其他一些Netflix和其他開源項目構建微服務， 請查看InfoQ的這篇文章 。
底線： Spring在微服務開發方面處于有利位置，并且圍繞著解決了運營角度的外部開源項目提供了產品。
4. Dropwizard
與Spring類似， Dropwizard也沒有太多談論微服務。 這是一個用于開發對ops友好的高性能RESTful Web服務的Java框架。 經過認真研究的Java庫集合，使構建易于生產的Java應用程序更加容易。
Dropwizard模塊允許連接Dropwizards核心所沒有的其他項目，并且社區還開發了一些模塊來連接類似Netflix Eureka的項目，類似于Spring Cloud。
之前，我們還對Dropwizard和Spring Boot進行了正面對比，并比較了它們的功能。
底線：由于Dropwizard是一個社區項目，沒有像Spring和Pivotal，Java EE和Oracle，Lagom和Lightbend這樣的大型公司的支持，因此它的開發速度可能會較慢，但是背后有一個強大的社區，因此可以大公司和較小項目的框架。
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）在其微服務先決條件博文中所說：“重要的是要確保您的監控指示問題時能夠Swift做出React。 特別是，任何事件管理都需要開發團隊和運營部門參與，以解決緊迫的問題和根本原因分析，以確保基本問題得到解決。” 同樣，如果您還沒有準備好使用微服務體系結構，那么此帖子和Hackernews上的帖子會共享更多的問題。
在OverOps ，我們正在構建一個工具來解決這一難題 ，并顯示何時，何地以及為什么在生產中導致代碼中斷。 它是唯一為您顯示整個調用堆棧中每個異常，已記錄警告和錯誤的完整源代碼和變量狀態的工具。 檢查一下 。
OverOps錯誤分析屏幕
最重要的是：微服務要付費，而且并非每個系統都適合。 如果您選擇微服務架構，則應該深入了解成本并確定應改進的流程。
最后的想法
不管使用哪種框架或平臺，構建微服務都與它們緊密結合。 這是一種思維定勢和一種體系結構的方法，您可能應該選擇自己覺得會更有效率的任何一種選擇。
話雖如此，成功實現微服務架構并不僅限于應用程序本身。 圍繞它的大部分成本來自所謂的DevOps流程，監視，CI / CD，日志更改，服務器配置等。 將來，我們將在博客上介紹這些方面，并很高興聽到您對此的想法，并在我們的下一篇文章中進行介紹。 隨時通過hello@overops.com和@overopshq進行聯系 。
翻譯自: https://www.javacodegeeks.com/2016/11/java-microservices-cake-lie-cant-ignore.html
java int不將0忽略
總結
以上是生活随笔為你收集整理的java int不将0忽略_Java微服务：蛋糕是骗人的，但您不能忽略它的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 苏州备案查询（苏州备案编号）
- 下一篇： java crud_Java 8流中的数