mesh

导读 ：2015 年，阿里云和华大基因立下一个目标：到 2020 年，要在 24 小时完成个人全基因组测序。这在当时是一个几乎被认为不可能的挑战。 而在 2020 年刚开始的第 17 天，我们就实现了这个目标！并且把个人全基因组测序分析做到只需要 15 分钟，不到一顿饭的功夫。 云端实现大规模弹性调度计算 图 1 - WGS 分析过程示意图 基因计算所面临的挑战不同于常规计算，大数据生信分析平台需要具备 PB 级的数据处理能力：存储与压缩、清理及管理、低成本保存的能力；快速、安全的云端分发共享；基因数据的安全隐私保护、大规模数据挖掘；按需调度和弹性扩容等。 此次方案由华大 DNBSEQ 自主测序仪、BGI Online 混合云架构、阿里云容器服务 ACK/AGS 基因服务以及赛乐基因 GPU 加速算法的深度融合而成。其中，华大基因联合阿里云的整体技术架构为云原生容器混合云，实现云上云下资源一体，跨地域集群统一管理。凭借云端的自动伸缩特性，实现大规模弹性调度计算。 在使用上，该方案用户无需关心基因数据处理过程中的计算资源、处理逻辑、数据缓存等细节，只需将下机数据 (FASTQ文件) 上传至 OSS，以及授权 Bucket 给 AGS 服务，即可高效、快速完成整个数据分析流程，并将结果数据上传到用户期望的存储空间。 这套端到端解决方案，无缝衔接测序平台和基因云平台，全面支持包括

随着以函数即服务（Function as a Service）为代表的无服务器计算（Serverless）的广泛使用，很多用户遇到了涉及多个函数的场景，需要组合多个函数来共同完成一个业务目标，这正是微服务“分而治之，合而用之”的精髓所在。本文以阿里云 函数计算 为例，试图全面介绍函数组合的常见模式和使用场景，希望有助于选择合适的解决方案。 虽然本文主要介绍的是函数组合，但是基本思想也可用于服务组合。 函数同步调用函数 在这种模式里，函数直接调用 InvokeFunction 同步 API 执行一个或者多个函数，等待被调用函数返回结果，然后继续执行。这是一个有些争议的模式，不使用同步调用通常有以下原因： 从费用的角度：由于函数计算按照函数实际执行时间收费，调用者在等待被调用函数返回前也会产生一定费用。 执行时长限制：由于函数最长执行10分钟，这就决定了调用的其它函数执行时间之和有限。 从容错的角度：被调用者出错会直接影响调用者，如果这个调用链很长，则这种错误会一直蔓延到最初的调用者，容错性较差。同时由于执行时长限制，调用者通常不容易针对错误做长时间重试。 上面的理由是在有些场景下成立的，但是微服务最经典最常见的组合方式就是同步调用，函数作为微服务的一种实现方式，这种同步调用的需求是不可回避的，在有些场景下采用同步调用模式是值得考虑的，这些场景包括：

本文将介绍微服务架构和相关的组件，介绍他们是什么以及为什么要使用微服务架构和这些组件。本文侧重于简明地表达微服务架构的全局图景，因此不会涉及具体如何使用组件等细节。 要理解微服务，首先要先理解不是微服务的那些。通常跟微服务相对的是单体应用，即将所有功能都打包成在一个独立单元的应用程序。从单体应用到微服务并不是一蹴而就的，这是一个逐渐演变的过程。本文将以一个网上超市应用为例来说明这一过程。 最初的需求 几年前，小明和小皮一起创业做网上超市。小明负责程序开发，小皮负责其他事宜。当时互联网还不发达，网上超市还是蓝海。只要功能实现了就能随便赚钱。所以他们的需求很简单，只需要一个网站挂在公网，用户能够在这个网站上浏览商品、购买商品；另外还需一个管理后台，可以管理商品、用户、以及订单数据。 我们整理一下功能清单： 网站 用户注册、登录功能 商品展示 下单 管理后台 用户管理 商品管理 订单管理 由于需求简单，小明左手右手一个慢动作，网站就做好了。管理后台出于安全考虑，不和网站做在一起，小明右手左手慢动作重播，管理网站也做好了。总体架构图如下： 小明挥一挥手，找了家云服务部署上去，网站就上线了。上线后好评如潮，深受各类肥宅喜爱。小明小皮美滋滋地开始躺着收钱。 随着业务发展…… 好景不长，没过几天，各类网上超市紧跟着拔地而起，对小明小皮造成了强烈的冲击。 在竞争的压力下

作者 | 高相林、陈俊、陈有坤、敖小剑 业界要闻 国内首个 Kubernetes SIG-Cloud-Provider 子项目揭秘 阿里云作为坚定的云原生计算推动者，贡献了阿里云上运行 Kubernetes 的最佳开源组件，成为 SIG Cloud Provider 子项目的国内首个云厂商。2020 年 2 月 12 日上午 10：00，阿里云 Kubernetes 团队召开了首次线上网络研讨会。 什么技术，让阿里拿下国家技术发明奖？ 新年伊始，国家科学技术奖励大会在北京人民大会堂隆重举行。阿里云获得国家技术发明奖、国家科技进步奖两项国家大奖。这是互联网公司首次同时荣获两大国家科技奖，也实现了互联网公司在国家技术发明奖上零的突破。 CNCF 发布 containerd 旅程报告 该报告对 containerd 发展过程进行了总结和分析。 上游重要进展 Kubenetes Build Kubelet without Docker 该 KEP 旨在提出一个方案，使得编译 Kubelet 不再依赖 Docker 相关的代码。 Fix statefulset conversion 修复了 statefulset 相关资源转换中的 bug，该 bug 会导致无法多次 apply 同一个 statefulset。 Add code to fix kubelet/metrics memory

作者 | 唐志龙（鲲龙） 阿里巴巴高级开发工程师 导读 ：本文总结了熟悉系统主要分三部分：业务学习、技术学习、实战。每部分会梳理一些在学习过程中需要解答的问题，这些问题随着经验的积累需要逐步补充完善。 前言 开发人员经常会面临下面一些场景： 新人入职，需要学习已有系统，作为 landing 的一部分，如何学习？ 被拉过去参与一个陌生系统的迭代开发或者系统维护（bugfix），如何快速上手？ 同事离职或转岗，需要把系统交接给你，怎么去接？ 内心 os：这是一口锅吗？ 这样的场景多了，就需要去梳理常见问题以及应对方法，方便后续遇到类似场景可以快速应对。本文总结熟悉系统主要分三部分：业务学习、技术学习、实战。每部分会梳理一些在学习过程中需要解答的问题，这些问题随着经验的积累需要逐步补充完善。 业务学习 业务学习就是从业务角度去学习系统，我们需要了解系统的客户是谁、使用人是谁、带来了什么价值，系统提供了哪些功能等。不清楚业务，就等于不知道系统在干什么。技术是为业务落地而服务，清楚了业务才知道怎样用技术更好地服务业务，所以业务学习是熟悉一个系统的首要任务。这块主要的学习方式有跟产品、运营、开发沟通，学习产品设计文档文档、PRD、自己使用系统，还有一些常见图，如产品功能架构图、业务流程图、功能树，用例图等。 常见问题： 系统所在行业的情况是怎样？ 系统的目标用户是谁？比如是给公司高层做决策用

英文原文 蒙皮 所有蒙皮都存储在资源的皮肤数组中。每个皮肤都由inverseBindMatrices属性定义(该属性指向一个带有IBM数据的访问器)，用于将蒙皮坐标变换到每个关节相同的坐标系下; 以及一个关节数组属性，该属性列出用作蒙皮动画的关节的节点索引。关节的顺序是在 skin.joints 数组中定义的，它必须与inverseBindMatrices数据的顺序相匹配。骨架属性(如果存在)指向作为关节层次结构的公共根的节点，或者指向公共根的直接或间接父节点。 注：这里IBM指的是inverseBindMatrices 实现注意: 定义如何将蒙皮的几何形状与关节一起使用的矩阵(“绑定形状矩阵”)应该预乘到网格数据或反向绑定矩阵。 实现注意: 客户端实现应该只将骨骼根节点的转换应用于蒙皮网格物体，而忽略蒙皮网格节点的转换。在下面的示例中，应用node_0的平移和node_1的缩放，而忽略node_3的平移和node_4的旋转。 { "nodes": [ { "name": "node_0", "children": [ 1 ], "translation": [ 0.0, 1.0, 0.0 ] }, { "name": "node_1", "children": [ 2 ], "scale": [ 0.5, 0.5, 0.5 ] }, { "name": "node_2" }, {

一、背景 有赞是 SaaS 公司，向商家提供了全方位的软件服务，支撑商家进行采购、店铺、商品、营销、订单、物流等等管理服务。 在这个软件服务里，能够满足大部分的商家，为商家保驾护航。 SaasS 形成是追求共性的过程，SaaS 生态化是求同存异的过程，所以当我们能够满足大部分客户需求时，我们得考虑大客户的个性化需求场景。 1.1 客户分析 上面讲到我们要求同存异，我们要满足个性化需求，这里简单讲解一下大客户的价值，下面就不区分优势和劣势了，都放一起： 中小客户 企业规模小，付费能力相对弱一些； 企业周期短，无法很好的保证续费； 大部分停留使用产品基本能力，说明软件可替代性强，难形成粘性； 但是数量庞大； 获客成本相对低一些； 大客户 企业规模大，付费能力强； 发展稳定，企业周期长，能够保证续费； 有利于形成标杆案例，用于推广； 只要能实现需求，对资金要求和价格不敏感； 定制需求多，一旦定制，替代成本高，粘性好； 简单罗列了一下，当然其他点还有很多，对比会发现，SaaS 会满足大部分客户的需求，尤其是中小客户，而且中小客户量可能会达到90%以上，但是中小客户续费能力弱会导致销售成本高，同时无法形成标杆，很难有行业影响力；大客户付费能力很强，只要能够满足需求，可能不太会对相对高的价格说不，但是基本上每个大客户都有定制需求，而且一旦达成合作，可以稳定的续费。 1.2 有赞云是什么

概述 与Zigbee、Thread等其他MESH组网技术相比，蓝牙Mesh能够在不需要额外硬件成本的前提下实现手机与蓝牙Mesh节点的通信，无疑是一个巨大的优势，因此本文将着重讲解手机是如何与蓝牙Mesh设备通信的，希望给读者以清晰的理解。 手机软硬件 手机软硬件的设计问题决定了蓝牙Mesh节点与手机通讯的方式，这是问题的出发点，因此本文将从手机的软硬件讲起，一步步洞悉其全貌。 硬件 现在的智能手机，不管是苹果或其他众多安卓厂家，蓝牙无疑都是手机标配，在笔者书写本文时，蓝牙已经演变到5·2版本，当然受限于整个供应链的问题，手机上携带的蓝牙版本目前还没有到最新版本，目前市场上蓝牙版本的分布以4-2和5-0为主，而蓝牙Mesh所要求的是蓝牙版本在4-0及其以上即可，因此，读者不必担心手机的硬件约束问题。另外，需要科普的是，从蓝牙4-0开始，蓝牙实际开始走两条路线：传统路线（Classic BT）也就是所谓的经典蓝牙，这种蓝牙通常注重于数据的高速传输，例如：蓝牙耳机，蓝牙音响等，第二条路线（Low Energy）低功耗蓝牙，该类型的蓝牙注重于功耗的低耗，例如：智能手环，智能锁等。相对于手机来说，一般都是集成这两类，我们称之为双模蓝牙。对于蓝牙音响一般都是单纯的经典蓝牙以及智能手环一般都是单纯的低功耗蓝牙，我们将这些分类为单模蓝牙

1， Assimp可以导入几十种不同格式的模型文件（同样也可以导出部分模型格式）。只要Assimp加载完了模型文件，我们就可以从Assimp上获取所有我们需要的模型数据。 Assimp把不同的模型文件都转换为一个统一的数据结构，所有无论我们导入何种格式的模型文，件，都可以用同一个方式去访问我们需要的模型数据。 2 ， 当导入一个模型文件时，即Assimp加载一整个包含所有模型和场景数据的模型文件到一个scene对象时，Assimp会为这个模型文件中的所有场景节点、模型节点都生成一个具有对应关系的数据结构，且将这些场景中的各种元素与模型数据对应起来。下图展示了一个简化，，的Assimp生成的模型文件数据结构： 所有的模型、场景数据都包含在 Scene 对象中，如所有的材质和Mesh。同样，场景的根节点引用也包含在这个scene对象中。 场景的根节点( Root node )可能也会包含很多子节点和一个指向保存模型点云数据mMeshes[]的索引集合。根节点上的mMeshes[]里保存了实际了Mesh对象，而每个子节点上的mMesshes[]都只是指向根节点中的mMeshes[]的一个引用(译者注：C/C++称为指针，Java/C#称为引用)。 一个 Mesh 对象本身包含渲染所需的所有相关数据，比如顶点位置、法线向量、纹理坐标、面片及物体的材质。 一个Mesh会包含多个面片。一个

Service Mesh（服务网格）会是今年微服务生态的主角吗？从趋势来看，众多企业正在将这项理微服务复杂性的技术/工具，搬进他们的IT“火药库”之中。 什么是Service Mesh？ 根据Linkerd CEO William Morgan定义，Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理。 Service Mesh与传统基础设施层不同之处在于，它形成了一个分布式的互连代理网络，以sidecar形式部署在服务两侧，服务对于代理无感知，且服务间所有通信都由代理进行路由。 为什么需要Service Mesh？ “Smart endpoint and dumb pipes”是微服务架构在集成服务时采用的一个核心理念，这一理念改变了过去臃肿集中的ESB（企业服务总线），无疑是正确方向上的一大进步，但同时也给我们出了一些难题——多智能才不会过于智能，而服务轻重大小的程度如何拿捏？我们应该如何处理微服务系统中服务间交互的复杂性？放在服务内部还是外部？如果是内部，如何处理业务逻辑关系，或者应该与基础设施更为相关？如果是外部，如何避免重蹈ESB的覆辙？ 皮的不谈，先来看看处理服务间通信时需要关注的点： 服务发现 负载均衡 路由 流量控制