为何 Java EE 是更好的选择

发表于 由
近期，似乎每个人都在谈论微服务的好处和新架构。大多数关于微服务新豪华架构的文章都认为，Java EE 运行慢，内容单一，而且规模小 。
看起来人们对Java EE的认识存在很大的误区。
我认为微服务新世界的年轻追随者们还不够了解Java EE的理念。就每个开发者都会遇到的问题，我举出三个例子，相信你对Java EE会有不一样的认识。
数据库连接池
如果你在开发一个应用, 大部分情况下，你将访问数据库对数据进行读写操作。在Java中使用一个JDBC连接来实现对数据库进行操作。
每一种数据库都有一个对应的数据库驱动并且使用起来非常简单。但是打开一个JDBC连接,从数据库中检索数据,最后关闭连接，都是在你的代码中必须要做的工作。
因为创建JDBC连接花费昂贵,所以一个好的解决办法是尽可能地在多个查询或更新中重用这些连接。
这就需要连接池，如果你熟悉这些概念并且知道如何处理一个JDBC连接池,你可能会乐于实现自己的连接管理器。但是如果你不熟悉相关概念,你应该留意,或者你应该看一看Java EE。
一个Java EE应用服务将你的代码与JDBC连接解耦。如果你需要访问一个数据库,你只需要注入一个JNDI数据库资源。数据库资源完全被应用服务以连接池管理。
请注意下面的图片,该图片是Wildfly的管理界面的截图：
你不仅可以管理连接池，还可以对验证,超时设置,内部缓存的预编译语句进行管理。上述功能使得你可以细粒度的管控数据库连接。我不太相信（所谓的）新的实践，即“让我们启动一个tomcat新实例”是一个合适的解决方案。
服务
下 一个例子是用一段简单的代码实现一些业务逻辑。假设这段代码执行一个复杂的计算，用时或多或少。这样问题就产生了，一个较长时间的执行过程会阻碍其它调 用。该怎么办呢？当然我们可以启动更多的 Tomcat 服务器，但对于当前这个例子，这种解决方案是非常昂贵的，还不用说可能有些执行过程还会花更长的时间。
另 一种解决方法是构建和管理一个服务池，每个服务都实现了我们的业务逻辑（这称之为工厂模式）。我们可在多个调用间共享这些服务，而不需要重新实例化，这也 是发明 EJB 的原因。EJB 是可以在多线程运行环境中分享的一小段代码。再来看看 Wildfly 的某页配置：
应用服务器的 EJB 容器可以通过各种方法来配置。可以配置 Bean 和线程池，以及这些池在集群中如何工作。有几种 EJB 类型适应不同的问题。因此如果有复杂的逻辑，简单无会话状态的 EJB 能大部分问题——甚至是仅在一台应用服务器上。
事务处理
我想讨论的最后一个用例是事务管理，它是软件开发中最复杂的问题之一。如果你遇到了需要一个或多个数据库连接的HTTP请求，同时还必须为不同的业务逻辑执行不同的代码组，那么在一个独立的操作中处理所有事情将变得非常困难。
事务管理是Java EE中的核心概念之一，不管你需要哪一种类型的service EJB或者哪一种JNDI源。每个请求都可以通过服务器在不同的容器中以一个或多个事务管理。对于绝大多数软件项目来说，几乎不可能独立的处理所有的问题和基本事务并正确执行它们。
再看一下Wildfly中事务子系统中的一个配置页面。
总结
我在这里到底需要传递什么信息呢？开发商业应用是一个复杂的问题。在性能和扩展性方面很多的细节需要被考虑。但是这些细节从软件开发之初直至开发完的两年内都不易被发现。Java EE 提供了一个平台能够规避掉大量细节问题。
因此如果你不是 Amazon, Netflix, 或者 Facebook 的架构师,最好不要不经思索采用他们的策略。微服务是个好办法，并且我相信将一个业务逻辑封装成一个独立的服务是值得的,但是很多情况下这也依赖于Java EE.
  1. da shang
    donate-alipay
               donate-weixin weixinpay

发表评论↓↓