mesh

#ubuntu下编译烧录nordic芯片 具体参考官方说明： http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.meshsdk.v2.0.1%2Fmd_doc_getting_started_getting_started.html ##一 操作环境 目标系统: ubuntu16.4 开发板： PCA10040 nordic52832 ##二 环境安装 ###安装 nRF5x Command Line Tools 工具： 1，下载 https://www.nordicsemi.com/eng/nordic/download_resource/58852/27/55084982/94917 2，解压 /usr/nRF5x-Command-Line-Tools_9_7_2_Linux-x86_64/ 3, 设置环境变量: $ sudo gedit /etc/profile 把path添加到文件中 export PATH=/usr/nRF5x-Command-Line-Tools_9_7_2_Linux-x86_64/mergehex:$PATH export PATH=/usr/nRF5x-Command-Line-Tools_9_7_2_Linux-x86_64/nrfjprog:

简介： 如何借助云原生技术来提升交付速度？云原生时代背景下，研发的关注点又会有哪些转变？阿里云高级技术专家许晓斌通过本文分享从 IaaS 上云时代到 PaaS 上云时代的应用架构演进方向，以及云原生技术与应用架构演进的关系。 作者 | 许晓斌 阿里云高级技术专家 导读 ：如何借助云原生技术来提升交付速度？云原生时代背景下，研发的关注点又会有哪些转变？阿里云高级技术专家许晓斌通过本文分享从 IaaS 上云时代到 PaaS 上云时代的应用架构演进方向，以及云原生技术与应用架构演进的关系。 云原生已经进入了 PaaS 上云为主的阶段 阿里巴巴已经经历了 IaaS 上云的阶段，迈进到了 PaaS 上云的时代。在去年的“双11”，阿里巴巴就已经实现了电商核心系统的全面上云，这里的上云主要是在 IaaS 层。所谓 IaaS 主要就是对计算、网络、存储的虚拟化，经过了这个阶段，阿里巴巴就进入了 PaaS 上云的阶段。在 PaaS 上云这个阶段就需要使用更多的云产品，包括中间件、存储、缓存甚至是应用托管平台等。 IaaS 阶段和 PaaS 阶段其实存在很大的差别。在 IaaS 阶段，对于应用研发来说，所关心的往往就是基础设施和资源，通俗来讲就是虚拟机或者容器等，这些对应用架构几乎没有任何侵入。但是在 PaaS 上云阶段，当你使用云产品，比如云 Redis、云 RDS、云 OSS、云

unity角色换装的关键是更改角色部位上的物体的SkinnedMeshRenderer组件的属性： 更改mesh:mesh决定了部位的物体的外形，是主要的数据。 刷新骨骼：同一个部位下，不同的mesh受到的不同的骨骼的影响不同，因此更换mesh之后，还要更新SkinnedMeshRenderer下的骨骼列表的信息，也就是更换骨骼列表。 替换材质：一个SkinnedMeshRenderer下由多个材质作用，因此还需要更换材质列表。 操作过程为，从预制物体中获取的需要更换的相关部位的mesh，然后通过从预制物体的相关部位的SkinnedMeshRenderer下获取到影响该部位的骨骼列表，然后从场景角色的骨骼下获取到同名的骨骼列表，将该骨骼列表赋予到场景下角色的部位的SkinnedMeshRenderer下，并且获取到预制物体下该部位的材质列表，同样的将该列表赋予场景下角色的部位的SkinnedMeshRenderer下。 为了获取到更换的信息，需要由预制物体存储物体的相关信息。预制物体如下，每个部位下所有的物体都呈现，便于程序提取信息。 原模型如下： 场景下角色如下： 具体代码如下： 该脚本可以放在任何地方 using System.Collections; using System.Collections.Generic; using UnityEngine; public

一. 微服务架构面临的挑战 1 微服务核心价值：3S 2 微服务架构带来的运维挑战 1）单服务流量激增时扩容 2）调用链条变长，调用关系更加复杂 3）微服务拆分导致故障点增多 1）单服务变更性能影响如何评估？ 2）性能瓶颈在各微服务间漂移，如何做好性能测试？ 3）应对突发流量需求，扩容能否解决问题，如何扩容？ 4）服务实例数量众多，如何收集信息，快速定位性能问题？ 二. 华为云微服务性能保障解决方案设计 华为云微服务性能保障解决方案介绍 1 什么是ServiceMesh 一种基础设施层，服务间通信通过Service mesh转发 一种TCP/IP之上的网络模型 一个轻量的网络代理，与业务部署在一起 可靠的传输复杂网络拓扑中的服务请求，将服务变为现代的云原生服务 2 华为ServiceMesh整体架构 3 管理面服务治理能力 可人工介入，未运行时的mesher和侵入式框架提供配置下发 注册中心 下发配置 监控服务 调用引擎 4 数据面支持侵入式与非侵入式Mesher 即侵入式框架与非侵入式mesher 注册发现 执行路由策略 负载均衡 透明TLS传输 生成监控数据 5 微服务架构的关键性能瓶颈点 1）Mesher的性能损耗（1ms） 2）单服务的接口性能 3）全链路调用性能 4）服务伸缩能力 6 关于性能我们需要做哪些 开展分层验证，掌握服务的能力基线 1）单服务接口测试

尼尔：机械纪元 上周介绍了 Unity项目中的资源配置 ，今天和大家分享一个AssetBundle打包工具。相信从事Unity开发或多或少都了解过AssetBundle，但简单的接口以及众多的细碎问题也给工作带来较多的困扰。今天分享AssetBundle工具的实践与想法，相信这块内容对帮助理解AssetBundle有较大的帮助。 Unity提供了两种资源加载方式，一种是Resources，另外种就是AssetBundle。所有的资源只要放在Resources目录下，在打包的时候会自动打进去，并可以通过相应的接口加载。正常情况下Resources非常方便，可以满足日常的需求，但资源放Resources会带来资源更新上的问题。之前写过一篇文章 Unity资源目录及加载接口介绍 可以了解些细节。 假设首包所有资源都放Resources，后续更新资源的走AssetBundle，会发现AssetBundle和Resources的资源互相不兼容。当调整一个模型的材质参数后，对模型进行打包仍需要把Mesh，Texture等资源都打进去。这会导致更新包过大，同时在加载这个模型时，这些资源是不共用的，相同的资源可能在内存中存在两份。所以正常情况下，项目发布时所有需要更新的资源要打成AssetBundle。 正常项目中资源的提交与变更非常频繁，手工对每个资源配置Bundle费时费力，基本不可取

零. 概述 主要介绍下蓝牙协议栈（bluetooth stack）低功耗蓝牙搜索广播的流程以及协议栈的实现流程，BLE scan flow btsnoop以及流程在资料中的......\STM32_UBUNTU_BLUETOOTH\2-蓝牙资料\蓝牙协议分析\BLE搜索广播.log 一. 声明 本专栏文章我们会以连载的方式持续更新，本专栏计划更新内容如下： 第一篇:蓝牙综合介绍 ，主要介绍蓝牙的一些概念，产生背景，发展轨迹，市面蓝牙介绍，以及蓝牙开发板介绍。 第二篇:Transport层介绍,主要介绍蓝牙协议栈跟蓝牙芯片之前的硬件传输协议,比如基于UART的H4,H5,BCSP，基于USB的H2等 第三篇:传统蓝牙controller介绍，主要介绍传统蓝牙芯片的介绍，包括射频层（RF），基带层（baseband），链路管理层（LMP）等 第四篇:传统蓝牙host介绍，主要介绍传统蓝牙的协议栈，比如HCI,L2CAP,SDP,RFCOMM,HFP,SPP,HID,AVDTP,AVCTP,A2DP,AVRCP,OBEX,PBAP,MAP等等一系列的协议吧。 第五篇：低功耗蓝牙controller介绍，主要介绍低功耗蓝牙芯片，包括物理层（PHY），链路层（LL） 第六篇：低功耗蓝牙host介绍，低功耗蓝牙协议栈的介绍，包括HCI,L2CAP,ATT,GATT,SM等 第七篇：蓝牙芯片介绍

简介： 云原生是零售云的最重要的技术底座，云原生是什么，会走向哪里，在零售2B交付的场景上该如何应用，怎么能够结合帮助建设零售云系列产品体系，值得我们的思考和探索，也将有效指导我们接下来几年的零售云项目和产品建设。 零售云是阿里三朵业务云：零售云、金融云和政务云之一，将开辟阿里在电商、零售行业的新蓝海，2B快速交付、赋能合作伙伴更快业务增长和节省成本。云原生是零售云的最重要的技术底座，云原生是什么，会走向哪里，在零售2B交付的场景上该如何应用，怎么能够结合帮助建设零售云系列产品体系，值得我们的思考和探索，也将有效指导我们接下来几年的零售云项目和产品建设。 云原生定义、阿里巴巴云原生架构方法论及产品体系 云原生定义 Cloud Native 翻译为云原生，是 Matt Stine 提出的一个概念，它是一个思想的集合，包括 DevOps 、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。Cloud Native 既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。Cloud Native 也可以说是一系列技术、企业管理方法的集合。 云原生的本质 云原生本质是以应用为中心

导读 9月最新产品动态简报： 1. 腾讯微服务平台TSF：新增不健康实例的监控信息；新增“屏蔽实例”的新功能。 2.消息队列CKafka：访问白名单配置可使用IP网段；支持在Partition维度设置offset；监控支持按带宽百分比进行监控；支持控制台查询消息。 3.分布式事务DTF：用户可在本地调试分布式事务。 4.分布式任务调度TCT：支持分片任务断点续跑能力；开放任务调度API；分片任务支持可选分片参数告警选项；分片任务支持参数传递。 ● 产品最新动态 ● 腾讯微服务平台TSF 产品介绍：稳定、高性能的微服务技术中台。 新功能特性 1. 更完善的服务监控能力：新增不健康实例的监控信息 在服务治理详情页，服务实例列表上增加离线的实例展示，同时显示实例的注册时间和上一次心跳时间。帮助用户查看由于异常而下线的实例信息，当服务实例和注册中心的连接断开时，用户能了解上一次心跳的时间和注册时间。 2. 更灵活的服务治理：新增屏蔽实例操作 在服务治理详情页，服务实例增加【屏蔽实例】操作，启用该功能后，实例不会被其他服务发现，避免流量发送到问题实例上。例如：当服务实例不可用但仍连接到注册中心时，为了避免流量发送到问题实例上可手动下线实例。 扫码了解更多相关信息 消息队列CKafka 产品介绍：分布式、高吞吐量、高可扩展性的消息服务，具备 数据压缩 、同时 支持离线和实时数据处理 等优点。

作者 | 郭浩（项升） 阿里巴巴经济体 RPC 框架负责人 导读： 本文整理自作者于 2020 年云原生微服务大会上的分享《Dubbo3.0 - 开启下一代云原生微服务》，主要介绍了关于思考 rpc 框架层面，功能演进的方向是什么？以及怎么更好地支持云上的多语言开发的新思考。 看 到这个题目，大家可能会有几个问题，比如，什么是云原生微服务？Dubbo3.0 是什么？和目前的 Dubbo2.0 有什么区别？用了 Dubbo3.0 会带来哪些业务视角的好处？ 后面的分享会对这些问题逐一解答。 这次分享分为以下几个环节： Dubbo 的演进历史 Dubbo 的开源现状 定义 Dubbo3.0 分享 Dubbo 3.0 目前取得的一些成果 考虑到有些同学对 Dubbo 可能不太熟悉，在介绍背景之前，我先简单介绍一下 Dubbo 是什么。简单地说，Dubbo 是基于 Java 的 RPC 框架。一个 RPC 框架至少由数据格式、传输协议和连接管理组成，这三点也是构成核心。Dubbo 能够被广泛应用主要有两个原因： 一方面是较好的插件机制支撑了多种扩展，这些扩展在不同业务场景和基础架构中能分别发挥最大优势； 另一方面不同于普通的 RPC 框架，Dubbo 的服务治理功能让其在易用性方面脱颖而出，比如路由规则能够支持灵活多样的运行时动态路由，可以基于此功能实现灰度、ABTest、流量回放等功能。

目录 文章目录 目录 微服务架构的问题 如何拆分服务 服务间如何通信 微服务框架 API 网关 配置中心 Service Mesh 文档 微服务治理 监控 链路跟踪 日志分析 服务中心 熔断、服务降级、限流 微服务框架 Service Mesh 流量治理 微服务架构的问题 微服务架构中，服务之间会有错综复杂的依赖关系，例如：一个前端请求一般会依赖于多个后端服务，称为 “1=>N 扇出”。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源（线程，队列等）被耗尽，造成所谓的雪崩效应（Cascading Failure），严重时可致整个网站瘫痪。另外，微服务架构整个应用分散成多个服务，定位故障点非常困难。 服务组合 服务依赖： 微服务架构虽然逻辑设计上看是完美的，但就像积木搭建的华丽宫殿一样，经不起风吹草动。在解决了旧问题，也引入了新的问题： 微服务架构整个应用分散成多个服务，定位故障点非常困难。 稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。事实上，在大访问量的生产场景下，故障总是会出现的。 服务数量非常多，部署、管理的工作量很大。 开发方面