在这个篇幅中将来分析下这个分布式服务框架的服务的生命周期的管理的问题，在分布式服务框架中，支持服务的动态部署、卸载、升级是很关键的，至于服务的生命周期是否需要做到像OSGi那样的动态通知，在这个篇幅中会进行分析，并最终形成这个分布式服务框架的生命周期模型以及到目前为止的服务架构模型。
先来分析下服务的生命周期是否需要做到像OSGi DS的动态通知，这里以服务组件安装为例稍微的说下OSGi DS服务的生命周期模型，在OSGi DS中，当有新的Service Component安装时，首先会检查其是否lazy，如是lazy或此Service Component对外提供服务则完成安装，生成ServiceRegistration对象放入其服务中心；如不是lazy或此Service Component不对外提供服务，则首先检查其引用的服务是否可用，如不可用则尝试激活引用的服务，如所有引用的服务均可用，那么激活此Component，对外提供此Service，并发布Service Active的事件；服务生命周期事件管理器在接收到Service Active的事件后，将会查找所有引用此Service的Component，如Component未激活，则尝试激活，如已激活，则根据配置的bind-method注入此Active的Service Instance。
根据上面的分析，到分布式的服务应用的环境下，来看看，下图为一个典型的分布式服务应用的图示：
根据OSGi DS服务的生命周期模型，那么当我们在服务应用端部署了一个分布式服务时，此服务首先需要到服务中心进行注册，在注册时，需检查去所引用的服务是否可用，如可用，得激活此服务，同时需要将此消息发送给所有引用了此服务的服务应用端，这整个过程说起来是相当的顺畅的，但我们可以想想，如果这个服务是个基础服务，被N多服务应用端引用了，那这个时候会是个什么状况，那要通知到多少的服务器呢(可以想象100+的服务群)，尽管可以cluster+同步，:)，更复杂的情况，当此服务引用了其他N个服务，首先需要发消息尝试激活这些服务，然后那些服务激活后又带来了N个服务的激活，这个就把整个过程变得极度繁琐了，整个的实现难度和逻辑复杂度大大提升了，动态的处理生命周期的变化将会带来很大的技术难度以及不可控因素，例如在高并发的场景时某服务突然不可用了，但它的通知的消息还在传递，那结果会怎么样呢？既然这么难控制，那就干脆不去控制这种动态的变化了，简化整个生命周期模型，保证实现的简便性和系统的高稳定性，这也是实现所有系统必须遵循的原则：“简单(但不是简陋)到可控、满足需求为止”。