带宽

摘要：带宽要变更， 费用不会算？要问怎么办，小课带你看！ 和小课一起来学习弹性公网IP（EIP）带宽的计费形式、应用场景及变更影响吧~本文分享自华为云社区《【云小课】根底服务第53课 不理解带宽计费规定？看这里！》，原文作者：云小萌 。 在应用弹性公网IP（EIP）产品后，你是否遇到过以下几种场景： 业务访问量变大，带宽貌似不够用，须要进步带宽了按需计费的带宽，因为业务趋于稳定，思考转换为包年包月模式了......那么各种带宽的计费规定及带宽变更的影响都是怎么的呢？ 带宽要变更，费用不会算？要问怎么办，小课带你看！ 明天小课就带大家一起理解一下各种计费形式的特点、应用场景及变更后对费用的影响。 计费模式弹性公网IP（EIP）反对包年包月和按需付费两种计费模式，和带宽计费形式组合，共包含包年包月按带宽计费、按需按带宽计费、按需按流量计费、按需-退出共享带宽计费四种计费形式。 批改带宽大小在按需与包年包月两种计费模式下，批改带宽大小对费用产生影响如下： 批改带宽计费形式计费形式间的变更关系及对费用影响如下： 课堂练习以上的各种带宽变更场景大家是不是都理解了呢？那么看个应用案例加深一下了解吧~ 例如：客户于2018/11/1 购买了1Mbit/s的带宽，购买时长为1个月，此时价格为18.4元/月，客户应用余额领取18.4元，实付金额为18.4元。 客户在2018/11/24 将带宽降级为5Mbit/s，价格为92元/月。 这时，残余天数为 30 - 24 = 6天，升配费用=92 / 30 6 - 18.4 / 30 6 = 14.72元。 以上价格仅作示例，理论价格请参考价格详情。 理解更多EIP带宽计费规定，请戳这里。 点击关注，第一工夫理解华为云陈腐技术~

本文是一个网友提出，经过计算验证可行，但是不适用于所有人。仅适合带宽需求范围在5M-10M之间的CDN加速网站用户。 阿里云带宽的计算方式(参考《ECS公网带宽》)，1-5M和6M及以上是两种单价。按照华东一的价格为例，阿里云5M固定带宽价格125元每月，超过部分单价为80元每月每兆。 假设需求10M带宽，那么价格计费方式为： 前5M的价格：125元 6-10M的价格：5x80元 总计：125元+400元=525元。 网友提出的办法：ECS的固定带宽5M+负载均衡的固定带宽5M 这样大致相当于，实现总需求10M，其中第6-10M的部分每兆省55元。优化效果必然是有的。不过不管哪种方式，都是带宽用的不均衡问题，多用户小访问还行，小用户大访问就有可能流量集中在某一个带宽上 当然也有一定缺点： 多IP，需要借助CDN或者域名解析等方式将网络流量分流。分流方式可能出现前面说的不均衡问题。 针对CDN情况，后端带宽不足的情况实际山并不多，CDN如果更新量小，采用按流量付费的ECS带宽其实更便宜。 原文地址： https://www.opengps.cn/Blog/View.aspx?id=334 文章的更新编辑依此链接为准。欢迎关注源站原创文章！

阿里妹导读：现代人离不开手机，更离不开Wi-Fi。很多同学经常吐槽家中Wi-Fi用得不爽，打游戏看视频又卡又慢。针对大家常见的问题，和坊间各种“谣传”，今天我们特别邀请了阿里工程师艺超，来为大家做全面的梳理分类，希望让每一位同学都能享受如丝滑般顺畅的Wi-Fi体验。前言家庭网络从出口宽带到终端是一条整体链路，分为以下几个部分。出口区域：电信运营商入户线路最终交付到户侧的是一条以太网网线，包含入户光纤(PON)终端及出口路由器，主要提供的“NAT”（实现家内[私网]IP地址到运营商[公网]IP的地址转换翻译）PPPOE拨号、安全访问控制等功能。核心区域：该区域是所有网络设备互联的中心点，是家中网络骨干通道。通常为路由器或者交换机，实现网段路由互通、DHCP、上网行为管理、限速和安全等功能。并提供直接与有线设备互联，提供较大流量的能力输入输出，例如家用NAS、监控录像机、服务器连接等。接入区域：是网络最面向用户的区域，但其却是网络边缘设备，其实现与终端（手机、电脑、IOT设备等）互联功能，通常为无线路由器（AP）和交换机有线端口。参考上图，网络是个整体工程，以上链路任何一个环节出现瓶颈都会影响“体感”。从历史处理的咨询类问题看，其中90%的问题与Wi-Fi信号质量相关，所以在此重点和大家分享下Wi-Fi信号侧通用技术原理和优化方法，以达到快速提升Wi-Fi质量的目的。具体设备配置方法可映射到各位同学购买的各款无线路由器（AP）的说明书。Wi-Fi网络故障表现表现1：网络断线、丢包、卡顿、速度忽快忽慢、抖动幅度大，不稳定。简析：从客户端角度出发，诊断网络质量好坏的直接体现在协商速率上：因为协商速率是根据信号值、噪声、干扰、重传率等一系列射频参数综合体现出来的。故障如下图所示(网络速率不稳定1分钟内大幅度跳动)。表现2：上网速度非常慢。虽然扩容购买了很高的外线带宽，并购买了高功率无线路由器，但是速度依然没有改善。简析：问题出现在Wi-Fi信号上，部分无线路由器厂商大力宣传其产品发射功率高信号可穿墙，但是忽略了终端发射功率回传能力和漫游切换的问题。由于其中无线路由器发射功率较高从而信号强，导致了离路由器较远的终端接收信号显示为满格，但是距离或者阻挡已经超出了终端自身发射功率回传的功率范围。如下图所示（信号接近满格，但协商速率只有13Mbps）。表现3：明明手机在卧室A，却经常连接到远处卧室B的路由器上，虽然屏幕上显示信号杠杠滴，但是实际使用起来网速“捉急”。简析：发射功率过高，家中安装多个无线路由器（AP）时，基本都会产生终端粘连不漫游现像。表现为如下图（蓝色为当前连接AP），电脑没有连接到信号最优距离自己最近的无线路由器上。Wi-Fi信号优化原则一、适当降低无线路由器发射功率(17db,50mw),参考室内通信半径为8-12米。1、双向通信：城市收音机广播基站发射塔只需要建设一座即可覆盖全城，村村通大喇叭只需要一个覆盖全村，其核心优势都是单向通信。当我们需要双向通信时，比如手机打电话，需要将手机MIC取到的声音通过抽样压缩变成电波信号返回给通信基站，此时就受制于手机功率，也就是有效发射距离。因为手机端发射功率比较小，所以移动运营商需要蜂窝状覆盖且数量庞大的通信基站，其目的是为了接收到终端有效的回传，实现有效的双向通信。Wi-Fi也是空中介质通信技术，同理相似。当通信双方功率不匹配时就会造成Wi-Fi使用中频繁中断、速率低等情况发生，所以Wi-Fi路由器要匹配终端功率的有效工作能力，建议配置为14-17db发射范围，从而使通信双方达到100%速率协商。反之Wi-Fi路由器功率越高，传输距离越远时表现出终端连接速率低，通信质量越差的现象。中国国家标准，室内Wi-Fi最大发射功率为20db(100mw)。功率参数对照表如下：2、蜂窝设计：按照原理，无线电通信双方距离越近，双方可协商的带宽就越高。目前普遍使用的5GHZ Wi-Fi协议，其主要运行在5.2GHZ~5.8GHZ频段，可以调制出高达1.3Gbps的理论通信带宽，主要面对室内小型蜂窝场景设计。另外，加上手机天线和外观、电池使用时间、功耗等考虑，目前市面上大部分手机功率为10-14db左右，如下图。笔记本电脑Intel Wi-Fi网卡大多为12-14db范围。3、通信距离：以iphone6手机为例，Wi-Fi 5GHZ频段无任何遮挡室内环境，满速协商速率情况下通信距离为8-12米，维持连接通信距离为70-90米。二、减少无线路由器数量、选好房子合适的中心点，进行吊顶或者桌面放装，保证终端和路由器之间视距可达无遮挡，或者最多穿1堵墙。1、选好位置：有条件的话尽量吊顶安装或者放于桌面高处。即保障了覆盖质量又节约了地面空间，若对美观有要求可以购买外观符合装修风格路由器或者自行刷漆解决。规避干扰：远离强磁0.5米之外（微波炉、电磁炉、高压设备、大屏电视等）。规避遮挡：不要把路由器藏起来放于弱电箱，尤其是金属材质的箱体或者木质柜子、衣帽间、储藏室、角落，或者地面上。2、完善网口：100%无死角且高质量满速的Wi-Fi是基于各房间完善的有线端口基础之上的。尽管通过无线桥接等方式进行扩展，但是通信质量会作出很大牺牲。3、减少设备：无线路由器数量越多，终端产生漫游、断线、重连的机率就越高，这是成正比的，其工作中出现协议冲突(例如DHCP覆盖冲突、同频干扰等)的机率也相对增加，网络架构就会越复杂，所以尽可能少设备数量，尽力做到大道至简。4、无线中继：在弱电网口不完善的大户型（大别野），为了减少施工和影响室内视觉冲击感，我们可以选择“桥接中继”、或者MESH方式简便部署的方案，但是当采用中继MESH这类方案，使用无线桥接互联，在使用体感上就不会那么“爽”。道理很简单易见，每次连接都会有带宽损失，最终会让总体带宽打折扣。桥接每增加一跳带宽对应下降50%，所以我们通常进行桥接设计时：最多下挂一级子设备。5、利器“电力猫”：弱电网口（有线）不完善的大户型（大别野），为了减少施工也可以考虑“电力猫”方式。它利用传统电线，采用分频段技术，转变电线为通信线路使用，只要是在于同一电表区域内的电线系统部署“电力猫“即可实现扩展通信网络的目的。但是在电磁特性上，电线并没有针对高频信号传输做相应的优化设计，不能和光缆、双绞线、同轴电缆这类专用通信线缆相比，存在干扰较大、信号完整性等缺点，并且在用电高峰或者电压不稳时，容易受大电流波动影响。所以这种实现方式，通信质量和稳定性有天生的缺陷，故障点也比较多，如果对网络稳定性要求较高，则不建议采用此方式。三、家用Wi-Fi配置为5GHZ频段40MHZ频宽，IOT设备及访客使用2.4G频段。1、频段选择：2.4Ghz频段低穿透性好，但可用信道只有3个，如下图。同5G频段相比，它的频段窄、速率低、干扰大，建议留作智能家居及IOT设备及访客使用，并配置单独SSID和安全策略。5 GHZ频段在原理上提供了更多的可用信道。在中国许可频段内共有13个可用信道，所以使用5GHZ有条件进行多信道绑定，以得到更高的带宽。2、信道绑定：更宽的信道带宽可以得到更高通信带宽，笔记本电脑普通Intel 802.11ac网卡，使用20Mhz=173Mbps，40Mhz=400Mbps，80Mhz=866Mbps，但是这也是双刃剑，更宽的信道也更容易受到干扰，使得延迟增加。所以我们抛弃20MHZ和80MHZ折中选用40Mhz部署。示意图如下：3、信道选择：使用工具软件(下文会提到具体软件名称) 扫描出空闲信道，并配置到无线路由器。家中每台路由器要配置为不同信道以规避同频干扰。网络优化方法一、不同户型Wi-Fi点位和频谱设计示例1、小户型：2、中户型3、大户型4、别墅，按单楼层布局参考以上户型即可。二、网络架构设计：家庭网络架构设计建议参考本文前言描述部分进行分层设计。我们通常还会有这样的疑问：1、我家使用的100M ADSL带宽，为何电脑手机测速始终无法达到这么高？可参考前言部分架构图，梳理出瓶颈位置进行针对性优化。另外注意大小字节单位换算，网络入户带宽通常以小byte计算（100Mbps/S带宽，实际下载文件速度为10MBps/S），可使用电脑测速www.speedtest.net确认入户带宽是否达标。出口带宽计算：基于家中同时段并发高峰所有终端流量叠加计算得出，通常情况下高清电视流量约为4MBps、电脑普通视频业务为2MBps、手机视频通常为1MBps，如有P2P下载上传等大流量需求，则根据应用需求叠加计算。重点访问资源：较为普及的热点网站及APP应用流量，三大运营商均可以满足。如有特殊需求，例如你需要与另外一个城市家中时常需要大流量视频互联，可以根据目标IP在不同运营商的跳数选择跳数最低的一家（可使用电脑上命令 tracert x.x.x.x 进行跳数和延迟跟踪）。2、我家网络经常断网，有一部分设备无法上网，终端网络连接图标上显示叹号，是什么原因？此类问题大多为DHCP协议冲突所致，非网关的路由器，上联的网线应接在LAN口而非WAN口，并且必须关闭DHCP等与核心层冲突的功能，只作为无线信号发射使用。三、网络安全安全是一个整体包含家中网络上参与的所有设备的软、硬件系统，安全和易用之间也需要相对平衡，可以根据自己的需求作出选择。可以参考以下3个层次设计。普通防范：家用Wi-Fi 与客人用（Guest） Wi-Fi 区分网段，并在核心设备上作路由隔离，配置WPA2 AES CCMP强加密，定期更新密码。相对保密：建议隐藏家用Wi-Fi SSID，当然，技术上通过抓包可以抓取到SSID名称所以需要增加其它配合策略。配置WPA2 AES CCMP强加密，同时关闭DHCP功能，采用静态地址分配、增加MAC地址绑定或者限制MAC访问等等策略及其叠加使用。严格保密：在前两项目基础上，根据自身需求购买相应级别防火墙、严格设计进出数据流量策略，并对家中所有设备系统安全进行严格安全防范，例如定期对路由器设备，AP设备软件进行更新，弥补软件的安全和功能漏洞。我们通常还会有这样的疑问：我的Wi-Fi密码设置的挺复杂的，我自己都记不住，为什么还是被其它人蹭网了？如果解决？若装有“万能密钥”类APP的手机，曾经接入过该网络，这类APP会把密码共享到云端或者其APP配置端。那么，自家中的密码设置再复杂也经不住这样的广播。我们严格控制家庭成员不安装此类APP，并且部署上参考前面介绍过的策略：通过访客和家人区分SSID也可以有效降低此类问题造成的影响，但是一旦发生“被蹭网”事件，建议立刻修改密码。四、设备选择根据自己的户型需求进行选择，例如小户型，选用一台无线路由器即可（相当于路由交换无线路由一体机）。超/大户型可分区/层设计。我们通常还会有这样的疑问：1、同样是家用无线路由器价格相差很大，它们的差距究竟在哪里？相关指标考虑如下要素：2.4&5G双频、802.11ac、千兆以太网、开机稳定运行时长、高并发流量稳定性、多终端并发数量、防潮抗高温及高处跌落保护、软件迭代售后支持能力、天线阵列设计和灵敏度、软件功能等等。2、网上有很多Wi-Fi信号增强的攻略，哪一种最实用？不要迷信高发射功率，任何所谓的穿墙王全是忽悠（参考上文优化原则部分）。也不要试图去增加路由器功率，装易拉罐、加功放、加天线，这样做确实发射端信号增强了。但是“有效”通信是双向的，只加强了发射端功率，终端、手机端功率很低，就会出现功率不匹配的现像，距离发射端较远处信号确实显示满格了，但是手机端回传的数据包无法返回，这样对通信而言实际上没有任何帮助，而且干扰了全局Wi-Fi信号部署的质量。(如下图，绿色信号范围是固定的，扩展出来的是红色的质量较差的信号)3、天线数量越多越好吗？天线数量的多寡，跟穿墙能力是否有关？理论上是的，如果将所有无线设备都放置于同一规格标准下来比较，越多天线代表其灵敏度越高，自然穿墙能力表现会更佳。但实际上受产品硬件设计（价格成本限制）、包含天线用料的影响，所以结论并无绝对，要依产品而定，内置天线路由器也不一定就会比外接式天线的灵敏度更差，因此天线数量只能说是一种参考的指标之一。4、大户型打算采用桥接方式覆盖，设备如何选型？上文提到，尽量不要选择这种方式覆盖。如果一定要采用这种方式，可以考虑使用天猫路由和钉钉路由产品，空口容量大、工作稳定、配置简单。五、效果测试相关工具：PC端可选择 Inssider、WirelessMon、Wireless Netview等，分系统而论。手机端可选择speed test、WiFi分析仪、WiFi Analyzer等，非常简单易用。分系统而论。测试方法：在目标覆盖区域使用以上工具软件进行信号和带宽测试，同时进行ping网关测试，并浏览国内大型互联网站点。相关指标：目标覆盖区域内，接收信号强度大于等于-75dBm，有语音和视频业务的区域，接收信号大于等于-67dBm；ping网关，包大小为1500bytes，ping包次数为100次，时延不大于100ms，Ping包的丢包率不大于1%；漫游切换成功率不小于90%，AP间切换时长ping网关记录，最多允许丢1个包。电脑连接Wi-Fi情况下使用www.speedtest.net 测试网速可以达到出口带宽数值。电脑连接Wi-Fi情况下，点击国内热点网站20次，访问成功率不低于100％；访问国内大型站点显示时延不大于2秒。大家还有哪些优化家中Wi-Fi的方法？欢迎在留言区分享补充。本文作者：艺超阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。

背景大约在5年前，也就是2013年我刚加入阿里的时候，那个时候 DevOps 的风刚吹起来没多久，有家公司宣称能够一天发布几十上百次，这意味着相比传统软件公司几周一次的发布来说，他们响应商业需求的能力可以甩后者几条街，而且这差距根本不是加班能赶上的。今天的 AliExpress 技术团队小几百人的规模，可一天发布几十次也已经司空见惯了，这主要得益于三个方面：非常彻底地微服务化，拆分粒度很细，且旗帜鲜明地反对重二方库。阿里集团整体的运维标准化，尤其是 Docker 技术的全面覆盖。AliExpress SRE 团队不断努力保证稳定性。然而，效能这个东西，你永远不会说：“够了，够快了”，尤其是在当下的消费型社会，人人都是消费者，而消费者恨不得脑子里的欲望刚闪现出来，你的商品或服务瞬间就到他面前。况且，随着我们不断国际化的步伐，新的因素必然会影响原来的高效能。沟通带宽衰减问题第一个因素是研发团队自身的发展和变化，今天的 AliExpress 技术团队已经是一个名副其实的分布式国际化团队，工作地是杭州+深圳+莫斯科+马德里+其他欧亚都市，外籍同学的比例是 15%，而且能看到这个比例会不断提高，新的国外工作地点也会增加。而这样的团队，对比在同一层楼里的一群中国人组成的团队，是有本质的区别的。我们可以将人与人之间的沟通和网络通信做类比，我们知道网络通信是有带宽的，从早期的拨号上网几十K，到现在的家庭宽带主流的几十上百M，再到数据中心内部局域网内部G级别的数量级，带宽越大，能传输的信息也就越多（通常浪费也就越多）。而人与人之间沟通也可以认为是有带宽的，例如充分信任的全由中国工程师组成小团队，平时相互一起吃饭散步聊天，大家彼此都特别了解，沟通起来就特别顺畅，想到一个点子转个朝向说两句对方就懂了。可对于一个分布式国际化团队来说，这个沟通带宽可是衰减得厉害：中文到英文的转换，衰减一次。对于大多数人来说，英语不是母语，沟通的效率自然会降低。单地到多地，衰减一次。电话，视频，钉钉，都没有面对面沟通来的高效。（否则大家都不会不约而同地刷脸了）时差，再衰减一次。杭州和莫斯科的时差是5个小时，所以基本上北京时间上午我们是联系不上莫斯科的同学的。文化的差异，再衰减一次。例如很多我们可以用来增强感情的团建方法，撸串K歌王者吃鸡，外籍同学可能完全不感冒。那有人可能会说，既然沟通成本这么高，那直接在一个地方全部招中国工程师多简单？这么做简单是简单的了，可都这么搞的话，怎么在全球范围吸引优秀的人才呢？更何况 AliExpress 的用户基本都是老外，这后面的人才如果全是中国人，听起来这生意就不太靠谱对不？谷歌微软亚马逊，哪家不是在全世界搜罗顶尖人才？所以说，既然沟通带宽的衰减是难以避免的，那我们唯有把对这带宽的利用率提上去。具体我们已经做了，或者在做一些事情：尽可能和行业主流技术接轨，降低工程师学习成本。我们基于开源 Spring Boot 做的阿里巴巴生态集成，摒弃 antx, webx, pandora，都是这个思路。English First：注释，文档，工具，英文必选，中文可选。服务发现，让所有微服务可见，增强自描述，可搜索。拥抱 Kotlin关于开发效率，我个人认为所有 Java 程序员都应该认认真真、仔仔细细去看下 Kotlin，因为这门语言太简洁了，而且和 Java 可以无缝互操作，完全具备生产环境使用的条件。有关简洁，我这两天把一块 Java 代码改成了 Koltin，在丝毫不降低可读性的情况下（实际上可读性是提高了），代码行妥妥地减少了 1/3 。此外我忍不住分享一下最近我基于 Sergey 的 Kotlin HSF DSL 写的一个将函数发布成 HSF 服务的功能：只需要不到 15 行代码，就可以启动一个 Spring Boot 应用，把一个字符串小写的功能发布成 HSF 服务，大家可以对比下 Java 需要写多少东西。语言层面的升级，给框架，中间件，API设计带来更多的可能性，这就能使我们砍掉更多的所谓脚手架代码，让业务代码更精简，更优雅，进而带来效率提升。作为程序员，如果只掌握一种语言，是非常危险的，因为这种语言的各种设计会禁锢你的思维。我自己会在业余看一些其他语言，不过在日常工作中基本也只能写 Java（如果 shell 也算一种语言的话，还是写过些 shell 的）。不过从现在开始，我会开始尽可能地用 Kotlin 写代码，我的团队也全面把日常编程语言从 Java 切换到 Kotlin，其实我们都已经不算 Early Adoptor 啦，雷卷在一年多前就已经不停在鼓吹 Koltin 并上线了一个应用，AliExpress 俄罗斯办公室的 Sergey 等同学也已经在生产用上了 Kotlin，Sergey 个人也在很多地方分享他的经验。我们会推动 AliExpress 拥抱 Koltin，从语言层面来提升我们的效率。阿里资深技术专家雷卷，在他最近的一篇谈程序员学习的文章中写了很多东西，我都是很认同的，其中一段话尤其想点赞：不要和程序员谈自己的编程历史，很多经验今天已经不适用啦，可能有一些，但是会给别人带来甄别成本，别人也懒得来甄别。2-3年不关注技术，基本快和程序员和编程绝缘啦，不是绝对，但是通常不会错。持续学习，与诸君共勉。FaaSFunction as a Service，又一个新的 Buzz Word？是的，不过我还真的相信这个 Buzz Word，行业里 AWS Lambda, Google Cloud Functions, Microsoft Azure Functions 等服务相继推出，大家都在尝试把自己的业务往上面搬，这其中的道理在哪？如果作为云服务提供商，这个道理是很显而易见。你的对手按照 docker instance 收费，2 core 4g 起，一小时多少钱；如果你能做到按调用次数收费，一小时内运行了 30 次。那这个价格差必然是数量级的，用这一招就可以秒杀对手了。上面所说的纯粹是硬件成本的考量，但我们还需要从效率方面看这个事情。首先由于 Function 天生是无状态的，而且是足够轻量的，那么理论上做到 ms 级别的 auto scaling 是没有问题的，例如 graalvm 就在这方面很有潜力。ms 级别的 auto scaling 不仅能够大幅提升资源利用率，更是提升了运维效率，开发几乎就不再需要考虑容量的事情的。例如在双11的时候，我们做大量的压测，很大程度上是为了保证系统各个部分的水位在预测的安全的线上，如果做到了实时扩缩，那么当流量高峰来的时候再扩容好了。什么是轻量？今天很多工程师可能已经忘了轻量的概念是什么，大家就是各种侵入，写个简单的应用，打出来的 jar 包，业务代码的占比往往不到 1/10。先不说这里可能无谓浪费了多少内存，无谓增加了多少启动时间。这个 client 那个 share 满天飞带来的最麻烦的后果就是，开发经常要做各种升级，而且一升就挂，一查就半天。打着所谓性能旗号的各种重客户端，就是反服务化的；各种缺乏细心设计的 API 导致的不兼容升级（而且是暴力推动，不升级卡发布），就是反工程师操守的。微服务化做得好的，应该积累一大批轻量的接口，使用这些接口甚至都不需要引入什么 share/open/client 的依赖，直接用 HSF 的泛化调用即可，这样的接口才不对用户有代码侵入。我们已经在 AliExpress 尝试（并已经上线）基于 Koltin DSL 和 HSF 泛化调用编写 Function，用户只需要依赖很简单的一个 FaaS SDK 就可以编写业务代码，基于前面提到的阿基米德服务发现，他可以快速重用现有服务，做一些聚合和过滤的操作，满足业务需求，这个在贴近无线的业务中非常有用。当然，这个尝试只是一个开始，但我们已经看到，其实有大量的业务逻辑（在 AliExpress 可能是 5/1 至 1/3）其实自身不依赖于数据，可以做成 Function，而且我们可以做到让这些业务不依赖任何业务二方库，甚至借助 Service Mesh 等技术，不依赖于任何中间件 client。这些业务的 owner 不需要关心各种乱七八糟的升级问题，不需要关心容量问题，真正地只关心自己的业务逻辑。我认为这是 FaaS 该成为的样子，而我及我的团队，正不断努力去实现之。作者介绍许晓斌，阿里高级技术专家，《Maven实战》作者，《Maven权威指南》译者，并合译有《Cucumber：行为驱动开发指南》，曾经负责维护 Maven 中央仓库，参与开发 Maven 仓库管理软件 Sonatype Nexus。曾多次在 ScrumGathering 和 AgileTour 等大会上发表演讲。工作之余喜欢读读人文、跑跑步。本文作者：云效鼓励师阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

摘要： “时间的朋友”跨年演讲背后的技术支撑。2018年12月31日20:30分，以“时间的朋友”为主题的罗振宇2018跨年演讲在深圳正式召开，同时通过深圳卫视、优酷等平台进行全球直播。作为年度总结式演讲开创者，2018年跨年演讲与以往跨年演讲一样，依旧保持着超高的人气，据现场统计演讲现场共吸引了7884名观众出席。罗辑思维自有平台“得到APP”，承载了演讲期间来自现场、网络及电视端用户持续不断的大流量、高并发访问，保障用户获得了稳定、流畅的使用体验。在这场知识盛宴的背后，罗辑思维技术团队与阿里云携手作战四余月，期间共同探讨、落实了多个提升和优化平台处理能力的技术方案，并通过多轮现网平台压测积累了多个应急处理措施。历届“时间的朋友”跨年演讲都吸引了大量现场和线上观众观看及互动，是典型的大流量、高并发、极端峰值的业务应用场景。随着演讲过程中罗振宇不断抛出新观点、新认知和新活动，海量用户也随之产生庞大的访问请求，这需要得到APP和生活作风电商平台能够稳定、流畅的将请求正确处理完成，使用户获得最好的使用体验。在项目筹备之初，双方技术团队就如何定制化的满足整场演讲高并发、大流量需求进行了深入探讨，阿里云技术团队将多年来支持阿里巴巴多年“双十一大促”活动所积累下来的产品技术及活动经验分享给罗辑思维技术团队。以优化系统处理能力提升为例，罗辑思维使用了阿里云全链路压测产品，在跨年演讲活动备战期间，双方团队协同使用了缓升、激增、脉冲等多种压测手段，模拟跨年演讲期间可能出现的各种对系统处理能力的需求。经过几十轮压测，多次模拟数百万用户集中访问平台等场景，实现了对平台各功能模块进行迭代式的摸底、扩容和验证的闭环过程，保障跨年演讲活动期间平台具备足够的计算、网络和存储等能力。阿里云技术服务团队全程参与到跨年演讲活动中，与罗辑思维技术团队一起进行现场护航工作，负责监控平台基础资源的运行指标、给出优化建议并在突发情况下给予全力支持。为了保证跨年演讲工作的技术投入具备最佳性价比，罗辑思维技术团队大量使用阿里云弹性计算、弹性带宽等产品技术。在跨年演讲活动准备期间，根据压测的结果罗辑思维技术团队扩缩容计算资源（ECS、RDS、Redis等）和带宽资源（SLB、EIP、NATGW等）。根据跨年活动的用户量预估和压测结果等数据，确定跨年演讲活动期间最具性价比的计算及带宽等云计算资源用量；同时，得到APP及生活作风平台经过17年和18年不断的技术架构进化，做到了弹性处理架构，使平台在活动期间可以做到秒级扩容云计算资源，进而秒级提升系统处理能力，最终保证了整场跨年演讲的顺利举行。同时在演讲中，罗振宇也提到了阿里的设计人工智能“鹿班”——让天下没有难撸的banner。刚刚过去的2018年双十一期间，阿里巴巴设计了5亿张广告图，那背后可能是人工设计师吗？当然不是，它是一个人工智能，叫做“鹿班”的系统。平均每秒可以设计8000张海报。使用了这个系统之后，首页Banner的点击率，提升了100%多，效果那是相当惊人。这只是阿里巴巴这样的公司，它庞大的智能后台系统的冰山一角。阿里云作为全球前三名、亚洲最大的云计算服务商，国内市场份额超第2-5名总和，在云计算、大数据及人工智能等领域拥有领先的技术优势，在全球19个地域开放了53个可用区，建设1500多个CDN节点，带宽储备120多T，为全球数十亿用户提供可靠的计算支持。2018年俄罗斯足球世界杯期间，为优酷、CNTV、CCTV5提供了技术及服务，承担了全网70%的世界杯流量。此外，阿里云还为全球客户部署超过200个飞天数据中心，通过底层统一的飞天操作系统，为客户提供全球独有的混合云体验。本文作者：阿里云头条阅读原文本文为云栖社区原创内容，未经允许不得转载。

阿里妹导读：在阿里，音视频会议已经成为跨地区沟通、开会以及招聘的首选方式。据悉，目前阿里巴巴的办公网络与音视频会议已经覆盖全球33个国家和地区，其中，音视频会议在过去3个月平均每天召开超过2000余场。在使用如此频繁、覆盖面如此之广的音视频场景中，如何满足全球各地使用者的不同需求，保障交流的顺畅？下面，我们一起来探讨、研究。音视频行业的发展音视频行业发展迅速，经历了1970年代的黑白时代、1980年代的数字化时代、1990年代的数字标清时代、2006-2015年代的高清时代，2016年逐步开始以融合通信为主的行业趋势，高质量（4K，高清，高帧率，HDR）、多场景（点播，直播，实时通讯）、云化（硬件软件化，平台云化）和行业化已经成为当下音视频行业的发展趋势。音视频行业未来的发展趋势，在我看来就是云+端+服务。云：平台云化，从PaaS到SaaS，从私有公有云，一切都是基于云的服务。端：兼容各种终端，PSTN和VOIP，会议室设备，手机，PC，Web，Android终端等。服务：包括短信，语音，IM，音视频，呼叫中心，云客服和附加AI服务等多种服务。目前，音视频已广泛应用于包括B2B（企业与企业间、企业内部间）、C2C（用户与用户间），以及B2C（企业和用户间）。根据著名Cisco的VNI（Virtual Network Index）预测，到2021年，地球上将有46亿互联网用户，271亿联网设备，82%互联网的流量是视频。每一秒钟将会有一百万分钟的视频内容被创建，其中4K高清的内容会增加30%，相当于每个月生成71亿部DVD影片，直播的需求也会大幅增长15倍。从视频本身发展的趋势看也是一路狂奔向高清、CIP、4CIP、720P、1080P、UHD4K和8K；加上高帧率FPS 120-160FPS、HDR（High Dynamic Range）、宽色域（Wide Color Gamut），一切发展变化都是为了给人一种身临其境的Immersive体验。当然还有VR、AR、360视频，这所有的一切都意味着更多的视频数据流将被生成和消费。网络环境让我们需不断完善音视频服务如果网络带宽是无限且畅通无阻的，那世界将是多么美好。但网络并不是一马平川的。有时像十一长假堵车，有时像乡间泥泞小道，而且还有可能布满大坑。根据Silver-Peak跨美国和欧洲的网络健康报告发现，网络传输的延时、抖动和丢包是普遍存在现象。有时网络状况就像天气一样令人难以捉摸。虽然网络的平均丢包率只有0.34%，但个别情况下可以达到2.2%；而且丢包从来都不是均匀的，是突发性的Burst，网络延迟可能会超过平均值300多倍。这些极端的网络情况对音视频的传输和用户体验来说，都是极大挑战。网络和音视频流量的供求矛盾，网络传输的不确定和不完善的残酷现实，倒逼着我们不断完善和监控音视频服务。音视频内容从生产到消费的过程会经历不同环节，且链路较长，其中涉及的技术也较多，下面将主要对其中的视频编码，网络构架进行解析。视频编码视频编码标准的选择视频编码标准作为视频技术的核心，在过去几个世纪出现过很多不同标准，但最终被市场采纳主要为以下两套体系：一套是标准化体系的H264、H265 和正在制定中的VVC；另一套是开源无版税的VP8、VP9和AOM(Alliance for Open Meida)的AV1。阿里巴巴是AOM的成员也同时积极参与VVC的制定，对于视频编码的核心不能被掐住发展的咽喉。针对不同场景的不同编码需求视频不同的应用场景（如：点播、直播、实时通讯），决定了在每一个应用场景底下对编码的不同需求。对点播而言最重要的是编码效率，如何有效节约带宽。直播对延时有要求，但是是在秒级的，对编码的速度和稳定性的需求也比点播高。实时通讯对“点对点”的延时要求最高，同时它对稳定性和容错性的要求也很高，这需要通过平衡编码效率来实现。如何配对编码率与分辨率视频编码以前简单地采用固定压缩参数，固定码率和固定分辨率，对于HLS和MPEG-DASH的ABR(Adaptive Bitrate)，也用固定编码率和分辨率来配对。这就无法满足不同视频对码率的不同需求。1M的720P动画片看起来可能已经不错了，但是1M的720P动作片看起来就会很糊。但对于ABR，编码率和分辨率也是一个动态平衡的过程。在低码率的情况下用低分辨率以减少块状效果（blocking effects），当码率的提高到一定程度时提升分辨率，包围不同分辨率RD曲线的就是凸包（Convex Hall）。曲线中的交叉点就是理性的编码率和分辨率配对。如何确定视频质量的衡量指标但怎么确定曲线中的交叉点呢？这需要有衡量视频质量的指标。通常的视频指标包括主观的MOS分和客观指标比如PSNR，SSIM和VMAF。阿里巴巴的视频质量指标，不但结合了通用的客观指标，也同时考虑了影响播放质量的的卡顿和网络状况。如何进行自适应编码自适应编码（Content Adaptive Encoding）是视频编码的一大趋势。从One-size-fit-all的单一编码参数、码率和分辨率配对，到根据视频内容的复杂度进行定制化的编码参数适配。自适应编码可以针对单个视频、场景、GOP，甚至是Frame用不同的压缩参数进行动态调整，这样最大限度优化视频质量、节约带宽。这种自适应优化最重要的就是视频质量的衡量指标。一旦定义好可用的指标，就可以围绕它进行不同层次的优化。对于自适应编码，机器学习可以大有用处。比如利用机器学习针对不同的视频特征，找到对应优化的编码参数。人脑占人身体的比例不大，但是消耗人体大约1/3的能量，人的基因特性决定了大脑只会关注画面中重要区域，忽略不重要的区域。利用这种ROI（Region of Interest）进行编码，就可以在保持视频主观质量的情况下减少编码率。比如人脸和文字是经验意义下的ROI的例子。音视频服务器网络架构实时音视频服务器的网络架构，除了MESH外，还有MCU（Multi-point Control Unit）和SFU(Selectiveforward Unit)两种。MCU是集中的媒体处理服务，优势在于可以对媒体和信令进行控制和转换，如对媒体进行转码、转流、混屏、分流，对信令进行转换，对媒体包进行路由优化等等。MCU可以减低Client端的CPU和对网络带宽的需求，但是MCU的缺点也较明显，那就是服务器CPU的开销以及带来的延迟。相对MCU来说，目前更流行的架构是SFU，它主要的好处是简单、低时延、高吞吐，缺点是对client端的带宽要求比较高，client上传一路或者多路流同时下载多路流。SFU的客户端可以发单流、多流（Simulcast）和SVC。根据运用场景的不同，客户端发流策略也不同。在阿里巴巴的音视频会议系统中，采用的是一种SFU+MCU的混合模式，以保证最大的兼容性。这种SFU和MCU级联的策略保证对各类客户端的最大灵活性。此外媒体服务器在不同区域可以进行级联，客户端就近入会、就近补包，减低第一公里和最后一公里对音视频质量的影响。网络带宽评估网络带宽评估是实时通话的关键技术。阿里巴巴在这方面进行了很多针对会议室场景的优化。并且通过评估算法可以在服务器端快速发布，不用等待更新客户端软件。在弱网不可避免的情况下，通过合理的带宽分配，确保音频优先传输，同时及时把弱网信息传达给用户，同样可以得到用户理解，提升用户体验。后记音视频提供的是服务，不是单点的QoS，用户的最终体验不是简单的抗丢包率、卡顿率的指标，而是端到端的体验。所以不仅需要我们在事先创造一个良好的音视频环境，更需要我们对整体链路进行质量监控。除了能及时发现问题，快速响应外，还能帮助我们不断发现与创造更多新业务场景。通过把业务数据化，再根据数据来指导业务，这样才能让音视频的服务体验达到极致。本文作者：致凡阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。

Dragonfly 是一个由阿里巴巴开源的云原生镜像分发系统，主要解决以 Kubernetes 为核心的分布式应用编排系统的镜像分发难题。随着企业数字化大潮的席卷，行业应用纷纷朝微服务架构演进，并通过云化平台优化业务管理。Dragonfly 源于阿里巴巴，从实际落地场景出发，前瞻性地解决了云原生镜像分发的__效率、流控与安全__三大难题。Dragonfly 目前承载了阿里全集团 90%以上的文件下载任务、日分发峰值达到 1 亿次，100%成功支撑双十一营销活动数据抵达数万台机器，github Star 数已达到 2500+。2018 年 11 月 14 日已正式进入 CNCF，成为 CNCF 沙箱级别项目（Sandbox Level Project）。Dragonfly 的由来随着阿里集团业务爆炸式增长，2015 年时发布系统日均发布量突破两万，很多应用的机器规模开始破万，发布失败率开始增高，而根本原因则是发布过程需要大量的文件拉取，文件服务器扛不住大量的请求，当然第一时间会想到服务器扩容，可是扩容后又发现后端存储成为瓶颈且扩容成本也非常巨大（按照我们的计算，为了满足业务需求，不阻碍业务的发展，后续至少需要 2000 台高配物理机且上不封顶）。此外，大量来自不同 IDC 的客户端请求消耗了巨大的网络带宽，造成网络拥堵。同时，阿里巴巴很多业务走向国际化，大量的应用部署在海外，海外服务器下载要回源国内，浪费了大量的国际带宽，而且还很慢；如果传输大文件，网络环境差，失败的话又得重来一遍，效率极低。于是我们很自然的就想到了 P2P 技术，P2P 技术并不新鲜，当时也调研了很多国内外的系统，但是调研的结论是这些系统的规模和稳定性都无法达到我们的期望，因此就有了Dragonfly这个产品的诞生。Dragonfly 能解决哪些问题作为一款通用文件分发系统，Dragonfly 主要能够解决以下几个方面的问题：大规模下载问题：应用发布过程中需要下载软件包或者镜像文件，如果同时有大量机器需要发布，比如 1000台，按照 500MB 大小的镜像文件计算，如果直接从镜像仓库下载，假设镜像仓库的带宽是 10000Mbps，那么理想状态下至少需要 10 分钟，而且实际情况很可能是仓库早已被打挂。远距离传输问题：针对跨地域跨国际的应用，比如阿里速卖通，它既要在国内部署，又要在美国和俄罗斯部署，而存储软件包的源一般只在一个地域，比如国内上海，那么在美国或者俄罗斯的机器当要下载软件包的时候就要通过国际网络传输，但是国际网络不仅延时高而且极不稳定，严重影响传输效率，进而导致业务不能及时上线新功能或者问题补丁，由此甚至会产生业务故障。带宽成本问题：除了传输效率问题，高昂的带宽成本也是一个非常严重的问题，很多互联网公司尤其是视频相关的公司，带宽成本往往可以占据其总体成本的很大一部分。安全传输问题：据统计，每年因为网络安全问题导致的经济损失高达 4500 亿美元，所以安全必须是第一生命线，文件传输过程中如果不加入任何安全机制，文件内容很容易被嗅探到，假设文件中包含账号或者秘钥之类的数据，一旦被截获，后果将不堪设想。Dragonfly 是如何解决这些问题的通过 P2P 技术解决大规模镜像下载问题，原理如下：针对上图有几个概念需要先解释：PouchContainer：阿里巴巴集团开源的高效、轻量级企业级富容器引擎技术。Registry：容器镜像的存储仓库，每个镜像由多个镜像层组成，而每个镜像层又表现为一个普通文件。Block：当通过Dragonfly下载某层镜像文件时，蜻蜓的SuperNode会把整个文件拆分成一个个的块，SuperNode 中的分块称为种子块，种子块由若干初始客户端下载并迅速在所有客户端之间传播，其中分块大小通过动态计算而来。SuperNode：Dragonfly的服务端，它主要负责种子块的生命周期管理以及构造 P2P 网络并调度客户端互传指定分块。DFget__：__Dragonfly的客户端，安装在每台主机上，主要负责分块的上传与下载以及与容器 Daemon 的命令交互Peer：下载同一个文件的 Host 彼此之间称为 Peer。主要下载过程如下：首先由 Pouch Container 发起 Pull 镜像命令，该命令会被 DFget 代理截获。然后由 DFget 向 SuperNode 发送调度请求。SuperNode 在收到请求后会检查对应的文件是否已经被缓存到本地，如果没有被缓存，则会从 Registry 中下载对应的文件并生成种子块数据（种子块一旦生成就可以立即传播，而并不需要等到 SuperNode 下载完成整个文件后才开始分发），如果已经被缓存，则直接生成分块任务。客户端解析相应的任务并从其他 Peer 或者 SuperNode 中下载分块数据，当某个 Layer 的所有分块下载完成后，一个 Layer 也就下载完毕，此时会传递给容器引擎使用，而当所有的 Layer 下载完成后，整个镜像也就下载完成了。通过上述 P2P 技术，可以彻底解决镜像仓库的带宽瓶颈问题，充分利用各个 Peer 的硬件资源和网络传输能力，达到规模越大传输越快的效果。Dragonfly的系统架构不涉及对容器技术体系的任何改动，完全可以无缝支持容器使其拥有 P2P 镜像分发能力，以大幅提升文件分发效率！结合 CDN 与预热技术解决远距离传输问题通过 CDN 缓存技术，每个客户端可以就近从 SuperNode 中下载种子块，而无需跨地域进行网络传输，CDN 缓存原理大致如下：同一个文件的第一个请求者会触发检查机制，根据请求信息计算出缓存位置，如果缓存不存在，则触发回源同步操作生成种子块；否则向源站发送 HEAD 请求并带上 If-Modified-Since 字段，该字段的值为上次服务器返回的文件最后修改时间，如果响应码为 304，则表示源站中的文件目前还未被修改过，缓存文件是有效的，然后再根据缓存文件的元信息确定文件是否是完整的，如果完整，则缓存完全命中；否则需要通过断点续传方式把剩下的文件分段下载过来，断点续传的前提是源站必须支持分段下载，否则还是要同步整个文件。如果 HEAD 请求的响应码为200，则表示源站文件已被修改过，缓存无效，此时需要进行回源同步操作；如果响应码既不是 304 也不是 200，则表示源站异常或地址无效，下载任务直接失败。通过 CDN 缓存技术可以解决客户端回源下载以及就近下载的问题，但是如果缓存不命中，针对跨域远距离传输的场景，SuperNode 回源同步的效率将会非常低，这会直接影响到整体的分发效率，为了解决该问题，Dragonfly采用了一种自动化层级预热机制来最大程度的提升缓存命中率，其大致原理如下：通过 Push 命令把镜像文件推送到 Registry 的过程中，每推送完一层镜像就会立即触发 SuperNode 以 P2P 方式把该层镜像同步到 SuperNode 本地，通过这种方式，可以充分利用用户执行Push和Pull操作的时间间隙（大概10分钟左右），把镜像的各层文件同步到 SuperNode 中，这样当用户执行 Pull 命令时，就可以直接利用 SuperNode 中的缓存文件，自然而然也就没有远距离传输的问题了。通过动态压缩和智能化调度解决带宽成本问题通过动态压缩，可以在不影响 SuperNode 和 Peer 正常运行的情况下，对文件中最值得压缩的部分实施相应的压缩策略，从而可以节约大量的网络带宽资源，同时还能进一步提升分发速率，相比于传统的 HTTP 原生压缩方式，动态压缩主要有以下几个方面的优势：动态压缩的优势首先自然是动态性，它可以保证只有在 SuperNode 和 Peer 负载正常的情况下才会开启压缩，同时只会对文件中最值得压缩的分块进行压缩且压缩策略也是动态确定的；此外，通过多线程压缩方式可以大幅提升压缩速率，而且借助 SuperNode 的缓存能力，整个下载过程只需要压缩一次即可，压缩收益比相对于 HTTP 原生方式至少提升 10 倍。除了动态压缩外，通过 SuperNode 强大的任务调度能力，可以尽量使在同一个网络设备下的 Peer 互传分块，减少跨网络设备、跨机房的流量，从而进一步降低网络带宽成本。通过加密插件解决安全传输问题在下载某些敏感类文件（比如秘钥文件或者账号数据之类的文件）时，传输的安全性必须要得到有效保障，在这方面，Dragonfly主要做了以下几个方面的工作：支持 HTTP Header 传输，以满足那些需要通过 Header 来进行权限验证的下载请求通过自研的数据存储协议对数据块进行包装传输，后续还会对包装的数据进行再加密即将支持安全加密功能插件化通过多重校验机制，可以严格防止数据被篡改Dragonfly目前的成熟度如何在阿里巴巴集团内部，Dragonfly作为全集团基础技术构件，目前已经承载了全集团 90%以上的文件下载任务，包括镜像文件、应用软件包、算法数据文件、静态资源文件以及索引文件等等，日分发峰值目前可以达到 1 亿次，为集团业务提供了高效稳定的文件分发能力；同时，每年双十一大家买买买的过程中，其中最为关键的营销活动数据（数 GB 大小）也是在将近零点的时候通过Dragonfly来成功（100%成功）抵达数万台机器上的，万一在这个过程中有一点点问题，双十一会如何，你懂的……目前 Dragonfly 也已经开源，在开源社区中， 目前 Star 数 2500+，同时有非常多的外部用户对 Dragonfly 表现出浓厚的兴趣，也有很多外部公司正在使用 Dragonfly 来解决他们在镜像或者文件分发方面遇到的各种问题，比如中国移动、滴滴、科大讯飞等；此外，Dragonfly 已成为全中国第三个进入CNCF Sandbox 级别的项目，后续我们还会继续加油努力，争取尽快毕业！通过以上介绍，我相信针对Dragonfly是否足够成熟，大家心里应该也有杆秤了吧，当然，Dragonfly还有很多事情需要不断完善和改进，在这里诚邀各路人才，一起把Dragonfly打造成一款世界级的产品！未来规则展望成为CNCF毕业项目，为云原生应用提供更加丰富和强大的文件分发能力。开源版与集团内部版融合，给社区开放出更多的高级特性。智能化方面进行更多探索和改进。本文作者：amber涂南阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...