我已经通过鉴权得到accessToken在用到其他API接口时报无效的鉴权码错误不晓得是不是appid的错误，因为appid是可选的麻烦各位大佬能不能解答一下，谢谢

本文将结合一个具体例子中的细节详细描述Istio调用链的原理和使用方式。并基于Istio中埋点的原理解释来说明：为了输出一个质量良好的调用链，业务程序需根据自身特点做适当的修改，即并非官方一直在说的完全无侵入的做各种治理。另外还会描述Istio当前版本中收集调用链数据可以通过Envoy和Mixer两种不同的方式。Istio一直强调其无侵入的服务治理，服务运行可观察性。即用户完全无需修改代码，就可以通过和业务容器一起部署的proxy来执行服务治理和与性能数据的收集。原文是这样描述的：Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, then configure and manage Istio using its control plane functionality。调用链的埋点是一个比起来记录日志，报个metric或者告警要复杂的多，根本原因是要能将在多个点上收集的关于一次调用的多个中间请求过程关联起来形成一个链。Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 描述了其中的原理和一般性的机制，还是挺复杂的。也有很多实现，用的比较多的如zipkin，和已经在CNCF基金会的用的越来越多的Jaeger，满足Opentracing语义标准的就有这么多。在Istio中大段的埋点逻辑在Sidecar中已经提供，业务代码不用调用以上这些埋点方式来创建trace，维护span等这些复杂逻辑，但是为了能真正连接成一个完整的链路，业务代码还是需要做适当修改。我们来分析下细节为什么号称不用修改代码就能搞定治理、监控等高级功能的Sidecar为什么在调用链埋点的时候需要改应用代码。调用详细服务调用关系简单期间，我们以Istio最经典的Bookinfo为例来说明。Bookinfo的4个为服务的调用关系是这样： 调用链输出从前端入口gateway那个envoy上进行一次调用，到四个不同语言开发的服务间完成调用，一次调用输出的调用链是这样：简单看下bookinfo 中的代码，能看到并没有任何创建维护span这种埋点的逻辑，想也是，对于python、java、ruby、nodejs四种不同的语言采用不同的埋点的库在来实现类似的埋点逻辑也是非常头痛的一件事情。那我们看到这个调用链信息是怎么输出的？答案当然是应用边上的sidecar Envoy，Envoy对于调用链相关设计参照这里。sidecar拦截应用程序所有的进和出的网络流量，跟踪到所有的网络请求，像Service mesh的设计理念中其他的路由策略、负载均衡等治理一样，只要拦截到流量Sidecar也可以实现埋点的逻辑。埋点逻辑对于经过sidecar流入应用程序的流量，如例子中流入roductpage， details、reviews和ratings的流量，如果经过Sidecar时header中没有任何跟踪相关的信息，则会在创建一个span，Traceid就是这个spanId，然后在将请求传递给通pod的业务服务；如果请求中包含trace相关的信息，则sidecar从走回归提取trace的上下文信息并发给应用程序。对于经过sidecar流出的流量，如例子中gateway调用productpage，或者productpage调用链details和reviews的请求。如果经过sidecar时header中没有任何跟踪相关的信息，则会创建根span，并将该跟span相关上下文信息放在请求头中传递给下一个调用的服务，当然调用前会被目标服务的sidecar拦截掉执行上面流入的逻辑；当存在trace信息时，sidecar从header中提取span相关信息，并基于这个span创建子span，并将新的span信息加在请求头中传递。以上是bookinfo一个实际的调用中在proxy上生成的span主要信息。可以看到，对于每个app访问都经过Sidecar代理，inbound的流量和outbound的流量都通过Sidecar。图上为了清楚表达每个将对Sidecar的每个处理都分开表示，如productpage，接收外部请求是一个处理，给details发出请求是一个处理，给reviews发出请求是另外一个处理，因此围绕Productpage这个app有三个黑色的处理块，其实是一个Sidecar。为了不使的图上太凌乱，最终的Response都没有表示。其实图上每个请求的箭头都有一个反方向的response，在服务发起方的Sidecar会收到response时，会记录一个CR(client received)表示收到响应的时间并计算整个span的持续时间。解析下具体数据，结合实际调用中生成的数据来看下前面proxy埋点的逻辑会更清楚些。1.从gateway开始，gateway作为一个独立部署在一个pod中的envoy进程，当有请求过来时，它会将请求转给入口的微服务productpage。Gateway这个Envoy在发出请求时里面没有trace信息，会生成一个根span：spanid和traceid都是f79a31352fe7cae9，parentid为空，并记录CS时间，即Client Send；2.请求从入口gateway这个envoy进入productpage前先讲过productpage pod内的envoy，envoy处理请求头中带着trace信息，则记录SR,Server received，并将请求发送给Productpage业务容器处理，productpage在处理请求的业务方法中需要接收这些header中的trace信息,然后再调用Details和Reviews的微服务。Python写的 productpage在服务端处理请求时，先从request中提取接收到的header。然后再调用details获取details服务时，将header转发出去。app.route('/productpage') def front(): product_id = 0 # TODO: replacedefault value headers = getForwardHeaders(request) … detailsStatus, details = getProductDetails(product_id, headers) reviewsStatus, reviews = getProductReviews(product_id, headers) return…可以看到就是提取几个trace相关的header kvdef getForwardHeaders(request): headers = {} incoming_headers = [ 'x-request-id', 'x-b3-traceid', 'x-b3-spanid', 'x-b3-parentspanid', 'x-b3-sampled', 'x-b3-flags', 'x-ot-span-context'    ] for ihdr in incoming_headers: val = request.headers.get(ihdr) if val is not None: headers[ihdr] = val return headers其实就是重新构造一个请求发出去，可以看到请求中包含收到的header。def getProductReviews(product_id, headers): url = reviews['name'] + "/" + reviews['endpoint'] + "/" + str(product_id) res = requests.get(url, headers=headers, timeout=3.0)3.从ProductPage出的请求去请求Reviews服务前，又一次通过同Pod的envoy，envoy埋点逻辑检查header中包含了trace相关信息，在将请求发出前会做客户端的调用链埋点，即以当前span为parent span，生成一个子span：即traceid：保持一致9a31352fe7cae9， spanid重新生成cb4c86fb667f3114，parentid就是上个span： f79a31352fe7cae9。4.请求在到达Review业务容器前，先经过Review的Envoy，从Header中解析出trace信息存在，则发送Trace信息给Reviews。Reviews处理请求的服务端代码中需要解析出这些包含trace的Header信息。reviews服务中java的rest代码如下：@GET @Path("/reviews/{productId}") public Response bookReviewsById(@PathParam("productId") int productId, @HeaderParam("end-user") String user, @HeaderParam("x-request-id") String xreq, @HeaderParam("x-b3-traceid") String xtraceid, @HeaderParam("x-b3-spanid") String xspanid, @HeaderParam("x-b3-parentspanid") String xparentspanid, @HeaderParam("x-b3-sampled") String xsampled, @HeaderParam("x-b3-flags") String xflags, @HeaderParam("x-ot-span-context") String xotspan)即在服务端接收请求的时候也同样会提取header。调用Ratings服务时再传递下去。其他的productpage调用Details，Reviews调用Ratings逻辑类似。不再复述。以一实际调用的例子了解以上调用过程的细节，可以看到Envoy在处理inbound和outbound时的埋点逻辑，更重要的是看到了在这个过程中应用程序需要配合做的事情。即需要接收trace相关的header并在请求时发送出去，这样在出流量的proxy向下一跳服务发起请求前才能判断并生成子span并和原span进行关联，进而形成一个完整的调用链。否则，如果在应用容器未处理Header中的trace，则Sidecar在处理outbound的请求时会创建根span，最终会形成若干个割裂的span，并不能被关联到一个trace上。即虽然Istio一直是讲服务治理和服务的可观察性对业务代码0侵入。但是要获得一个质量良好的调用链，应用程序还是要配合做些事情。在官方的distributed-tracing 中这部分有描述：“尽管proxy可以自动生成span，但是应用程序需要在类似HTTP Header的地方传递这些span的信息，这样这些span才能被正确的链接成一个trace。因此要求应用程序必须要收集和传递这些trace相关的header并传递出去”• x-request-id• x-b3-traceid• x-b3-spanid• x-b3-parentspanid• x-b3-sampled• x-b3-flags• x-ot-span-context调用链阶段span解析：前端gateway访问productpage的proxy的这个span大致是这样："traceId": "f79a31352fe7cae9",         "id": "f79a31352fe7cae9",                 "name": "productpage-route",                 "timestamp": 1536132571838202,                 "duration": 77474,                 "annotations": [             {                 "timestamp": 1536132571838202,                                 "value": "cs",                                 "endpoint": {                                           "serviceName": "istio-ingressgateway",                                           "ipv4": "172.16.0.28"                                 }                         },                         {                 "timestamp": 1536132571839226,                                 "value": "sr",                                 "endpoint": {                     "serviceName": "productpage",                     "ipv4": "172.16.0.33"                  }             },             {                 "timestamp": 1536132571914652,                 "value": "ss",                 "endpoint": {                     "serviceName": "productpage",                     "ipv4": "172.16.0.33"                 }             },             {                 "timestamp": 1536132571915676,                 "value": "cr",                 "endpoint": {                     "serviceName": "istio-ingressgateway",                     "ipv4": "172.16.0.28"                 }             }         ],gateway上报了个cs，cr, productpage的那个proxy上报了个ss，sr。分别表示gateway作为client什么时候发出请求，什么时候最终受到请求，productpage的proxy什么时候收到了客户端的请求，什么时候发出了response。Reviews的span如下："traceId": "f79a31352fe7cae9",         "id": "cb4c86fb667f3114",                "name": "reviews-route",                 "parentId": "f79a31352fe7cae9",                 "timestamp": 1536132571847838,                 "duration": 64849,  Details的span如下："traceId": "f79a31352fe7cae9",         "id": "951a4487642c0966",                 "name": "details-route",                 "parentId": "f79a31352fe7cae9",                 "timestamp": 1536132571842677,                 "duration": 2944,可以看到productpage这个微服务和detail和reviews这两个服务的调用。一个细节就是traceid就是第一个productpage span的id，所以第一个span也称为根span，而后面两个review和details的span的parentid是前一个productpage的span的id。Ratings 服务的span信息如下：可以看到traceid保持一样，parentid就是reviews的spanid。"traceId": "f79a31352fe7cae9",         "id": "5aac176b61ec8d84",                 "name": "ratings-route",                 "parentId": "cb4c86fb667f3114",                 "timestamp": 1536132571889086,                 "duration": 1449,当然在Jaeger里上报会是这个样子：根据一个实际的例子理解原理后会发现，应用程序要修改代码根本原因就是调用发起方，在Isito里其实就是Sidecar在处理outbound的时生成span的逻辑，而这个埋点的代码和业务代码不在一个进程里，没法使用进程内的一些类似ThreadLocal的方式（threadlocal在golang中也已经不支持了，推荐显式的通过Context传递），只能显式的在进程间传递这些信息。这也能理解为什么Istio的官方文档中告诉我们为了能把每个阶段的调用，即span，串成一个串，即完整的调用链，你需要修你的代码来传递点东西。当然实例中只是对代码侵入最少的方式，就是只在协议头上机械的forward这几个trace相关的header，如果需要更多的控制，如在在span上加特定的tag，或者在应用代码中代码中根据需要构造一个span，可以使用opentracing的StartSpanFromContext 或者SetTag等方法。调用链数据上报Envoy上报一个完整的埋点过程，除了inject、extract这种处理span信息，创建span外，还要将span report到一个调用链的服务端，进行存储并支持检索。在Isito中这些都是在Envoy这个sidecar中处理，业务程序不用关心。在proxy自动注入到业务pod时，会自动刷这个后端地址。如： 即envoy会连接zipkin的服务端上报调用链数据，这些业务容器完全不用关心。当然这个调用链收集的后端地址配置成jaeger也是ok的，因为Jaeger在接收数据是兼容zipkin格式的。Mixers上报除了直接从Envoy上报调用链到zipkin后端外，和其他的Metric等遥测数据一样通过Mixer这个统一面板来收集也是可行的。即如tracespan中描述，创建一个tracespan的模板，来描述从mixer的一次访问中提取哪些数据，可以看到trace相关的几个ID从请求的header中提取，而访问的很多元数据有些从访问中提取，有些根据需要从pod中提取（背后去访问了kubeapiserver的pod资源）apiVersion: "config.istio.io/v1alpha2" kind: tracespan metadata:   name: default     namespace: istio-system spec:   traceId: request.headers["x-b3-traceid"]     spanId: request.headers["x-b3-spanid"] | ""     parentSpanId: request.headers["x-b3-parentspanid"] | ""     spanName: request.path | "/"     startTime: request.time     endTime: response.time     clientSpan: (context.reporter.local | true) == false     rewriteClientSpanId: false     spanTags:     http.method: request.method | ""         http.status_code: response.code | 200         http.url: request.path | ""         request.size: request.size | 0         response.size: response.size | 0         source.ip: source.ip | ip("0.0.0.0")         source.service: source.service | ""         source.user: source.user | ""         source.version: source.labels["version"] | ""最后在这个文章发出前，一直在和社区沟通，督促在更明晰的位置告诉大家用Istio的调用链需要修改些代码，而不是只在一个旮旯的位置一小段描述。得到回应是1.1中社区首页第一页what-is-istio/已经修改了这部分说明，不再是1.0中说without any changes in service code，而是改为with few or no code changes in service code。提示大家在使用Isito进行调用链埋点时，应用程序需要进行适当的修改。当然了解了其中原理，做起来也不会太麻烦。参照https://thenewstack.io/distributed-tracing-istio-and-your-applications/ https://github.com/istio/old_mixer_repo/issues/797 http://www.idouba.net/opentracing-serverside-tracing/ 

一、项目描述亿琪软件是物联网行业技术领先的企业，专注于物联网领域前沿技术的创新，致力于为用户提供全方位、智能化和安全的物联网解决方案。亿琪软件的业务涵盖了智慧城市、智慧农业、智能工厂和智慧园区等多个领域，公司软硬件产品和解决方案获得华为技术认证，是华为公司在物联网领域的全球合作伙伴。公司还得到中国移动OCP认证，是中国移动的物联网合作伙伴。本项目是基于华为 Boudica 150 芯片的 NB-IoT 模组和华为 OceanConnect IoT 平台为基础的智能锁应用，设备端主要是用了 OpenCPU 技术完成的“南向设备”的开发，实现了数据的采集和上传；利用 OceanConnect 的开放性API完成了“北向应用”，实现了对设备的管理、数据查看。本次hackathon，我们使用YiLOCK作为比赛项目。YiLOCK是一款公寓锁，实现了快速安装，插卡即用的物联网智能锁，通讯板采用OpenCPU技术方案实现。二、技术方案我们采用了华为IoT技术套件实现了整个方案，包含端侧LiteOS，设备端NB-IoT模组，云端OceanConnect平台，完成整个方案的建设。南向设备：采用OpenCPU作为端侧设备（内置LiteOS），实现数据采集，传输，命令处理等等；IoT平台：采用OceanConnect平台作为云端服务，实现了端云无缝对接，完成数据包解码；北向应用：通过OceanConnect平台的开放API能力，我们开发了YiServer北向应用；展现层：采用Vue.js技术实现了前端应用，支持web，手机，和平板。三、技术实现3.1、南向设备3.1.1、硬件设计第一，我们针对智能锁体本身的对外接口（USART），我们构建了通讯控制板的逻辑框图，确定了各个模块的工作特性，作为硬件设计的基础；第二，我们针对要实现的南向设备的功能，设计了原理图，基于移远BC28模组实现了OpenCPU电路图，确保每个元器件的正确性可靠性；第三，我们针对锁体的空间、厚度大小、螺丝孔位置等等，设计了PCB电路板，并采用了最好的元器件实现了整个端侧设备，板子大小为：64mm*42mm。3.1.2、软件开发软件上，以HUAWEI LiteOS为基础，我们直接在移远公司BC系列模组提供的API基础上，实现了整个北向设备的应用程序。我们使用了如下特性：1、任务：新建了主任务和外围任务，负责模组在激活后处理不同的应用功能；2、队列：通过各种队列机制实现了激活不同任务处理；3、中断：使用了串口中断，数据收发自动实现；4、串口：使用了物理串口1和虚拟串口，实现了对外通信，包括上行数据和锁具通讯；5、AT命令：本方案主要还是采用了AT指令方式，通过虚拟串口发出，以实现端云互通；6、端云互通：段云互通我们采用了编解码方式。3.2、IoT平台3.2.1、Profile通过OceanConnect平台的技术，我们先需要制作平台端profile文件，将要实现的功能和参数预先设定好，比如，设备类型、电池、连接性、数据等等各种字段。当然，平台端提供了非常好用的GUI界面，非常方便使用。这些参数主要根据应用类型来确定，当然，也可以根据平台提供的范例来作为参考，快速实现自己的应用。3.2.2、编解码插件OceanConnect 平台的编解码插件对于业务实现非常有帮助，我们将编解码插件和Profile对应好，实现业务展现，最终以json格式呈现到API中，对于北向应用对接非常有帮助。图形化编解码插件，省去了繁琐的代码开发，我们俗称**化开发，这个体验非常好，profile和编解码的对应关系一目了然，一键部署。平台还实现了在线调测，方便开发者快速实现应用在线调试，所见即所得，非常利于故障排查，在云端就实现了应用的调测。3.3、北向应用本次比赛，我们采用了公司自主知识产权的YiServer应用程序，并且已经得到华为技术认证，实现了快速连接平台的能力。我们实现了以下功能:1、用户管理：针对SaaS应用的内部用户管理；2、设备管理：实现了物联网设备管理；3、系统配置：配置系统和连接平台的能力；4、安全认证：用户安全认证，登录，会话管理；5、日志报警：日志记录和系统报警；6、数据分析：简单的数据分析和统计功能；7、数据管理：数据的备份/恢复管理；8、开放API：开放API，为第三方应用对接提供的能力；9、行业应用：具体行业应用能力。3.4、前端展现层管理员：采用WEB UI的方式管理，随时随地登录应用服务器管理，支持HTTPS安全认证。使用者：支持H5用户端，Android和iOS客户端，方便随时随地查看数据和设备控制。四、商业应用1、公寓酒店统一管理所有的房间门，无需钥匙，无需现场管理。房东或管理机构不再需要催缴房租和水电费，实现了高效管理。2、发电厂针对发电厂类的行业，每个发电厂都有成百上千把门锁，处于主动式人身安全的想法，我们指定时间、人员、门号进行管理。3、机房机柜几百万几千万的基站，运营商机房和机柜，保证物料安全性，避免人为事故，不再为“被”拔网线而断网。

近期很多厂家在讨论完方案后准备接入OC 公有云平台调测，但是不知道资源怎么获取，现在简单写下，希望对大家有帮助流程简单如下：NB-IoT方案使用IoT增强版进行调测1)申请测试资源，获取测试账号及密码申请链接，登录首页，点击开发者平台按钮，申请开通前需要先实名认证，账号密码邮箱短信通知到华为云租户账号https://www.huaweicloud.com/product/iot.html2）获取IoT平台接入信息开发者环境统一参考链接接入信息，NB-IoT使用CoAP协议栈接入https://bbs.huaweicloud.com/forum/thread-11864-1-1.html3）调测API文档说明参考线上IoT增强版API接口说明，重点看接入鉴权，订阅数据变化通知，推送数据几个API能力https://support.huaweicloud.com/api-IoT/iot_06_0003.html目前常用的两个关键场景是上报数据  命令下发 基本上测试都是围绕这两个场景展开

在这个帖子，我会将所有IoT平台开放给应用服务器的接口都调用一遍，并分别介绍各个接口需要注意的地方以及容易出现的问题，还会附上接口调用时的抓包。关于接口的说明，请参考https://support.huaweicloud.com/api-IoT/iot_06_0002.html1、鉴权接口的调用2、刷新Token接口的调用3、订阅接口的调用4、注册直连设备接口的调用5、设置设备信息接口的调用6、[NB-IoT]查询设备激活状态的接口调用7、删除设备的接口调用8、批量查询设备信息列表的接口调用9、查询单个设备信息接口的调用10、查询设备历史数据接口的调用11、查询设备服务能力接口的调用12、[NB-IoT]投递异步命令接口的调用13、[NB-IoT]查询异步命令接口的调用

什么是SoftRadio呢？SoftRadio是用来实现远程online调试模式的系统，在项目集成时，有时模组、基站等还没有就绪，便会使用SoftRadio进行端到端集成验证，提升设备接入调试效率。IoT平台作为NB-IoT业务统一的联接平台，需要支撑生态建设扩展。因此，需要支撑NB-IoT的模拟器SoftRadio接入到IoT平台。NB-IoT芯片的开发已使用SoftRadio进行模拟开发。在使用TUP协议后，平台支持SoftRadio使用TUP协议接入到IoT平台。注意啦注意啦：该特性仅用于OceanConnect生态圈扩展NB-IoT业务时，提供给开发者做调试使用，属于测试特性，禁止在任何商用局点环境使用。SoftRadio功能SoftRadio主要分为三层：芯片终端应用开发者：使用芯片接入到SoftRadio可以观察，也可上报到平台。不具备芯片的终端应用开发者：开发终端应用，连接到SoftRadio查看数据流，同步数据。Network Application开发者：使用SoftRadio模拟真实设备上报数据，数据信息等。我的价值可大啦~基于SoftRadio和远程实验室，实现NB-IoT设备及业务的远程集成验证。仿真工具及平台远程接入，体现伙伴“离岸联调，提升效率”价值。不具备芯片的终端应用开发者也可以接入进行终端应用的开发。可模拟真实设备进行数据上报。虽然我功能如此强大，但是我也有局限性，毕竟我还在成长嘛~SoftRadio仅应用于测试场景，不允许接入客户现网以及进行商业使用。SoftRadio使用者同时在线数不可以超过3000个。SoftRadio使用创建的设备需要保存deviceID，appID和password，一但丢失需要删除设备重新创建。如何实现的？SoftRadio通过南向REST API接入平台绑定API：携带verifyCode以及设备详细信息，在平台注册绑定，获取deviceID，appID，password信息。说明：verifyCode格式为TEST$_UUID，即北向注册时需要填入nodeId和verifyCode格式为TEST$_UUID。获取deviceID，appID，password后需要妥善保存，防止丢失，一但丢失则需要删除device，重新创建和绑定。登录API：使用deviceID，appID，password登录平台，同时获取token以及CoAP订阅通知的token。MO API：携带整个CoAP报文和token，上报到平台的SR Adapt，并转换为CoAP over UDP进行处理。MT API：从平台获取平台向SoftRadio下发的CoAP消息包，每次获取一条。MO/MT消息通过头域中的deviceID和accesstoken，调用NSCL的鉴权接口，获取所属的APPID，gatewayID以及设备列表，同进判断参数中的deviceID是否在设备列表中或都等于gatewayID。如果通过则直接返回失败。MO消息则直接将body体中的payload，通过base64解码后，交由CoAP连接池发送到CIG，并返回成功。MT消息则在鉴权通过后，直接从数据库中将MT消息取出，并通过base64编码后，通过回应消息返回。模拟CoAP over UDP接入IoT平台实现SR Adapt来模拟真实芯片的数据上报、命令下发等功能与CIG对接，提供南向REST接口与SoftRadio对接。CoAP连接池：最大支持1000个CoAP Server连接，起始EndPoint的端口为[30000，30999]，IP为127.0.0.1。每当device注册、数据上报、命令下发时，从连接池中分配空闲的连接与deviceID绑定，如果16秒内没有数据流，则自动回收（解除deviceID与EndPoint的绑定关系，并放到空闲队列中）。CoAP协议栈：提供CoAP发包和收包监听通知，当MO REST消息发的消息包过来时，通过直接抛入UDP层队列，发到CIG上。当CIG发包到SR Adapt时，截取到并查找到对应的deviceID，如果有命令下发消息则入MT队列（数据库实现），MT REST消息过来时，直接从队列中取出整个CoAP包回应给SoftRadio。好啦，今天的五分钟就到这里啦！到此，【NB-IoT系列】也暂时告一段落。希望该系列能够帮助到您噢！后续如果有新的内容，会继续添加，感兴趣的您可以继续关注！如果您想了解更多的全联接内容，欢迎关注【每天五分钟，精通全联接】噢~往期回顾：【每天五分钟，精通全联接】【NB-IoT系列】——NB-IoT：我来了~【每天五分钟，精通全联接】【NB-IoT系列】——CoAP Over DTLS：你的安全，我来守护~【每天五分钟，精通全联接】【NB-IoT系列】——低功耗订阅：我功耗低，却能收集和处理数据，服不服~【每天五分钟，精通全联接】【NB-IoT系列】——PSM/eDRX/DRX模式：低功耗，从我做起~【每天五分钟，精通全联接】【NB-IoT系列】——设备无连接状态管理：无连接，我仍然知道你的状态~【每天五分钟，精通全联接】【NB-IoT系列】——命令下发机制：立即下发还是缓存下发？任君选择~【每天五分钟，精通全联接】【NB-IoT系列】——批量下发：我可以批量控制设备噢~【每天五分钟，精通全联接】【NB-IoT系列】——LWM2M固件升级：有了我就可以对接标准第三方设备啦~

知道我为什么要给你特权么？第三方应用开发者通过调用IoT平台的接口，可以开发出基于网关或者传感器设备的应用，如车联网、智慧家庭等，从而实现对设备的管理（包括设备的增、删、查、改）、数据采集、命令下发和消息推送等功能。具体的特权有哪些呢？APP ID管理：IoT联接管理平台提供一个门户网站服务器（SP Portal Server）用于给开发者提供注册和认证的功能。注册成功后，服务器会把APP ID和APP密码提供给开发者。此APP ID和密码是APP在IoT联接管理平台中的唯一标识。第三方应用APP凭借申请的APP ID和APP密码作为鉴权信息访问平台API。第三方开发者通过SP Portal管理应用。当前APP ID管理包括创建、编辑、删除应用，鉴权，刷新Token等基本操作，还包括数据统计、升级认证管理、APP流量控制和重置密钥。应用安全接入API：应用携带在IoT联接管理平台产生的APP ID和密码，调用鉴权接口，获取鉴权token。鉴权接口是调用其他API的前提。设备管理API：设备管理API提供了应用申请设备的增、删、改、查接口，提供了应用修改设备或者设备所属传感器基本信息的功能，实现对新增设备接入的灵活操作。APP向IoT联接管理平台申请新的设备，IoT联接管理平台分配对应的设备验证码。待设备携带验证码请求接入平台后，分配其ID、密码，允许其使用。数据采集API：IoT联接管理平台提供数据采集API，支持对网关事件的订阅，同时还支持查看传感器上报的历史数据，能按时、天、月等维度查看传感器上报的历史数据。数据采集实现了对网关数据的收集。命令下发与投递API：IoT联接管理平台分别提供了下发至设备或者具体某传感器的控制命令接口，下发消息的具体格式需要可以根据应用与设备进行自定义，平台在接口中进行封装，透传。应用给设备发送命令消息，实现对传感器的实时控制。规则API：通过调用规则API，应用能够根据具体的业务需要，制定规则（条件）和动作，当网关的状态达到指定规则后，以邮件或者短信的方式对用户进行实时提醒。根据业务需要，编排规则，指定场景触发。消息推送API：通过调用消息推送API，应用向平台订阅设备变更通知，当设备发生变更时，平台向应用推送此消息（应用启动初始化订阅），应用根据通知类型进行对消息分派对应的服务模块进行处理。APP接入的机密性和完整性：IoT联接管理平台提供HTTP接口，通过Internet与应用对接。由于在业务中存在鉴权、密码、业务数据等敏感信息，因此采用HTTPS（HTTP over TLS）传输协议。应用通过HTTPS安全传输协议接入到IoT联接管理平台，可以确保用户信息和数据的安全。   特权提供给你咯，接下来你就可以参考华为云社区的华为IoT Platform API参考（北向）和华为IoT Platform北向应用开发指南 构建自己的IoT应用 ，构建之后就可以通过SP Portal管理应用啦~

（转自 https://developer.huawei.com/ict/forum/thread-19449.html  ）众所周知，OceanConnect平台提供了北向的RESTful类型的接口。开发者通过调用这些接口，可以管理平台之上的设备、获取设备的最新数据和历史数据、通过平台向设备发送命令等操作。根据南向接入设备的方案的不同（NB-IoT方案或非NB-IoT方案），OceanConnect提供的北向接口会有略微的不同。开发者需要下载匹配的文档，切勿用错文档。NB-IoT方案：华为IoT联接管理平台北向接口文档（for NB-IoT)，该文档暂时未开放下载，请通过devcenter向华为支持人员获取；非NB-IoT方案：华为IoT_Platform_API参考(北向)，可以在开发者社区下载。下面，我们以NB-IoT方案的接口为主，进行介绍。* 接入管理1，鉴权：通过AppId和secret，获得访问平台的权限（秘钥）。2，刷新秘钥：鉴权获得的秘钥是有有效期的，需要定期刷新。* 设置应用信息1，更新NB设备的异常时间和离线时间。1天没有数据变化，设备显示异常，2天显示离线* 设备管理1，注册直连设备：使用IMEI（NB模组）或TEST$_(IMEI)（SoftRadio）注册一个直连设备到平台；2，设置设备信息：注册完毕后，设置设备的manufacturerId、model、deviceType、protocolType等相关信息；3，查询设备激活状态：南向设备成功绑定、登录后，设备激活状态会被修改为激活。注意这里的激活状态不同于设备的在线、离线状态。4，删除设备：从平台上删除指定设备。* 数据采集1，按条件批量查询设备信息列表：可以根据设备的状态、注册设备的时间来获取满足条件的设备列表。通过这个接口，不仅获得了满足条件的设备信息，还可以获得这些设备之上的服务的最新数据。2，查询单个设备信息：通过设备的唯一标识，获取指定设备的信息，以及设备之上的服务的最新数据。3，查询设备历史数据：可以获取指定设备、指定服务、指定时间段内的设备上报数据。IoT平台有一个定时器，每20分钟检测一次历史数据。符合以下两种情况中的一种，部分数据会被删除：①. 若检测到整个IoT平台保存的历史数据条数超过10万条。②. 若检测到有历史数据产生时间到当前时间大于90天。上面两个条件“10万条”和“90天”都是在平台后台可以配置的。删除数据都是删除老数据保存新数据。4，查询设备的服务能力：获取指定设备的服务能力，包括数据上报的属性和命令下发的内容格式。* 消息订阅1，注册订阅：可以通过该接口，注册bindDevice、deviceDataChanged、deviceDeleted、commandRsp、ruleEvent事件消息。当对应的时间发生时，平台会向指定的URL推送POST消息。更多订阅相关的内容，可以参考：https://bbs.huaweicloud.com/forum/thread-13264-1-1.html * 异步命令1，向设备投递异步命令：应用通过平台向指定设备发送命令，也可以理解成数据的下行通路。有关异步命令的更多信息，可以参考：https://bbs.huaweicloud.com/forum/thread-13535-1-1.html 2，查询异步命令：可以查询指定设备、指定时间段内，收到的命令，包括暂未下发到设备、暂未收到设备回应、超时、已撤销、命令响应成功、命令响应失败等各种状态下的命令。3，撤销异步命令：可以对已经下发到平台，但是平台暂未下发到设备的命令，进行撤销。如果命令已经执行完成或失效，则撤销操作无效。* 规则引擎1，创建规则：创建特定规则，平台对指定服务进行监控，满足触发条件后，发送短息、邮件或者执行相关命令。有关规则的更新信息，可以参考：https://bbs.huaweicloud.com/forum/thread-13536-1-1.html2，更新规则：更新指定规则的内容和响应。3，修改单个规则状态：规则的状态，即为激活与未激活。4，批量修改规则状态：可同时对多个规则的状态进行修改。5，删除规则：删除指定的规则。6，查找规则：根据规则的创建者和规则名，进行查找。通过上述的介绍，相信大家已经对OceanConnect北向接口有了一定的认识。下一步，结合相关接口文档，通过华为提供的Lite Demo和GUI Demo，对接口的参数和返回值的内容加深了解。

在过去的一段时间里，笔者从各个渠道看到了一些关于通过OBS REST接口的疑问。为此，笔者特意去帮助各位了解了一番。--------------------------------------------------------------------------------------------------------------------------------OBS提供了两种二次开发的方式供大家选择：通过OBS提供的多种主流语言的SDK开发工具包创建请求SDK对接口进行了封装，可以简化客户端实现的复杂度，提高程序的兼容性和稳定性。SDK相对简单，OBS给用户提供了各种语言的帮助文档：https://developer.huaweicloud.com/sdk?OBS通过OBS提供的REST接口创建请求REST接口使用户能够非常容易地从Web应用中访问对象存储服务。用户可以在任何时间、任何地点、任何互联网设备上上传和下载数据。让所有开发人员都能访问同一个具备高扩展性、可靠性、安全性和快速价廉的数据存储基础设施。相比SDK，使用REST接口构造HTTP请求时，需要进行签名计算。--------------------------------------------------------------------------------------------------------------------------------鉴于部分用户不太了解签名的计算过程，笔者去求教了OBS的技术专家，专程为大家录制了一份使用REST API构造请求的指导视频。同时，大家还可以查阅OBS的API参考文档，了解各个接口的详细信息：https://support.huaweicloud.com/api-obs/zh-cn_topic_0031051947.html视频以创建桶、列举桶列表和上传对象的实例向大家简单介绍使用REST API构造HTTP请求的全流程。9分钟的短视频可以帮助大家扫盲API，玩转对象存储。话不多说，送上视频链接：中国站（中文）：https://bbs.huaweicloud.com/videos/e932611c4b354cd2b6f9b6562ba7bf16国际站（英文）：https://support-intl.huaweicloud.com/obs_video/index.html

本文适合于熟悉开源区块链技术Hyperledger Fabric，以及希望更高效地使用华为云区块链服务的读者。当然，也欢迎任何对区块链技术有兴趣的读者阅读本文，相信读者们都能从中受益。2018年2月1日 华为云发布企业级区块链开放平台区块链服务BCS（Blockchain Service），是基于开源区块链技术和华为在分布式并行计算、数据管理、安全加密等核心技术领域多年积累基础上推出的企业级区块链云服务产品,旨在帮助各行业、企业在华为云上快速、高效的搭建企业级区块链行业方案和应用。如前所述，搭建区块链不是目的，关键是要方便应用更高效地使用区块链。本文要介绍的RESTFUL链码调用API即是华为云区块链为此目的而开发的，在详细介绍API之前，先对链代码做一下简单介绍，便于没有Fabric知识背景的读者理解。我们知道区块链是一种由区块串联而成的链式结构，每一个区块上都记录着账户数据，这些数据一经写入是不可篡改的。那么数据是如何写入的呢？如果让拥有写入权限的用户都能随意写入数据的话，区块链也就失去了存在的意义，因此链代码概念的引入意义重大。链代码又被称之为智能合约，顾名思义就是向区块链写入数据的预先约定好的代码。它是一段逻辑，这个逻辑可以是简单的限制和约束，也可以是非常复杂的业务相关的逻辑，根据用户的输入，进行逻辑的运算，最终得出向区块链写入的数据集合，然后将数据写入到区块链上去。如果这样描述过于抽象的话，我们以一个账户转账的例子来进行说明。如上图所示，图中右边的区块链记录着原始账户的余额，a为100元，b为200元。图中左边客户端应用程序发起一笔转账交易：a向b转x元。这笔交易不会直接写入区块链，而是先经过中间的链代码进行智能合约的运算，检查a的账户里是否有足够的余额，然后才允许转账交易的进行，将最终的a、b账户的余额写入到最新的区块链中。整个交易过程以及链代码的作用其实非常浅显易懂，但其实我们的应用程序向链代码发起调用的过程还是有些复杂的。因为区块链的调用请求不同于普通的RPC远程调用，客户端需要有如下的事情：将链代码的调用信息如通道ID、链码ID、调用参数、调用者信息等进行打包将打包好的二进制内容使用用户私钥进行签名根据链码的背书策略不同，可能需要向多个组织的节点上的链码发起调用   由此可见，这个调用过程如果让客户端自己来实现是不太现实的，因此需要借助SDK的帮助来实现。目前根据客户端的语言不同，SDK也有各种不同的语言版本，例如golang语言就有fabric-sdk-go的实现，javascript也有nodejs版本的SDK实现。我们先来看一下使用SDK需要的配置文件以及使用SDK进行调用的示例代码片段：上图是一个200行的SDK配置文件片段这是一个nodejs版本的SDK使用示例。由此我们可以看出客户端应用直接使用SDK的弊端：配置文件书写复杂虽然华为云已经提供了SDK配置文件下载功能，对于首次使用SDK的开发人员来说成本仍然很高。SDK语言相关，并且学习成本高虽然很多语言都提供了FabricSDK，但是学习起来仍然有一定学习成本，并且不同语言的类库名称，方法名称调用方式都各不相同，切换不同语言时的学习成本成倍增加。SDK过于厚重应用程序在使用SDK的时候需要将SDK类库引入，虽然不用开发语言的SDK打包后大小各不相同，但对于一些薄客户端（比如安卓或者IOS手机应用）来说仍然显得十分厚重。华为云为了方便开发者使用区块链服务，在服务端提供了RESTFUL的API以克服上述直接使用SDK方式的不足：如上面架构图所示，华为云区块链服务直接暴露RESTFUL形式的API供开发者使用，在服务端封装了对SDK的调用。因为华为云替用户管理着区块链的组织结构以及各种证书，所以天然具备了所需要的SDK的配置文件，不需要用户自己手动生成。在此给出一个RESTFUL链码调用请求的Header和Body的示例供读者参考： HEADER:x-bcs-signature-sign: 1f8b08000000000000ff14cbb11503510c02b081d260c098bfff6279d74bb90a5ca7384e3cae9b5825af7cb076b65e039be41da8e8b1e38700d599fa4aee37d6c159a94355ada783dbb4d66e17e967db39cef36bcd0b5adc8be3e178698ef9070000ffff BODY: {   "channelId": "testchannel",   "chaincodeId": "zmmcode",   "chaincodeVersion": "1.0",   "userId": "User1",   "orgId":  "7258adda1803f4137eff4813e7aba323018200c5",   "opmethod": "invoke",   "args":  "[\"invoke\",\"a\",\"b\",\"1\"]",   "timestamp": "2018-10-31T17:28:16+08:00",   "cert": "-----BEGIN CERTIFICATE-----\nMIIDBzCCAq2gAwIBAgIQEXPZlMsReamxVtVNnKwCCzAKBggqhkjOPQQDAjCCAQQx\nDjAMBgNVBAYTBUNISU5BMRAwDgYDVQQIEwdCRUlKSU5HMRAwMwUQYD14eH+jTTBLMA4GA1Ud\nDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAAMCsGA1UdIwQkMCKAIFBXQ5TC4acFeTlT\nJuDZg62XkXCdnOfvbejSeKI2TXoIMAoGCCqGSM49BAMCA0gAMEUCIQCadHIKl0Mk\nYn0WZizyDZYR4rT2q0nzjFaiW+YfV5FBjAIgNalKUe3rIwXJvXORV4ZXurEua2Ag\nQmhcjRnVwPTjpTE=\n-----END  CERTIFICATE-----\n"}看到这里，读者可能会对上面Header中的签名以及Body中的cert证书信息有所疑惑。请不要着急，在此先介绍一下华为云区块链RESTFUL接口的实现原理，读者自然就能解除心中疑虑。根据前文我们已经了解区块链的调用和普通RPC的远程调用最主要的区别在于需要有用户签名用于证明交易是指定用户所发起的，那么RESTFUL调用也不可避免这个问题。因此我们在使用华为云区块链RESTFUL接口时仍然需要使用用户私钥对整个请求消息体进行签名如图中j所示，签名的结果放到HEADER中指定名称下。这个签名在服务端会使用用户的公钥进行验证，验证通过交易才能继续。在某些情况下，用户的公私钥对并不是华为云区块链服务管理的，而是用户使用组织私钥自行签发的，这个时候服务端就缺少这个用户的公私钥，此时就需要在请求消息体中使用cert字段上传用户公钥，服务端使用用户上传的公钥验证HEADER中的签名是否是私钥对消息体的合法签名。这时问题就来了，任何一个伪造者都可以自己制作一个非对称的公私钥对，然后对一个非法的消息体进行私钥签名，并把公钥放到消息体中以通过服务端的验签。为了避免这个漏洞，服务端在验签之前会对用户上传的公钥进行合法性验证，如上图k。因为用户上传的公钥实际上是一个证书，该证书包含了用户公钥以及组织私钥对该证书的签名，而伪造者缺少组织私钥无法伪造签名，这样服务端就能判定用户上传证书的合法性。当服务端使用合法的用户证书验证请求HEADER中的签名是用户私钥的签名后，服务端就可以真正发起区块链链码的调用了，这里服务端使用SDK的方式与客户端直接使用SDK的方式并无不同，只不过如果客户端证书是自行签发的，那么服务端是没有用户私钥的，这个时候就会使用组织的admin证书发起区块链链码的调用。至此，RESTFUL的调用机制读者也清楚了，那么RESTFUL调用的优点也就很容易理解：使用简单方便，由华为云区块链服务封装SDK的复杂性。由于绝大多数语言都已经拥有很成熟的RESTFUL调用类库，调用RESTFUL基本没有学习成本。不用引入SDK类库，适合更轻量的客户端。以上就是对华为云区块链RESTFUL链代码调用API的原理的详细讲述，目前RESTFUL接口还处于公测阶段，欢迎读者到华为云进行免费体验并提出宝贵意见。本文作者：华为云BCS技术专家 周meng。原创作品，转载请联系或附原文链接。

扫码或者“点击这里”查看最新REST API Demo资料。

华为云API创新大赛奖项设定及评定细则 1 大赛时间2018年12月1日 00:00:00 - 2019年1月31日 23:59:59。2 参与方式 服务商：        注册成为华为云市场服务商，2018年12月1日至2019年1月31日期间，在华为云市场成功发布API商品即视为参赛。发布时间以云市场商品页记录的“上架时间”为准，如下所示：用户/开发者：       2018年12月1日至2019年1月31日期间，访问华为云市场并购买云市场API商品，即有机会获得大奖，详见第四章节“用户/开发者奖项 – 参与奖”说明。3  注意事项（1）部分商品可能有购买次数限制，以商品详情页及订单提交页说明为准，请详细阅读。（2）奖品中发放的代金券规则：i.代金券限云服务器、云硬盘等云服务产品使用，不适用于云市场商品；ii.代金券仅可用于新购；iii.代金券支持每订单使用1张，不支持和特价套餐、折扣券、其他优惠券叠加使用；iv.代金券发放后用户可在费用中心查看；v.代金券在领取后6个月内有效，逾期失效；vi.未尽事宜以实际发放的代金券显示的适用说明为准。（3）为保证活动的公平公正，华为云有权对恶意刷活动资源（“恶意”是指为获取资源而异常注册账号等破坏活动公平性的行为）并利用资源从事违法违规行为的用户收回套餐使用资格及所赠送的代金券，并取消其抽奖及其它获奖资格。（4）活动期内，服务商的API商品被用户向华为云投诉，且被华为云认定为服务商商品质量问题（包括API对接问题）≥3次，华为云将取消该服务商的评奖资格。（5）“有效订单”定义： i. 用户购买非0元API按次套餐包商品，生成订单并支付开通后，记为一条有效订单。API按次套餐包商品是指API商品页显示“套餐包”的商品，如下为API按次套餐包示意商品：ii. 用户开通API按需商品（即购买方式为“按需”的API商品）后将会生成按需资源，在活动期内该按需资源消费＞0元，且在活动期内未删除该按需资源的，该按需资源记录为一条有效订单。如下为API按需示意商品：或者（6）有效订单、有效订单数统计、消费记录、消费金额统计、API调用次数等数据以华为云后台数据为准。（7）所有参加本活动的用户，均视为认可并自觉遵守《华为云用户协议》及本活动规则。（8）所有奖项将在2019年2月28日前评定，华为云代金券奖品将在2019年3月31日前发放至华为云账户，实物奖品将在2019年3月31日前寄出。 4 奖项设定及评定细则4.1      　 服务商奖项 – 商业奖说明：商业奖从服务商维度评定。每个服务商最多限领一次商业奖，如同一服务商同时获得多个商业奖，可获得多个证书，但代金券、实物奖励等只按最高奖项予以奖励。最佳商业成功奖（共计2名）奖品设置评定细则数量（1）获奖证书（2）8万元华为云代金券（3）HUAWEI MateBook E 12英寸时尚二合一笔记本电脑 （M3/4GB/128GB）一台同时满足如下两个要求：（1）活动期间服务商在架API商品总成交额≥1万元；（2）活动期间该服务商在架API商品总成交额，在全部服务商中按照从高到低排名第一名。1名（1）获奖证书（2）8万元华为云代金券（3）HUAWEI MateBook E 12英寸时尚二合一笔记本电脑   （M3/4GB/128GB）一台同时满足如下两个要求：（1）活动期间服务商在架API商品总有效订单数≥500笔，且有效订单至少来自≥10名用户；（2）活动期间该服务商在架API商品总有效订单数，在全部服务商中按照从高到低排名第一名。1名 最佳勤奋奖（共计1名）奖品设置评定细则数量（1）获奖证书（2）6万元华为云代金券同时满足如下两个要求：（1）活动期间服务商发布API商品总数≥30个，发布时间以云市场商品页记录的“上架时间”为准。同一商品不同规格不得拆分发布，以云市场审核结果为准；（2）活动期间该服务商发布API商品总数，在全部服务商中按照从高到低排名第一名。1名 最佳人气奖（共计1名）奖品设置评定细则数量（1）获奖证书（2）6万元华为云代金券同时满足如下两个要求：（1）活动期间服务商发布的API商品被用户购买后，活动期内全部用户使用该服务商的API商品实际调用总次数≥500次；（2）活动期间该服务商发布的API商品被用户购买后，在活动期间API调用总次数，在全部服务商中按照从高到低排名第一名。1名 4.2       服务商奖项 – 创新奖说明：创新奖从商品维度评定。每个商品最多限领一次创新奖，若同一商品同时获得多个创新奖，则只获得最高奖项，其他奖项由第二名递进。每个服务商最多不超过5个商品入选创新奖。最佳商品奖（共计1名）奖品设置评定细则数量（1）获奖证书（2）4万元华为云代金券评审专家团从商品创意、技术创新、商业价值、功能完备度、华为云服务集成度、商品演进潜力等角度综合打分最高的API商品。1名 创新商品奖（共计4名）奖品设置评定细则数量（1）获奖证书（2）1万元华为云代金券评审专家团从serverless维度综合评分最高的API商品。1名（1）获奖证书（2）1万元华为云代金券评审专家团从BCS维度综合评分最高的API商品。1名（1）获奖证书（2）1万元华为云代金券评审专家团从IoT维度综合评分最高的API商品。1名（1）获奖证书（2）1万元华为云代金券评审专家团从AI维度综合评分最高的API商品。1名 潜力商品奖（共计10名）奖品设置评定细则数量每个潜力商品奖获奖商品将获得如下奖励：（1）获奖证书（2）6千元华为云代金券评审专家团综合评分TOP10的API商品。10名 4.3       用户/开发者奖项 – 参与奖幸运大抽奖活动结束后，将从有效订单维度进行抽奖，同一用户有N个有效订单即可获得N次抽奖机会。获奖用户将获得如下奖励：奖项奖品数量一等奖HUAWEI Mate 20 Pro手机(6GB+128GB）一部1名二等奖1千元华为云代金券10名三等奖100元京东储值卡30名 精美定制礼品活动期间，购买并使用云市场API商品且累计消费总金额≥100元用户，即可获赠精美礼品一份。礼品为华为云市场严选商城纪念T恤一件或API Gateway定制水杯一个，将随机发放，请以实际收到的礼品为准。 最高消费奖奖品获奖标准数量HUAWEI Mate 20 Pro 手机(6GB+128GB）一部同时满足如下两个要求：（1）活动期间购买并使用云市场API商品且累计消费总金额≥5,000元；（2）活动期间购买API商品的累计消费总金额，在全部参与活动的用户中按照从高到低排名第一名。1名HUAWEI Mate 20 手机(6GB+64GB) 一部同时满足如下两个要求：（1）活动期间购买并使用云市场API商品且累计消费总金额≥5,000元；（2）活动期间购买API商品的累计消费总金额，在全部参与活动的用户中按照从高到低排名第二名。1名HUAWEI Mate 20 Pro 手机(6GB+128GB）一部同时满足如下两个要求：（1）活动期间购买云市场API商品的有效订单数≥500条；（2）活动期间购买API商品的有效订单数，在全部参与活动的用户中按照从高到低排名第一名。1名HUAWEI Mate 20 手机(6GB+64GB) 一部同时满足如下两个要求：（1）活动期间购买云市场API商品的有效订单数≥500条；（2）活动期间购买API商品的有效订单数，在全部参与活动的用户中按照从高到低排名第二名。1名 最佳实践奖活动期内，购买云市场API商品并调用该商品自主开发应用或服务(包括但不限于Android app,基于华为云的SAAS或镜像服务等)开展应用实践，在2019年1月31日前提交华为云API Gateway专家邮箱（fuyiwei1@huawei.com ）。华为云API Gateway团队将在2019年2月28日前综合评定出最优的应用实践。最优应用实践获奖者将会获得1万元华为云代金券，该应用实践Demo将会在华为云API Gateway产品页（https://www.huaweicloud.com/product/apig.html）展示1年。

转码服务对应的接口列表如下：接口说明POST /v1/{project_id}/transcodings创建转码任务。DELETE /v1/{project_id}/transcodings{?task_id}删除转码任务。GET /v1/{project_id}/transcodings{?task_id}查询转码任务。POST /v1/{project_id}/template/transcodings创建自定义转码模板。DELETE /v1/{project_id}/template/transcodings{?temp_id}删除自定义转码模板。PUT /v1/{project_id}/template/transcodings修改自定义转码模板。GET /v1/{project_id}/template/transcodings{?temp_id}查询自定义转码模板。

文档内容快速浏览：1 序言：Rust语言简介   1.1 核心概念：所有权系统2 使用Rust进行HTTP Web后端应用开发   2.1 实战演练         2.1.1 准备后端应用服务器         2.1.1 安装相关的工具链         2.1.2 编写后端Web应用   2.2 API部署1 序言：Rust语言简介参与过C/C++大型项目的同学可能都经历过因为Null Pointer、Memory Leak等问题“被” 加班了不知道多少个晚上。别沮丧，你不是一个人，Mozilla Firefox的开发者们同样经历过这个问题。浏览器可以说是我们日常使用最为频繁的软件了，目前主流的浏览器主要 有Google Chrome、Internet Explorer、Mozilla Firefox。为了提升用户体验，Mozilla就已经启动了多线程渲染的计划。然而，面对大型的C/C++工程，Mozilla的开发者们也坚持不住了。此时，Rust进入了开发者的眼中，与C语言ABI兼容、多编程范式支持、无GC及独特的所有权系统，使得Mozilla与Rust语言一拍即合，并迅速启动了 Mozilla 的下一代浏览器引擎项目：servo，到目前为止（2018年8 月），servo已经成为了除Rust编译器自身外，社区中最大的Rust项目。servo目前已经部 分应用在Firefox 57之后的版本中。Rust语言的设计目标是安全、高效、并发以及实用性。Rust 从一定程度上解决了C++的以 下痛点：1.  容器/数组越界访问；2.  动态内存分配的泄露与double free问题；3.  难以对依赖进行管理；其中前两点在C/C++项目中是最容易引发Bug以及安全问题的原因，依靠人来对这些问题进行检查往往不是最佳的解决方案。Rust通过其独特的所有权系统，简化所研究的对象，使得一些隐晦的问题在编译期间便暴露出来。任何事情都是有两面性的，由于严格的编译期检查以及工程实现上的取舍，Rust在一定程度上牺牲了编译速度以及灵活性，对“灵活性”的舍弃并不代表Rust语言的表现力下降，只是我们在编写Rust程序时，可能需要 改变一下以往的思路。在Rust圈子中，有一句调侃：“C++是调试的时候想撞墙，而Rust是编译的时候想撞墙”。接下来我们将通过一个简单的例子来建立Rust中所有权系统的一个基本印象。1.1 核心概念：所有权系统Rust 的所有权系统包括三个核心概念：所有权、借用以及生命周期。我们首先来通过一个 简单的例子来建立对所有权以及生命周期的直观概念。#[derive(Debug)]  struct Foo;    fn main() {      let foo = Foo; // Note: Foo not implement Copy trait      let bar = foo;        println!("{:?}", bar);      // println!("{:?}", foo);  }首先创建了一个Foo类型的变量foo，然后我们执行let bar = foo;，然后我们尝试 输出这两个变量的值，如果我们将第9行的注释去掉，程序将无法通过编译，这是因为在 Rust中，对于没有实现Copy trait的类型，如果我们将一个绑定赋给另一个绑定，默认 使用的是move语义，也即对于任意给定的资源，当且仅当有一个变量绑定与之对应。想要进一步学习Rust的小哥哥小姐姐，可以参考Rust Learning。2 使用Rust进行HTTP Web后端应用开发在Rust生态中进行HTTP Web后端应用开发目前主要依赖两个基础库：http 以及hyper，其中 http 提供HTTP标准相关的基础类型，如Request<T> 、Response<T>以及StatusCode和常用的Header等；hyper的定位是一个高效、准确的 HTTP底层库，它封装了HTTP的报文解析、报文编码处理、连接控制等内容，对于用户而言 只需要实现一个类似于Fn(Request) -> Response的映射，就可以完成HTTP Web服务端的开 发。基于http以及hyper，社区中还有很多用于Web应用开发的框架，常用的有：•  rocket•  iron• actix-web•  tower-web值得一提的是上周刚发布的tower-web，因为这是官方net团队2018年工作计划的一部分， 这个库在未来会为Rust生态提供一个灵活、高效、易于使用的Web开发框架。那么事不宜迟， 我们通过实战演练来一睹为快。 在本月月底，tower-web将会集成到warp项目中，成为warp框架的一部分，开发的重心将会转移到warp上。2.1 实战演练2.1.1 准备后端应用服务器登录华为云，并创建弹性云服务器作为我们的后端应用服务器。实战中使用的系统版本为Ubuntu 16.04，如果选择不同的系统需要根据情况调整命令。2.1.2 安装相关的工具链apt update && apt install build-essential# 安装Rust工具链curl https://sh.rustup.rs -sSf | sh这一步结束后，我们就可以开始编写我们的应用服务了。2.1.3 编写后端Web应用这次分享我们来构建一个RESTful中文分词API。1. 首先我们来创建一个Rust工程 cargo new --bin chinese_segmentation2. 接下来在Cargo.toml中添加相关依赖。[dependencies]  tower-web = "0.2"  # Jieba Chinese Work Segmentation  jieba-rs = "0.2"    # logging utils  log = "0.4.0"  env_logger = "0.5.12"    # Serializing responses, deserializing requests  serde = "1.0.70"3. 然后是我们的main.rs，与其他语言一样，在文件开始的部分引入外部依赖以及相关声明：extern crate jieba_rs;  #[macro_use]  extern crate tower_web;    #[macro_use]  extern crate log;  extern crate env_logger;    use std::iter::FromIterator;  use std::collections::HashSet;    use jieba_rs::Jieba;  use tower_web::ServiceBuilder;4. 接下来我们定义我们的服务资源ChineseTokenizer：#[derive(Debug)]  struct ChineseTokenizer {      inner: Jieba,  }    impl ChineseTokenizer {      pub fn new() -> ChineseTokenizer {          ChineseTokenizer { inner: Jieba::new() }      }        //对传入的字符串进行分词，并返回一个字符串向量      pub fn cut(&self, text: &String) -> Vec<String> {          let words = self.inner.cut(&text, true)              .into_iter()              .map(|word| word.to_owned())              .collect::<HashSet<String>>();            let mut words = Vec::from_iter(words.into_iter());            //由于使用HashSet进行去重会引入不确定性，               //因此对结果进行重排，使输出的结果有序。          words.sort();          words      }  }5. 定义了我们的服务资源后，我们来定义输入Web API的输入输出类型：#[derive(Debug, Extract)]  struct TokenizeRequest {      text: String  }    #[derive(Debug, Response)]  #[web(status = "200")] //当handler返回Ok(xx)时，返回200状态码  struct TokenizeResponse {      words: Vec<String>,  }6. 到目前为止，我们已经有了我们的服务资源，输入输出类型，接下来就到我们的重头戏了， Web 部分的实现，别担心，因为真的很简单。impl_web! {      impl ChineseTokenizer {          #[post("/tokenize")]          #[content_type("application/json")]          fn tokenize(&self, body: TokenizeRequest) -> Reqult<TokenizeResponse, ()> {              Ok(TokenizeResponse {                  words: self.cut(&body.text),              })          }      }  }7. 最后是我们的main函数：fn main() {      //初始化Logger      env_logger::init();      let addr = "0.0.0.0:8081".parse().expect("invalid address");      info!("listening on http://{}", addr);        ServiceBuilder::new()          .resource(ChineseTokenizer::new()) //注册我们的服务资源          .run(&addr)             //让我们的服务跑起来          .unwrap();  }8. 现在，我们通过命令RUST_LOG=chinese_segmentation=info cargo run --release来检验 一下我们的成果了。  服务在本地跑起来之后，我们可以通过命令 curl -H "Content-Type: application/json" -X POST -d '{"text":"中间件小哥"}' <url> 来测试一下我们的接口。  本地测试通过之后，就需要着手开始部署了，我们检查一下弹性云服务器的安全组的入方向 是否放开8081端口。2.2 API 部署API 网关集成了监控、流控、负载均衡等一系列功能，为开发者提供高性能、高可用的API 托管服务，在本次实践中，我们将我们的API部署在API网关中。1. 登录华为云API网关服务，选择“新建API”。    2. 填写API的基本信息  在本次实验中，选择无认证。      3. 定义API请求。  请求路径填为 /segment，方法为 POST      4.   定义后端服务。  请求方式设置为POST，在VPC通道这一项中，我们需要新建VPC通道。端口设置为8081， 并将其与弹性云服务器关联。      6. 创建完VPC通道后，回到API创建页面，填入相关信息：     7. 网关创建完成后，我们需要回到我们的弹性云服务器，将我们的后端服务器先跑起来：     RUST_LOG=chinese_segmentation=info nohup ./target/release/chinese_segmentation 2>&1 ~/api.log &  作为示例，这里使用nohup命令来跑我们的服务。但在生产环境中，建议使用 systemd等工具来跑服务。8. 服务在云服务器运行起来之后，将API发布至RELEASE环境中。     然后我们就可以和我们的API愉快地玩耍啦。 欢迎扫码查看更多精彩： 

文档内容快速浏览：1 序言：Rust语言简介   1.1 核心概念：所有权系统2 使用Rust进行HTTP Web后端应用开发   2.1 实战演练         2.1.1 准备后端应用服务器         2.1.1 安装相关的工具链         2.1.2 编写后端Web应用   2.2 API部署1 序言：Rust语言简介参与过C/C++大型项目的同学可能都经历过因为Null Pointer、Memory Leak等问题“被” 加班了不知道多少个晚上。别沮丧，你不是一个人，Mozilla Firefox的开发者们同样经历过这个问题。浏览器可以说是我们日常使用最为频繁的软件了，目前主流的浏览器主要 有Google Chrome、Internet Explorer、Mozilla Firefox。为了提升用户体验，Mozilla就已经启动了多线程渲染的计划。然而，面对大型的C/C++工程，Mozilla的开发者们也坚持不住了。此时，Rust进入了开发者的眼中，与C语言ABI兼容、多编程范式支持、无GC及独特的所有权系统，使得Mozilla与Rust语言一拍即合，并迅速启动了 Mozilla 的下一代浏览器引擎项目：servo，到目前为止（2018年8 月），servo已经成为了除Rust编译器自身外，社区中最大的Rust项目。servo目前已经部 分应用在Firefox 57之后的版本中。Rust语言的设计目标是安全、高效、并发以及实用性。Rust 从一定程度上解决了C++的以 下痛点：1.  容器/数组越界访问；2.  动态内存分配的泄露与double free问题；3.  难以对依赖进行管理；其中前两点在C/C++项目中是最容易引发Bug以及安全问题的原因，依靠人来对这些问题进行检查往往不是最佳的解决方案。Rust通过其独特的所有权系统，简化所研究的对象，使得一些隐晦的问题在编译期间便暴露出来。任何事情都是有两面性的，由于严格的编译期检查以及工程实现上的取舍，Rust在一定程度上牺牲了编译速度以及灵活性，对“灵活性”的舍弃并不代表Rust语言的表现力下降，只是我们在编写Rust程序时，可能需要 改变一下以往的思路。在Rust圈子中，有一句调侃：“C++是调试的时候想撞墙，而Rust是编译的时候想撞墙”。接下来我们将通过一个简单的例子来建立Rust中所有权系统的一个基本印象。1.1 核心概念：所有权系统Rust 的所有权系统包括三个核心概念：所有权、借用以及生命周期。我们首先来通过一个 简单的例子来建立对所有权以及生命周期的直观概念。#[derive(Debug)]  struct Foo;    fn main() {      let foo = Foo; // Note: Foo not implement Copy trait      let bar = foo;        println!("{:?}", bar);      // println!("{:?}", foo);  }首先创建了一个Foo类型的变量foo，然后我们执行let bar = foo;，然后我们尝试 输出这两个变量的值，如果我们将第9行的注释去掉，程序将无法通过编译，这是因为在 Rust中，对于没有实现Copy trait的类型，如果我们将一个绑定赋给另一个绑定，默认 使用的是move语义，也即对于任意给定的资源，当且仅当有一个变量绑定与之对应。想要进一步学习Rust的小哥哥小姐姐，可以参考Rust Learning。2 使用Rust进行HTTP Web后端应用开发在Rust生态中进行HTTP Web后端应用开发目前主要依赖两个基础库：http 以及hyper，其中 http 提供HTTP标准相关的基础类型，如Request<T> 、Response<T>以及StatusCode和常用的Header等；hyper的定位是一个高效、准确的 HTTP底层库，它封装了HTTP的报文解析、报文编码处理、连接控制等内容，对于用户而言 只需要实现一个类似于Fn(Request) -> Response的映射，就可以完成HTTP Web服务端的开 发。基于http以及hyper，社区中还有很多用于Web应用开发的框架，常用的有：•  rocket•  iron• actix-web•  tower-web值得一提的是上周刚发布的tower-web，因为这是官方net团队2018年工作计划的一部分， 这个库在未来会为Rust生态提供一个灵活、高效、易于使用的Web开发框架。那么事不宜迟， 我们通过实战演练来一睹为快。 在本月月底，tower-web将会集成到warp项目中，成为warp框架的一部分，开发的重心将会转移到warp上。2.1 实战演练2.1.1 准备后端应用服务器登录华为云，并创建弹性云服务器作为我们的后端应用服务器。实战中使用的系统版本为Ubuntu 16.04，如果选择不同的系统需要根据情况调整命令。2.1.2 安装相关的工具链apt update && apt install build-essential# 安装Rust工具链curl https://sh.rustup.rs -sSf | sh这一步结束后，我们就可以开始编写我们的应用服务了。2.1.3 编写后端Web应用这次分享我们来构建一个RESTful中文分词API。1. 首先我们来创建一个Rust工程 cargo new --bin chinese_segmentation2. 接下来在Cargo.toml中添加相关依赖。[dependencies]  tower-web = "0.2"  # Jieba Chinese Work Segmentation  jieba-rs = "0.2"    # logging utils  log = "0.4.0"  env_logger = "0.5.12"    # Serializing responses, deserializing requests  serde = "1.0.70"3. 然后是我们的main.rs，与其他语言一样，在文件开始的部分引入外部依赖以及相关声明：extern crate jieba_rs;  #[macro_use]  extern crate tower_web;    #[macro_use]  extern crate log;  extern crate env_logger;    use std::iter::FromIterator;  use std::collections::HashSet;    use jieba_rs::Jieba;  use tower_web::ServiceBuilder;4. 接下来我们定义我们的服务资源ChineseTokenizer：#[derive(Debug)]  struct ChineseTokenizer {      inner: Jieba,  }    impl ChineseTokenizer {      pub fn new() -> ChineseTokenizer {          ChineseTokenizer { inner: Jieba::new() }      }        //对传入的字符串进行分词，并返回一个字符串向量      pub fn cut(&self, text: &String) -> Vec<String> {          let words = self.inner.cut(&text, true)              .into_iter()              .map(|word| word.to_owned())              .collect::<HashSet<String>>();            let mut words = Vec::from_iter(words.into_iter());            //由于使用HashSet进行去重会引入不确定性，               //因此对结果进行重排，使输出的结果有序。          words.sort();          words      }  }5. 定义了我们的服务资源后，我们来定义输入Web API的输入输出类型：#[derive(Debug, Extract)]  struct TokenizeRequest {      text: String  }    #[derive(Debug, Response)]  #[web(status = "200")] //当handler返回Ok(xx)时，返回200状态码  struct TokenizeResponse {      words: Vec<String>,  }6. 到目前为止，我们已经有了我们的服务资源，输入输出类型，接下来就到我们的重头戏了， Web 部分的实现，别担心，因为真的很简单。impl_web! {      impl ChineseTokenizer {          #[post("/tokenize")]          #[content_type("application/json")]          fn tokenize(&self, body: TokenizeRequest) -> Reqult<TokenizeResponse, ()> {              Ok(TokenizeResponse {                  words: self.cut(&body.text),              })          }      }  }7. 最后是我们的main函数：fn main() {      //初始化Logger      env_logger::init();      let addr = "0.0.0.0:8081".parse().expect("invalid address");      info!("listening on http://{}", addr);        ServiceBuilder::new()          .resource(ChineseTokenizer::new()) //注册我们的服务资源          .run(&addr)             //让我们的服务跑起来          .unwrap();  }8. 现在，我们通过命令RUST_LOG=chinese_segmentation=info cargo run --release来检验 一下我们的成果了。  服务在本地跑起来之后，我们可以通过命令 curl -H "Content-Type: application/json" -X POST -d '{"text":"中间件小哥"}' <url> 来测试一下我们的接口。  本地测试通过之后，就需要着手开始部署了，我们检查一下弹性云服务器的安全组的入方向 是否放开8081端口。2.2 API 部署API 网关集成了监控、流控、负载均衡等一系列功能，为开发者提供高性能、高可用的API 托管服务，在本次实践中，我们将我们的API部署在API网关中。1. 登录华为云API网关服务，选择“新建API”。    2. 填写API的基本信息  在本次实验中，选择无认证。      3. 定义API请求。  请求路径填为 /segment，方法为 POST      4.   定义后端服务。  请求方式设置为POST，在VPC通道这一项中，我们需要新建VPC通道。端口设置为8081， 并将其与弹性云服务器关联。      6. 创建完VPC通道后，回到API创建页面，填入相关信息：     7. 网关创建完成后，我们需要回到我们的弹性云服务器，将我们的后端服务器先跑起来：     RUST_LOG=chinese_segmentation=info nohup ./target/release/chinese_segmentation 2>&1 ~/api.log &  作为示例，这里使用nohup命令来跑我们的服务。但在生产环境中，建议使用 systemd等工具来跑服务。8. 服务在云服务器运行起来之后，将API发布至RELEASE环境中。     然后我们就可以和我们的API愉快地玩耍啦。 欢迎扫码查看更多精彩：