考虑将WCF用于日志服务…请告知

问题描述

| 我正在考虑企业日志记录服务的体系结构。它的工作是接收和存储日志消息,然后允许用户访问这些日志消息。我们不需要将日志记录功能构建到我们现在可以使用的现有Windows服务中,而是需要将其分离,以便其他服务可以在不久的将来使用它。我喜欢这样一个事实,我们的各种服务可以通过net.tcp记录其消息,然后可以构建一个RESTful接口,用于将特定的日志消息传递给浏览器或其他任何对象。 任何人都可以说出以下选择的明智之处或不足之处: 使用WCF进行日志记录服务 使用net.tcp进行传输 将服务托管在Windows Service项目中(使用ServiceHost) 另外,我应该如何设计它以便利用将托管它的一些功能更强大的服务器呢?是否可以打开多个连接(或自动完成连接)或实现一些自动多线程处理? 我们目前使用该日志记录服务的一项服务非常冗长,并且会非常频繁地发送日志消息(约40-100k /天)。我尚未建立原型并进行任何基准测试,我知道我没有为您提供足够的详细信息来做出确定的决定,但是我现在只是在寻找一些方向和考虑因素。谢谢。     

解决方法

还有其他方法可以创建一个仅用于日志记录的服务。您可以将日志记录构建为一个方面,并在任何
ServiceContract
OperationContract
需要时附加/分离此方面(也称为注入)。通过这种方式,您可以取消日志记录的耦合,但可以避免在每次调用时再调用一个服务的开销。一旦创建了这些方面,就可以将它们编译成单独的二进制文件,并在将来的所有服务中按需使用它们,与拥有仅用于日志记录的专用服务相比,启用和禁用特定日志记录方案是更易于维护的IMO。 看一下下面的两篇文章,他们提供了简化的方法,您必须根据需要填写项目的内容。 创建日志记录方面 WCF可扩展性:参数检查器 您想要查看的重要MSDN文档。 IParameterInspector IOperation行为 IService行为 编辑-示例代码 使用以下代码,您可以在任何运营合同上方添加“ 2”,然后可以在“ 3”中拦截对该运营合同的调用。 在任何服务合同上使用ѭ4,该服务调用中定义的所有操作都可以被拦截和记录。 将ѭ5设置为ѭ6以外的任何值,这些其他行为不会添加到您的服务管道中。这很酷,因为这些代码都不基于config中的此键执行。
public class LoggingInspector : IParameterInspector
{
    private string service;
    public LoggingInspector(string serviceName){ service = serviceName;}
    public void AfterCall(string operationName,object[] outputs,object returnValue,object correlationState){}
    public object BeforeCall(string operationName,object[] inputs)
    {
      // your logging logic
    }
}

 //Operation Logging attribute - applied to operationcontracts.
 [AttributeUsage(AttributeTargets.Method)]
 public class OperationLoggingAttribute : Attribute,IOperationBehavior
 {
    public void AddBindingParameters(OperationDescription operationDescription,BindingParameterCollection bindingParameters){}
    public void ApplyClientBehavior(OperationDescription operationDescription,ClientOperation clientOperation){}
    public void ApplyDispatchBehavior(OperationDescription operationDescription,DispatchOperation dispatchOperation)
    {
        if (ConfigurationManager.AppSettings[\"your_app_config_key\"] == \"TRUE\")
            dispatchOperation.ParameterInspectors.Add(new LoggingInspector(dispatchOperation.Parent.Type.Name));
    }
    public void Validate(OperationDescription operationDescription){}
 }

 //Service Loggign attribute - applied to Service contract
[AttributeUsage(AttributeTargets.Class)]
public class ServiceLoggingAttribute : Attribute,IServiceBehavior
{
    public void AddBindingParameters(ServiceDescription serviceDescription,ServiceHostBase serviceHostBase,Collection<ServiceEndpoint> endpoints,BindingParameterCollection bindingParameters){}
    public void ApplyDispatchBehavior(ServiceDescription serviceDescription,ServiceHostBase serviceHostBase)
    {
        if (ConfigurationManager.AppSettings[\"your_app_config_key\"] == \"TRUE\")
            foreach (ServiceEndpoint endpoint in serviceDescription.Endpoints)
                foreach (OperationDescription operation in endpoint.Contract.Operations)
                    operation.Behaviors.Add(new OperationLoggingAttribute());

    }
    public void Validate(ServiceDescription serviceDescription,ServiceHostBase serviceHostBase){}
}
    ,原则上,我认为单一审核服务是有意义的,只要它在您的应用程序的有限上下文内。 IDesign此处提供了ES日志的示例实现(请查找\“ Enterprise Services Logbook \”)。您可以进行一些初始测试,以查看它是否可以处理您期望的负载。如果您担心性能,我会考虑通过tcp进行消息排队(示例日志应用程序也支持此功能)。至于托管,该服务需要始终运行,因此Windows Service很有意义。如果要使用IIS,则建议使用Windows Server AppFabric并启用应用程序的自动启动功能。 HTH。     ,阅读问题我有一些想法要分享。 日志记录本身并不是一件非常复杂的事情,使用WCF创建企业日志记录框架就可以了。但是,仅用于记录的记录数据没有用。然后,此数据需要由某个进程\\ app消耗,因此需要提供一些附加值。因此,日志记录更重要的方面是 正在记录什么数据。 记录的数据如何被消耗\\利用 因此,我的建议是花更多时间考虑需要记录什么以及该数据增加了什么价值。     

相关问答

依赖报错 idea导入项目后依赖报错,解决方案:https://blog....
错误1:代码生成器依赖和mybatis依赖冲突 启动项目时报错如下...
错误1:gradle项目控制台输出为乱码 # 解决方案:https://bl...
错误还原:在查询的过程中,传入的workType为0时,该条件不起...
报错如下,gcc版本太低 ^ server.c:5346:31: 错误:‘struct...