操作视频如下：需要依赖的软件：>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>以上工具已经下载好了，下载链接如下：链接： https://share.weiyun.com/5GBLw90 （密码：TQ7E）另外microsoft.net framework如果没有安装或者版本不到4.5.2可能需要安装microsoft.net framework 4.5.2.exe1、gcc-arm-none-eabi-4_9-2015q3-20150921-win32.exe安装多次next后，提示如下，添加到系统环境变量中，勾选上然后一路next就安装好了，然后确认GCC是否安装成功，以及版本确认2、python-2.7.10.amd64.msi（我的电脑是win 7 64位，对应选择amd64）建议选择默认路径建议添加到系统环境变量中，选择添加确认python版本，注意要python2.7的3、pywin32-220.win-amd64-py2.7.exe安装4、python相关的pip安装5、scons-2.4.0-amd64-setup安装，对应系统32/64位选择会提示python的目录，注意对应python2.7安装（我这里是安装了多个python版本）：6、找到SDK压缩包，解压如下：对应python2.7/scons安装路径修改socns_nws.bat的路径，如下编译一个新工程，直接运行scons_new.bat，可以直接拖拽近cmd：编译成功：编译完后是在…\BC28_OpenCPU_Hi1_SDK_V1.0\build_scons\arm\目录下有一个***.bin的文件需要将.bin的文件和原始fwpkg固件文件进行合成，这里就需要用到海思的另外一个工具，下面安装另外一个工具7、安装UpdatePackage-3.22.0.14.msi，双击安装8、执行"C:\Program Files(x86)\Neul\UpdatePackage\UpdatePackage.exe" updateApplication --in.\fwpkg\BC28JAR01A07.fwpkg --folder .\build_scons\arm --out BC28JAR01A07_OCN1命名可修改生成可下载的fwpkg升级文件下载工具，确认版本和IMEI号，加载版本点击Dowanload

之前的问题自己操作失误，ps: 发现python SDK 的一个包（dto）放在demo下面了将下图的dto放入SDK 的client下即可

CSE JAVA SDK使用service_description.version定义版本号， 目前推荐支持如下规则：x.y.z或者a.b.c.d其中x/y/z/a/b/c/d都是一个int值（short），不能超过2个字节（注意不是4个字节）的数字大小。 关于版本规则的特殊说明CSE JAVA SDK的版本号必须采用数字，而不能使用字符等特殊字符。 因为这个版本号，不是传统意义上的版本管理的概念，用于表达一些版本逻辑，比如主要、次要、补丁等。 CSE的版本号主要用于表达“接口兼容”性概念， 版本号变化表示可能存在接口变更。 在处理路由规则的时候，会基于契约和版本号进行分组，将兼容的接口分为一组，从而实现多版本并存和自动基于接口兼容性进行请求转发。 这个特性是CSE JAVA SDK非常独特的特性，优雅的解决了灰度版本并存的问题，而不需要用户做任何额外的开发。 关于接口兼容性的一些推荐实践参考：https://huaweicse.github.io/cse-java-chassis-doc/question-and-answer/interface-compatibility.html

CSE JAVA SDK使用vertx的HTTP实现，支持客户端TLS和服务端TLS。 使用openssl 加上配置项：   ssl.engine: openssl即可。 文档参考:  https://docs.servicecomb.io/java-chassis/zh_CN/security/tls.html

某业务出现一个奇怪的消息，一个接口的调用始终超时， 错误消息为：The timeout period of 60000ms has been exceeded while executing POST /rest/csbmessagecenterservice/v1/config/email/test-email-config for host 172.16.1.186, server is rest://172.16.1.186:8443?sslEnabled=true详细日志中有如下内容，表示配置了重试，重试也是失败。用户使用postman直接请求，调用不会超时，而使用测试工具系统请求，则会超时。 一时不知道为什么。[2019-01-22 06:16:25:638] [ERROR] - [transport-vert.x-eventloop-thread-18] [org.apache.servicecomb.transport.rest.client.http.RestClientInvocation.lambda$invoke$0(RestClientInvocation.java:104)] - Failed to send request to /172.16.1.186:8443.io.vertx.core.http.impl.HttpClientRequestBase$1: The timeout period of 60000ms has been exceeded while executing POST /rest/csbmessagecenterservice/v1/config/email/test-email-config for host 172.16.1.186[2019-01-22 06:16:25:638] [ERROR] - [transport-vert.x-eventloop-thread-18] [org.apache.servicecomb.loadbalance.LoadbalanceHandler$4.lambda$null$0(LoadbalanceHandler.java:369)] - service CONSUMER rest CSBMessageCenterService.ApiMessageConfigResource.testEmailConfig, call error, msg is cause:InvocationException,message:InvocationException: code=490;msg=CommonExceptionData [message=Cse Internal Bad Request];cause:,message:The timeout period of 60000ms has been exceeded while executing POST /rest/csbmessagecenterservice/v1/config/email/test-email-config for host 172.16.1.186, server is rest://172.16.1.186:8443?sslEnabled=true[2019-01-22 06:16:25:639] [ERROR] - [transport-vert.x-eventloop-thread-18] [org.apache.servicecomb.loadbalance.LoadbalanceHandler$3.onExceptionWithServer(LoadbalanceHandler.java:294)] - Invoke server failed. Operation CONSUMER rest CSBMessageCenterService.ApiMessageConfigResource.testEmailConfig; server rest://172.16.1.186:8443?sslEnabled=true; 0-0 msg cause:InvocationException,message:InvocationException: code=490;msg=CommonExceptionData [message=Cse Internal Bad Request];cause:,message:The timeout period of 60000ms has been exceeded while executing POST /rest/csbmessagecenterservice/v1/config/email/test-email-config for host 172.16.1.186[2019-01-22 06:16:25:639] [ERROR] - [transport-vert.x-eventloop-thread-18] [org.apache.servicecomb.loadbalance.LoadbalanceHandler$3.onExecutionFailed(LoadbalanceHandler.java:322)] - Invoke all server failed. Operation CONSUMER rest CSBMessageCenterService.ApiMessageConfigResource.testEmailConfig, e=cause:InvocationException,message:InvocationException: code=490;msg=CommonExceptionData [message=Cse Internal Bad Request];cause:,message:The timeout period of 60000ms has been exceeded while executing POST /rest/csbmessagecenterservice/v1/config/email/test-email-config for host 172.16.1.186超时问题一般通过日志看不出根本原因。 建议业务先做了如下排查：查看服务端的access log，看是否有接受到请求；弄清楚问题出现的环节。 查看下打印超时日志的的服务的access log， 将调用目标服务的其他接口的访问情况观察看，看是一个接口超时还是所有接口都超时。通过日志看，很多接口都有超时，但也并不是每次都超时，只是有些请求超时。 一时找不到原因。 无赖只好自己把所有日志都拉出来，重新排查了一遍，最后发现业务开发者在排查第1步的都是搞漏了。 业务接口在某种输入情况下，处理时间超过8分钟，而access log是在业务处理完毕后打印的，包日志看漏了。 contract:172.16.3.8 - - - - [22/Jan/2019:03:26:16 +0000] "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" 400 72 8172.16.3.8 - - - - [22/Jan/2019:03:33:07 +0000] "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" 500 62 481105172.16.3.8 - - - - [22/Jan/2019:03:34:48 +0000] "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" 500 62 481116172.16.3.8 - - - - [22/Jan/2019:03:40:17 +0000] "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" 400 72 8172.16.3.8 - - - - [22/Jan/2019:03:41:44 +0000] "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" 400 72 7172.16.3.8 - - - - [22/Jan/2019:03:42:42 +0000] "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" 400 72 8edge:172.16.3.1 - 2019-01-22 03:25:06,271 "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" - 490 38 60003 809168370546  -- 业务22/Jan/2019:03:33:07返回，超过8分钟172.16.3.1 - 2019-01-22 03:26:16,297 "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" - 400 61 13 5c468d580e692bee172.16.3.1 - 2019-01-22 03:26:47,616 "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" - 490 38 60002 180593684930 -- 业务22/Jan/2019:03:34:48返回，超过8分钟172.16.3.1 - 2019-01-22 03:40:17,559 "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" - 400 61 12 5c4690a18978dcfe172.16.3.1 - 2019-01-22 03:41:44,823 "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" - 400 61 11 180593684930172.16.3.1 - 2019-01-22 03:42:42,757 "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" - 400 61 12 180593684930为了让超时问题更好的得到定位，建议开发者每个服务都打开access log，便于分析。 对于性能问题，可能还需要打开metrics日志，分析瓶颈点。 

系统性问题：1.      整体服务架构和规模摸底a.       对服务规模（微服务数量，每个微服务的实例数，每个微服务的schema个数等）需要进行一定的评估，如果微服务总接口数非常多，并且所有服务的请求都经过Edge Service转发，建议Edge Service等需要调用大量其他服务的消费者设置较大的的JAVA metaspace空间， -XX:MaxMetaspaceSize=512m。 一个微服务接口数量太多还有个问题就是服务第一次被访问的时候，加载会比较慢。 对于对一次访问有明显要求的业务，可以考虑预加载提升访问速度。 2.       业务线程池配置a.       CSE提供的两个配置项servicecomb.rest.server.thread-count和servicecomb.rest.client.thread-count并不是业务线程池配置。这两个参数不需要配置的特别大，一般等于CPU核数即可，建议配置为8~16之间。b.      对于tomcat场景，以及Edge Service的vert.x场景，都有一个业务处理线程池(Edge Service的场景默认在reactive模式，是没有业务线程池的)。CSE设置的默认线程池的线程个数为2 * CPU个数。如果部分服务处理比较慢（比如评价时延>50ms），那么建议要设置一个较大的业务线程池，以提升吞吐量。如果所有接口都处理的很快，则不需要设置非常大的业务线程池，过多线程反而会因为线程调度，增加处理时延。如果一个微服务，有少量的几个接口处理非常耗时，需要考虑将这些接口放到独立的线程池执行（线程池隔离），防止访问慢的接口，影响访问快的接口。 3.       运维参数和建议a.       设置合理的超时时间。超时时间设置不能够小于3秒，即使业务处理时间都非常小（比如小于1ms）b.      打开metrics，用于分析性能瓶颈，并将日志输出到独立的日志文件c.       打开access logd.      对接APM的调用链，增强问题快速定界能力  4.       开发效率提升开发效率提升需要把一些准备工作放到平时，每个微服务尽可能梳理出本微服务对外的依赖关系，通过在本地安装依赖服务（或者提供模拟桩），实现在开发环境调试和验证微服务基本功能。这样能够大大提高开发效率，同时提升软件质量。 5.       SSL性能风险SSL在高并发、频繁断连重连的情况下，可能出现内存高、性能慢的情况。SSL协议慢是已知问题，并没有解决方案，对于对于时延要求很高，频繁超时、短连接，并发特别高等场景，不适合使用HTTPS。 目前有些产品的具体做法：1. 内部通讯使用HTTP；接入层使用HTTPS；2. 使用和验证HTTP2协议，降低连接数和连接重建。 这个可以纳入后续规划，以应对可能的用户增长问题。  开发常见错误：1.       业务中常驻线程或者定时任务的保护。 常驻线程或者定时任务的Task跑出异常， 会导致这些任务不再被调度执行。如果存在这种场景，一定要通过catch Throwable保证线程的可靠性。 可以通过通用的ThreadFactory创建线程实现，详细参考这个问题修改代码。2.       使用vert.x异步HttpClient一定需要注意设置如下几个异常处理器，保证异常的时候，异步回调能够正常执行。这类逻辑再CBC的Edge网关等场景也有使用，建议也排查下。a.       request.exceptionHandlerb.      response.exceptionHandler  --- 这个特别容易遗漏c.       response.bodyHandler3.       程序故障保护和运维方面的一些问题，保护错误，能够让程序在一些故障场景下能够有更好的适应性，但是实际上也会隐含的一层意思“业务故障可能被推迟发现”。 如果没有良好的运维机制，那么故障还是随着问题积累，慢慢的被发现。虽然从软件角度来讲，这个可以提高SLA的水平，是正向的，但是我们还是需要有一定的机制，能够先于用户发现问题。4.       Tomcat超时问题：maxKeepAliveRequests修改为-1， keepAliveTimeout建议是客户端的2倍5.       使用环境变量指定SC地址问题(以及其他需要使用yaml中的List类型情况）：需要测试下配置两个IP地址的情况下，如果一个地址失败，是否访问第二个地址。案例参考： https://bbs.huaweicloud.com/forum/thread-13404-1-1.html

gradle 需要被镜像的地址 如下 https://services.gradle.org/distributions/就是镜像 gradle安装包的仓库,类似已经有的java sdk镜像Android开发 项目工程里gradle-wrapper.properties 文件用到的谢谢!ps. 感谢提供的众多镜像!

CSE JAVA SDK Maven 仓库地址早期做过一次变更，最新迁移到华为云了。         <repository>             <id>HuaweiCloudSDK</id>             <url>https://mirrors.huaweicloud.com/repository/maven/huaweicloudsdk/</url>             <releases>                 <enabled>true</enabled>             </releases>             <snapshots>                 <enabled>false</enabled>             </snapshots>         </repository>详细配置参考： https://support.huaweicloud.com/devg-cse/cse_03_summary.html

背景信息CSE Java SDK的开源部分ServiceComb项目已于2017年12月全票通过进入Apache孵化器，根据Apache软件基金会要求，项目groupId统一由io.servicecomb调整为org.apache.servicecomb。CSE Java SDK作为ServiceComb的商业版本，除提供对接华为公有云的能力、安全、分布式数据一致性等商业能力外，其大部分组件来自于开源的ServiceComb。因此提供本指导用于支持客户顺利升级至包名变更后的CSE Java SDK版本（2.3.3+）。更改说明CSE Java SDK版本（2.3.3+）中涉及包名变化情况如下：序号包名称groupId（修改前）groupId（修改后）变化类型1CSE Java-SDK开源包65个包名变更，详见CSE Java SDK开源包列表io.servicecomborg.apache.servicecomb修改2CSE Java-SDK开源包foundation-config-cc新增config-cc，groupId为org.apache.servicecomb新增3CSE Java-SDK商业包foundation-config-cc移除foundation-config-cc删除4CSE Java-SDK商业包共计13个，详见CSE Java SDK商业包列表com.huawei.paas.cse无变化操作步骤通过配置maven setting文件以获取SDK依赖。profiles中增加如下配置。<profile>     <id>nexusProfile</id>     <repositories>         <repository>             <id>cse1</id>             <url>http://maven.huaweicse.com/nexus/content/groups/public/</url>         </repository>     </repositories> </profile>新增activeProfiles配置。<activeProfiles>     <activeProfile>nexusProfile</activeProfile> </activeProfiles>引入dependencyManagement，建议开发者在pom.xml中进行如下配置以便更好的管理三方件。 说明：版本使用2.3.3以上版本。<dependencyManagement>     <dependencies>         <dependency>             <groupId>com.huawei.paas.cse</groupId>             <artifactId>cse-dependency</artifactId>             <version>2.3.58</version>             <type>pom</type>             <scope>import</scope>         </dependency>     </dependencies> </dependencyManagement>修改pom.xml中依赖包的groupid。此处仅以引入对spring-boot-starter-provider、cse-solution-service-engine、foundation-auth的依赖为例。修改前<dependency>     <groupId>io.servicecomb</groupId>     <artifactId>spring-boot-starter-provider</artifactId> </dependency> <dependency>     <groupId>com.huawei.paas.cse</groupId>     <artifactId>cse-solution-service-engine</artifactId> </dependency> <dependency>     <groupId>com.huawei.paas.cse</groupId>     <artifactId>foundation-auth</artifactId>     <exclusions>         <exclusion>             <groupId>org.slf4j</groupId>             <artifactId>slf4j-log4j12</artifactId>         </exclusion>     </exclusions> </dependency>修改后<dependency>     <groupId>org.apache.servicecomb</groupId>     <artifactId>spring-boot-starter-provider</artifactId> </dependency> <dependency>     <groupId>com.huawei.paas.cse</groupId>     <artifactId>cse-solution-service-engine</artifactId> </dependency> <dependency>     <groupId>com.huawei.paas.cse</groupId>     <artifactId>foundation-auth</artifactId>     <exclusions>         <exclusion>             <groupId>org.slf4j</groupId>             <artifactId>slf4j-log4j12</artifactId>         </exclusion>     </exclusions> </dependency>CSE Java SDK开源包列表序号artifactIdgroupid（修改前）groupid（修改后）1common-javassistio.servicecomborg.apache.servicecomb2common-protobufio.servicecomborg.apache.servicecomb3common-restio.servicecomborg.apache.servicecomb4commonio.servicecomborg.apache.servicecomb5config-apolloio.servicecomborg.apache.servicecomb6dynamic-configio.servicecomborg.apache.servicecomb7edge-coreio.servicecomborg.apache.servicecomb8edgeio.servicecomborg.apache.servicecomb9foundation-commonio.servicecomborg.apache.servicecomb10config-ccio.servicecomborg.apache.servicecomb11foundation-configio.servicecomborg.apache.servicecomb12foundation-metricsio.servicecomborg.apache.servicecomb13foundation-sslio.servicecomborg.apache.servicecomb14foundation-test-scaffoldingio.servicecomborg.apache.servicecomb15foundation-vertxio.servicecomborg.apache.servicecomb16foundationsio.servicecomborg.apache.servicecomb17handler-bizkeeperio.servicecomborg.apache.servicecomb18handler-flowcontrol-qpsio.servicecomborg.apache.servicecomb19handler-loadbalanceio.servicecomborg.apache.servicecomb20handler-publickey-authio.servicecomborg.apache.servicecomb21handler-tracing-zipkinio.servicecomborg.apache.servicecomb22handlersio.servicecomborg.apache.servicecomb23java-chassis-coreio.servicecomborg.apache.servicecomb24java-chassis-dependenciesio.servicecomborg.apache.servicecomb25java-chassis-parentio.servicecomborg.apache.servicecomb26java-chassisio.servicecomborg.apache.servicecomb27metrics-commonio.servicecomborg.apache.servicecomb28metrics-coreio.servicecomborg.apache.servicecomb29metrics-extensionio.servicecomborg.apache.servicecomb30metrics-integrationio.servicecomborg.apache.servicecomb31metrics-prometheusio.servicecomborg.apache.servicecomb32metricsio.servicecomborg.apache.servicecomb33provider-jaxrsio.servicecomborg.apache.servicecomb34provider-pojoio.servicecomborg.apache.servicecomb35provider-rest-commonio.servicecomborg.apache.servicecomb36provider-springmvcio.servicecomborg.apache.servicecomb37providersio.servicecomborg.apache.servicecomb38service-registryio.servicecomborg.apache.servicecomb39spring-boot-starter-configurationio.servicecomborg.apache.servicecomb40spring-boot-starter-discoveryio.servicecomborg.apache.servicecomb41spring-boot-starter-parentio.servicecomborg.apache.servicecomb42spring-boot-starter-providerio.servicecomborg.apache.servicecomb43spring-boot-starter-registryio.servicecomborg.apache.servicecomb44spring-boot-starter-servicecombio.servicecomborg.apache.servicecomb45spring-boot-starter-transportio.servicecomborg.apache.servicecomb46spring-cloud-zuul-zipkinio.servicecomborg.apache.servicecomb47spring-cloud-zuulio.servicecomborg.apache.servicecomb48swagger-generator-coreio.servicecomborg.apache.servicecomb49swagger-generator-jaxrsio.servicecomborg.apache.servicecomb50swagger-generator-springmvcio.servicecomborg.apache.servicecomb51swagger-generatorio.servicecomborg.apache.servicecomb52swagger-invocation-coreio.servicecomborg.apache.servicecomb53swagger-invocation-jaxrsio.servicecomborg.apache.servicecomb54swagger-invocation-springmvcio.servicecomborg.apache.servicecomb55swagger-invocationio.servicecomborg.apache.servicecomb56swaggerio.servicecomborg.apache.servicecomb57tracing-commonio.servicecomborg.apache.servicecomb58tracing-zipkinio.servicecomborg.apache.servicecomb59tracingio.servicecomborg.apache.servicecomb60transport-highwayio.servicecomborg.apache.servicecomb61transport-rest-clientio.servicecomborg.apache.servicecomb62transport-rest-servletio.servicecomborg.apache.servicecomb63transport-rest-vertxio.servicecomborg.apache.servicecomb64transport-restio.servicecomborg.apache.servicecomb65transportsio.servicecomborg.apache.servicecombCSE Java SDK商业包列表增删说明序号artifactIdgroupid（不涉及修改）1foundation-config-cc已迁移至ServiceCombCSE Java-SDK商业包列表序号artifactIdgroupid（不涉及修改）1cse-adapter-springmvccom.huawei.paas.cse2cse-dependencycom.huawei.paas.cse3cse-handler-2pccom.huawei.paas.cse4cse-handler-cloud-extensioncom.huawei.paas.cse5cse-handler-performance-statscom.huawei.paas.cse6cse-handler-tcccom.huawei.paas.cse7cse-handler-tracing-apmcom.huawei.paas.cse8cse-handler-tracingcom.huawei.paas.cse9cse-narayanacom.huawei.paas.cse10cse-solution-service-enginecom.huawei.paas.cse11cse-solutionscom.huawei.paas.cse12foundation-authcom.huawei.paas.cse13paas-csecom.huawei.paas.cse

一路走过来终于把如何使用php sdk梳理好了，我把期间遇到的问题列出来，希望以后的人不会走弯路。1、背景我已经按步骤设置了转码模板，选择的是hls和2.64的模式用于加密；同时上传了视频，同时转码成功了；最后我设置好了防盗链的白名单和加密设置里面的秘钥url。我先后设置了两个域名www.a.com、www.b.com。2、坑第一、由于需求，需要将a域名改为b域名，同时将ab两个域名加入了防盗链，于是乎我就将获取秘钥的url从www.a.com改为www.b.com，在此情况下，奇怪的事情，我点击现在域名下面的播放链接在手机上能播放，但是我b域名下的里程序并没有将key写进存放key的文件里。 查找过程，将播放页面视频放入pc的web上查看网络连接，发现视频请求秘钥的链接还是请求的a域名的秘钥地址，经过漫长的寻觅，终于发现原来上传视频转码时已经将秘钥地址写入了m3u8，因此，我又重新设置了当前b域名下的秘钥地址，并重新上传转码，在查看网络请求时已经改为了b域名下的秘钥地址，所以一定要注意，一旦更改了获取秘钥的地址，一定要重新上传转码一次才能正常请求。第二、在设置防盗链时的白名单和空referer时给了我极大的困扰，点击后面的灰色问号，显示的是https能访问，并没有提http可以访问，在此情况下，我先后将域名加了证书，发现加证书的访问不能进行，而http是可以访问成功播放的。这里我总结的是，https应该是可以访问的，前提是你要设置好自己服务器的443端口的访问以及各种配置和转码都要是https统一才行，我采用的方法是都没有采用https，统一为http能成功，我们在理解华为云的文档时要注意了，希望以后能更明确一些。第三，在开发之前，我始终没有理解到我们在系统中设置的获取秘钥key是什么时候可以调用，通过我在pc端查看请求时才知道，js会根据请求的m3u8去解析里面的秘钥地址，会带上token一直请求直到请求成功这个地址，在这这里租户系统可以获取这个token进行验证。

本文整理自华为Cloud BU技术专家在K8S技术社上关于Istio调用链的分享。前言大家好，我是idouba，来自华为Cloud BU，当前在做Istio服务网格在华为云容器服务的产品化工作。今天跟大家分享的主题是Istio调用链相关内容。通过剖析Istio的架构机制与Istio中调用链的工作原理来解答一个大家经常问道的一个问题：Istio是否像其官方文档中宣传的一样，对业务代码完全的无侵入，无需用做任何修改就可以完成所有的治理能力，包括调用链的埋点？关于这个问题，可以提前透漏下，答案是让人有点沮丧的，得改点。在Isito中你不用在自己的代码里使用各种埋点的SDK来做埋点的逻辑，但是必须要有适当的配合的修改。为什么本来无侵入的Service Mesh形态的技术却要求我们开发者修改些代码，到底要做哪些修改？Istio中调用链到底是怎么工作的？在下面的内容中将逐个回答这些问题。本次分享的主题包括两部分: 第一部分作为背景和基础，介绍Istio的架构和机制；第二部分将重点介绍Istio调用链的相关内容，解答前面提出的几个问题。Isito的架构和机制Service Mesh如官方介绍，Istio是一个用于连接、控制、保护和观测服务的一个开放平台。即：智能控制服务间的流量和API调用；提供授权、认证和通信加密机制自动保护服务安全；并使用各种策略来控制调用者对服务的访问；另外可以扩展丰富的调用链、监控、日志等手段来对服务的与性能进行观测。Istio是Google继Kubernetes之后的又一重要项目，提供了Service Mesh方式服务治理的完整的解决方案。2017年5月发布第一个版本 0.1， 2018年6月1日发布了0.8版本，第一个LTS版本，当前在使用的1.0版本是今年7.31发布，对外宣传可用于生产。最新的1.1版本将2018.11中旬最近发布(当时规划实际已延迟，作者注)。Istio属于Service Mesh的一种实现。通过一张典型图来了解下Service Mesh。如图示深色是Proxy，浅色的是服务，所有流入流出服务的都通过Proxy。Service Mesh正是由这一组轻量代理组成，和应用程序部署在一起，但是应用程序感知不到他的存在。特别对于云原生应用，服务间的应用访问拓扑都比较复杂，可以通过Service Mesh来保证服务间的调用请求在可靠、安全的传递。在实现上一般会有一个统一的控制面，对这些代理有个统一的管理，所有的代理都接入一个控制面。对代理进行生命期管理和统一的治理规则的配置。这里是对Service Mesh特点的一个一般性描述，后面结合Isito的架构和机制可以看下在Istio中对应的实现。可以看到Service Mesh最核心的特点是在Proxy中实现治理逻辑，从而做到应用程序无感知。其实这个形态也是经过一个演变的过程的：最早的治理逻辑直接由业务代码开发人员设计和实现，对服务间的访问进行管理，在代码里其实也不分治理和业务，治理本身就是业务的一部分。这种形态的缺点非常明显就是业务代码和治理的耦合，同时公共的治理逻辑有大量的重复。很容易想到封装一个公共库，就是所谓的SDK，使用特定的SDK开发业务，则所有治理能力就内置了。Spring Cloud和Netflix都是此类的工具，使用比较广泛，除了治理能力外，SDK本身是个开发框架，基于一个语言统一、风格统一的开发框架开发新的项目非常好用。但这种形态语言相关，当前Java版本的SDK比较多。另外对于开发人员有一定的学习成本，必须熟悉这个SDK才能基于他开发。最重要的是推动已经在用的成熟的系统使用SDK重写下也不是个容易的事情。比如我们客户中就有用C开发的系统，运行稳定，基本不可能重写。对这类服务的治理就需要一个服务外面的治理方式。于是考虑是否可以继续封装，将治理能力提到进程外面来，作为独立进程。即Sidecar方式，也就是广泛关注的Service Mesh 的。真正可以做到对业务代码和进程0侵入，这对于原来的系统完全不用改造，直接使用Sidecar进行治理。用一段伪代码来表示以上形态的演变：可以看到随着封装越来越加强，从公共库级别，到进程级别。对业务的侵入越来越少，SDK的公共库从业务代码中解耦，Sidecar方式直接从业务进程解耦了。对应的治理位置越来越低，即生效的位置更加基础了。尤其是Service Mesh方式下面访问通过 Proxy执行治理，所以Service Mesh的方式也已被称为一种应用的基础设施层，和TCP/IP的协议栈一样。TCP/IP负责将字节流可靠地在网络节点间传递；而应用基础设施则保证服务间的请求在安全、可靠、可被管控的传递。这也对应了前面Istio作为Service Mesh一种实现的定位。Istio 关键能力Istio官方介绍自己的关键能力如上所示，我把它分为两部分：一部分是功能，另有一部分提供的扩展能力。功能上包括流量管理、策略执行、安全和可观察性。也正好应对了首页的连接、保护、控制和观测四大功能。流量管理：是Istio中最常用的功能。可以通过配置规则和访问路由，来控制服务间的流量和API调用。从而实现负载均衡、熔断、故障注入、重试、重定向等服务治理功能，并且可以通过配置流量规则来对将流量切分到不同版本上从而实现灰度发布的流程。策略执行：指Istio支持支持访问控制、速率限制、配额管理的能力。这些能力都是通过可动态**的策略控制后端实现。安全：Istio提供的底层的安全通道、管理服务通信的认证、授权，使得开发任务只用关注业务代码中的安全相关即可。可观察性：较之其他系统和平台，Istio比较明显的一个特点是服务运行的监控数据都可以动态获取和输出，提供了强大的调用链、监控和调用日志收集输出的能力。配合可视化工具，运维人员可以方便的看到系统的运行状况，并发现问题进而解决问题。我们这次分享的主题调用链也正是Isito可观察性的一个核心能力。后面分析可以看到以上四个特性从管理面看，正好对应Istio的三个重要组件。扩展性：主要是指Istio从系统设计上对运行平台、交互的相关系统都尽可能的解耦，可扩展。这里列出的特性：平台支持：指Istio可以部署在各种环境上，支持Kubernetes、Consul等上部署的服务，在之前版本上还支持注册到Eureka上的Service，新版本对Eureka的支持被拿掉了；集成和定制：指的Istio可以动态的对接各种如访问控制、配额管理等策略执行的后端和日志监控等客观性的后端。支持用户根据需要按照模板开发自己的后端方便的集成进来。其实这两个扩展性的能力正好也对应了Istio的两个核心组件Pilot和Mixer，后面Isito架构时一起看下。Istio 总体架构以上是Isito的总体架构。上面是数据面，下半部分是控制面。数据面Envoy是一个C++写的轻量代理，可以看到所有流入流出服务的流量都经过Proxy转发和处理，前面Istio中列出的所有的治理逻辑都是在Envoy上执行，正是拦截到服务访问间的流量才能进行各种治理；另外可以看到Sidecar都连到了一个统一的控制面。Istio其实专指控制面的几个服务组件：Pilot：Pilot干两个事情，一个是配置，就是前面功能介绍的智能路由和流量管理功能都是通过Pilot进行配置，并下发到Sidecar上去执行；另外一个是服务发现，可以对接不同的服务发现平台维护服务名和实例地址的关系并动态提供给Sidecar在服务请求时使用。Pilot的详细功能和机制见后面组件介绍。Mixer：Mixer是Istio中比较特殊，当前甚至有点争议的组件。前面Isito核心功能中介绍的遥测和策略执行两个大特性均是Mixer提供。而Istio官方强调的集成和定制也是Mixer提供。即可以动态的配置和开发策略执行与遥测的后端，来实现对应的功能。Mixer的详细功能和机制见后面组件介绍。Citadel：主要对应Istio核心功能中的安全部分。配合Pilot和Mixer实现秘钥和证书的管理、管理授权和审计，保证客户端和服务端的安全通信，通过内置的身份和凭证提供服务间的身份验证，并进而该通基于服务表示的策略执行。Isito主要组件Pilot如Istio架构中简介，Pilot实现服务发现和配置管理的功能。作为服务发现，Pilot中定义了一个抽象的服务模型，包括服务、服务实例、版本等。并且只定义的服务发现的接口，并未实现服务发现的功能，而是通过Adapter机制以一种可扩展的方式来集成各种不同的服务发现，并转换成Istio通用的抽象模型。 如在Kubernetes中，Pilot中的Kubernetes适配器通过Kube-APIServer服务器得到Kubernetes中对应的资源信息。而对于像Eureka这种服务注册表，则是使用一个Eureka的HTTP Client去访问Eureka的名字服务的集群，获取服务实例的列表。不管哪种方式最终都转换成Pilot的标准服务发现定义，进而通过标准接口提供给Sidecar使用。而配置管理，则是定义并维护各种的流量规则，来实现负载均衡、熔断、故障注入、流量拆分等功能。并转换成Envoy中标准格式推送给Envoy，从而实现治理功能。所有的这些功能用户均不用修改代码接口完成。详细的配置方式可以参照Istio Traffic Routing中的规则定义。重点关注：VirtualService、 DestinationRule、 Gateway等规则定义。如可以使用流量规则来配置各种灰度发布，也可以通过注入一个故障来测试故障场景；可以配置熔断来进行故障恢复；并且可以对HTTP请求根据我们的需要进行重定向、重写，重试等操作。Istio主要组件MixerMixer是Isito特有的一个组件。主要做两个功能Check和Report，分别对应Istio官方宣传的两个重大特性策略执行和遥测功能。逻辑上理解每次服务间的请求都会通过proxy连接Mixer来进行处理，由Mixer来将请求派发到对应的后端上处理。通过扩展不同的后端来增强Mixer的能力。如可以做访问控制、配额等这样的控制，也可以对接不同的监控后端来做监控数据的收集，进而提供网格运行的可观察性能力。Mixer通过使用通用插件模型实现的对接不同后端，避免了proxy为了完成不同的功能而去对接各种不同的后端。每个插件都被称为Adapter。对于每个请求Sidecar会从每一次请求中收集相关信息，如请求的路径，时间，源IP，目地服务，tracing头，日志等，并请这些属性上报给Mixer。Mixer和后端服务之间是通过适配器进行连接的，Mixer将Sidecar上报的内容通过适配器发送给后端服务。可以在不停止应用服务的情况下动态切换后台服务。除了可以通过adapter机制接入不同的后端，mixer还支持根据需要定义收集的metric，和对metric的处理方式，如样例所示，可以自定义监控指标。后面我们会看到Istio中调用链的数据也可以通过Mixer来收集。Istio和Kubernetes的天然结合尽管Isito强调自己的可扩展性的重要一点就是可以适配各种不同的平台，但实际场景上，甚至看Istio当前代码、设计可以发现其所有重要的能力都是基于Kubernetes展开的。Istio与Kubernetes结合之紧密，甚至有描述说看上去是一个团队开发的。即Istio就是基于Kubernetes之上，对Kubernetes能力的补齐。从功能场景看，Kubernetes提供了部署、升级和有限的运行流量管理能力；利用Service的机制来做服务注册和发现，转发，通过Kubeproxy有一定的转发和负载均衡能力。但是往上的如熔断、限流降级、调用链等治理能力就没有了。前面的功能介绍可以发现Istio很好的补齐了Kubernetes在服务治理上的这部分能力。即Kubernetes提供了基础服务运行能力，而Istio基于其上提供服务治理能力，对Kubernetes服务的治理能力。除了功能互补外，从形态上看Istio也是基于Kubernetes构建的。包括： Sicecar 运行在Kubernetes Pod里，作为一个Proxy和业务容器部署在一起，部署过程对用户透明。Mesh中要求业务程序的运行感知不到Sidecar的存在，基于Kubernetes的pod的设计这部分做的更彻底，对用户更透明，通过Isito的自动注入用户甚至感知不到部署Sidecar的这个过程，和部署一个一般的Deployment没有任何差别。试想如果是通过VM上部署一个Agent，不会有这么方便。另外Istio的服务发现也是非常完美基于Kubernetes的域名访问机制构建。Isito中的服务就是Kubernetes的服务，避免了之前使用独立的微服务框架在Kubernetes上运行时两套名字服务的尬尴和困惑。机制上Pilot通过在kubernetes里面注册一个controller来监听事件，从而获取Service和Kubernetes的Endpoint以及Pod的关系，并将这些映射关系转换成为Istio的统一抽象模型下发到Envoy进行转发。Istio所有的我们熟悉的路由规则、控制策略都是通过Kubernetes CRD表达，不需要一个单独的APIserver和后端的配置管理。所以Istio APIServer就是Kubernetes的KubeAPIServer，数据也当然的存在了对应Kubernetes的ETCD中。就连Istio的命令行工具Istioctl都是类似Kubectl风格的功能，提供基于命令行的配置功能。

我手上有树莓派，想知道如何接入OC平台。提交工单后，反馈sdk不提供

当有些业务处理比较耗时的时候，日志里面经常打印如下异常：2019-01-09 10:42:22,890 [ntloop-thread-0] ERROR Unhandled exception [io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:345)]java.lang.IllegalStateException: Response is closedat io.vertx.core.http.impl.HttpServerResponseImpl.checkValid(HttpServerResponseImpl.java:548)at io.vertx.core.http.impl.HttpServerResponseImpl.end0(HttpServerResponseImpl.java:401)at io.vertx.core.http.impl.HttpServerResponseImpl.end(HttpServerResponseImpl.java:319)at org.apache.servicecomb.foundation.vertx.http.VertxServerResponseToHttpServletResponse.internalFlushBuffer(VertxServerResponseToHttpServletResponse.java:122)at org.apache.servicecomb.foundation.vertx.http.VertxServerResponseToHttpServletResponse.lambda$flushBuffer$0(VertxServerResponseToHttpServletResponse.java:112)at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:339)at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:463)at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)at java.lang.Thread.run(Thread.java:745)这个异常表示的是在给请求返回结果的时候，写结果发现连接已经关闭。这种情况通常发生在业务处理比较长的情况。这个日志在服务端打印（服务端是相对的）。和这个问题相关的配置由如下几个：客户端：cse.rest.client.connection.idleTimeoutInSeconds（缺省值30s）服务端：cse.rest.server.connection.idleTimeoutInSeconds（缺省值30s）如果业务处理时间超过这两个值的最小值，那么服务端就会报告这个异常。 

CSE JAVA SDK的线程池模型比较复杂，对于tomcat场景，以及Edge Service的vert.x场景，都有一个业务处理线程池(Edge Service的场景默认在reactive模式，是没有业务线程池的)。CSE设置的默认线程池的线程个数为2 * CPU个数。如果部分服务处理比较慢（比如评价时延>50ms），那么建议要设置一个较大的业务线程池，以提升吞吐量。如果所有接口都处理的很快，则不需要设置非常大的业务线程池，过多线程反而会因为线程调度，增加处理时延。如果一个微服务，有少量的几个接口处理非常耗时，需要考虑将这些接口放到独立的线程池执行（线程池隔离），防止访问慢的接口，影响访问快的接口。     线程池配置 （可以适当的抽时间学习下线程模型： https://bbs.huaweicloud.com/blogs/0a1a862f412611e89fc57ca23e93a89f）        通过配置项servicecomb.executors.default给业务接口制定执行线程池。配置项的的缺省值为servicecomb.executor.groupThreadPool，这个值是Bean的ID，CSE缺省的几个Bean ID如下：  <bean id="cse.executor.groupThreadPool" class="org.apache.servicecomb.core.executor.FixedThreadExecutor"/>   <alias name="cse.executor.groupThreadPool" alias="cse.executor.default"/>   <alias name="cse.executor.groupThreadPool" alias="servicecomb.executor.groupThreadPool"/>   <bean id="cse.executor.reactive" class="org.apache.servicecomb.core.executor.ReactiveExecutor"/>   <alias name="cse.executor.reactive" alias="servicecomb.executor.reactive"/>  2.       通过servicecomb.executors.Provider.[servicename.schemaid.operationId]给某个具体的接口指定不同的线程池。

对于代码方面主要涉及到如下的代码：1、web端自动获取核对的秘钥接口如图这个url的主要代码结合文档可以如下，主要使用到了php的json转数组函数和base64_decode函数：<?php /**  * 查询媒资密钥  */ require './cloudvod/vod/service/AssetService.php'; require './cloudvod/vod/model/QueryAssetCiphersReq.php'; $req = new QueryAssetCiphersReq(); $req ->setAssetId('0718d0ac557e702f2cff78df3021fcf8'); $rsp = ""; try {     $rsp = AssetService::QueryAssetCiphers($req);     $rspp=json_decode($rsp->getBody());         echo base64_decode($rspp->dk); } catch (Exception $e) {     echo $e; } ?>2、前端播放器的代码，代码可以参考音视频管理-》管理，查看示例代码，直接黏贴过来：<!DOCTYPE html> <html> <head>     <meta charset="UTF-8">     <meta http-equiv="x-ua-compatible" content="chrome=1,ie=edge">     <!--[if lt IE 9]>     <script  src="http://media-cache.huaweicloud.com/video/hwplayer/0.0.6/lib/video-js-5.20.5/ie8/videojs-ie8.min.js?ttl=1828668305"></script>     <![endif]-->     <script  src="http://media-cache.huaweicloud.com/video/hwplayer/0.0.6/dist/hwplayer.js?ttl=1828668305"></script> </head> <body> <video controls id="test" width="480" height="300" class="video-js  vjs-default-skin vjs-big-play-centered"> </video> <script>     hwplayerloaded(function () {         var player = new HWPlayer("test",{             width: 480,             height: 300,             controls: true         },function(){             //播放器加载完成执行的逻辑                      });         player.src({             src: "https://613.cdn-vod.huaweicloud.com/asset/0718d0ac220exxxf2cff78df3021fcf8/play_video/11111111111111111111111111111111/add626b8dxxxx46d63498048f3cba3_1_1280X720_1500_0.m3u8",             type: "application/x-mpegURL"         });     }); </script> </body> 3、phpsdk的引入，在下载sdk解压后，为了减少require_once引入而发生错误，建议根据实际的情况将里面的相对路径改为绝对路径，改的方法很多，可以通过变量等方法。根据华为的开发文档，在init.php文件中填写自己的ak、sk、projectid。 4、以上相关的代码，是没有考虑到租户系统认证的token的代码，这个将在下一篇进行介绍。