根据以上图表还可以看得出Zuul全项适用，但是因为Zuul与SpringCloud的高度集成化，故只可以针对APPJava环境的微服务架构开展防护。其他云原生API接口端口均有一个不兼容，关键为Ambassador针对内容丢失防护不兼容，Gloo针对SSL证书监管不兼容，Kong也是对内容丢失防护不兼容，须要留意的是，这3个API接口端口对比于Zuul有较为突出的差别，Ambassador与Gloo均为Kubernetes原生态端口，且从官网上[21][26]都能见到她们兼容微服务治理架构Istio的方式，因而假如每位阅读者APPIstio整治微服务架构，还可以挑选 Ambassador和Gloo。Kong归属于这四者中开源项目较为快速增长及成熟期的，从官方网的解决方法中[21]还可以见到，其以适用Kubernetes的实施方式，凭着Kong在API接口安全上的累积，坚信没多久还可以在云原生API接口端口上占领立足之地，变成大部分人的挑选 。

针对《云原生APP安全隐患审视》这篇文章中提及的云原生APP业务方面安全性问题，根据基准线的异常检测是一种较为合理的方式：最先创建正常业务情形与基本参数的基准线，从而找到偏离基准线的不正常业务使用，当中，基准线的创建须要融合业务管理系统的特点和专业人士专业知识一同来实现。

在电商系统中，业务基本参数基准线关键根据专业人士专业知识来创建。比如产品价格不但与产品自身有关，也与时长和各种优惠促销等有关。这类基准线须要运营技术人员不断的系统维护。针对业务逻辑基准线的创建，因为业务管理系统在开始上架运转之后，其使用逻辑通常不容易有很大的改变，另外不正常使用所占的占比较少。因而还可以搜集业务管理系统过去的使用数据信息，融合数据统计分析与机器学习方法创建业务逻辑的基准线。对比于人工服务方式，这类方式还可以提升基准线创建的工作效率，合理缓解运营技术人员的任务量。

因此，可运用分布式系统跟踪软件对云原生APP中形成的数据信息开展搜集，小编对当今流行的分布式系统跟踪软件Zipkin，Jaeger，Skywalking，Pinpoint开展了调查，这种分布式系统跟踪软件大致可分成三种，根据安卓sdk的，根据探头的，根据Sidecar的。