BlueDavy之技术Blog

技术是为需求而服务的，分布式服务框架也同样如此，它不是凭空诞生的，也是因为有这样的需求才会有分布式服务框架这么样的东西诞生，在这篇blog中来详细的分析分布式服务框架诞生的原因(其实也是需要用分布式服务框架的应用场景，这里隐含的意思就是并不是什么应用都需要分布式服务框架的)、分布式服务框架需要提供的feature以及实现这些feature可选的技术方案。
其实这篇blog应该写在实现分布式服务框架系列blog之前，:)，不废话了，来看为什么会需要分布式服务框架，在一个不断发展的大型应用中，系统的业务和功能不断的增加，同时技术在不断的发展、团队在不断的变化，很容易造成的现象就是：各个子系统、模块实现的技术五花八门，部署时各子系统的方式和要求不同，各个子系统之间的交互方式和方法不统一。这种现象带来的问题就是整个系统感觉很混乱，不过技术毕竟是不断的发展，因此各子系统、模块的具体实现技术要完全限制应该是不太可能的，也没必要，但会希望系统对外提供的功能能采用统一的部署以及交互方法，这样的话每个子系统能保持其黑盒的实现方式，其他子系统不想也不需要关心它的实现方式，只需要能够统一的方式调用到它们提供的功能就可以了，这是出现的第一个需求。
起初整个应用部署在一台机器上，但随着系统的功能越来越多，不得不不断的增加机器以减轻服务器的压力，但很快就出现瓶颈，不得不把应用分层部署，这样可以撑一段时间，在撑过一段时间后发现再度出现瓶颈，于是希望能够再度的把系统进行划分，这个时候就变成了希望能够以非常细的粒度来部署了，而不是把一堆的功能都部署在同一台机器上，这样带来的好处是系统的重用性能够再度的增强，服务器的压力能够有效的降低，使得系统可以以较低的成本继续保持Scable（就像google），其实这也是ebay的演变过程，大家可以去看看那个著名的ebay架构演变的PPT，还有一篇中文的ebay是怎样炼成的。
从上面的需求场景描述中可以看出，需要分布式服务框架的场景并不是很多，这里还有一种场景没去提及，那就是对于一个大型企业而言，由于需要用到的软件多种多样，其实也是有分布式服务框架的需求的，但还是有些不同，因为要去满足那种场景的方法可以更为简单。
分析下分布式服务框架的应用场景，可以得知，分布式服务框架的诞生目的主要有两个：
1、约束需要对外提供的功能，保证其以一个统一的方式来对外提供和获取；
2、分布式的部署细粒度的功能。
在确定了这两个目的后，来详细的分析下为了达到这两个目的，需要提供些什么feature。
要约束对外提供的功能，保证以统一的方式来对外提供和获取，首先需要制定的标准是功能到底以什么方式来对外提供，这里首先诞生了服务这个很好很形象的名词，对外提供的功能其实也就是为别人提供的服务了，那么服务里到底有些什么呢，面向接口自然是首选，所以服务都以接口方式来提供，另外可能就是会有一些服务的元信息了，如服务的名称、描述、依赖、所在机器等等；接着要完成的就是如何把各子系统对外提供的功能定义成服务呢，这里要求分布式服务框架能提供强大的集成能力，例如子系统是采用spring来实现，那么就需要支持能把spring的bean直接定义成服务；定义服务完成了，这个时候要解决的问题就是其他的子系统怎么知道有这些服务的存在呢，因此需要提供一个统一的服务的注册中心，同时相应的带来的问题就是各个服务应用端怎么来查找这些服务，怎么调用这些服务，这也是分布式服务框架需要解决的，在提供了上面的这些feature后，第一个需求就可以基本实现了。
分布式的部署细粒度的功能，这个在第一个需求达成的情况下，直接就可以实现了，因为分布式服务框架对服务应用端的粒度并没有要求，可粗可细，只是分布式的部署细粒度的功能其实潜在的带来了另外的需求，那就是怎么样把这些细粒度的服务直接组装来满足业务的需求，这也是分布式服务框架应该提供的功能；同时，还要注意的一点是，当变成细粒度的分布式部署的场景时，系统的稳定性和性能是会受到影响的，对于大型应用来讲这两点偏偏又是非常重要的，分布式服务框架需要对此进行考虑。

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

继续，上面分析完毕后产生了分布式服务框架的基本Feature，来总结看看，并同时对其进行可选的实现技术的分析：
1、服务模型
      在服务模型中需要详细定义服务模型包含了哪些信息，而这些信息也就决定了服务在发布时需要提供的信息，同时也是为服务查找和调用提供的信息。
2、服务的注册中心
      服务的注册中心在分布式服务框架中充当的就是服务信息的存储场所的作用，同时它还需要提供的一个重要的功能就是查找服务，这两个最重要功能最重要的就是稳定、高效以及支持Cluster。
      存储服务信息上可采用数据库存储、分布式文件系统存储等，查找服务需要的就是支持高效的查找，这个要根据服务的查找方法等来建立相应的缓存和索引，这里需要注意的是在cluster情况下的处理，选用数据库存储或分布式文件系统存储自然是不会有cluster的问题的。
      另外一个需要确定的就是服务应用端怎么调用服务注册中心提供的管理接口，可采用的技术有JNDI、JMS、WebService等等N多种实现方式，可以根据具体的性能要求、实现方法、需求等来进行选择。
      从扩展方面去看，服务的注册中心应该提供多种服务应用端和注册中心的交互协议的选择、扩展。
3、发布服务的方式，支持Spring、EJB3等等
      支持直接的把服务应用端的功能发布为服务，发布的方式更多的是xml、annotation等方式，就是一种很不错的设计，所以要根据服务应用端采用的技术而定，常见的如spring、EJB，这个完全根据分布式服务框架所面对的应用场景而定，如果你的服务应用端都是基于Spring的，那么就可以暂时只提供Spring的方式了。
      注册服务方面的技术基本也不用选择，因为它其实是根据服务应用端采用的技术而决定的，相当于提供一个集成的接口而已，由此接口去完成和服务中心的交互。
      但这里有个关键的实现技术需要选择，就是把服务以什么方式对外提供，例如有JNDI、Webservice、JMS等等，就像Spring中的HessianServiceExporter，这里需要的是服务框架本身支持好这些协议，至于到底要实现多少种也是根据需求来看了，而各种协议的实现可以选用协议对应的成熟产品，如jndi有jboss jnp，也可以自己根据需求实现。
      也许在spring中我们可以这么来发布service：
      <hsf:service>
              <ref bean="Spring Bean"/>              
              <metainfo:jndi server="" interface="服务接口名" name="简要名称" desc="服务功能描述"/>
              <!--以jndi的方式对外提供-->
              <publish:jndi server="">
                        <property name=""></property>
              </publish:jndi>
              <!--以hessianservice的方式对外提供-->
              <publish:hessian server=""/>
              <!--以jms的方式对外提供-->
              <publish:jms server="" queue=""/>
      </hsf:export>
4、查找服务和调用服务的方式，支持Spring、EJB3等等
      查找服务和调用服务方面，需要做到的就是能够让服务应用端透明的使用远程的服务，所以其实也是和服务应用端采用的技术相关的。
      当然，它本身需要提供以各种协议和服务中心通讯，以各种协议调用远端服务的支持，另外就是同步、异步的支持等，还需要从高效性去考虑。
      对于使用者来说则比较简单，也许在Spring中我们可以这么来调用远端的service：
      <bean id="loginService" class="HSFObjectFactoryBean">
              <hsf:service>
                      <import:jndi server="" interface="">
                              <!--可用于过滤查找的服务-->
                              <property name=""></property>
                      </import:jndi>
              </hsf:service>
      </bean>
5、服务的组装
      服务的组装需要提供的就是将服务中心的服务进行组装，以实现复杂的业务需求，这里面需要包括容错等等的支持，同样，高效性也是这里面的重点。
      可选用的技术有采用事件框架、jbpm等。
6、稳定性和性能
      通常来讲，需要用到分布式服务框架的应用在稳定性和性能方面都会有很高的要求，当然，稳定性更多的是通过避免Single Point的方式来提供，但同时软件层面也应该尽量避免无谓的错误，从技术角度上来讲可以采取fail-fast的思想来实现。
      性能方面，需要根据使用时的压力情况来决定，如查找服务时太慢，需要考虑提升服务中心查找服务的效率，增加索引，使用分布式存储等等都是可采用的方式，提升性能的方面其实可采用的方案是非常多的，但每种技术几乎都是需要非常专业的人才去实现的。

上面分析的feature只是分布式服务框架的基本feature了，一个强大的分布式服务框架的话实现的东西会比这个多很多(例如提供服务管理端、监控端、IDE等)，不过主要会是细节上，在具备了这些基础feature的情况下，细节就决定了高低了，:)。
分布式服务框架的引入也许会降低些性能，但应用的适当的话，则能充分发挥服务器性能，并且很大程度的降低系统Scable的成本，至于开发效率的话我不觉得是分布式服务框架需要解决的问题。
服务框架其实对于所有应用而言几乎都是需要的，而且非分布式的服务框架可选的是有很多的，但分布式服务框架可选的目前基本是没有，所以如果不是应用真的需要，没有必要去实现分布式服务框架（就像在企业应用模式里Martin Fowler讲的一样，尽量不要分布式，:)），因为分布式服务框架对于技术层面还是有挺高的要求的，说简单点呢，就是高效的存储、查找策略+高效的通讯策略+满足需求的服务模型+强大的集成能力构成了分布式服务框架的核心技术实现。

ps：在写完这篇blog后，发现自己在基于OSGi实现分布式服务框架（四）里面写OSGi不适合其实是个不准确的词，因为在服务的应用端其实是可以采用OSGi的，不过以分布式服务框架而言，OSGi是没有什么适用的场景，除了服务模型可参考外，但在服务应用端而言，OSGi仍然是个很好的选择。