生成NC钻孔文件 在【NC钻孔设置】对話框中完成NC Drill文件参数设置后单击【确定】按钮，打开如图9-32所示的【输入钻孔数据】对话框 图9-32 【输入钻孔数据】对话框 生成NC钻孔文件 在【输入钻孔数据】对话框中设置长度单位和默认孔的尺寸，单击【确定】按钮生成钻孔NC Drill文件，如图9-33所示 在单击标准工具栏中的工具按鈕，保存生成的文件 图9-33 生成的钻孔文件 打印输出PCB图 页面设计 首先激活PCB图为当前文档，然后执行【文件】/【页面设计】命令将打开【Composite Properties】對话框，如图9-34所示可以在该对话框中指定页面方向(纵向或横向)和页边距，还可以指定纸张大小和来源或者改变打印机属性。 图9-34 【Composite Properties】对話框 打印输出PCB图 【打印纸】设置：在【打印纸】选项区域中单击尺寸列表框后的点击，在出现的下拉列表中选择打印纸张的尺寸如图9-35所示。【肖像图】和【风景图】单选按钮用来没置纸张的打印方式是水平还垂直 图9-35 打印纸张的尺寸 打印输出PCB图 【高级选项】设置：单击【Composite Properties】对话框中的【高级设置】按钮，将打开【PCB Printout Properties】对话框如图9-36所示。在该对话框中可设置要输出的工作层面的类型设置好输出层面后，單击OK按钮确认操作 图9-36 【PCB Printout Properties】对话框 打印输出PCB图 【预览】设置：在进行上述页面设置和打印设置后，可以首先预览一下打印时的效果单击【Composite for】对话框 使用智能PDF建立PDF文档 打开工程“Audio AMP.PrjPCB”及有关原理图。 执行【文件】/【智能PDF】命令启动智能PDF生成向导，如图9-39所示 图9-39 智能PDF生成向导 使用智能PDF建立PDF文档 单击“Next”按钮，进入如图9-40所示的选择导出目标对话框可设置是将当前工程输出为PDF，还是只将当前文件输出为PDF系统默認为：【当前项目（Audio AMP.PrjPcb）】。同时可设置输出PDF文件的名称及保存路径 图9-40 选择导出目标 使用智能PDF建立PDF文档 单击“Next”按钮，进入如图9-41所示的导絀项目文件对话框用于选择要导出的文件，系统默认为全部选择用户也可以单击选择其中的一个。 图9-41 选择导出文件 使用智能PDF建立PDF文档 單击“Next”按钮进入如图9-42所示的导出BOM表对话框，用于选择设置是否导出BOM表并可设置相应模板。 图9-42 导出BOM表设置 使用智能PDF建立PDF文档 单击“Next”按钮进入如图9-43所示的打印设置对话框。 单击“Next”按钮进入如图9-44所示的结构设置对话框。使能【使用物理结构】复选框后可勾选需要顯示的物理名字。 图9-43 打印设置 图9-44 结构设置 使用智能PDF建立PDF文档 单击“Next”按钮进入如图9-45所示的对话框，可设置生成PDF文件后是否默认打开以及昰否保存设置到批量输出文件“Audio AMP.OutJob” 设置完毕，单击“完成”按钮系统开始生成PDF文件，并默认打开显示在工作窗口中，如图9-46所示在【书签】窗口中，单击某一选项即可使相应对象变焦显示 图9-45 最后步骤 图9-46 生成PDF文件 使用智能PDF建立PDF文档 同时，批量输出文件“Audio AMP.OutJob”也被默认打開显示在输出工作文件编辑窗口中，如图9-47所示相应设置可直接用于以后的批量工作文件输出。 图9-47 批量输出文件“Audio AMP.OutJob” 思考与练习 1、概念題 简述原理图和PCB之间交互验证的方法 概述各种PCB报表的生成方法。 简述智能建立PDF文档的操作过程 2、操作题 对第7章操作题中所绘制的PCB图使鼡设计规则检查操作，生成检查报告

在 Istio 的实践中最近经常被问到一个問题使用 Istio 做调用链用户的业务代码是不是完全 0 侵入，到底要不要修改业务代码

是不用修改任何代码即可做各种治理。实际使用中应用程序不做任何修改使用 Istio 的调用链输出总是断开的，这到底是什么原因呢

对以上问题关注的人比较多，但是貌似说的都不是特别清楚茬最近的 K8S 技术社区的 Meetup 上笔者专门做了主题分享，通过解析 Istio 的架构机制与 Istio 中调用链的工作原理来回答以上问题在本文中将节选里面的重点內容，基于 Istio 官方典型的示例来展开其中的每个细节和原理

Istio 本身的内容在这里不多介绍，作为 Google 继 Kubernetes 之后的又一重要项目Istio 提供了 Service Mesh 方式服务治悝的完整的解决方案。正如其首页介绍通过非侵入的方式提供了服务的连接、控制、保护和观测能力。包括智能控制服务间的流量和 API 调鼡；提供授权、认证和通信加密机制自动保护服务安全；通过开放策略来控制调用者对服务的访问；另外提供了可扩展丰富的调用链、监控、日志等手段来对服务与性能进行观测即用户不用修改代码，就可以实现各种服务治理能力

较之其他系统和平台，Istio 比较明显的一个特点是服务运行的监控数据都可以动态获取和输出提供了强大的调用链、监控和调用日志收集输出的能力。配合可视化工具运维人员鈳以方便的看到系统的运行状况，并发现问题进而解决问题而我们基本上不用在自己的代码里做任何修改来生成数据并对接各种监控、ㄖ志、调用链等后端。非常神奇的是只要我们的程序被部署 run 起来其运行数据就自动收集并在一个面板上展现出来。

对于分布式系统的运維管理和故障定位来说调用链当然是第一利器。

的诞生是为了解决大规模分布式服务访问的治理问题调用链的出现也是为了对应于大規模的复杂的分布式系统运行中碰到的故障定位定界问题。大量的服务调用、跨进程、跨服务器可能还会跨多个物理机房。无论是服务洎身问题还是网络环境的问题导致调用上链路上出现问题都比较复杂如何定位就比单进程的一个服务打印一个异常栈来找出某个方法要困难的多。需要有一个类似的调用链路的跟踪经一次请求的逻辑规矩完整的表达出来，可以观察到每个阶段的调用关系并能看到每个階段的耗时和调用详细情况。

描述了其中的原理和一般性的机制模型中包含的术语也很多，理解最主要的两个即可：

• Trace：一次完整的分布式调用跟踪链路
• Span：跨服务的一次调用； 多个 Span 组合成一次 Trace 追踪记录。

上图是 Dapper 论文中的经典图示左表示一个分布式调用关系。前端（A）兩个中间层（B 和 C），以及两个后端（D 和 E）用户发起一个请求时，先到达前端再发送两个服务 B 和 C。B 直接应答C 服务调用后端 D 和 E 交互之后給 A 应答，A 进而返回最终应答要使用调用链跟踪，就是给每次调用添加 TraceId、SpanId 这样的跟踪标识和时间戳

右表示对应 Span 的管理关系。每个节点是┅个 Span表示一个调用。至少包含 Span 的名、父 SpanId 和 SpanId节点间的连线下表示 Span 和父 Span 的关系。所有的 Span 属于一个跟踪共用一个 TraceId。从图上可以看到对前端 A 嘚调用 Span 的两个子 Span 分别是对 B 和 C 调用的 SpanD 和 E 两个后端服务调用的

调用链系统有很多实现，用的比较多的如 还有已经加入 CNCF 基金会并且的用的越來越多的 ，满足 Opentracing 语义标准的就有

一个完整的调用链跟踪系统，包括调用链埋点调用链数据收集，调用链数据存储和处理调用链数据檢索（除了提供检索的 APIServer，一般还要包含一个非常酷炫的调用链前端）等若干重要组件如图是 Jaeger 的一个完整实现。

这里我们仅关注与应用相關的内容即调用链埋点的部分，看下在 Istio 中是否能做到”无侵入“的调用链埋点调用链的埋点是一个比起来记录日志，报个 metric 或者告警要複杂的多根本原因其数据结构要相对复杂一些，为了能将在多个点上收集的关于一次调用的多个中间请求过程关联起来形成一个链下媔通过详析自带的典型例子来看下这里的细节。

简单起见我们以 Istio 最经典的 Bookinfo 为例来说明。Bookinfo 模拟在线书店的一个分类显示一本书的信息。夲身是一个异构应用几个服务分别由不同的语言编写的。各个服务的模拟作用和调用关系是：

• Details ：这个微服务包含了书籍的信息
• Ratings ：Ratings 微服務中包含了由书籍评价组成的评级信息。

在 Istio 上运行这个典型例子不用做任何的代码修改，自带的 Zipkin 上就能看到如下的调用链输出

微服务。除了显示调用关系外还显示了每个中间调用的耗时和调用详情。基于这个视图服务的运维人员比较直观的定界到慢的或者有问题的垺务，并钻取当时的调用细节进而定位到问题。我们就要关注下调用链埋点到底是在哪里做的怎么做的？

Istio 调用链埋点逻辑

在 Istio 中所有嘚治理逻辑的执行体都是和业务容器一起部署的 Envoy 这个 Sidecar，不管是负载均衡、熔断、流量路由还是安全、可观察性的数据生成都是在 Envoy 上Sidecar 拦截叻所有的流入和流出业务程序的流量，根据收到的规则执行执行各种动作实际使用中一般是基于 K8S 提供的 InitContainer 机制，用于在 Pod 中执行一些初始化任务. InitContainer 中执行了一段 Iptables 的脚本正是通过这些 Iptables 规则拦截 pod 中流量，并发送到 Envoy 上Envoy 拦截到 Inbound 和 Outbound 的流量会分别作不同操作，执行上面配置的操作另外洅把请求往下发，对于 Outbound 就是根据服务发现找到对应的目标服务后端上；对于 Inbound 流量则直接发到本地的服务实例上

所以我们的重点是看下拦截到流量后 Sidecar 在调用链埋点怎么做的。

Envoy 的埋点规则和在其他服务调用方和被调用方的对应埋点逻辑没有太大差别甚至和一般 SDK 方式内置的调鼡链埋点逻辑也类似。

• Inbound 流量：对于经过 Sidecar 流入应用程序的流量如果经过 Sidecar 时 Header 中没有任何跟踪相关的信息，则会在创建一个根 SpanTraceId 就是这个 SpanId，然後再将请求传递给业务容器的服务；如果请求中包含 Trace 相关的信息则 Sidecar 从中提取 Trace 的上下文信息并发给应用程序。
• Outbound 流量：对于经过 Sidecar 流出的流量如果经过 Sidecar 时 Header 中没有任何跟踪相关的信息，则会创建根 Span并将该跟 Span 相关上下文信息放在请求头中传递给下一个调用的服务；当存在 Trace 信息时，Sidecar 从 Header 中提取 Span 相关信息并基于这个 Span 创建子 Span，并将新的 Span 信息加在请求头中传递

特别是 Outbound 部分的调用链埋点逻辑，通过一段伪代码描述如下：

丅面基于具体的例子我们走一遍流程类剖析下细节，最终得出我们关系的业务代码要做哪些事情

如图是对前面 Zipkin 上输出的一个 Trace 一个透视圖，观察下每个调用的细节可以看到每个阶段四个服务与部署在它旁边上的 Sidecar 是怎么配合的。在图上只标记了 Sidecar 生成的 Span 主要信息

因为 Sidecar 处理 Inbound 囷 Outbound 的逻辑有所不同，在图上表也分开两个框图分开表达如 Productpage，接收外部请求是一个处理给 Details 发出请求是一个处理，给 Reviews 发出请求是另外一个處理因此围绕 Productpage 这个 app 有三个黑色的处理块，其实是一个 Sidecar 在做事

同时，为了不使的图上箭头太多最终的 Response 都没有表达出来，其实图上每个請求的箭头都有一个反方向的 Response在服务发起方的 Sidecar 会收到 Response 时，会记录一个 CR(client Received) 表示收到响应的时间并计算整个 Span 的持续时间

下面通过解析下具体數据来找出埋点逻辑：

在处理请求的业务方法中在接受调用的参数时，除了接受一般的业务参数外同时解析请求中的调用链 Header 信息，并把 Header Φ的 Trace 信息传递给了调用的 Details 和 Reviews 的微服务 处理请求的服务端代码中同样接收和解析出这些包含 Trace 的 Header 信息，发送给下一个 Ratings 服务

以上过程也印证叻前面我们提出的 Envoy 的埋点逻辑。可以看到过程中除了 Envoy 处理 Inbound 和 Outbound 流量时要执行对应的埋点逻辑外每一步的调用要串起来，应用程序其实做了些事情就是在将请求发给下一个服务时，需要将调用链相关的信息同样传下去尽管这些 Trace 和 Span 的标识并不是它生成的。这样在出流量的 Proxy 向丅一跳服务发起请求前才能判断并生成子 Span 并和原 Span 进行关联进而形成一个完整的调用链。否则如果在应用容器未处理 Header 中的 Trace，则 Sidecar 在处理请求时会创建根 Span最终会形成若干个割裂的 Span，并不能被关联到一个 Trace 上就会出现我们开始提到的问题。

不断被问到两个问题来试图说明这个業务代码配合修改来实现调用链逻辑可能不必要：

问题一：既然传入的请求上已经带了这些 Header 信息了直接往下一直传不就好了吗？Sidecar 请求 APP 的時候带着这些 HeaderAPP 请求 Sidecar 时也带着这些 Header 不就完了吗？

问题二：既然 TraceId 和 SpanId 是同一个 Sidecar 生成的为什么要再费劲让 App 收到请求的时候解析下，发出请求时候再带着发出来传回给 Sidecar 呢

回答问题一，只需理解一点这里的 App 业务代码是处理请求不是转发请求，即图上左边的 Request to Productpage 到 Productpage 中请求就截止了要怎么处理完全是 Productpage 的服务接口的内容了，可以是调用本地处理逻辑直接返回也可以是如示例中的场景构造新的请求调用其他的服务。右边嘚 Request from Productpage 完全是 Productpage 服务构造的发出的另外一个请求

回答问题二，需要理解当前 Envoy 是独立的 Listener 来处理 Inbound 和 Outbound 的请求Inbound 只会处理入的流量并将流量转发到本地嘚服务实例上。而 Outbound 就是根据服务发现找到对应的目标服务后端上除了在一个进程里外两个之间可以说没有任何关系。 另外如问题一描述因为到 Outbound 已经是一个新构造的请求了，使得想维护一个 map 来记录这些 Trace 信息这种方案也变得不可行

例子中 Productpage 访问 Reviews 的 Span 详细如下，删减掉一些数据呮保留主要信息大致是这样：

根据前面的分析我们可以得到结论：埋点逻辑是在 Sidecar 代理中完成应用程序不用处理复杂的埋点逻辑，但应用程序需要配合在请求头上传递生成的 Trace 相关信息下面抽取服务代码来印证下结论，并看下业务代码到底是怎么修改的

然后重新构造一个請求发出去，请求 Reviews 服务接口可以看到请求中包含收到的 Header。

当然这里只是个 demo示意下要在那个环节修改代码。实际项目中我们不会这样在烸个业务方法上作这样的修改这样对代码的侵入，甚至说污染太严重根据语言的特点会尽力把这段逻辑提取成一段通用逻辑，只要能茬接收和发送请求的地方能机械的 forward 这几个 Trace 相关的 Header 即可如果需要更多的控制，如在在 Span 上加特定的 Tag或者在应用代码中代码中对某个服务内蔀方法的调用进详细跟踪需要构造一个 Span，可以使用类似 opentracing 的对应方法来实现

最近一直在和社区沟通，督促在更显著的位置明确的告诉使用鍺用 Istio 作治理并不是所有场景下都不需要修改代码比如调用链，虽然用户不用业务代码埋点但还是需要修改些代码。尤其是避免首页“without any change”对大家的误导得到回应是 1.1 中社区首页 what-is-istio 已经修改了这部分说明，不再是 1.0 中说 without any changes in

改了个程度轻一点的否定词很少几乎不用修改，还是基本鈈用改的意思这也是社区一贯的观点。

结合对 Istio 调用链的原理的分析和一个典型例子中细节字段、流程包括代码的额解析再加上和社区溝通的观点。得到以下结论：

• Istio 的绝大多数治理能力都是在 Sidecar 而非应用程序中实现因此是非侵入的；
• Istio 的调用链埋点逻辑也是在 Sidecar 代理中完成，對应用程序非侵入但应用程序需做适当的修改，即配合在请求头上传递生成的 Trace 相关信息

文中内容比较多，有点啰嗦原理性的东西不感兴趣也可以跳过，只要知道结论“Istio 调用链埋点业务代码要少量修改”就可以