分析分布式服务框架

分析分布式服务框架2010-01-12 BlogJava BlueDavy技术是为需求而服务的，分布式服务框架也同样如此，它不是凭空诞生的，也是因为有这样的需求才会有分布式服务框架这么样的东西诞生，在这篇blog中来详细的分析分布式服务框架诞生的原因（其实也是需要用分布式服务框架的应用场景，这里隐含的意思就是并不是什么应用都需要分布式服务框架的）、分布式服务框架需要提供的feature以及实现这些feature可选的技术方案。

其实这篇blog应该写在实现分布式服务框架系列blog之前，:），不废话了，来看为什么会需要分布式服务框架，在一个不断发展的大型应用中，系统的业务和功能不断的增加，同时技术在不断的发展、团队在不断的变化，很容易造成的现象就是：各个子系统、模块实现的技术五花八门，部署时各子系统的方式和要求不同，各个子系统之间的交互方式和方法不统一。这种现象带来的问题就是整个系统感觉很混乱，不过技术毕竟是不断的发展，因此各子系统、模块的具体实现技术要完全限制应该是不太可能的，也没必要，但会希望系统对外提供的功能能采用统一的部署以及交互方法，这样的话每个子系统能保持其黑盒的实现方式，其他子系统不想也不需要关心它的实现方式，只需要能够统一的方式调用到它们提供的功能就可以了，这是出现的第一个需求。

起初整个应用部署在一台机器上，但随着系统的功能越来越多，不得不不断的增加机器以减轻服务器的压力，但很快就出现瓶颈，不得不把应用分层部署，这样可以撑一段时间，在撑过一段时间后发现再度出现瓶颈，于是希望能够再度的把系统进行划分，这个时候就变成了希望能够以非常细的粒度来部署了，而不是把一堆的功能都部署在同一台机器上，这样带来的好处是系统的重用性能够再度的增强，服务器的压力能够有效的降低，使得系统可以以较低的成本继续保持Scable（就像google），其实这也是ebay的演变过程，大家可以去看看那个著名的ebay架构演变的PPT，还有一篇中文的ebay是怎样炼成的。

从上面的需求场景描述中可以看出，需要分布式服务框架的场景并不是很多，这里还有一种场景没去提及，那就是对于一个大型企业而言，由于需要用到的软件多种多样，其实也是有分布式服务框架的需求的，但还是有些不同，因为要去满足那种场景的方法可以更为简单。

分析下分布式服务框架的应用场景，可以得知，分布式服务框架的诞生目的主要有两个：

1、约束需要对外提供的功能，保证其以一个统一的方式来对外提供和获取；

2、分布式的部署细粒度的功能。

在确定了这两个目的后，来详细的分析下为了达到这两个目的，需要提供些什么feature。

要约束对外提供的功能，保证以统一的方式来对外提供和获取，首先需要制定的标准是功能到底以什么方式来对外提供，这里首先诞生了服务这个很好很形象的名词，对外提供的功能其实也就是为别人提供的服务了，那么服务里到底有些什么呢，面向接口自然是首选，所以服务都以接口方式来提供，另外可能就是会有一些服务的元信息了，如服务的名称、描述、依赖、所在机器等等；接着要完成的就是如何把各子系统对外提供的功能定义成服务呢，这里要求分布式服务框架能提供强大的集成能力，例如子系统是采用spring来实现，那么就需要支持能把spring的bean直接定义成服务；定义服务完成了，这个时候要解决的问题就是其他的子系统怎么知道有这些服务的存在呢，因此需要提供一个统一的服务的注册中心，同时相应的带来的问题就是各个服务应用端怎么来查找这些服务，怎么调用这些服务，这也是分布式服务框架需要解决的，在提供了上面的这些feature后，第一个需求就可以基本实现了。

分布式的部署细粒度的功能，这个在第一个需求达成的情况下，直接就可以实现了，因为分布式服务框架对服务应用端的粒度并没有要求，可粗可细，只是分布式的部署细粒度的功能其实潜在的带来了另外的需求，那就是怎么样把这些细粒度的服务直接组装来满足业务的需求，这也是分布式服务框架应该提供的功能；同时，还要注意的一点是，当变成细粒度的分布式部署的场景时，系统的稳定性和性能是会受到影响的，对于大型应用来讲这两点偏偏又是非常重要的，分布式服务框架需要对此进行考虑。

.......................................................咖啡一杯，休息一下.......................................................