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忽略