后台服务所应该具备的非业务特性。

根据个人的经验，按照重要程度一条条地列。 这里要列出来的特性并不是业务的，比如你的服务需要实现什么样的业务，已经业务有什么要求，这些都在业务的范畴内。这里列出的特性都是属于非业务的特性。

1. 状态标记。

状态标记可以以最简洁的方式说明了当前服务的运行情况。这个情况可以根据组件来分，也可以根据业务模块来分，还可以根据一些业务指标来分。

按组件来分：整体级别和组件级别。整体级别的就是一个概况，说明这个服务的运行状态，例如Windows中的服务主要状态为Stopped，Running，Start-Pending，Stop-Pending。然后也可以根据服务所包括的组件来分，例如DbConnection = OK，WebService = OK，Component 1 = Stopped。

按业务模块来分。例如收到消息=100个，发出消息=200个，消息接收器状态=OK，消息触发器=Warning。

这些标记最好简单明了，查看方便。这个查看方便可以俩方面的，一是手工查看方便。二是程序对状态的读取方便。建议使用Plant-text的方式，或简单格式XML。这种简单的格式对于调试和分析都是很简单，很容易的。

2. 动态配置。

一个服务，总是会有很多参数。如果可以将这些参数的配置都动态化，这样就可以在服务运行的时候动态地调整参数。避免了因为服务宕机时，影响业务。动态配置也可以分为各种分类参数级别，或者组件级别，例如可以将一些阈值作为参数化配置，例如限制的Log大小，限制的Message大小，文件大小等等。也可以是一些大的业务的配置，例如是否需要Log？根据需要动态的配置Log，可以配置为将Log写入文件，也可以将Log写入数据库，或通过某个Service来写。 

动态配置的最大好处就是可以避免服务宕机，以及因此宕机时所带来的一系列问题，同步状态，切换服务等等。

3. 动态升级。

需要动态升级的目的和动态配置的目的是一样的——就是避免宕机和停止服务。我们可以对服务做一个框架设计，对组件进行一个抽象。然后让服务变成一个框架，所有的业务组件都是一个插件，可以动态的插和拔。也可以动态的更改——即升级。例如我们的服务中一个接收器——Receiver。我们可以设定一个Plug-in的目录。当程序启动时，自动读物Plug-in里面的插件。读取完后不再占有Plug-in里面的任何文件——这样就允许在服务允许的过程中，对文件进行删除，修改（升级）的操作。然后对Plug-in文件夹进行监视。当发现文件更新的时候，重新读入Receiver，并替代内存中的Receive。——这样就完成了一个动态升级的过程了。

当然，在实际的项目当中，动态升级的过程要复杂一些。需要考虑升级的时机和情况。我们可以根据业务的需求对升级进行细化的管理。例如可以在业务不忙的时候，或者在发现服务空闲的时候去升级。这样可以避免升级的时候积攒了太多的待办业务。不过，如果服务程序设计得好，一般服务都不是单独的，服务都可能是部署在多台服务器上的。一台服务升级时，其他服务可以继续地处理业务。

4. 服务应该是小，全，并且可随意复制（扩展的）

服务可以部署在一台服务器上运行。也可以部署在多台服务器上运行。服务和服务之间应该是相互透明的。任何一个服务可以协调其他服务，也可以向其他服务报告自己的状态。服务和服务之间应该是平等的。任何一个服务宕机，其他的服务都可以替代它。也可以随意扩展服务。服务之间最后不要引入状态，例如将服务分为服务A，服务B，服务C，必须A，B，C同时存在才能完成一次业务。服务引入状态之后，我们不得不对状态进行管理。而当服务的数量增加时，我们需要管理的状态就变成了一个乘积。最后可能导致的结果是——需要管理的状态比需要做的业务还多。可是我们服务本来是用来做业务的。