企业级应用开发架构的现状与趋势 - Part 2
目录
在这篇文章中我们将讨论三个流行词汇API、SOA、ESB。
模块
目前公认的解决复杂系统构建的方法是模块化。模块化的目的是产生功能内聚而单一的功能单元，以方便测试、部署和重用。
在拆分了模块之后，模块之间该如何通讯呢？
这个时候我想大家都听说过SOA这个词，SOA这个玄乎的词汇任何搞架构的人都会有自己的理解，下面说说我的理解。
API
有了模块之后，那么模块对于外界来讲是一个什么东西呢？这个时候另外一个流行词汇API闪亮登场了。所以我们可以如下定义模块：模块是一个功能单元，通过对外暴露API来提供服务。
有了上述抽象的定义，接下来我们不得不面对如何在真实的系统中实现模块的问题。在一个Java系统中，一个模块通常就是一个jar文件，而API则是Java Class上面的方法构成。等等，如果是这样，我们的界面如何来调用这些API呢？要知道我们的界面是完全在浏览器中运行的应用，与服务器端通讯的唯一方式就是Ajax + JSON。
好吧，我们需要包装一些Restful Web Services。这个简单，Resteasy或者Spring MVC轻松搞定。
好了，搞定上述这些之后，我们终于可以部署我们的模块了。打包成一个war，放到Tomcat下面，然后配置一下Tomcat端口等等。
Service Registry & Discovery
就这样，我们创建了很多模块，把它们部署到不同的Tomcat实例当中，so far so good。可是如果这样的话，我就需要记住每个服务到底是由那个Tomcat实例提供的，这个岂不是很麻烦？没问题，我们需要一个Service Registry，把提供服务的Tomcat实例的地址和端口与它们相应的模块记录在一个公共的地方，这样的话，我们需要某个模块的时候，我们就只需要询问Service Registry就行啦。
搞定了Service Discovery问题之后，如果要上生产，我们得考虑一下性能和扩展性问题了。假设模块A提供了一个流行的API，很多人都要调用它，我们可以在不同的机器上面部署该模块的多个实例，然后在前面在放置一个反向代理。
ESB
等等，运营部的同事来找你了，你们搞这么多Tomcat实例，让我们怎么管理啊。好吧，让我们添加一些监控和性能指标和日志收集的能力，在弄一个dashboard。
写到这里，估计很多朋友都在嘀咕了，搞这么麻烦，实现起来是不是很复杂啊，答案是肯定的。ESB这个东西该闪亮登场了。IBM、Oracle、JBoss的顾问肯定会说，这些需求我们的ESB产品都能提供啊，而且还能提供更多，比如多协议支持，路由，消息转换等等。
ESB到底是什么？不是一句话能够讲清楚的，简单来讲，它是实现SOA架构的一种策略，但是记住，这绝对不是唯一的方法。而且绝大部分ESB产品都过于复杂，提供一堆你永远用不到的功能。如果你问我们公司核心系统的人ESB是什么，他们会说不就是一个用来调用SOAP Web Service的东东嘛，好吧，听完这个，我想说如果是调用SOAP Web Services，直接用CXF或者JAX-WS不就行了，干嘛还用ESB，这不是杀鸡用牛刀嘛。
