zipkin集成到node，C#

1、node与zipkin集成

• 结论：
  • 暂时只考虑已有产品线的node与zipkin的集成。
  • 如果后续有新的node服务，推荐使用zipkin-js官方使用的rest + zipkin-instrumentation-cujojs-rest组合。
    
    
• 原因：
  
  • 1、zipkin与node集成需要node的版本号 >= 6.0;
  • 2、zipkin与express的集成非常简单，并且侵入性也小，但是与client的集成推荐zipkin-rest + rest的方式，而目前各产品线的client使用多种多样，有node-rest-client、request等，需要我们针对不同的第三方模块额外封装一层才能工作；
  • 3、目前node人力资源有限，并且未使用framework的java服务暂时也没有与zipkin集成，所以优先级不高；
  • 4、后续node可能不会再用来写新项目。

 

• node与zipkin集成核心模块
  
  
  • Express server：server服务器与zipkin的集成，即server接收到请求时把自身的调用信息发送到zipkin
    
    
  • Rest Client：服务a调用服务b时，服务a把调用链信息发送到zipkin
    
    
  • Tracer：根据context把记录的span信息通过recorder发送到zipkin。
    
    
  • recorder：发送信息到zipkin，支持两种方式，一种是发送到zipkinserver，还有一种是控制台输出，控制台输出的方式可以用来调试。

• 集成方案：
  • 把zipkin-js的recorder、tracer封装成一个tracer模块，直接给express server和rest client使用；

  • express server直接与zipkin-instrumentation-express + 封装后的tracer集成,可参考示例：

    express + zipkin example

    // initialize tracer const tracer = require( './tracer' );   const express = require( 'express' ); const app = express();   // instrument the server const zipkinMiddleware = require( 'zipkin-instrumentation-express' ).expressMiddleware; app.use(zipkinMiddleware({    tracer,    serviceName:  'backend'  // name of this application }));

 

• • 把request + zipkin封装成一个模块，使用request的产品线通过修改require后面的模块名称切换是否与zipkin集成。（难点） 

    • 已经初步实验过方案可行，大概的做法是把request封装一层，在其调用api request前后，仿照zipkin提供的zipkin-instrumentation-cujojs-rest模块，各发送一次span信息到zipkin。

      封装request的方式

      function  requestOverride(url, options, callback) {        if  ( typeof  options ===  'function' ) {          callback = options;          options = {};      }      const re = request(url, options,  function  (err, response, body) {          //from zipkin-instrumentation-cujojs-rest request method          zipkinResponse(response, tracer);          return  callback(err, response, body);      });        //from zipkin-instrumentation-cujojs-rest response method      zipkinRequest(re, tracer,  'request-zipkin' ); }

      
      

    • 使用方法：假设封装后的模块名称为request-zipkin-rest,则只需把原来的require('require')修改成require('request-zipkin-rest')即可。
    • 争议：方案2–针对request模块，通过propertype重写其请求调用方法与zipkin集成。
    • 不建议方案2，理由贴出如下：
      • 如果使用propertype全局修改request的方法，则需要在app启动时加载，而request模块需要在后端实际处理请求时require，故加载时机会是一个问题；
      • 每次require request module的时候，全局加载的propertype是否会应用到require到的对象中有待进一步调研；
      • 方案2的方式强制添加zipkin到server必须基于server级的粒度去控制，并且直接改变require第三方对象的行为，不一定是产品线想要的结果。

• 问题：
  • 原node仓库现在已经基本无人维护，而且cnpm本身如果不经常升级，和npm兼容也不是特别好。推荐https://github.com/rlidwka/sinopia或者nexus – shiqi；
  • sample rate还未与express middleware集成，讨论链接：https://github.com/openzipkin/zipkin-js/issues/75。
    
• 相关资料：
  • zipkin-js：https://github.com/openzipkin/zipkin-js
  • zipkin + js example： https://github.com/openzipkin/zipkin-js-example

 

  2、C#与zipkin集成

• 结论：不迁移旧的admin代码与zipkin集成。
  
  

• 原因：
  • 服务之间调用支持zipkin的解决方案对Admin已经使用的client的侵入性比较大；
  • 没有一个合适的official repo，openzipkin对C#的解决方案还不成熟；
  • 调研成本相对较高，对C#的asp.net使用不熟；
  • 旧的admin代码与zipkin集成不是一个值得花大成本实现的需求。
    
    

• 调研资料：

  • Medidata.zipkinTracerModule:31颗星，git上star最多的zipkin + C#项目，到目前为止已经维护了三年，多人维护。搜索C# + zipkin时被多次推荐。

  • zipkin.net:11颗星，支持RabbitMQ传输，单人维护，被zipkin-csharp的作者要求合并到zipkin-csharp仓库。

  • zipkin-csharp:official C# + zipkin repo，目前还处于开发阶段。

    附上一篇C# zipkin的讨论文章：https://github.com/openzipkin/zipkin/issues/1518