基于Kong和Kubernetes的WebApi多版本解决方

　　一：背景1。讲故事
　　去年阿里聚石塔上的所有isv短信通道全部对接阿里通信，我们就做了对接改造，使用阿里提供的。netsdk。
　　网址：https：help。aliyun。comdocumentdetail114480。html
　　同事当时使用的是ons。netv1。1。3版本，程序上线后若干天就会有一次程序崩溃现象，当时也没特别在意，以为是自己代码或者环境出了什么问题，索性就加了一个检测程序，如果检测到sdk程序退出就自动重启，就这样先糊弄着，直到有一天服务器告警，那个程序CPU居然飙到100，服务器可是16核128G的哦二：分析问题1。抓dump文件
　　情况比较紧急，马上给程序发送CtrlC命令让程序退出，结果又退出不了，奇葩为了分析问题抓了一个dump下来，然后强制kill掉程序。2。查看线程池以及各个线程正在做什么？0：000！tpCPUutilization：100WorkerThread：Total：0Running：0Idle：0MaxLimit：32767MinLimit：16WorkRequestinQueue：0NumberofTimers：1CompletionPortThread：Total：1Free：1MaxFree：32CurrentLimit：1MaxLimit：1000MinLimit：16
　　从CPUutilization：100上看，果然cpu100了，发现WorkerThread没有Running线程，可能是因为执行了CtrlC都销毁了，接下来用e！clrstack把所有的托管线程栈打出来。0：000e！clrstackOSThreadId：0x1818（0）Unabletowalkthemanagedstack。Thecurrentthreadislikelynotamanagedthread。Youcanrun！threadstogetalistofmanagedthreadsintheprocessFailedtostartstackwalk：80070057
　　从输出结果看，没有任何托管线程，唯一的那个线程0还不是还托管线程，然后改成e！dumpstack把非托管线程栈找出来。0：000e！dumpstackOSThreadId：0x1818（0）Currentframe：ntdll！ZwRemoveIoCompletion0x14ChildSPRetAddrCaller，Callee000000637323ef4000007ff8327bac2fKERNELBASE！GetQueuedCompletionStatus0x3f，callingntdll！ZwRemoveIoCompletion000000637323efa000007ff81b9c8a00ONSClient4CPP！metaqjuce：：URL：：launchInDefaultBrowser0x273d0，callingkernel32！GetQueuedCompletionStatus000000637323f09000007ff81ba3eb0aONSClient4CPP！ons：：Message：：getMsgBody0x5a8a，callingONSClient4CPP！metaqjuce：：URL：：launchInDefaultBrowser0x1f100000000637323f14000007ff81ba3f084ONSClient4CPP！ons：：Message：：getMsgBody0x6004，callingONSClient4CPP！ons：：Message：：getMsgBody0x5800000000637323f28000007ff81ba233b4ONSClient4CPP！ons：：ONSFactoryProperty：：setSendMsgTimeout0xa6b4，callingONSClient4CPP！ons：：ONSFactoryProperty：：setSendMsgTimeout0xa5d0000000637323f2b000007ff81ba11b43ONSClient4CPP！ons：：ONSFactoryAPI：：ONSFactoryAPI0x153000000637323f31000007ff81ba12d64ONSClient4CPP！ons：：SendResultONS：：operator0xc44，callingONSClient4CPP！ons：：ONSFactoryAPI：：ONSFactoryAPI0x10000000637323f46000007ff81ba83eb4ONSClient4CPP！ons：：Message：：getStoreTimestamp0xf484，callingONSClient4CPP！ons：：Message：：getStoreTimestamp0xf1c4000000637323f63000007ff8356f7d94ntdll！RtlExitUserProcess0xb4，callingntdll！LdrShutdownProcess000000637323f69000007ff832777c23KERNELBASE！CtrlRoutine0xa3000000637323f78000007ff834df8364kernel32！BaseThreadInitThunk0x14，callingkernel32！WriteConsoleOutputW0x530
　　从非托管调用栈来看，其中KERNELBASE！CtrlRoutine表明主线程接受到了CtrlC命令，从栈顶发现貌似不能退出的原因是主线程被ONSClient4CPP接管，而且这个C正在做远程连接再等待网络IO返回，但这种会把16核cpu打满应该不太可能，这个问题貌似到这里就卡住了。三：重启程序发现问题依旧1。抓dump文件
　　很开心的是程序重新启动后，过了两分钟CPU又在飙升，这次学乖了，等CPU到了60，70的时候抓dump文件。2。继续排查0：000。timeDebugsessiontime：FriApr1717：36：50。0002020（UTC8：00）SystemUptime：355days5：33：48。092ProcessUptime：0days0：02：11。000Kerneltime：0days0：03：31。000Usertime：0days0：13：22。0000：000！tpCPUutilization：59WorkerThread：Total：3Running：0Idle：3MaxLimit：32767MinLimit：16WorkRequestinQueue：0NumberofTimers：1CompletionPortThread：Total：2Free：2MaxFree：32CurrentLimit：2MaxLimit：1000MinLimit：16
　　从上面代码可以看到，进程启动了2分11秒，这次cpu利用率是59，抓的有点早，不过没关系，先看一下Threads情况。0：000！threadsThreadCount：25UnstartedThread：0BackgroundThread：8PendingThread：0DeadThread：16HostedRuntime：noLockIDOSIDThreadOBJStateGCModeGCAllocContextDomainCountAptException01cdc0000022bb9f532202a020Preemptive0000022BBBFACCE8：0000022BBBFADFD00000022bb9f27dc01MTA223dc0000022bb9f7f9f02b220Preemptive0000000000000000：00000000000000000000022bb9f27dc00MTA（Finalizer）34296c0000022bb9fe97b0102a220Preemptive0000000000000000：00000000000000000000022bb9f27dc00MTA（ThreadpoolWorker）XXXX500000022bb9ffc5a01039820Preemptive0000000000000000：00000000000000000000022bb9f27dc00Ukn（ThreadpoolWorker）XXXX600000022bd43938c01039820Preemptive0000000000000000：00000000000000000000022bb9f27dc00Ukn（ThreadpoolWorker）。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。1632429e80000022bd48986501029220Preemptive0000022BBC102108：0000022BBC103FD00000022bb9f27dc00MTA（ThreadpoolWorker）1642529840000022bd489d4701029220Preemptive0000022BBC0EA2D0：0000022BBC0EBFD00000022bb9f27dc00MTA（ThreadpoolWorker）
　　好家伙，才2分11秒，托管线程ThreadCount：25就死了DeadThread：16个，而且从threads列表中看，windbg给的最大编号是164，说明当前有（1641）25142个非托管线程，应该就是阿里的ONSClient4CPP开启的，为什么开启这么多线程，这就是一个很值得关注的问题了，接下来还是用e！dumpstack把所有线程的托管和非托管线程栈打出来，由于信息太多，我就截几张图。
　　个人猜测，纯技术讨论：图1：
　　从堆栈上看，有105个线程卡在ntdll！ZwRemoveIoCompletion0x14这里，而且从ONSClient4CPP！metaqjuce：：URL：：launchInDefaultBrowser0x23072中看，貌似阿里开了一个浏览器内核，用内核来发送数据，估计这里并发阈值开的还挺大的，咨询了下同事是前面有一家大客户发了很多的短信，估计是大量的回持积压，这个Csdk进行了疯狂读取，这个跟CPU暴涨应该有脱不了的关系。图2：
　　从检索上看有28个线程貌似正在临界区等待锁，CPU高的一个经典案例就是当很多线程在临界区等待的时候，当某一个正在临界区中的线程离开后，这28个线程的调度竞抢也是CPU高的一个原因。
　　个人水平有限，进一步挖非托管堆目前还没这个技术（）四：解决方案
　　这种SDK的问题还能有什么解决方案，能想到的就是去官网找下可有最新版：
　　可以看到最新版的ons。netv1。1。4中提到的优化点：优化消息拉取流程，避免特殊情况下拉取异常造成的消息堆积。
　　果然用了最新版的sdk就可以了，。