阿里云链路追踪（阿里云链路追踪怎么用）

本文目录一览：

• 1、阿里云数据产品
• 2、阿里云IoT云产品交流会：物联网痛点多，阿里能做什么？
• 3、Istio是什么？
• 4、阿里云消息中间件（MQ）探秘

阿里云数据产品

1.客流数字化

（1）周边潜客

（2）到店客流

（3）店内动线

客群画像：结合电商及阿里生态丰富的数据资源，深度刻画人群画像。

行为路径分析：全链路分析目标用户的线上及线下的消费行为与位置轨迹。

周边潜客挖掘：结合人群画像与位置信息，挖掘周边及商圈目标潜客。

2.客户链接

（1）线上营销

（2）线下营销

（3）效果评估

多渠道人群推广：基于丰富的用户位置信息，通过阿里妈妈、手淘、短信等多渠道对周边人群做触达。

效果分析：全链路跟踪营销触达用户的消费行为，跟进分析触达后的效果。

3.市场研究

（1）门店区域行业分析

（2）市场潜力分析

产品陈列优化：分析区域内行业属性，指导门店产品陈列。

营销策略指导：分析门店服务范围内人群特征，基于目标人群画像，指导销策略。

研发策略优化：根据门店周边区域内行业属性及变化趋势，指导品牌商进行研发策略的优化。

4.经营辅助（营销选址）

（1）人群流动分析

（2）目标人群区域分析

开店选址：结合城市人群流动信息，及目标用户的分析，为品牌商挑选最优的开店地址。

营销选址：分析目标人群流动信息，及集中区域，指导营销地址选择。

阿里云IoT云产品交流会：物联网痛点多，阿里能做什么？

经历了互联网、移动互联网，人类正在迈入万物互联、万物智能的世界。5G、IoT、云计算、人工智能成为 社会 关注的对象，数字经济成为政策宣传的重点，各种概念和解释产生，使得当下有很多话题可以讨论。

数字经济背景下，企业竞争最核心的能力是什么。

不同行业发展数据智能的潜力有何不同？

企业如何高效进行物联网应用开发？

企业对云平台的使用体验如何

对于类似问题，阿里云IoT、ICA联盟一直希望与行业人士进行对话。上周，ICA联盟物联网万亿生态伙伴聚合沙龙在杭州举办，活动以“粘合行业碎片，共创IoT基石”为主题，以阿里云IoT云产品为话题，吸引近200名行业人士到场交流。

4位嘉宾依次上台分享

物联网需要化繁为简

物联网产业链很长，覆盖了感知层、网络层、应用层三大层次。它改变了传统的商业运作方式，让商业 社会 变得更加复杂。

首先，物联网让产品变得复杂。增加了传感器、模块等部件，需要进行更多的开发管理。

其次，物联网让需求变得复杂。企业从生产产品变成了提供个性化的服务。

就是这两个变化，让产业体会到很多新的发展痛点。

1. 物联网开发过程链路极长，从获客到交付典型过程常常要经历十几个环节。

2. 将软件研发、硬件研发、嵌入式研发，云产品的购买，施工/安装/维修费用计算在内，物联网开发成本极高。

3. 调查表示目前78%的用户需求为定制化需求，65%的物联网软件需要定制化开发，这导致软件复用性较低。

4. 设备联网、用户交互产生海量数据，众多场景亟需数据实时分析、可视化的能力，提升使用效率及用户体验。

新的形势促进了变化的发生，计算力的进步预示着满足更大的信息处理能力，更强的灵活性。

物联网平台在整个产业链中地位，也从当年行业所关注的“要不要上云”，随着企业自身数据资源日渐丰富，应用数据意愿的显著增强，过渡到了“如何高效地上云”。

物联网云平台，由此更直接地承担起IoT产业“基础设施”的角色，为物联网项目的规模化落地减负降压。

阿里云IoT 产品结构

阿里云 IoT 资深产品专家JASON CHEN从各个原子化产品角度，描绘了阿里云IoT的全局样貌。包含物联网操作系统AliOS Things、边缘计算Link Edge、网络管理平台Link WAN、开发平台IoT Studio、物联网设备接入与管理、物联网数据分析、物联网市场Link Market、物联网安全Link Security等功能在内，展现阿里云为各类IoT场景和行业开发者赋能的能力。

将各个基础产品分别阐述，体现出阿里云IoT强化基础设施角色，希望阿里云的产品技术变成合作伙伴解决方案一部分的心态。再次印证阿里云智能总裁张建锋在3月阿里云峰会上所提出的“被集成”口号，阿里云的重要转变已经发生。

以下，我们就将重新认识阿里云IoT云产品。

物模型

阿里云 IoT 技术运营专家薛圆在交流中表示，ICA联盟推出物模型，定义物联网设备模型与属性。通过对任意物联网设备建模，合作伙伴共创设备数据标准模型，确保数据标准的准确性、合理性，实现设备间的互联互通互懂。

类似将拼图碎片整理成更完整的拼图模块，物模型将实现碎片数据结构化、差异模型统一化、烟囱场景联动化、软硬一体标准化的目标，帮助用户缩短开发时间、标准化开发工具。

物联网数据分析

在任何商业活动中，数据都是一种资本，数据分析是可以产生创新收益的手段。

阿里云 IoT 高级产品经理腾春艳在对物联网数据分析产品介绍时表示，阿里云为物联网开发者提供数据分析服务，覆盖了数据存储、清洗、分析及可视化等环节，有效降低数据分析门槛，助力物联网开发。

在空间数据可视化方面，阿里云IoT提供二维、三维空间数据的可视化功能，致力用数据连接真实世界。比如对智能停车场的车场现状、排队数据、收入进行分析；比如定义电子围栏，当物品超出围栏范围时，配置报警；比如在物流追踪、设备管理等物联网低频定位场景下，展示设备轨迹；比如在三维空间可视化需求下，基于阿里云物联网平台构建监控、展示、控制为重点的BIM可视化系统，实现园区、建筑、楼层、房间、设备的逐级可视化。

图：阿里云IoT数据分析产品架构

IoT Studio 物联网应用开发

如前文所述，物联网产业的痛点很多都落在了开发上。阿里云 IoT 产品专家曲文政在演讲中再次阐明IoT Studio作为物联网开发者生产力工具的产品定位与功能。

1. 一站式完成云端SaaS 搭建 ：用户可以通过IoT Studio轻松搭建出简单IoT SaaS系统，或构建出部分功能集成在原有的SaaS系统中

2. 可视化搭建，降低定制化成本 ：通过可视化搭建、服务编排的方式让一般嵌入式开发者经过简单培训也可以快速搭建出各种物联网应用；

3. 提供AI 等高阶能力： 将高阶能力输出给开发者，增加营收，扩展业务边界；

4. 后续提供更多解决方案模版： 通过模版的方式给用户提供即刻可用的IoT SaaS解决方案（包含硬件、嵌入式代码、页面/APP、服务）。

整体而言，IoT Studio作为开发工具，向上承接业务需求帮助用户快速搭建SaaS，向下汇聚能力将阿里体系的能力更快更好地输出给用户，是阿里云IoT产品中承上启下的关键一环。

图：IoT Studio 产品架构

结语

在 汽车 行业，定制化需求增多，产品的敏捷规划、全生命周期运维是厂商的关注焦点；在零售行业，企业追求着精准化营销的目标；在农业，看天吃饭需要向精准化种植转变……

未来的各行各业，在面对各种不确定的因素之时，都希望用数据说话，用数据管理、用数据决策。

在这样的产业愿景之中，阿里云IoT将继续践行技术和商业基础设施的角色，覆盖物联网云管边端开发环节，提供满足各类开发者需要的基础产品，助力合作伙伴创新模式，发展商机。

Istio是什么？

Istio是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语，意思是”起航“使用istio可以很简单的创建具有负载均衡、服务间认证、监控等功能的服务网络，而不需要对服务的代码进行任何修改。你只需要在部署环境中，例如Kubernetes的pod里注入一个特别的sidecar proxy来增加对istio的支持，用来截获微服务之间的网络流量。

特性：

使用istio的进行微服务管理有如下特性：

流量管理：控制服务间的流量和API调用流，使调用更可靠，增强不同环境下的网络鲁棒性。可观测性：了解服务之间的依赖关系和它们之间的性质和流量，提供快速识别定位问题的能力。

策略实施：通过配置mesh而不是以改变代码的方式来控制服务之间的访问策略。

服务识别和安全：提供在mesh里的服务可识别性和安全性保护。

未来将支持多种平台，不论是kubernetes、Mesos、还是云。同时可以集成已有的ACL、日志、监控、配额、审计等。

正是 Istio 的出现使 “Service Mesh”（ 服务网格 ） 这一概念开始流行起来。在深入介绍 Istio 的细节之前，让我们首先简单地了解一下 Service Mesh 是什么，以及它的重要性体现在哪里。我们都已经了解单体应用所面对的挑战，一种显而易见的方案是将其分解为多个微服务。虽然这种方式简化了单个服务的开发，但对于成百上千的微服务的通信、监控以及安全性的管理并不是一件简单的事。

直至目前，对于这些问题的解决方案也只是通过自定义脚本、类库等方式将服务串联在一起，并且投入专门的人力以处理分布式系统的管理任务。但这种方式降低了各个团队的效率，并且提高了维护的成本。这正是 Service Mesh 大显身手的时机

Istio以及Service Mesh的未来

阿里云消息中间件（MQ）探秘

阅读字数： 2513 | 5分钟阅读

获取嘉宾演讲视频及PPT ，请点击：

阿里巴巴中间技术专家不铭从功能特性、技术架构、最佳实践、案例分析四个方面进行了《Aliware-MQ消息队列》的分享。

Aliware-MQ是阿里云提供的企业级互联网架构的核心产品，基于高可用分布式集群技术，支持海量高并发和万亿级消息流转，支持海量的消息堆积，支持高可靠/高可用方案，提供了运维、监控等一系列完整的配套服务。

如上图所示，从消息的维度来看分为普通消息、顺序消息、定时消息和事务消息等四种消息,无论是发送哪种消息客户端都支持熔断机制，即如果发现发送目标节点有性能问题，客户端会自动进行熔断，把有问题的节点排出去，保证消息发往可靠性最高的机器。管理方面已经支持消息的查询、消息回溯、消息全链路轨迹和监控报警机制。性能上MQ已经达到了百亿级的堆积能力，毫秒级的投递延迟，支持万级节点高并发，集群水平热扩缩。消息消费方面，支持失败后的消息重投机制，失败的消息会重新投递到队列中去，现在最多支持16次重投。

上图是Aliware-MQ的功能架构。左边是控制台的管理，可以在上面做发布订阅管理。右边目前的接入方式是SDK支持TCP协议，同时也支持HTTP接口，以及面向手机终端的MQTT协议。

OpenAPI是MQ提供给用户的管控方式，用于实现一系列资源管理和运维功能，用户可以通过Open API查询所需要的任何东西。

上图中是我们今年推出的一个MQ移动物联网套件。之前的客户端，不管是上游还是下游收发都是用各自的服务器。但是今年我们有了移动物联网套件，可以直接面向终端设备。比如手机、汽车等移动设备利用移动物联网套件，通过一个网关就可以直接和消息系统打通。

Aliware-MQ的消息系统是基于队列。队列要保证数据安全，是支持高并发和高性能读写的最基本元素。

如上图所示，Producer是消息发送集群，下游的Consumer是消费者集群，都依赖于MQ的SDK。Broker是消息服务器，所有的消息都发送到Broker上面；Name Server和ZK功能类似，用来做服务发现。Producer要从Name Server获取到Topic在哪个节点上，订阅Topic时需要知道Topic从哪里取，同样需要Name Server。Broker上的Topic信息会定时在Name Server上注册，Producer和Consumer在交互之前会从Name Server上获取目标。

图中的master是主机，slave是备机，主备之间会做数据同步，有异步和同步两种方式。一个master可以布多个节点，这个根据自己的成本来决定。如果扩容的话，只要直接布一台master即可，它会定时地将Topic注册到Name Server上，发送方和订阅方也会定时地感知这个过程，整个扩容的过程对于用户来说大概30秒就能完成。

Aliware-MQ所有数据存储在Commit Log里，它在实现上就相当于一个文件夹，每次会生成一个1G的文件。不管哪个Topic写过来的消息都会直接写入这个文件中，这个文件写满后再直接写下一个。

针对每一个Topic，要在业务层面对它进行区分，所以我们做了一层索引。例如在上图中有5个队列，每个队列都会生成定长的索引文件，通过索引，可以找到这条消息当前处于哪个CommitLog文件的某个具体位置中。

这样存储结构，保证了无论多少个topic，CommitLog的写是顺序的，能较大的保证MQ的写入性能。

Aliware-MQ的负载均衡是按照队列维度来做的，消费的时候会把topic的队列平均分配给消费实例。比如有2个消费实例，topic队列是4个，那么每个消费实例就消费2个；而如果共有5个队列，那么就是是1个消费2个，另1个消费3个。一个队列同一时间只会被一个消费实例消费，所以当出现队列数量小于消费实例数量的情况时，就会有消费实例出现空闲，这个时候可以根据业务实际情况手动通过工具将队列数量调大。

消息写进来都是先放在Java堆里，然后再落盘。如果用户要消费的消息都在内存里，那么就可以很快的读取到。但是如果用户消息堆积比较久，消息已经不在内存里而是存储在了磁盘中，这个时候就需要去磁盘里取数据，然后加载到内存里面读取出来。

Aliware-MQ的刷盘策略有异步和同步两种。异步到内存就返回成功，同步写则一定是消息刷到磁盘中才会返回成功。这种刷盘方式可以根据业务的具体需求进行配置，从写入的性能来看，异步写的性能肯定是会比同步的好。

从发消息的角度来看，如果发送失败，会有补偿机制。MQ的客户端会做三次重发，一台机器发送失败之后会默认往另外两台机器再尝试，如果三次都失败了才会把最终的失败结果传回，这个时候用户需要自己对发送异常进行相关处理。

有幂等要求的业务，Consumer在使用的时候需要自己做去重操作，在一些场景下，如客户端本地等待超时等，是无法保证消息完全不重复的，因此用户在进行系统设计时需要考虑到这一点。

Aliware-MQ目前支持的消息最大是4M，消息越小，性能越高。定时消息是支持消息的定时投递，可以自行设置要投递的时间，最长是40天。事务消息通过两阶段的提交的方式，来解决分布式事务问题。顺序消息可以采用全局顺序、分区顺序，严格保证消息的顺序。

Aliware-MQ的使用场景主要有系统间异步解耦、分布式事务、异构数据复制与分发、双十一大促的削峰填谷、大规模机器的Cache同步、日志服务和IM实时通信以及实时计算分析。

MQ顺序消息分为全局有序和队列有序。全局有序是从指所有消息发出开始，下游的接收方都是按照顺序接收；队列有序则是将消息进行区块分区，同一个分区内的消息按照先入先出的顺序进行顺序消费，保证一个队列只会被一个进程消费。

当一个交易系统下单之后，会发一条消息到MQ，购物车接收消息把购物车里的状态清空。如果这时交易消息发送失败，购物车就无法清空，对于数据来说这就是一个脏数据。面对这种情况我们有事务消息可以解决这个问题，在交易开始时先发送一条半事务消息，然后交易系统开始下单，所有事情做完之后再提交半事务，这时只有主动提交成功，消息队列才会将这条消息实际发送给用户。如果交易下单过程失败，则可以主动回滚这条消息，购物车和交易系统之间可以做到没有脏数据。

双十一大促时，各个分会场会有玲琅满目的商品，每件商品的价格都会实时变化。使用缓存技术也无法满足对商品价格的访问需求，缓存服务器网卡跑满。访问较多次商品价格查询影响会场页面的打开速度。于是MQ提供了一种广播机制，本来一条消息只会被集群的一台机器消费。如果使用广播模式，那么这条消息会被集群下的所有节点消费一次，相当于把价格信息同步到需要的每台机器上，可以取代缓存的作用。

实时计算功能主要是做一个消息总线，业务系统自动采集数据，把消息分发达下游的实时计算系统里，根据实时计算结果来给业务方做服务。

我今天的分享就到这里，谢谢大家！