忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？( 九 ) 【51CTO.com原创稿件】面试的时候

调用链监控其实最早是 Google 提出来的， 2010 年 Google 发表了一篇调用链的论文，论文以它内部的调用链系统 Dapper 命名。
这个论文中讲解调用链在 Google 使用的经验和原理，大致的原理如下图：
这里可以采用 ELK 的方式去记录和展示调用链监控日志，当我们一条调用为一行记录存储下来。
通过 TraceId 和 ParentSpanId 就可以串联起来为一个整体的链路，并可以从这个链路去分析错误或者调用延时和调用次数等等。
目前市面主流的调用链选型有 Zipkin ， Pinpoint ， Cat ， Skywalking ，他们之间各有一些偏重点。
值得一说的是 Skywalking 是国人出品的一款新的调用链工具，采用开源的基于字节码注入的调用链分析，接入段无代码入侵。
而且开源支持多种插件， UI 在几款工具来说比较功能比较强大，而且 UI 也比较赏心悦目，目前已经加入了 Apache 孵化器。
采用 Skywalking 作为调用链工具
为何会采用 Skywaling ，在低层原理的实现，这几款产品都差不多，但在实现和使用的细节相别还是很大：

首先在实现方式上， Skywalking 基本对于代码做到了无入侵，采用 Java 探针和字节码增强的方式，而在 Cat 还采用了代码埋点，而 Zipkin 采用了拦截请求， Pinpoint 也是使用 Java 探针和字节码增强。
其次在分析的颗粒度上， Skywaling 是方法级，而 Zipkin 是接口级，其他两款也是方法级。
在数据存储上， Skywalking 可以采用日志体系中比较出名的 ES ，其他几款， Zipkin 也可以使用 ES ， Pinpoint 使用 Hbase ， Cat 使用 MySQL 或 HDFS ，相对复杂。

由于目前公司对 ES 熟悉的人才比较有保证，选择熟悉存储方案也是考虑技术选型的重点。

还有就是性能影响，根据网上的一些性能报告，虽然未必百分百准备，但也具备参考价值， Skywalking 的探针对吞吐量的影响在 4 者中间是最效的，经过对 Skywalking 的一些压测也大致证明。

完美，把微服务的包打好，上传到服务器就可以运行了。 ^?_?^

等等，微服务包都打好了，剩下就是 Jar 包或 War 包一个一个上传到服务器上，然后用个脚本 Start ，在以前单块应用还好，现在微服务几十几百个应用，请问，运营人员怕不怕?
听说， Docker + Kubernetes 和微服务更配喔。
Docker + Kubernetes
就几个服务，先不用容器化部署了...乍一看，没完没了，还有 CICD ，灰度发布...容易编排...
下次再讲吧，先把服务部署上去吧。
部署到生产，预估容量
该把服务部署上线了，一个服务上线肯定得评估下或者预估下访问量有多少用户，有多少访问，这个涉及到该配置多少的机器资源，这应该怎么去估算呢，反正程序员在家里怎么算都算不出来。
评估访问量
①问运营，如果是一个已经上线的产品，肯定存在已有的用户数和访问数据，就算存在偏差，也是可控的范围。