标签：
对于日志的记录，无论是Log4Net也好，NLog日志也罢，提供的功能都比较全面，并且久经历史考验，但是基于服务的日志架构并不采用他们其中的任何一个框架来实现，即使他们可以处理的更好，该架构主要用来处理对于多台服务器，并且每台服务器下的有许多不同的站点，集中对日志进行处理，包含需要记录的审计日志和系统日志，统一交由一个服务来实现对日志的存储。并且可通过相应的工具进行查看日志的实时监控情况。
我相信主要我画的不太毛糙的话，基本原理也都可以看得懂，主要的原理实现起来也很简单。
首先，写一个WCF服务，里面提供接口并且提供订阅接口，自定义一个配置文件用来配置日志的记录的记录规则和日志的存储方式，在每次服务启动的时候加载一次，剩下的逻辑就是你怎么去根据配置对Task发送给服务的数据进行处理。
其次，创建一个类库，实现对服务的引用，这个类库的主要作用是对服务的隔离，也就是使用代理模式实现服务的引用，应用程序在使用服务进行日志存储的时候，只需要访问代理类即可，在代理中主要处理，如何连接远程WCF服务，对出错的情况如何处理以及服务在不可用的时候，如何保证应用程序发出来的日志不丢失，并且不影响使用的应用程序。在代理类中我主要根据队列来实现的，每次应用程序发送过来的日志，首先进入日志队列中，然后开启异步任务去实现出队列发送数据到远程服务进行存储，其次就是在远程服务不可用的时候，需要采用辅助队列来对出队列并未进行远程存储的数据的储存，然后辅助队列开始出队列/入队列不断尝试知道服务可用为止，当服务可用时可以保证日志的顺序不会错乱，并且不会丢失。在进行入队列操作是一定要对上锁，要不然会出现错误。
最后，在调用组件的应用程序端在配置文件中对WCF访问节点进行配置。
目前存在最大的问题就是，当服务不可用时，有大量的数据需要进队列，然后没有消费方对日志消息进行消费，当时队列越来越大，占用应用程序内存，导致应用程序崩溃。目前也正在设想中....
首先对于排版和描述逻辑问题，本人的语文不怎么好，也不知道自己说的是否明白，再者就是由于本人经验尚浅第一次去设计这样一个日志架构，肯定存在很多问题，还希望各位大神多多指点。
标签：
原文地址：http://www.cnblogs.com/retop/p/5643840.html
