Go 语言开源发布 8 周年，盘点基于 Go 的重要开源项目

发表于 2017-11-13

点击上方“CSDN”，选择“置顶公众号”

关键时刻，第一时间送达！

Go 语言作为开源项目发布，已经 8 周年了。官方发表博客表示了对它的庆祝，并罗列了几项流行度趋势图。我们明显可以看出，Go 这几年的快速发展。

来源：trends.google.com

Go 在全世界拥有大约 100 万的 Go 开发者，它在 GitHub 的 2017 年最流行编程语言榜上排第九，超过了 C，也是 2017 年 GitHub 增长最快的语言，同比增长率 52%，超过了 Javascript 的 44%。

来源：octoverse.github.com

Stack Overflow 2017 年的调查显示，Go 同时进入用户最喜欢编程语言和最想要编程语言榜单的前五，也是唯一一个同时进入两个榜单前 5 的语言。

来源：insights.stackoverflow.com/survey/2017

用 Go 的开发者喜欢它（最喜欢的是 Rust），没用过的人也迫切想用它。Go 是云基础设施语言，每一家云服务公司的基础设施中都有用 Go 实现的关键组件，它也是阿里巴巴、Cloudflare 和 Dropbox 等公司的云设施的关键组成部分。Go 开发者已经在准备开发下一代的 Go 2。

基于 Go 的重要开源项目

Moby（https://github.com/moby/moby）：一个新的开源项目，旨在推动软件的容器化，并帮助生态系统使容器技术主流化。

Kubernetes（https://github.com/kubernetes/kubernetes）：来自 Google 云平台的开源容器集群管理系统，用于自动部署、扩展和管理容器化（containerized）应用程序。

Hugo（https://github.com/gohugoio/hugo）：Go 编写的静态网站生成器，速度快，易用，可配置。Hugo 有一个内容和模板目录，把他们渲染到完全的 HTML 网站。

Prometheus（https://github.com/prometheus/prometheus）：一个开源的服务监控系统和时间序列数据库。

Grafana（https://github.com/grafana/grafana）：Graphite 和 InfluxDB 仪表盘和图形编辑器。

Syncthing（https://github.com/syncthing/syncthing）：一个免费开源的工具，它能在你的各个网络计算机间同步文件/文件夹。

————— END —————

一小时入门 Python 3 网络爬虫

我在楼上写代码，你在楼下虐我娃

曾经的 Java IDE 王者 Eclipse 真的没落了？21 款插件让它强大起来！

)

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

天猫11·11：蚂蚁金服如何用小团队支撑数亿人买买买？

发表于 2017-11-13

策划 & 撰稿丨 Natalie
又到了一年一度的“天猫双 11”，外行看热闹（剁手），内行看门道（技术）。每年“天猫双 11”都会创造不少与“交易量”相关的世界纪录，而这些世界纪录的背后则有改变世界的技术作支撑。作为买买买的重要一环，支付宝是如何撑起 12 万笔每秒的交易量的？InfoQ 小编带你走进蚂蚁金服一探究竟。
下面这张图，记录了支付宝历年双 11 的峰值交易数据。

从 2010 年的每秒 300 笔，到 2016 年的每秒 12 万笔，交易笔数提升的背后，是蚂蚁金服技术能力被“逼”着快速升级。

1 从人肉云计算到智能化云平台
曾经支付宝距离数据库崩溃仅剩 4 秒
支付宝刚起步时，技术远没有今天那么受重视，原因很简单，不需要、没必要。在创业之初，2004 年时，支付宝还是淘宝中的一个结算部门，淘宝的会计人员用两台电脑和一张 Excel 表就能进行结算。那时每天的交易金额是三位数，全天交易笔数只有十几笔，如果分摊到每秒钟，则约等于零。

2009 年是淘宝第一次搞双 11 大促，那时双 11 还不像现在这样广为人知，所以 2009 年的交易量并不大。在此之前，支付宝也刚完成二代架构的升级改造。在二代架构做完之后，支付宝的技术团队感觉能解决的技术问题都已经解决了，很多人认为未来系统也许就可以这样发展下去。因此在 2010 年双 11 大促之前，支付宝的系统规划是按照每年增长 100% 余量预估的。

但谁也没有预料到人们买买买的疯狂程度，二代架构上线并没有多久就迎来了严峻的考验。双 11 当天零点刚过，支付宝的业务量快速攀升，每秒交易量直接飙到平时峰值的三倍——每秒 500 笔，而且居高不下。这时大家才意识到，系统容量并不足以支撑当天的交易量。

情急之下，支付宝技术团队开始不停地“搬资源”、“砍业务”，东拼西揍地保障系统不崩溃，这一窘迫的过程事后又被大家戏称为“人肉云计算”。直到当天的 23 时 59 分 30 秒，眼看 2010 年双 11 大促就要结束了，突然核心账务系统报警。千钧一发之际，技术团队紧急将内部对账用的会计系统应用杀掉（可以在双 11 过去之后再用交易数据恢复），将资源释放出来，这次双 11 才算有惊无险地度过，而这时距离数据库崩溃仅剩 4 秒。

“双 11”逼出来支付宝的三代架构
从 2005 年开始，支付宝的技术架构经历了“烟囱型”、“面向服务型”、 “云平台型”三个时期。支付宝的三代架构可以说是和双 11 彼此成就的。

支付宝的第一代架构就像一个个独立的“烟囱”，没有基础架构可言，做一个业务就竖起一个“烟囱”。“烟囱”之间的关联性不大，每做一个新业务就要对一个烟囱进行手动改造，而支持主要业务的“大烟囱”则经历了无数次改动。

第一代“烟囱型”架构能够满足小团队开发、业务快速试错的需求，但是这个架构无法支持大团队的分布式开发。与此同时，它的部署也是集中的，核心系统就是一个集群，数据库也只有一个。随着业务量的上升，这样的数据库和集群很快就会达到极限。为了满足业务扩展的需要，分布式架构改造被提上了日程。

当时，分布式系统在互联网的应用并不罕见，规模较大的互联网公司系统都分布化了。但是由于金融系统对于稳定性和安全性要求较高，分布化尚无先例。对于金融系统来说，任何改进都要先保证用户账目上的钱分毫不差，在系统数据分离之后，保证系统之间业务处理的一致性就成了核心问题。

2007 年初，分布式系统技术逐渐成熟，特别是大规模 SOA 系统中的分布式事务处理标准逐渐明晰，支付宝随之启动了分布式改造工作。从 2007 年开始，支付宝陆续花费了三年左右对整个系统进行分布化，将原来的大系统拆成了一个个分布式的“服务”。由此，支付宝夯实了分布式事务的基础设施，所有的业务都可以分开来做，系统具备了可伸缩性，如果遇到业务峰值，就可以增加资源。当然，这时增加资源还需要人工搬运。但支付宝的第二代架构已经为第三代架构“云支付”打下了基础，因为如果使用云计算，系统首先要分布，只有这样才能用很多小型机器、云资源作为支撑。

二代架构改造完成之后，淘宝开始了每年一度的双 11 大促。对于支付宝技术来说，2010 年是一个拐点，这一年，交易数据的峰值比此前翻了三倍，也正是这一年惊险的双 11 让技术团队意识到，业界现有技术和传统架构已经无法满足支付宝的发展需求。

支付宝技术团队尝试了一种新的对策——分布式“异地多活”架构。蚂蚁金服副总裁胡喜将其比喻为“拆掉了高端中央收银台，换成了分散在商场各个角落的无数小型计算器”，每台计算器虽然不如单一中央收银台厉害，但个个都能记点帐，同时支付宝为分散在各处的计算器设计了相互关联的逻辑关系，使它们互为补充、互相备份，从全局上保证运算可靠，因而任何单个计算器的故障，都不会影响整个系统的正常运行。这是这种架构中最核心的云计算能力。

从二代架构过渡到三代架构，支付宝又花了三年时间。在此期间，支付宝开始自主研发中间件、数据库、大数据平台。第三代云支付架构完成了两方面的改造：一方面是在底层使用云计算技术；另一方面是在上层把服务变成云服务，如此一来，建立在这个架构之上的业务增长就不会受到限制。

正是这个云计算架构，支撑了近几年淘宝大促的交易，也使后来的“天猫双 11”能够平稳地进行。

2016 年双 11 蚂蚁金服在技术保障上有两个亮点，一是整个支付核心链路，包括交易、支付、会员、账务都运行在自研数据库 OceanBase 上；另一个是蚂蚁自主研发的弹性架构，能够利用全国多个城市的云计算资源，从而支撑 12 万笔／秒的支付峰值（2015 年的 1.4 倍）。

弹性架构具备在云计算平台上快速伸缩容量的能力，50% 流量基于云计算资源弹性伸缩，能够快速扩充支付容量，从而优化运维成本。理论上可以做到每秒百万级的交易支付能力。

2017 年支付技术保障新亮点
1. 离在线混合部署

今年蚂蚁金服推出了离在线混合部署，使用的服务器资源有 25% 是自有的，55% 在云上，20% 是离线资源。今年天猫双 11 交易高峰期，一部分交易将首次跑在临时“征用”来的存放和处理分析离线数据的服务器上。

说是临时“征用”，但绝不仅仅是“征来就用”那么简单。因为处理离线数据（即处理每天数据分析报告以及当日账表）和处理在线交易（即处理支付宝用户在线的海量实时交易）是完全不同的任务，这也决定了处理离线数据和处理在线交易的服务器的配置相差悬殊。

如何在交易高峰期，以秒级的速度将在线服务器的各种软件、应用转移到离线服务器中？这背后起到关键作用的，是容器技术和统一资源调度的能力。容器技术相当于 标准化改造，有了这个标准化改造的能力，各种配置不一、可以暂时放下手中的活伸出援手的服务器，都可以在各种大促场景派上用场，帮助疏通与分流。据估算，离在线混部技术能为 2017 年天猫双 11 减少近两千台服务器的投入。

2. 超级会计师 OceanBase

2016 年天猫双 11，12 万笔每秒交易峰值的背后，是“超级会计师”OceanBase 在发挥关键作用。

OceanBase 是一个海量数据库，可以存放千亿条以上的记录，单台普通的服务器每秒可以处理百万笔事务，平均一次花的时间仅在毫秒级别。

但意外的发生：服务器机房所在城市断电、连接机房的光纤被挖断、再好的机器也有出故障的时候……所以，金融机构普遍采用两地三中心来部署机房。

为了达到更高的可靠性，OceanBase 今年开始把数据同时放到三个城市，做五份数据备份，进一步降低了出错的可能性。

三地五中心，不仅仅是多了一个城市两个机房，蚂蚁金服还尝试使用一个新的选举协议：在出意外情况时，谁得到大多数投票，谁就当选主库。主库不再是固定的，每个被选举出的主库都是临时的，且它做的决定必须得到半数以上的同意才能实施。举个例子，一个主库刚被选举出来，它所在城市的光纤突然被挖断了，它会立即被票出去，做不成老大了，它做的决定也会全部被宣布无效；同时，一个新的主库会被票选出来，保证线上交易的顺利进行。

采用三地五中心的方案后，主库突发故障或者任何一个甚至两个机房同时断电、断网，业务都能在极短时间内自动恢复，不需要任何形式的人工对账。

3. 金融级图数据库 GeaBase

除了 OceanBase，蚂蚁技术团队还自主研发了一个叫 GeaBase（以下简称 GB）的金融级图数据库，它通过特有的数据组织方式和分布式并行计算算法，可以在几十毫秒内彻查目标对象的多跳资金转移关系、设备关联关系等组成的复杂网络，从而迅速锁定目标关联、识别欺诈。

GeaBase 是蚂蚁金服风控系统背后的关键技术支撑之一。刷单党、花呗套现党、羊毛党、欺诈等行为，都依靠 GeaBase 来识别。胡喜介绍道：“风控从最早偏向于规则架构，到后来规则加模型架构，现在向 AI 转，这也是双 11 相关的关键能力，背后承载的是我们在分布式金融交易之外的金融级实时决策能力。”

2 “未问先答”的新客服，开启主动服务模式
双 11 大促当天，随着交易量暴增，使用中遇到问题的用户数量也会大幅增加。不知道在你的想象中，支付宝会有多少客服小二？

记者走访了一圈蚂蚁金服 Z 空间大楼，这里的淘宝小二只有 600 人左右，算上成都团队和外包团队，也不过小数千人。而且，蚂蚁金服智能客服负责人子孟说道：“淘宝天猫平台业务量逐年增长，但是我们客服人数没有增加，反而还减少了。”

而这背后，是蚂蚁金服客服技术的进步史。

子孟介绍道，客户服务分为三个阶段：

客服 1.0：查询问答

在这个阶段，更多是查询类的事情，把很多回答的内容做成一个类目树让大家查询，不管在热线电话还是在 PC 端、APP 端，多数情况下需要大家逐层挖掘。比如我们拨打客服电话经常遇到的“xx 请按 1，xx 请按 2……人工服务请按 0”，要找到精确的问题分类或人工客服，不得不先听一段无比冗长的录音，导致查询效率底下，难以找到准确的答案。

客服 2.0：快捷应答

这一阶段是互联网企业通常会采用的手段，包括蚂蚁金服在很多场景下也会切换到这个手段，就是快捷应答。它包含两个点：一是更多在 APP 端、PC 端用问答机器人解决用户问题，通过用户问题可以快速识别问题分类，并指向某一个具体答案或者人工服务；二是在传统的电话过程当中，减少按键输入，更多使用语音交互方式。

客服 3.0：未问先答

很多时候客服的角色是相对滞后的，要等用户找上门来提出问题，甚至反复不断提出要求才能够回应，我们认为极致服务应该把事情做到事前，在用户可能遇到问题的时候提前化解他的障碍和疑问。

前一阶段积累了很多数据和用户行为的数据，我们现在希望推出的叫做“未问先答”服务。

在所有服务渠道中，我们不断依据用户的实时行为数据，经过学习和分析，在用户没有开口的时候就知道他可能想问什么问题，更快速地解决问题，这是“未问先答”这样一个技术在整个服务中的角色。

“未问先答”服务使用效果如下（整理自真实录音）：

复制代码`智能客服：欢迎致电蚂蚁金服，为给您提供自助或人工服务，请简单描述一下您的问题，请讲。`

用户：我想问一下那个余额宝里面的那个一万块的话一天是多少利息？

机器客服：您是要咨询余额宝的收益如何计算，对吗？

用户：对！

机器客服：您的解决方案已经发送，你可以登录手机支付宝在首页进行查询，请问还有其他问题吗，没有问题请挂机，如需人工服务请按 1。

“未问先答”还有其他玩法，比如用户在支付宝里反复操作、研究一个功能，但是多次操作后还没有成功，那么智能客服就会自动弹出，询问是否遇到困难，然后给出方案帮助客户解决。

“未问先答”的技术原理

“未问先答”如神算子一般的预测能力背后，离不开数据采集、算法加工和持续反馈学习。

大量 用户行为数据 是一切的基础。蚂蚁金服为实现“未问先答”而采集的数据主要有以下几种：一是通过客服加工过的有规则的精准因子，即这个用户具备什么样的特征，意味着什么样的问题；二是大量用户在支付宝操作、点击、页面跳转行为轨迹的特征；三是客户在服务渠道上咨询过什么问题、求助过几次；四是用户在支付宝、服务端描述过的，和他的需求相关的文本信息。
通过深度神经网络 算法加工 数据。不同数据加工方式不一样，比如轨迹类数据使用 RNN 模型，从而能更好地表现建模时间的先后顺序；对于用户画像和人工设计的精准因子会使用全连接的神经网络；对于文本数据则使用注意力模型。本质上就是在海量特征和标类问题之间进行匹配，精度相对比较高。
持续不断的 反馈学习。一次性做完可能很容易，但是结果通常不会一次就达到理想水平，因此需要利用反馈数据进行自学习优化。正负反馈都能进一步优化模型的训练，整个过程是数据闭环和自学习的过程，蚂蚁金服三月份就上线了这一模型，但是运转了约半年以后这个模型才相对成熟，甚至很多数据采集其实很多年前就开始了，但也经过了 1-2 年的沉淀才真正将数据投入应用。

今年，智能客服的“未问先答”技术首次运用于双 11。在人工智能的帮助下，新客服系统能预判用户可能碰到的问题，从被动型服务（等待用户来提问）转为主动型服务（提前预知用户可能存在的问题并提供解决方案），进而提高服务效率和用户体验。

3 AI Everywhere
沟通会上，胡喜回忆起三四年前的双 11，感慨万千。他说道：“以前的双 11，技术保障团队差不多三四百人，从年初开始准备，这些人很多事情都不做，就是要支持双 11，一次双 11 做完以后非常累。”而今年，智能化系统已经可以辅助人工进行系统容量预估和自动扩容。

除了容量预测和智能客服，人工智能也被应用到了双 11 的故障监控中。所有系统运行数据输入相应的机器，由机器进行训练，训练后生成模型，系统运行时模型输出的值是否合理不再由人来判断，而是由机器自动判断，从而快速发现系统异常。

胡喜表示，今年是 AI 的实验期，对于金融系统来说最大的挑战是可靠性和安全性，如何在保证系统智能化的同时提升系统的可靠性和安全性，一直是蚂蚁金服追求的方向。“今年蚂蚁金服已经把 AI 能力先应用在一些点上，比如故障预测、容量预测等，明年我们还会推出一个内部叫做免疫系统的平台，专门做故障自动发现和恢复的事情。”

胡喜感叹：“2017 年‘大考’，All in 支付技术保障只需要一个弹性化的小团队，而无需占用大量人力。这意味着‘天猫双 11’越来越常态化。 翻看几年前双 11 的老照片，照片里满公司的帐篷、睡袋，感觉已经是很久远的事情了。”

这背后，是技术在变得越来越智能化。

今日荐文

点击下方图片即可阅读

禅与互联网技术：龙泉寺的程序员们

渴望了解更多双 11 背后最新的技术架构？12 月 8-11 日，请前往由 InfoQ 举办的 ArchSummit 全球架构师峰会 北京站，大会与阿里巴巴合作策划了 双 11 架构专场，并邀请了顶级技术专家担任出品人，设置了“新一代 DevOps”、“人工智能与业务应用”、“架构升级与优化”等 17 个热门话题，更多详情可点击 阅读原文 了解大会日程。

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

QCon 2017分享总结——分布式系统设计的几点思考

发表于 2017-11-13

在QCon2017的基础设施专场，笔者以表格存储[1]为基础分享了分布式系统设计的几点考虑，主要是扩展性、可用性和性能。每个点都举了一个具体的例子来阐述。这里对这次分享做一次简单的总结，细节见文后slice。

首先，说到了表格存储产生的背景。

图1 表格存储出现的背景

上面介绍，大规模、弱关系数据，对灵活schema变动的需求，传统数据库无法很好的满足，NOSQL的出现是一个很好的补充。NOSQL不是为了取代SQL，也无法取代SQL，是已有数据库生态的很好补充。我认为未来会出现更多种类的数据库，面向不同的业务，使用不同的硬件，数据库市场将迎来更多的成员。

下面描述了表格存储的功能、生态、架构以及数据模型，有了这些基础才能更好的理解后面的内容，比如面向公共云服务的产品和面向企业内部的产品在架构设计的时候会有不同的权衡。

图2 表格存储一览

下面介绍分布式系统第一个要素，扩展性。扩展性是个很广泛的话题，我们只讨论系统能否尽快的利用更多的机器资源。很多分布式系统都有分区的概念（Partition, Segment, Range …），分区就是将单体切割为多个子单位，这样才有可能利用多个物理机器。但是何时切割、如何切割、切割后怎么办都是值得讨论的问题。下面讨论的是其中一个子问题，就是如何切割。

图3 在连续分裂能力上，表格存储 vs HBase

熟悉HBase的同学知道，HBase在一次分裂之后，需要做Compaction才能继续分裂，而Compaction时间持续可能数个小时，也就意味着数个小时内无法进一步分裂从而分担读写压力。表格存储支持连续分裂，也就是1个分区分裂成2个后，可以立刻继续分裂。那么，为什么表格存储要支持连续分裂呢？主要原因在于公有云多租户服务和企业内自用产品的不同。对于表格存储而言，用户点点鼠标就可以开通，业务访问随时可能大幅上涨，用户不会提前告诉我们，即使告诉了我们也没那么多人随时响应。而访问量上涨有很大的可能导致分区内访问热点，这些热点会导致延时上涨或者访问错误，需要系统能够快速的处理，否则就要赔钱。这时候系统必须具备连续分裂的能力，1个分裂成2个，2个分裂成4个…
。HBase更多的是作为一个软件，在企业内部由专门的DBA独立运维。而在企业内部，业务一般可以预期，很难出现运维不期望的巨量上升，所以对于HBase而言，连续分裂的必要性就降低了。这个不同，看似技术的不同，实际则是用户不同、产品形态不同带来的的不同选择。

再介绍分布式系统第二个要素，可用性。可用性就更是一个关乎全局的话题，全链路上任何一点风吹草动都可能影响可用性。我们这里将可用性的讨论局限在硬件故障，局限在机器down这个很小的层面上。众所周知，分布式系统能够自主应对少部分机器down而不需要任何人工干预（如果不是，那一定是假分布式系统），以尽可能的减少因为机器down而产生的服务中断问题。此时，不同的系统有不同的设计抉择，服务中断时间各不相同，作为用户会希望服务中断时间越短越好。

图4 在down机可用性上，表格存储 vs BigTable/HBase

我们这里以谷歌的BigTable以及开源的HBase为例来介绍。谷歌BigTable和开源HBase都采用在worker层聚合日志以提高性能。这个思路很好理解，就是将多个分区的日志聚合在一起，写入文件系统中，这样就能减少文件系统的IOPS，提高性能。但是，这对可用性是个很大的伤害，因为一旦机器发生down机，日志文件需要被读出来按照分区进行分割，这些分割完的日志文件再被相应的分区replay，然后相应分区才能提供服务。显然，上面这个过程会使得机器down时分区不可用的时间变长（想想看谁来分割日志呢？这是否会成为瓶颈？）。如果考虑到全集群重启，或者交换机down导致较多机器失联，那么其对可用性的影响将十分可观。这里是一个可用性和性能的权衡，表格存储在设计之初，是选择了可用性的，也就是每个分区有独立的日志文件，以降低在机器failover场景下不可服务时间。但是这是否意味着性能的下降？是的，但是我们相信可用性优先级更高，而性能总会被解决，后来我们也找到了非常不错的办法，见下面描述。

本节讨论分布式系统设计的第三个问题，性能。性能总是能让程序员热血沸腾，吭哧吭哧码了那么多代码，如果性能有了显著的提升，真是让人十分开心的事情。前面说，为了可用性，我们放弃了性能，难道就一直忍受吗？作为有骨气的程序员，显然是不能接受的。现在难题是必须在不伤害可用性的前提下，提高性能。其实说到性能，有两个基本的招数，就是聚合和拆分，然而在哪里聚，在哪里拆是一个设计的抉择。

图5 全链路视角权衡聚合的层次，考虑可用性和系统通用性

如上图所示，就是聚合时机选择的问题。BigTable和HBase的核心思想是聚合以减少IOPS，从而提高性能；那么聚合是否一定要做在table server这一层做呢？是否可以下推做到分布式文件系统层？结论是当然可以，而且效果更好，受益方更多。具体架构见附件里面的说明，我们通过将聚合下推到文件系统、RPC层小包聚合、Pipeline传输等大幅改进了性能，在可用性和性能之间取得了很好的平衡。当然，随着硬件的演进，未来可能磁盘控制器就把聚合做好了，上面的应用都不需要关心，这样受益方就更多了。

至此，我们聊到了分布式系统的扩展性、可用性和性能，并以实际的例子进行了分析。下面就介绍一个表格存储的特性，PK串行自增列，在消息推送、分布式ID生成、Feed系统中非常有用。这是一个很好地例子，来展示作为一个平台，如何向用户学习。附件中给出了PK自增列用于消息推送系统的例子，这方面我们写过不少文章，见[3][4]。

图6 向用户学习，表格存储提供串行PK自增列

以上就是分享的核心内容，大多是笔者的一些实践总结，没有上升到理论高度，难免有一定的片面性，欢迎探讨。表格存储钉钉交流群：搜索群号11789671加入，群名是“表格存储公开交流群”。目前表格存储引擎组在北京、杭州均有团队，我们也在努力寻找KV存储/SQL引擎优化人才，欢迎讨论。

[1]. 表格存储：www.aliyun.com/product/ots

[2]. QCon 2017资料: ppt.geekbang.org/qconsh2017
[3]. 高并发IM架构：yq.aliyun.com/articles/66…
[4].
打造千万级Feed流系统：yq.aliyun.com/articles/22…
[5]. 演讲PPT下载：ppt.geekbang.org/slide/show/… （QCon）或yq.aliyun.com/attachment/… （云栖）

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

文本表示的应用与评价

发表于 2017-11-13

前言：本文是对CMU CS 11-747（Neural Networks for NLP）课程中Using/Evaluating Sentence Representations章节内容的一个梳理。本文第一部分将对前几次课程中提到的文本表示方法进行一个概括。第二部分介绍五种文本表示的应用，分别是句子分类、释义识别、语义相似度、文本蕴涵和信息检索。本文将分别介绍这五种应用的任务及评价指标、常见数据集及其产生的方法、以及使用的模型。第三部分将做一个简要总结并分享一些相关问答。

本文作者：李思晴，2014级本科生，目前研究方向为深度学习、推荐系统，来自中国人民大学大数据管理与分析方法研究北京市重点实验室。

一、文本表示方法的简要概括

本文大致介绍两类文本表示方法。一类是将一个句子表示为一个向量，例如向量空间模型（VSM），也称词袋模型（BOW）。定义一个与字典长度相同的向量，向量中每个位置对应字典中相应位置的单词，句子中出现的单词，就在向量的对应位置填入相应权值，这样就可以用一个向量来表示一个句子。另一类是将一个句子表示为多个向量的序列，例如利用word embedding，将句子中每个单词都转化为一个向量，这样，一个具有n个单词的句子就可以表示为n个向量的序列。

二、文本表示的应用与评价方法

1、句子分类（Sentence Classification）

1.1 任务：根据主题或者情感语义等特性对句子进行分类。

1.2 模型：CNN在NLP中的一大应用就是句子分类。

传统的句子分类是使用SVM和Naive Bayes，它们选择的文本表示方法大多是词袋模型，会忽略词序信息。CNN用的是word-embedding来表示句子，可以保留词的序列特征。模型如下图所示：

首先将句子中的单词向量化作为输入，然后用CNN抽取句子的特征，可以得到对应的一个分数，再通过softmax函数将分数映射成概率。本专栏上一篇文章《从CNN视角看在自然语言处理上的应用》中有对CNN更详细的介绍，在此就不过多赘述了。

1.3 数据集：Stanford Sentiment Treebank (Socher et al. 2013)

下图为一个例子：

此数据集特殊的地方在于，句子中的每个单词都标有一个情感值，介于1到25之间，1表示最负面，25表示最正面。可以用此数据集来进行句子的情感分类。

2、释义识别（Paraphrase Identification）

2.1 任务：识别两个句子意思是否相同。

2.2 数据集：Microsoft Research Paraphrase Corpus (Dolan and Brockett 2005)

生成步骤：

（1）爬取大量新闻语料

（2）用启发式方法或分类器自动判别语句是否意思相同

（3）由评价者来判定两个句子是否真的相似

由于该数据集需要人工评测，所以数据量比较小但十分高质量。

2.3 模型：将两个句子的向量表示输入分类器，输出意思是否相同。

这里介绍一个可以用来做释义识别的句子表示模型：Skip-thought Vectors(Kiros et al. 2015) NIPS

这个模型训练时的输入是文档中的第i个句子，输出是第i-1个句子和第i+1个句子，例如下图：

这三句话的顺序是，I got back home. I could see the cat on the steps. This was strange.从训练的文本中取出类似这样的连续的三个句子，将中间的句子作为输入，前一个和后一个句子作为正确的输出来训练模型。模型使用的是encoder-decoder框架，并且用了RNN中的GRU来作为encoder和decoder。

Encoder的输入是第i个句子中单词的向量序列 $w_{i}^{1},...,w_{i}^{N}$ ，GRU的重置门、遗忘门、候选隐藏层和隐藏层的公式如下：

最后时刻输出的隐藏层 $h_{i}$ 将作为encoder的输出，也是第i个句子的单一向量表示，同时将其作为decoder的输入，decoder的重置门、遗忘门、候选隐藏层和隐藏层的公式如下：

与encoder的公式类似，不同的是多了 $C_{r}$ ， $C_{z}$ 和，分别用来分离出 $h_{i}$ 中重置门、遗忘门、候选隐藏层的部分。每一时刻t的隐藏层 $h_{i+1}^{t}$ 将作为decoder的输出。第i+1个句子的概率模型由以下公式给出：

其中 $v_{w_{i+1}^{t}}$ 是单词矩阵V中 $w_{i+1}^{t}$ 所对应的行，由这条公式即可生成第i+1个句子。生成第i-1个句子的方法同理。

目标函数是第i+1个句子和第i-1个句子概率模型的对数似然的和：

3、语义相似度（Semantic Similarity）

3.1 任务：衡量两个句子的语义相似/相关程度。

3.2 数据集：SICK Dataset (Marelli et al. 2014)

生成句子的过程：

（1）收集短的视频描述句子

（2）将句子进行主动态与被动态的转化、同义词替换等变化方式，生成新的句子

（3）将句子加入否定词或者进行反义词替换，生成反义句子

（4）打乱单词顺序生成新句子

最后人工测量这些句子的语义相关性，并用1-5进行打分。

3.3 评价过程：将两个句子输入模型计算相关度，并测量其与人工评测分数的相关性（例如Pearson相关系数）。

3.4 模型：ManhattanLSTM Model (Mueller and Thyagarajan 2016)

该模型将两个句子a和b的单词向量序列分别输入两个LSTM模型，输出分别是他们最后时刻的隐藏状态 $h_{n}^{a}$ 和 $h_{m}^{b}$ ，n和m分别是两个句子的长度，作差后取e^-L1作为相似度指标，如下图所示：

由于向量的L1范数是大于等于零的，所以该模型的相似度指标范围是0到1

4、文本蕴涵（Textual Entailment）

4.1 任务：文本蕴涵指的是两个文本之间有指向关系，关系分为以下三种：

Entailment：文本A为真，能推出文本B也为真

Contradiction：文本A为真，能推出文本B为假

Neutral：文本A为真不能推出文本B的真假

4.2 数据集：Stanford Natural Language Inference Dataset (Bowman et al. 2015)

生成数据步骤：

（1）取Flickr的标题作为初始数据

（2）对每个标题都分别创建它的entailed, neutral, contradicted标题

（3）人工对两两标题进行关系的评判

5、信息检索（Retrieval）

5.1 任务：给定一个输入句子，从大量数据中找出与之匹配的信息。

主要思想是，先将目标数据库中的文本编码成向量，然后将query也编码成向量，寻找数据库中与query距离最近的向量。

信息检索经常遇到的一个问题是数据库中数据量太大，导致训练太慢，所以可以只选取数据库中很小的一部分作为负样来进行负采样。

损失函数：

其中 $x^{*}$ 是正例的输入， $y^{*}$ 是正例的输出，S是负例样本。 $s(x,y^{*})$ 是负例所得的分数， $s(x^{*},y^{*})$ 是正例所得的分数，意思是若正例的分数比负例大于1则损失函数为0，否则会产生损失。

5.2 评价指标：

常用的评价指标有召回率和精确率。

召回率（Recall）： $R=\frac{TP}{TP+FN}$

精确率（Precision）： $R=\frac{TP}{TP+FP}$

由此衍生的评价指标还有：

recall@X：检索的前X个结果中是否有正确答案

MAP(mean average precision)：所有queries的平均精确率

三、总结与Q&A

本文首先简要介绍了文本表示的两类方法，一类是将一个句子表示为一个向量，另一类是将一个句子表示为多个向量的序列。然后介绍了五个文本表示的应用，分别是句子分类、释义识别、语义相似度、文本蕴涵和信息检索。

下面与大家分享几个相关问答。

1、与传统句子分类方法相比，CNN的优势是什么？

答：传统的句子分类是使用SVM和Naive Bayes，它们选择的文本表示方法大多是词袋模型，会忽略词序信息。CNN用的是word-embedding来表示句子，可以保留词的序列特征。

2、本文介绍的用于Paraphrase Identification的模型skip-thought vectors的框架是什么？

答：框架是encoder-decoder模型，其中encoder和decoder都用RNN中的GRU来实现。

3、skip-thought vectors中encoder和decoder的输入输出分别是什么？

答：encoder的输入是第i个句子中单词的向量序列 $w_{i}^{1},...,w_{i}^{N}$ ，输出是最后时刻的隐藏状态 $h_{i}$ 。decoder的输入是encoder的输出 $h_{i}$ ，输出是每一时刻t的隐藏状态 $h_{i+1}^{t}$ ，用来生成句子的概率模型。

4、Manhattan LSTM Model的相似函数是什么？

答：e^-L1，即

5、本文介绍的检索评价指标有哪些？

答：召回率（Recall）： $R=\frac{TP}{TP+FN}$

精确率（Precision）： $R=\frac{TP}{TP+FP}$

recall@X和MAP(mean average precision)

四、参考文献

Neural Networks for NLP

papers.nips.cc/paper/5950-… (Skip-thought Vectors)

nlp.stanford.edu/sentiment/t… (Sentiment Treebank)

www.aaai.org/ocs/index.p… (Manhattan LSTM)

nlp.stanford.edu/pubs/snli_p… (Stanford Natural Language Inference Corpus)

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

【译】Linux概念架构 Linux内核在整个计算机系统中的

发表于 2017-11-13

Linux kernel成功的两个原因：（1）灵活的架构设计使得大量的志愿开发者能够很容易加入到开发过程中；（2）每个子系统（尤其是那些需要改进的）都具备良好的可扩展性。正是这两个原因使得Linux kernel可以不断进化和改进。

Linux内核在整个计算机系统中的位置

Fig 1 - 计算机系统分层结构

分层结构的原则：the dependencies between subsystems are from the top down: layers pictured near the top depend on lower layers, but subsystems nearer the bottom do not depend on higher layers.

这种子系统之间的依赖性只能是从上到下，也就是在上图中位于顶层的子系统依赖位于底层的子系统，反之则不行。

内核的作用

虚拟化(抽象)，将计算机硬件抽象为一台虚拟机，供用户进程(process)使用；进程运行时完全不需要知道硬件是如何工作的，只要调用Linux kernel提供的虚拟接口(virtual interface)即可。
多任务处理，实际上是多个任务在并行使用计算机硬件资源，内核的任务是仲裁对资源的使用，制造每个进程都以为自己是独占系统的错觉。

PS：进程上下文切换就是要换掉程序状态字、换掉页表基地址寄存器的内容、换掉current指向的task_struct实例、换掉PC——>也就换掉了进程打开的文件(通过task_struct的files可以找到)、换掉了进程内存的执行空间(通过task_struct的mem可以找到)；

Linux内核的整体架构

中心系统是Process Scheduler（SCHED）：所有其余的子系统都依赖于Process Scheduler，因为其余子系统都需要阻塞和恢复进程。当一个进程需要等待一个硬件动作完成时，相应子系统会阻塞这个进程；当这个硬件动作完成时，子系统会将这个进程恢复：这个阻塞和恢复动作都要依赖于Processor Scheduler完成。

上图中的每一个依赖箭头都有原因：

Process Scheduler依赖Memory manager：进程恢复执行时，需要依靠Memory Manager分配供它运行的内存。
IPC子系统依赖于Memory manager：共享内存机制是进程间通信的一种方法，运行两个进程利用同一块共享的内存空间进行信息传递。
VFS依赖于Network Interface：支持NFS网络文件系统；
VFS依赖于Memory Manager：支持ramdisk 设备
memory manager依赖于VFS，因为要支持swapping，可以将暂时不运行的进程换出到磁盘上的swap分区，进入挂起状态。

高度模块化设计的系统，利于分工合作。

只有极少数的程序员需要横跨多个模块开展工作，这种情况确实会发生，仅发生在当前系统需要依赖另一个子系统时；
硬件设备驱动（hardware device drivers）、文件系统模块（logical filesystem modules）、网络设备驱动（network device drivers）和网络协议模块（network protocol modules）这四个模块的可扩展性最高。

系统中的数据结构

Task List
Process Scheduler 针对每个进程维护一个数据结构task_struct；所有的进程用链表管理，形成task list；process scheduler还维护一个current指针指向当前正在占用CPU的进程。
Memory Map
Memory Manager存储每个进程的虚拟地址到物理地址的映射；并且也提供了如何换出特定的页，或者是如何进行缺页处理。这些信息存放在数据结构mm_struct中。每个进程都有一个mm_struct结构，在进程的task_struct结构中有一个指针mm指向次进程的mm_struct结构。
在mm_struct中有一个指针pgd，指向该进程的页目录表（即存放页目录首地址）——>当该进程被调度时，此指针被换成物理地址，写入控制寄存器CR3(x86体系结构下的页基址寄存器)
I-nodes
VFS通过inodes节点表示磁盘上的文件镜像，inodes用于记录文件的物理属性。每个进程都有一个files_struct结构，用于表示该进程打开的文件，在task_struct中有个files指针。使用inodes节点可以实现文件共享。文件共享有两种方式：（1）通过同一个系统打开文件file指向同一个inodes节点，这种情况发生于父子进程间；（2）通过不同系统打开文件指向同一个inode节点，举例有硬链接；或者是两个不相关的指针打开同一个文件。
Data Connection
内核中所有的数据结构的根都在Process Scheduler维护的task list链表中。系统中每个进程的的数据结构task_struct中有一个指针mm指向它的内存映射信息；也有一个指针files指向它打开的文件（用户打开文件表）；还有一个指针指向该进程打开的网络套接字。

子系统架构

Process Scheduler 架构

目标

process scheduler是Linux kernel中最重要的子系统。系统通过它来控制对CPU的访问——不仅仅是用户进程对CPU的访问，也包括其余子系统对CPU的访问。

模块

进程调度器
调度策略模块(scheduling policy module)：决定哪个进程获得对CPU的访问权；调度策略应该让所有进程尽可能公平得共享CPU。

体系结构相关模块(architecture-specific module)设计一组统一的抽象接口来屏蔽特定体系接口芯片的硬件细节。这个模块与CPU交互以阻塞和恢复进程。这些操作包括获取每个进程需要保存的寄存器和状态信息、执行汇编代码来完成阻塞或者恢复操作。
体系结构无关模块(architecture-independent module) 与调度策略模块交互将决定下一个执行的进程，然后调用体系结构相关的代码去恢复那个进程的执行。不仅如此，这个模块还会调用memory manager的接口来确保被阻塞的进程的内存映射信息被正确得保存起来。
系统调用接口模块(system call interface) 允许用户进程访问Linux Kernel明确暴露给用户进程的资源。通过一组定义合适的基本上不变的接口（POSIX标准），将用户应用程序和Linux内核解耦，使得用户进程不会受到内核变化的影响。

数据表示

调度器维护一个数据结构——task list，其中的元素时每个活动的进程task_struct实例；这个数据结构不仅仅包含用来阻塞和恢复进程的信息，也包含额外的计数和状态信息。这个数据结构在整个kernel层都可以公共访问。

依赖关系、数据流、控制流

正如前面提到过的，调度器需要调用memory manager提供的功能，去为需要恢复执行的进程选择合适的物理地址，正因为如此，所以Process Scheuler子系统依赖于内存管理子系统。当其他内核子系统需要等待硬件请求完成时，它们都依赖于进程调度子系统进行进程的阻塞和恢复。这种依赖性通过函数调用和访问共享的task list数据结构来体现。所有的内核子系统都要读或者写代表当前正在运行进程的数据结构，因此形成了贯穿整个系统的双向数据流。

除了内核层的数据流和控制流，OS服务层还给用户进程提供注册定时器的接口。这形成了由调度器对用户进程的控制流。通常唤醒睡眠进程的用例不在正常的控制流范围，因为用户进程无法预知何时被唤醒。最后，调度器与CPU交互来阻塞和恢复进程，这又形成它们之间的数据流和控制流——CPU负责打断当前正在运行的进程，并允许内核调度其他的进程运行。

Memory Manager 架构

目标

内存管理模块负责控制进程如何访问物理内存资源。通过硬件内存管理系统（MMU）管理进程虚拟内存和机器物理内存之间的映射。每一个进程都有自己独立的虚拟内存空间，所以两个进程可能有相同的虚拟地址，但是它们实际上在不同的物理内存区域运行。MMU提供内存保护，让两个进程的物理内存空间不互相干扰。内存管理模块还支持swap——将暂时不用的内存页换出到磁盘上的swap分区，这种技术让进程的虚拟地址空间大于物理内存的大小。虚拟地址空间的大小由机器字长决定。

模块

内存管理子系统

架构相关模块(architecture specific module)提供访问物理内存的虚拟接口；
架构无关模块(architecture independent module)负责每个进程的地址映射以及虚拟内存交换。当发生缺页错误时，由该模块负责决定哪个内存页应该被换出内存——因为这个内存页换出选择算法几乎不需要改动，所以这里没有建立一个独立的策略模块。
系统调用接口(system call interface) 为用户进程提供严格的访问接口（malloc和free；mmap和ummap）。这个模块允许用进程分配和释放内存、执行内存映射文件操作。

数据表示

内存管理存放每个进程的虚拟内存到物理内存的映射信息。这种映射信息存放在mm_struct结构实例中，这个实例的指针又存放在每个进程的task_struct中。除了存放映射信息，数据块中还应该存放关于内存管理器如何获取和存储页的信息。例如：可执行代码能够将可执行镜像作为备份存储；但是动态申请的数据则必须备份到系统页中。（这个没看懂，请高手解惑？）
最后，内存管理模块还应该存放访问和技术信息，以保证系统的安全。

依赖关系、数据流和控制流

内存管理器控制物理内存，当page fault发生时，接受硬件的通知（缺页中断）—— 这意味着在内存管理模块和内存管理硬件之间存在双向的数据流和控制流。内存管理也依赖文件系统来支持swapping和内存映射I/O——这种需求意味着内存管理器需要调用对文件系统提供的函数接口(procedure calls)，往磁盘中存放内存页和从磁盘中取内存页。因为文件系统请求非常慢，所以在等待内存页被换入之前，内存管理器要让进程需要进入休眠——这种需求让内存管理器调用process scheduler的接口。由于每个进程的内存映射存放在进程调度器的数据结构中，所以在内存管理器和进程调度器之间也有双向的数据流和控制流。用户进程可以建立新的进程地址空间，并且能够感知缺页错误——这里需要来自内存管理器的控制流。一般来说没有用户进程到内存管理器的数据流，但是用户进程却可以通过select系统调用，从内存管理器获取一些信息。

Virtual File System 架构

目标

虚拟文件系统为存储在硬件设备上数据提供统一的访问接口。可以兼容不同的文件系统（ext2,ext4,ntf等等）。计算机中几乎所有的硬件设备都被表示为一个通用的设备驱动接口。逻辑文件系统促进与其他操作系统标准的兼容性，并且允许开发者以不同的策略实现文件系统。虚拟文件系统更进一步，允许系统管理员在任何设备上挂载任何逻辑文件系统。虚拟文件系统封装物理设备和逻辑文件系统的细节，并且允许用户进程使用统一的接口访问文件。

除了传统的文件系统目标，VFS也负责装载新的可执行文件。这个任务由逻辑文件系统模块完成，使得Linux可以支持多种可执行文件。

模块

虚拟文件系统模块

设备驱动模块（device driver module）
设备独立接口模块（Device Independent Interface）：提供所有设备的同一视图
逻辑文件系统（logical file system）：针对每种支持的文件系统
系统独立接口（system independent interface）提供硬件资源和逻辑文件系统都无关的接口，这个模块通过块设备节点或者字符设备节点提供所有的资源。
系统调用模块（system call interface）提供用户进程对文件系统的统一控制访问。虚拟文件系统为用户进程屏蔽了所有特殊的特性。

数据表示

所有文件使用i-nodes表示。每个inode都记录一个文件在硬件设备上的位置信息。不仅如此，inode还存放着指向逻辑文件系统模块和设备驱动的的函数指针，这些指针能够执行具体的读写操作。通过按照这种形式（就是面向对象中的虚函数的思想）存放函数指针，具体的逻辑文件系统和设备驱动可以向内核注册自己而不需要内核依赖具体的模块特性。

依赖关系、数据流和控制流

一个特殊的设备驱动是ramdisk，这个设备在主存中开辟一片区域，并把它当成持久性存储设备使用。这个设备驱动使用内存管理模块完成任务，所以在VFS与对内存管理模块存在依赖关系（图中的依赖关系反了，应该是VFS依赖于内存管理模块）、数据流和控制流。

逻辑文件系统支持网络文件系统。这个文件系统像访问本地文件一样，从另一台机器上访问文件。为了实现这个功能，一种逻辑文件系统通过网络子系统完成它的任务——这引入了VFS对网络子系统的一个依赖关系以及它们之间的控制流和数据流。

正如前面提到的，内存管理器使用VFS完成内存swap功能和内存映射I/O。另外，当VFS等待硬件请求完成时，VFS需要使用进程调度器阻塞进程；当请求完成时，VFS需要通过进程调度器唤醒进程。最后，系统调用接口允许用户进程调用来存取数据。不像前面的子系统，VFS没有提供给用户注册不明确调用的机制，所以没有从VFS到用户进程的控制流。

Network Interface 架构

目标

网络子系统让Linux系统能够通过网络与其他系统相连。这个子系统支持很多硬件设备，也支持很多网络协议。网络子系统将硬件和协议的实现细节都屏蔽掉，并抽象出简单易用的接口供用户进程和其他子系统使用——用户进程和其余子系统不需要知道硬件设备和协议的细节。

模块

网络协议层模块图

网络设备驱动模块（network device drivers）
设备独立接口模块（device independent interface module）提供所有硬件设备的一致访问接口，使得高层子系统不需要知道硬件的细节信息。
网络协议模块（network protocol modules）负责实现每一个网络传输协议，例如：TCP，UDP，IP，HTTP，ARP等等~
协议无关模块（protocol independent interface）提供独立于具体协议和具体硬件设备的一致性接口。这使得其余内核子系统无需依赖特定的协议或者设备就能访问网络。
系统调用接口模块（system calls interface）规定了用户进程可以访问的网络编程API

数据表示

每个网络对象都被表示为一个套接字（socket）。套接字与进程关联的方法和i-nodes节点相同。通过两个task_struct指向同一个套接字，套接字可以被多个进程共享。

数据流，控制流和依赖关系

当网络子系统需要等待硬件请求完成时，它需要通过进程调度系统将进程阻塞和唤醒——这形成了网络子系统和进程调度子系统之间的控制流和数据流。不仅如此，虚拟文件系统通过网络子系统实现网络文件系统（NFS）——这形成了VFS和网络子系统指甲的数据流和控制流。

结论

1、Linux内核是整个Linux系统中的一层。内核从概念上由五个主要的子系统构成：进程调度器模块、内存管理模块、虚拟文件系统、网络接口模块和进程间通信模块。这些模块之间通过函数调用和共享数据结构进行数据交互。、

2、Linux内核架构促进了他的成功，这种架构使得大量的志愿开发人员可以合适得分工合作，并且使得各个特定的模块便于扩展。

可扩展性一：Linux架构通过一项数据抽象技术使得这些子系统成为可扩展的——每个具体的硬件设备驱动都实现为单独的模块，该模块支持内核提供的统一的接口。通过这种方式，个人开发者只需要和其他内核开发者做最少的交互，就可以为Linux内核添加新的设备驱动。
可扩展性二：Linux内核支持多种不同的体系结构。在每个子系统中，都将体系结构相关的代码分割出来，形成单独的模块。通过这种方法，一些厂家在推出他们自己的芯片时，他们的内核开发小组只需要重新实现内核中机器相关的代码，就可以讲内核移植到新的芯片上运行。

参考文章：

声明：本文翻译自Conceptual Architecture of the Linux Kernel

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

Docker周报第149期

发表于 2017-11-13

学习教程

瓜子云的任务调度系统

瓜子云的任务调度系统结合了Kubernetes的Job和Airflow。并在Airflow基础上加了很多改动。本文跟大家交流瓜子云的调度系统的架构设计和解决方案。

DockOne.io
因Kubernetes漏洞导致银行应用瘫痪1小时，事件细节回顾和分析

手机银行Monzo经历了自成立来历史上最大的一次技术事故，技术主管Oliver在论坛上兑现承诺公布了整个事件的细节，并对未来技术要求作出了新的承诺。下面是Monzo技术主管Oliver在论坛再现最黑暗的一个半小时的记录。

Monzo技术博客
 从架构演进的角度聊聊Spring Cloud都做了些什么？

Spring Cloud作为一套微服务治理的框架，几乎考虑到了微服务治理的方方面面，之前也写过一些关于Spring Cloud文章，主要偏重各组件的使用，本次分享主要解答这两个问题：Spring Cloud在微服务的架构中都做了哪些事情？Spring Cloud提供的这些功能对微服务的架构提供了怎样的便利？

个人博客
 容器和分布式系统：从哪里来，将会去哪里

Mesosphere首席执行官（CEO）Florian Leibert最近和Chuck McManis进行了一次座谈，内容关于早期研发分布式系统遇到的挑战、容器技术的起源和计算的未来。如果你有看Hacker News，很有可能你已经认识他了，笔名为ChuckMcM的他很活跃。这次惊世的对话涉及到Chuck和他团队早期在建立分布式系统时所解决的问题，学到的经验教训和如何形成现在的架构–同时很有可能是计算的未来。

Mesosphere
携程容器云优化实践

随着微服务架构的流行，把容器技术推到了一个至高点上；而随着Docker，K8S等容器技术的日趋成熟，DevOps的概念也再次热度上升；面对容器化的大潮趋势，各家公司都在积极地响应和实践，携程也在这方面做了不少工作，形成了自己的容器云平台。

携程技术中心
 项目实施DevOps时，我们是如何做测试的

正如我们所知，DevOps最近几年很风靡，很多企业正在如火如荼的推行它。然而，你可曾想过，从传统到敏捷、再到DevOps，开发模式的不断革新对测试提出了怎样的挑战？

Thoughtworks
OPS基于Mesos/Docker构建的Elasticsearch容器化私有云

本文主要介绍 OPS 团队利用 Mesos 资源管理平台和 Docker 容器技术所构建的 Elasticsearch 容器化的私有云。

Qunar技术沙龙
 Kubernetes ConfigMap热更新测试

ConfigMap是用来存储配置文件的kubernetes资源对象，所有的配置内容都存储在etcd中，本文主要是探究 ConfigMap 的创建和更新流程，以及对 ConfigMap 更新后容器内挂载的内容是否同步更新的测试。

个人博客
 Kubernetes 1.8抢占式调度Preemption源码分析

本博文是对Kubernetes 1.8中基于Pod优先级抢占式调度Preemption的源码分析，整个过程主要围绕这scheduler的相关源码进行分析，从源码角度解读抢占式调度的全过程，相信从中你会学到很多在官方文档中你看不到但又很重要的细节，比如抢占的最佳节点到底是怎么选出来的？竟然还跟scheduler extender相关？

个人博客

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

有赞11·11：全链路压测方案设计与实施详解

发表于 2017-11-13

2017年双十一即将来临，对于买家来说是一年一度的购物狂欢，可是对于电商公司的技术人员来说，却是一年一次的大考。如何用更少的预算完成指定当前业务规模的流量高峰，是技术的永恒主题。

由InfoQ举办的ArchSummit全球架构师峰会即将于12月8-11日北京举行，大会与阿里巴巴合作策划了双11架构专场，并邀请了顶级技术专家担任出品人，设置了“新一代DevOps”、“人工智能与业务应用”、“架构升级与优化”等17个热门话题，目前
大会日程已出，欢迎前来讨论交流。

有赞在双十一之前完成了全链路压测方案，并把它用于大促的扩容和容量验证，取得了不错的成果。

在电商公司待过的技术同学都知道，在大促来临时，整个集群的最高峰压力将是正常时间的几十倍，最高峰持续的时间会特别短，然后回落到正常水平的几倍。所以，我们可能会自然而然地想到，把整个集群扩容几十倍的机器，在双十一当天应对几十倍的流量，然后第二天减至正常量，就可以完成大促的考验。事实情况是否真的这么简单？

大促保障的困难

用户购买商品的链路是一条很长很复杂的系统集群，中间会涉及到店铺、商品、会员、营销、交易、支付等6大核心模块，每个模块又会涉及到多个不同的服务化系统单元，我们把这一条骨干的链路就叫做核心链路。

大家都知道，双十一当天，真正爆增的其实是买家的购买量，像开店/商品上架等功能，其实并发量没什么变化。也就是说，真正的压力其实是在核心链路上面，如果把所有的系统都扩容几十倍，本身就是一个很大的浪费。正常来说，一个稍有规模的电商公司，日常有几千台机器维持正常的运转，本身就是一个较大的开销，如果突增几十倍的系统开销，对于公司的财务也是很大的压力。所以，一个较理想的方法，是只把核心链路的系统扩大几十倍的系统吞吐量，就可以达到目标。

困难一

大型的分布式系统其实错综复杂，公司需要维持成百上千的服务化系统。理论上来说，只有少部分系统是核心链路的系统。但是在实际情况下，因为公司人员的关系，可能会把某些非核心系统，不知不觉加入到了核心链路中。所以，第一件要做的事情，就是把非核心系统从核心链路上剔除。

困难二

一般公司都会在线下搭建性能测试环境，在该环境下，我们的测试同学可以借助一些测试工具，去压单机单接口的性能。假如，店铺的首页面，我们在性能测试环境下，得出单机单接口的QPS峰值是500，这是否意味着，要达到10w的QPS，我只需要设置200台机器就可以了呢？答案当然是否定的。因为任何的页面接口都不是单独存在的，都会受到公共资源的制约，如：DB、Redis、MQ、网络带宽等。比如当店铺首页达到10w QPS的时候，商品详情页可能要达到8w的QPS了，也会消耗公共资源。当公共资源的能力下降时，势必会影响所有的系统。所以，通过单机性能算出来的理论值，跟实际情况会相差很远。

困难三

正常来说，任何大促都会有业务目标，这个目标一般是拿GMV进行评估。但是我们在进行系统容量评估的时候，一般会想扩大多少台机器。那么GMV跟核心链路各个系统之间的机器数量的转化关系是什么样的？

困难四

做过大型分布式系统的同学，可能都知道一个事实，即整个集群的性能其实取决于接口的短板效应。而这个短板的接口，在正常的流量下，是不会显现出来的。只有集群的整体压力达到一定值的情况下，才会偶尔显现，然后造成雪崩效应，拖累整个系统集群。所以，如何在大促之前找到这些短板，然后把它们一个一个优化，这件事情就显得非常重要。

困难五

应用系统的扩容相对而言是比较简单的，完成大促之后，可以很容易归还。但是DB等核心资源的扩容其实并不容易，而且资源不可能归还（数据不不可丢失）。

事实是检验真理理的唯⼀一标准，上面提到的五个困难，其实都可以用线上真实压测的办法去检验。业内大型电商公司，会用全链路压测的方案去指导扩容的进程，有赞也不例外。今年双十一，有赞用该方案完成了对核心链路20倍的扩容，但是整个集群的规模只是扩大了了一倍多一点。

有赞全链路压测的设计方案

全链路压测的目标是让双十一要发生的事情提前发生，并验证在该情况下系统表现良好。做线上压测，有一个很重要的原则：线上系统是不允许有脏数据的。

有赞的压测设计方案，可以用几句简单的话做概括：

压测流量落影子库，正常流量落正常库。
压测不能把系统压崩溃。
压测是模拟双十一流量最高峰时用户的购物行为，所以综合性的流量模型需要跟实际情况相符。

全链路压测的总体设计

有图有真相，我们先上图。

在上述图中，我们明显可以看到，全链路压测有几个关键部分：

数据工厂，负责造请求数据。
大流量下发器，产生很大的压力去压系统。
线上服务集群同时处理压测请求+正常请求。
压测流量落影子存储，正常流量落正常存储。
压测流量对于外部的依赖走mock服务器，正常流量走正常外部集群。
水位检测，需要检测存储+线上应用服务器的健康度，并且能够干预流量下发。

关键模块的设计方案

数据工厂设计

数据工厂是压测的一个核心部件，主要由Hive表的集合+各种导入、导出脚本组成。

数据工厂的目的是保存压测需要准备的所有数据，数据需要做清洗，比如：

商品未下架
商品的库存无限
营销活动的信息有效，未过期
店铺未关闭等等

场景的定义：场景的定义关系到数据的准备，正常来说，压测只会压随着买家人数暴增、系统的压力立即增加的场景，我们把这个场景涉及到的系统叫做“核心链路”。

影子存储的设计与路由能力

DB、路由方式由RDS提供，存储可以有两种方式：
- 影子表与正常表存在同样的instance、不同的schema中。这个方案不需要增加额外的存储开销，相对更便宜，但是风险较高（把库压死了会影响线上业务）。
- 影子表与正常表存在不同的instance、相同的schema中。这个方案相对较贵，需要额外搭建DB集群，但是安全性较高。我们选择的是第一个方案。
Redis：通过key值来区分。压测流量的key值加统一前缀，通过Redis-Client做路由。
HBase：通过命名空间做隔离。影子空间加前缀，提供统一的HBase Client做数据访问，由该Client做路由。
ES：通过index名字来区分。影子的索引统一加前缀，提供统一的ES Client做数据访问，由该Client做路由。

线上应用集群的变更

统一线上应用对于数据的访问（DB+ES+HBase+Redis），提供统一的Client。
由于线上的应用都是服务化工程，远程调用时，必须具备压测流量的标记透传能力。
线上的少部分应用，需要访问第三方服务，比如：物流、支付。这些应用需要改造为压测的流量直接访问mock服务器。

全布式流量下发器设计与链路设计的能力

我们选用gatling作为我们的流量下发器实现。

数据文件的内容

每一种场景都有不同的数据文件，数据文件由场景相对应的多种url组合而成。比如：我们本次压测会压“无优惠的场景、秒杀场景、满减场景、拼团场景” 等等。无优惠的场景分为“店铺首页、商品详情页、加购物车页、下单页、支付页、支付成功页”等等。这个文件不涉及漏斗转化率。一般来说，一个数据文件很大（至少是G级别的）。所以我们的数据文件内容格式为：

所有的数据⽂文件
- 无优惠的场景数据文件
  - 场景集合1
    - 店铺首页URL
    - 商品详情页URL
    - 加购物车页URL
    - 下单页URL
    - 支付页URL
    - 支付成功页URL
  - 场景集合2
    - 店铺首页URL
    - 商品详情页URL
    - 加购物车页URL
    - 下单页URL
    - 支付页URL
    - 支付成功页URL
- 秒杀场景数据文件
- 满减场景数据文件
- 拼团场景

流量下发脚本的内容

流量下发脚本的核心是控制漏斗转化率：

不同场景的流量配比。
每个场景下面，url从上往下的漏斗转化率。

gatling提供天然的转化率配置脚本，用起来非常方便。有兴趣的同学可以自行Google。

水位检测系统的能力设计

这个是一个很重要的模块，在项目启动之初，我们希望以实时计算的方式，一边采集各个应用系统的资源使用情况+接口耗时+业务正确率，一边向gatling发送流量干预信号，以做到自动保护系统的目的。由于时间关系，我们并未实现这一方案。取而代之的是人肉查看实时监控界面的方式，人为去干预gatling的流量下发情况。

全链路路压测的实施

如果实施过全链路压测的项目，大家都会有一个共同的感受：做基础的组件容易，让核心业务去完成相关的升级与验证工作很难。原因只有一个：需要用全链路压测的公司，业务规模都很大，涉及的团队会特别多。梳理理清楚庞大的业务，让所有的业务团队一起发力，本身就是一件很难的事情。

我们把链路压测的实施分为以下几个阶段：

基础中间件开发，各种框架升级开发，压测器研究与脚本开发。
业务升级与线下验证（人工点击，数据落影子库）
业务升级与线上验证（人工点击，数据落影子库）
数据工厂数据准备。
小流量下发验证（用gatling下发，数据落影子库）
大流量量压测与系统扩容

第2、3、5阶段，需要借助业务测试同学的力量；第4阶段，需要借助业务开发同学的力量；第6阶段，则需要借助业务团队+运维同学的力量。

由于每个阶段人员都不太一样，所以需要每一个阶段都组织不同成员的虚拟小组，借助各个团队的力量完成相应的工作。

压测过程中的重要细节与把控

流量爬升的规律

正常来说，在大促之前做压测，目的一般是给扩容/优化做方向性的指导。

假设我们双十一需要扩大20倍的容量以应对高峰，那我一定不会一开始就拿20倍的流量去压我们的系统，因为这样做的话，所有的系统都会在一瞬间就挂掉，这样没有任何意义。我们的做法是，阶段性的爬坡打流量，然后把系统的能力一段一段提升上去。

例如：

第一天，我们会以日常流量的最高峰为起始流量，然后爬坡到一个流量高峰A，记为第一天的目标。在压测之前先做一次扩容。在压测中，碰到了某个瓶颈了，通过增加该系统的机器来提升能力。
第二天，我们以A为起始流量，然后再次爬坡到B。同样压测前做扩容+压测中碰到瓶颈加机器。
以此类推，一直到最终流量达到目标流量为止。
每一天的压测，也需要以慢慢爬坡的方式提升流量。在爬坡的某个高度稳定5分钟，然后再次爬坡。稳定时间5分钟，爬坡时间30秒。

非核心链路进核心链路的问题

发现并解决这个问题，本身就是压测的目的之一。

正常来说，非核心链路，在大促来临时不会扩大多少容量。当压测的压力增大时，很容易通过系统报警查到。

当发现这个问题的时候，一定要坚决要求业务方做系统改造，把非核心系统的强依赖去掉。解耦的技术有很多，需要根据不同的业务规则来选择方案。比如：业务降级、通过中间件解耦、异步化等。

上下游扩容/代码优化的选择

一般来说，在压测的过程中，当碰到压测流量不能再升高的时候，会有很多原因，我们碰到的情况有以下几种：

下游的某些服务化工程的能力达到瓶颈了，导致网关RT值升高，拖累整个集群的QPS上不去。
网关应用自身的能力达到瓶颈。
中间件/DB能力达到瓶颈。
job的能力达到瓶颈，导致数据处理不够及时。
流量集中的页面，消耗了集群大量资源，如：店铺首页、商品详情页等。

针对2、3、4这样的情况，我们的选择是毫不犹豫地加机器，代码优化的性价比较低。

针对第1种情况，需要做一些分析，如果这样的能力是在系统设计者的预期之内的，可以选择加机器，如果完全超乎意料的，一定需要通过程序优化来提升能力，否则加了资源，可能还是瓶颈。

针对第5种情况，一定要做的事情是静态化。因为这些流量集中页面，一般都是展示性质的。不管如何做应用内的优化，获得的能力提升远不如做静态化的收益大。

未来展望

全链路压测的方案有赞只是初试牛刀，我们已经看到了这个方案在提升+验证集群处理能力方面巨大的价值。当前，这个方案做得还较粗糙，存在一些问题：

压测只能在夜间做。
压测中需要有很多业务开发人员陪同。
链路规划复杂度太高。
压测控制台的稳定性还不够高。
水位检测与流量干预是通过肉眼观察监控来实现。

后续我们团队会继续投入大量精力去完善整个方案。希望可以将压测方案变成：

线上测试链路的机器人，实时检测线上系统的正确性，同时没有脏数据干扰。
测试同学手里的工具，做到流量压测常规化，开发同学不用陪同。
压测可以在白天进行，晚上熬夜毕竟不利于健康。
链路规划图形化，并与数据工厂结合，完成数据的准备工作。
通过水位检测与流量干预来保护系统，让业务系统不会被压崩溃。

作者介绍

金瑞敏，有赞核心交易、java框架团队负责人。带领团队完成核心交易平台化体系建设，优化有赞服务化治理方案、环境隔离方案、全链路压测方案等等。长期从事分布式系统的建设与研究。

当当11·11：高可用移动入口与搜索新架构实践

国美11·11：大促场景下的国美智能推荐系统演进之路

苏宁11·11：Monitor在左，Control在右，监与控的结合——深度剖析穆加决策分析平台

苏宁11·11：从0到1，苏宁API网关的演进之路

蘑菇街11·11：图像算法在电商大促中的应用浅析

这可能是最好的技术内容搜索引擎

京东虚拟商品系统如何做高可用架构设计？

顶尖架构师岁末总结大会：上百技术案例日程出炉！

不改一行代码：左耳朵看微服务调度的三大件

AI时代，我到底该如何跟上技术潮流？

您好，朋友！

您需要注册一个InfoQ账号或者登录才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

社区评论
Watch Thread
关闭
 关闭
 关闭

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

腾讯云11·11：千亿订单背后的安全“暗战”

发表于 2017-11-13

每年的电商大促，就像是一次次的系统检阅仪式，接受着来自用户、同行以及老板的审视。而在一次次订单量记录刷新，成交额飙出新高的同时，平台架构也在面临巨大的挑战，如页面打不开、服务不可用、优惠券被薅、网络被攻击、支付延迟等都有可能发生。那么针对这些问题，腾讯云是如何助力其电商客户解决？本文将从海量并发、安全性、用户体验几个方面，深入讲解腾讯云电商平台最佳实践方案。

另外，由InfoQ举办的ArchSummit全球架构师峰会即将于12月8-11日北京举行，大会与阿里巴巴合作策划了双11架构专场，并邀请了顶级技术专家担任出品人，设置了“新一代DevOps”、“人工智能与业务应用”、“架构升级与优化”等17个热门话题，目前
大会日程已出，欢迎前来讨论交流。

海量并发弹性扩容

回顾近年来的电商大促，最具特色的便是抢购、秒杀活动了，而这也使得Web 访问量可能瞬间陡增十倍甚至是数十倍，对接入层、逻辑层的按需、实时、快速平行扩展能力提出了较高的要求，如选用传统的硬件设备搭建集群，会遇到成本高昂，运维繁琐等问题。

对于这些问题，可以采用负载均衡配合云监控、弹性伸缩（Auto Scaling）、消息队列、分布式缓存、分布式数据库等服务来解决。

负载均衡服务：CLB 单集群的最大并发连接数超过1.2亿，可处理峰值40Gbps的流量，每秒处理包量为600万，负载均衡服务曾在历年的春节微信“抢红包”历练；
弹性伸缩可以根据需求和策略，比如CPU利用率达到阀值，就自动扩容指定数量的云服务器，也可根据定时、周期或监控策略，相应地增加或减少CVM实例，并完成配置，保证业务平稳健康运行。

对于自建IDC的客户，则可以采用混合云的模式，以专线将腾讯云与其自建IDC连接起来，这样仅在公有云上部署其接入、逻辑、cache层，就可充分复用公有云的BGP接入及弹性的能力。

腾讯云安全体系防御原理及过程分析

安全性对于电商平台来说，不仅仅在大促期间会一而再再而三地关注到，它更是一个日常话题，网站入口、支付等环节，都往往处于“高危”环境，来自于网络“黑客”及“黑产”团队的恶意攻击等，都有可能会导致网站核心业务不可用、运营投入的大量优惠券被“羊毛党”抢占，甚至给后台系统带来“致命”打击。

腾讯云今年推出了AI安全战略，以大数据和AI的算法为驱动，构建应用于安全领域的包括社交图谱分析、图像自动识别、自然语言处理、知识表达推理等AI通用能力，形成智能身份鉴定、威胁情报分析、异常流量检测、网络攻击溯源、人机行为识别、恶意图片识别、垃圾文本检测等7项技术应用。

这些能力通过多款产品，如业务安全（天御）、主机安全（云镜）、数据安全（数盾）、移动安全（乐固）、账号安全（祝融）、网站与流量安全、内容安全与风控安全，为客户提供安全保障。本次我们将重点放在电商客户最常遇到的网络安全和业务安全展开介绍。

网络安全检测系统及防御原理

BGP高防（大禹）产品是腾讯云针对电商网站遭受大流量 DDoS 攻击时服务不可用的情况推出的增值服务，提供300G 的防护服务并拥有35线的 BGP 线路，帮助客户全面应对DDoS 攻击的挑战，同时改善客户的访问体验。

图：腾讯云DDos防护体系架构

BGP高防攻击检测

对于BGP的高防攻击检测，腾讯云采用光棱镜物理分光来做1:1流量镜像，旁路Netflow检测镜像流量，不影响客户正常业务流向，检测后的镜像流量被丢弃。检测原理主要是基于流量建模分析客户IP的流量中是否存在攻击流量。

对于清洗攻击，在检测到某个IP被攻击后，清洗集群向核心路由发布BGP牵引路由，将该IP的流量牵引至清洗集群防护。清洗后的干净流量，再通过BGP路由回注至核心路由，最终流至客户的云主机或通过转发集群流至客户在腾讯云外的机房。
防护算法主要是基于IP/TCP/UDP协议的缺陷检测及HTTP、HTTPS报头的分析，不涉及、不查阅业务负载报文，防护系统对客户的业务数据完全无感知。
云内客户通过高防包绑定需要防护的设备，来提升防护级别。
- BGP高防专区除了提供高防服务，还同时对腾讯云客户的公网IP提供基础防护
- 业务部署在腾讯云的客户，可以将绑定高防包绑定至需要防护的设备，提升防护级别。

云外客户通过高防IP牵引攻击流量，保护后端业务
- 客户在腾讯云高防IP上配置业务转发规则；
- 客户将高防IP作为业务IP对外发布；
- 所有流量都先经过腾讯高防IP，再转发到客户真实源站，攻击流量在高防机房被清洗。
- 高防IP基于公网IP回源，在其他云或IDC机房的业务，都可以接入腾讯云高防IP的防护

网络安全防御实践

大禹是腾讯云AI安全战略的网站安全防御系统，大禹网站高防可抵御SYN Flood、ACK Flood、UDP Flood、NTP Flood、SSDP Flood、DNS Flood、HTTP Flood、ICMP Flood、CC等各类攻击。防护与腾讯安全大数据平台联动，实时更新防护策略库，有效防护新攻击手法。

DDos防护：大禹 BGP 高防基于先进特征识别算法进行精确清洗，抵御 Syn Flood、ICMP Flood 等各种大流量攻击。业务接入大禹 BGP 高防后，该功能自动开启，无论是 SYN Flood、UDP Flood 还是其他类型的大流量攻击，大禹 BGP 高防系统单节点能够防御300Gbps攻击。
CC防护：大禹 BGP 高防通过模式识别、身份识别等多种手段，来识别恶意访问者，同时采用重认证、验证码、访问控制等手段，抵御 http get 等各类应用层攻击。恶意竞争者和黑产从业者将无法通过应用层攻击威胁到客户的业务服务器。

腾讯目前通过自建骨干网的CAP平台，BGP链路对接了35家运营商，其中包括中国电信、中国联通、中国移动、中国教育和科研计算机网、中国科技网5家运营商。其余为中小运营商，包括：鹏博士、长宽以及各地广电等宽带接入服务商。

腾讯云业务安全防御框架深度解析

“羊毛党”双十一刷单流程

“羊毛党”其实早已经从个体行为、小作坊发展成了产业链，他们往往有着明确的分工，已形成几大团伙。下图为电商刷单团队的工作模式和任务分工。

图：电商刷单团队的工作流程

具体操作方式：

1.软件制作团伙：专门制作各种自动、半自动的黑产工具，比如注册自动机、刷单自动机等；他们主要靠出售各种黑产工具、提供升级服务等形式来获利。

2.短信代接平台：实现手机短信的自动收发。这其中，有一些短信平台是亦正亦邪，不但提供给正常的商家使用，一些黑产也会购买相关的服务。

3.账号出售团伙：他们主要是大量注册各种账号，通过转卖账号来获利；该团伙与刷单团伙往往属于同一团伙。

4.刷单团伙：到各种电商平台刷单，获取优惠，并且通过第三方的电商平台出售优惠，实现套现。

腾讯云天御系统安全监测方案

腾讯天御产品通过腾讯积累的安全大数据和防刷引擎，精准识别“薅羊毛”的恶意行为，避免企业被刷带来的巨大经济损失。其防御过程大概如下：

1.通过天御防刷，判定请求流量是否为恶意（API实时接口）；

2.之后，天御结果200毫秒内返回，厂商可根据返回的风险值（level），共计5个档位做合适的处理：

3.若厂商需要做精细化运营，或者希望对某种异常标签做针对性的打击。可参考risktype返回的标签。通常根据风险值（level）做处理已足够。在风险值level不为0的情况下，risktype可任意组合（根据命中异常的标签实际情况）。

风险防御处理案例解析

以下为某厂商根据天御返回的风险值（level）进行处理的实际案例：

基于输入参数的实时分析系统，确保每次请求都实时评估判定：

传统黑名单机制，极易造成用户投诉。比如手机重放号、账号被盗后找回等，因历史作恶判定为黑而永久黑；
天御的实时判定服务，确保在不同的环境（如IP）下，实时关联数据亦不相同。所以每次请求，即使是同一个账号，亦会做出公允的评判
天御实时模型，在大量业务中学习和训练。这是整个服务的核心引擎，确保高可用高覆盖

创新玩法，提升用户体验

除了基础稳定性、安全性的保障，越来越多的电商平台，也在寻找新的模式、新的玩法，来提升自身平台的用户体验，提升转化率。腾讯云就现金电商平台的业务需求，总结了以下三大创新应用：

智能推荐，是最普适的一个诉求，面对不同的用户，根据客户的特征、喜好，展现不同的商品，一来可以提升用户好感度，另一方面也是提升转化率的良方。但这对于一般企业来说，是个漫长的周期，需要投入大量的人力和时间，不断地积累数据，不断地打磨算法，才能有所见效。腾讯云依托腾讯在电商、游戏、金融、泛娱乐、资讯及 3C 等多领域深厚的大数据技术积累，为客户提供基于海量用户画像 + 实时大数据机器学习的内容个性化推荐 PaaS 服务。
电商+直播。说到新玩法，“电商+直播”绝对是一个绕不开的火热话题，然而自主研发，却是难熬的等待，腾讯云基于腾讯多年在视频领域的经验，推出一站式解决方案，从全平台的推流主播SDK，到海量云端处理系统，再到强大的CDN云端加速，最终到用户播放SDK，无缝链接，24小时即可完成接入。
当然，如今备受关注的小程序，也是一个不得不提的话题，据统计，蘑菇街女装精选小程序7月4日正式上线，截至目前已经获取了6000万的新客户。到9月份，日均访问量增长较7月超过200%，GMV增长超过140%。而小程序现有的SDK/DEMO缺乏对云端的支持，依赖开发者逐个模块搭建云端服务，过程繁琐。腾讯云提供了一键构建具备云端能力的专属小程序，提高小程序开发的效率。此外，还提供PaaS级的WebSocket信道服务，降低了开发者使用WebSocket通信的门槛。同时，通过提供完整的鉴权会话管理服务，来保证用户的信息安全。

写在最后

本文通过云端海量并发弹性扩容、AI安全体系防御构建与实施、电商领域的创新应用三大板块介绍了腾讯云如何在双十一电商大促的情境下，为电商平台提供可用、高效、完善的安全护航方案。电商与黑产之间的较量从来不会结束，双十一来临之际，我们希望通过一些对抗黑产的新经验和技术的分享，给电商从业人员以及相关的开发者提供一些新的思路和借鉴。

作者介绍

戴唯伟，腾讯云解决方案资深架构师，5年传统SI技术工作经历，5年公有云上云架构咨询经历。上云架构“老司机”，曾就职于微软云、金山云，对国内外云厂商产品发展、各类用户上云历程有很多“切身体会”。深谙传统企业客户、游戏行业客户、互联网行业客户“上云”和“用云”的痛点、难点和机遇，职业理想是做云计算和AI殿堂里的“扫地僧”。

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

SpringMvc4x高级配置(一) 文件上传配置

发表于 2017-11-13

一. 点睛

文件上传是一个项目里经常要用到的功能，Spring MVC通过配置一个MultipartResolver来上传文件。

在Spring的控制器中，通过MultipartFile file来接收文件，通过MultipartFile[] files接收多个文件上传。

二. 示例

添加文件上传依赖

复制代码<!-- file upload -->
<dependency>
    <groupId>commons-fileupload</groupId>
    <artifactId>commons-fileupload</artifactId>
    <version>1.3.1</version>
</dependency>
<!-- 非必需，可简化IO操作 -->
<dependency>
    <groupId>commons-io</groupId>
    <artifactId>commons-io</artifactId>
    <version>2.3</version>
</dependency>

增加上传页面upload.jsp。

在src/main/resources/views下新建upload.jsp

复制代码
<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>upload page</title>

</head>
<body>

<div class="upload">
    <form action="upload" enctype="multipart/form-data" method="post">
        <input type="file" name="file"/><br/>
        <input type="submit" value="上传">
    </form>
</div>


</body>
</html>

添加转向到upload页面的ViewController

在文件MyMvcConfig的addViewControllers方法里面增加下面的转向配置，代码如下:

1	复制代码registry.addViewController("/toUpload").setViewName("/upload");

添加完成之后的代码如下所示：

复制代码
@Override
public void addViewControllers(ViewControllerRegistry registry) {
    registry.addViewController("/index").setViewName("/index");
    registry.addViewController("/toUpload").setViewName("/upload");
}

MultipartResolver配置

在文件MyMvcConfig中增加下面的代码，提供对上传文件的支持：

复制代码@Bean
public MultipartResolver multipartResolver() {
    CommonsMultipartResolver multipartResolver = new CommonsMultipartResolver();
    multipartResolver.setMaxUploadSize(1000000);
    return multipartResolver;
}

控制器

复制代码package org.light4j.springMvc4.web;

import java.io.File;
import java.io.IOException;

import org.apache.commons.io.FileUtils;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.multipart.MultipartFile;

@Controller
public class UploadController {

    @RequestMapping(value = "/upload", method = RequestMethod.POST)
    public @ResponseBody
    String upload(MultipartFile file) {// ①

        try {
            FileUtils.writeByteArrayToFile(new File("e:/upload/" + file.getOriginalFilename()),file.getBytes()); // ②
            return "ok";
        } catch (IOException e) {
            e.printStackTrace();
            return "wrong";
        }
    }
}

代码解释：

① 使用MultipartFile file接受上传的文件。
② 使用FileUtils.writeByteArrayToFile快速写文件到磁盘。

运行

访问http://localhost/springMvc4.x-fileUpload/toUpload，效果如下图所示：
xxx
单击”上传”按钮之后，上传文件之后页面显示ok，如下图所示：

查看f:/upload/文件夹下面增加了刚刚上传的文件，如下图所示：
xxx

三. 源代码示例：

github地址：点击查看
码云地址：点击查看

打赏 欢迎关注人生设计师的微信公众账号
公众号ID：longjiazuoA

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有

【Java并发系列】 2Java中的原子操作类

发表于 2017-11-12

系列目录

[Java并发系列] 1.Java并发机制的底层实现
[Java并发系列] 2.Java中的原子操作类

1. 原子操作类的作用

当程序更新一个变量时，如果多个线程同时更新该变量，可能会得到期望以外的值。比如i=1，线程A更新i+1，同时线程B更新I+1,经过两个线程的操作，最终变量i的值可能不是3，而是2。因为线程A、B拿到的i的值都是1，这就是线程不安全的更新操作。我们可以用synchronized来解决这样的问题，synchronized可以保证多线程之间的同步，以保证多个线程不会同时操作变量i。
但是在JDK1.5开始，就提供了java.util.concurrent.atomic包，这个包中的原子操作类提供了更为简单高效、线程安全的方式来更新一个变量的值。

2. 原子操作类基本分类

原子更新基本类型(3个)

AtomicBoolean 原子更新布尔类型
AtomicInteger 原子更新整型
AtomicLong 原子更新长整型

原子更新数组(3个)

AtomicIntegerArray 原子更新整形数组中的元素
AtomicLongArray 原子更新长整型数组中的元素
AtomicReferenceArray 原子更新引用类型数组中的元素

原子更新引用类型(3个)

AtomicReference 原子更新引用类型
AtomicReferenceFieldUpdater 原子更新引用类型中的字段
AtomicMarkableReference 原子更新带有标记位的引用类型

原子更新字段类(3个)

AtomicIntegerFieldUpdater 原子更新整形字段
AtomicLongFieldUpdater 原子更新长整型字段
AtomicStampedReference 原子更新带有版本号的引用类型

3. CAS方式实现原子操作基本原理

JVM中CAS操作主要是利用了处理器提供的CMPXCHG执行实现。基本的思路就是利用循环进行CAS操作，直到成功为止。CAS主要涉及到三个操作数，内存中的值(V)、旧的预期值(A)、需要修改的新值(B)，当且仅当V==A时，才会将V值修改为B值，否则什么都不做，并且通过一个布尔值返回结果。伪代码如下：

复制代码//伪代码
boolean compareAndSwap(V,A,B){
    for(;;){
        if(V==A)
            V=B;//替换旧值
    }
}

4. CAS方式产生的问题(3个)

ABA问题： CAS操作时，检查值有没有变化，如果没有变化则更新，但是如果一个值原来是A，中间变成了B，然后又变为A，CAS进行检查时，就会发现它的值没有变化，但是实际上却已经变化了。解决ABA问题，可以在变量前加一个版本号，变量更新时，版本号就加1.
循环时间长，开销大：CAS采用的是自循的方式进行检查，如果长时间不成功，那么就会给CPU带来非常大的开销。
只能保证一个共享变量的原子操作：当对一个共享变量进行原子操作时，我们可以采用CAS的方式进行更新，但是如果对多个共享变量进行操作时，CAS就无法保证操作的原子性，那么这个时候就需要用锁来实现。

5. 原子操作类中主要的方法

boolean compareAndSet(int expect, int update) ；如果输入的值等于预期值，那么以原子的方式将该值设为输入的值。
int addAndGet(int delta)；以原子的方式将输入的数值与实例中的值相加，并返回更新之后的值
int getAndAdd(int delta); 以原子的方式将输入的数值与实例中的值相加，并返回旧值
int getAndSet(int newValue)；以原子方式设置为newValue的值，并返回旧值

通过阅读源码，可以发现CAS操作都是使用Unsafe类下的方法进行操作，而Unsafe类只提供了三种CAS方法：

compareAndSwapObject(this, valueOffset, expect, update);

compareAndSwapLong(this, valueOffset, expect, update);

compareAndSwapInt(this, valueOffset, expect, update);
所以，对于其他类型的原子操作，都是进行类型转换，将其类型转换为这三种类型，然后进行原子操作。如Boolean型的，先转成整整，然后在使用compareAndSwapInt进行操作；所以像char/float/double/short…等都可以按照这种思路实现。

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有