Sheng Wu <wu.sheng.841...@gmail.com> 于2019年9月4日周三 上午11:31写道：
> Willem Jiang <willem.ji...@gmail.com> 于2019年9月3日周二 下午6:25写道： > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei <zhang_...@boco.com.cn> wrote: > > > > > > Hi Willem, > > > > > > I agree to integrate a transaction tracking service, I used Zipkin, > but > > I don't know much about Skywalking. > > > > > > I have some questions: > > > > > > 1. Skywalking agent just working on the Omega side? > > Yep, but we can also let the agent do the instrumentation on the Alpha > > side. > > > > > 2. Use @Trace in the same location as @SagaStart and @Compensable, Or > > Combined annotation? And use TraceContext.traceId() to generate > globalTxId > > or localTxId ? > > This is the detail thing we need to think about. > > I think you are just proposing a way to integrate the Zipkin, am I right? > > > > @Trace is SkyWalking annotation, which SkyWalking agent could identify and > instrument as a local span(Not RPC related) > > > > > > > 3. Will Omega users have conflicts if they already use Zipkin? > > We need to do some end to end verification, currently I think it's > > fine if we can find a way to generate a correlation id between tracing > > system and pack, we don't need to deeply combine these two system > > together, they can work separately. > > > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to use both > at the same time, because it is pointless. > > > > > > > 4. About provides a service to bridge the Trace information that > > Skywalking collects with ServiceComb Pack Transaction events information. > > Do you mean that Alpha sends service chain information directly to > > Skywalking via API? > > It's more like a portal integration. We can still leverage the old API > > provide by Skywalking and ServiceComb Pack. > > > > In this way, we need to have a deeper discussion about what ServiceComb > wants and requires. > Basically, I think we need to track the saga transaction status by the global id. > > > > > > > > > > > > Lei Zhang > > > > > > > 在 2019年9月3日，下午7:22，Willem Jiang <willem.ji...@gmail.com> 写道： > > > > > > > > Hi, > > > > > > > > As ServiceComb Pack use the GlobalTransactionId to trace the > > > > distributed transactions, it's make sense that let the ServiceComb > > > > Pack and Skywalking share the same Id for tracing. > > > > In this way, we can bring the APM feature into Distribution > > > > Transaction managemet world. > > > > > > > > Current ServiceComb has Interface IdGenerator[1], which is used for > > > > the generate the GlobalTransactionId in OmegaContext[2]. I think if > we > > > > can reuse the transaction implementation with the Skywalking agent to > > > > generate the GlobalTransactionId. In this way we can search the trace > > > > information and transactions with same correlation ID. > > > > > > > > The missing part is LocalTransactionId, we need to figure a way to > > > > bring the LocalTransactionId with the trace information. > > > > > > > > BTW, ServiceComb Pack is using ES to store the Transaction related > > > > event[3]. I think we can provide a service to bridge the Trace > > > > information that Skywalking collects with ServiceComb Pack > Transaction > > > > events information. > > > > > > > > Any thoughts? > > > > > > > > [1] > > > https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java > > > > [2] > > > https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java > > > > [3] > > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm > > > > > > > > Willem Jiang > > > > > > > > Twitter: willemjiang > > > > Weibo: 姜宁willem > > > > > >
