966,690 八月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
语言 & 开发 在InfoQ上的内容
关于云技术混合架构的三个认识误区
Stephen Orban
技术决策有时候确实是个难题，而且作出的选择往往不够完美。但创建一套混合架构却用不着这样瞻前顾后。
作为一名Java程序员，我为什么不在生产项目中转向Go
Go语言近几年在国内一直呈现蓬勃发展的趋势，不仅有活跃的社区，各种公司也纷纷试水使用Go做一些开发。但是，感兴趣学习Go是一回事，在生产中运用Go又是另一回事，本文将从一名Java程序员的角度，来探讨一下是不是应该在生产中由Java转向Go。
梁胜：用户是Docker最大的筹码
Rancher Labs是由梁胜（CloudStack创始人）创立的一家提供容器服务的云计算公司，产品包括RancherOS和Rancher。近日，Rancher Labs和东网科技宣布在国内成立合资子公司，全面开展Rancher在华的业务。InfoQ记者采访了Rancher CEO梁胜，与他探讨了容器、OpenStack、CloudStack等技术的发展和变革。本文根据采访整理而成。
LinkedIn是如何优化Kafka的
在LinkedIn的数据基础设施中，Kafka是核心支柱之一。现在，LinkedIn每天利用Kafka处理的消息超过1万亿条，在峰值时每秒钟会发布超过450万条消息。近日，来自LinkedIn的高级工程主管Kartik Paramasivam撰文分享了他们使用和优化Kafka的经验。
Docker在蚂蚁金融云平台中的探索与实践
为了进一步了解蚂蚁金融云的整个体系架构，InfoQ采访了蚂蚁金服基础技术部系统组leader吴峥涛。
深入浅出ES6（十）：集合
Jason Orendorff
ECMAScript 6已经正式发布了，作为它最重要的方言，Javascript也即将迎来语法上的重大变革，InfoQ特开设“深入浅出ES6”专栏，来看一下ES6将给我们带来哪些新内容。本专栏文章来自Mozilla Web开发者博客，由作者授权翻译并发布。
元数据驱动设计 —— 为动态移动应用创建Web API
Aaron Kendall
在本文中，Aaron Kendall将详细讨论如何使用这种设计方法，并且通过实现一个元数据驱动的移动应用，将这一设计方法与RESTful服务或HATEOAS等现有技术的异同之处进行了比较。
假如不是BAT，专项测试要怎样做？
BAT对测试本身的投入力度，在行业内是走在前面的。那BAT之外的公司，应该如何做专项测试呢？本文作者黄闻欣最近接触了一些腾讯系公司，了解了他们的测试现状，觉得需要有所总结，希望能给出一些真正帮助到测试行业内的其他团队的意见。
Apache Calcite：Hadoop中新型大数据查询引擎
Apache Calcite是面向Hadoop新的查询引擎，它提供了标准的SQL语言、多种查询优化和连接各种数据源的能力，除此之外，Calcite还提供了OLAP和流处理的查询引擎。正是有了这些诸多特性，Calcite项目在Hadoop中越来越引入注目，并被众多项目集成。
深入浅出React（四）：虚拟DOM Diff算法解析
React中最神奇的部分莫过于虚拟DOM，以及其高效的Diff算法。这让我们可以无需担心性能问题而”毫无顾忌”的随时“刷新”整个页面，由虚拟DOM来确保只对界面上真正变化的部分进行实际的DOM操作。理解其运行机制不仅有助于更好的理解React组件的生命周期，而且对于进一步优化React程序也会有很大帮助。
DevOps与持续交付实践
Ben Linders
Danilo Sato的新作《实战DevOps：可靠的自动化软件交付》以一种动手实验的风格帮助读者了解如何实现持续交付与DevOps实践。
& 加载更新的 文章
加载更多 文章 &
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?LinkedIn的Kafka：我是如何做到1秒发布450万+条消息！_用户_新浪博客
LinkedIn的Kafka：我是如何做到1秒发布450万+条消息！
“微软和LinkedIn（领英）周一宣布已经签订了最终收购协议，微软将以每股196美元全现金收购该公司，交易价值达到262亿美元，较后者上周五收盘价溢价近50%。作为一家数据公司，它是怎么使用和优化Kafka的？文末有福利下载哟！
在LinkedIn的数据基础设施中，Kafka是核心支柱之一。现在，LinkedIn每天利用Kafka处理的消息超过1万亿条，在峰值时每秒钟会发布超过450万条消息。LinkedIn的高级工程主管KartikParamasivam撰文分享了他们使用和优化Kafka的经验。
LinkedIn在2011年7月开始大规模使用Kafka，当时Kafka每天大约处理10亿条消息，这一数据在2012年达到了每天200亿条，而到了2013年7月，每天处理的消息达到了2000亿条。在几个月前，他们的最新记录是每天利用Kafka处理的消息超过1万亿条，在峰值时每秒钟会发布超过450万条消息，每周处理的信息是1.34PB。每条消息平均会被4个应用处理。在过去的四年中，实现了1200倍的增长。
随着规模的不断扩大，LinkedIn更加关注于Kafka的可靠性、成本、安全性、可用性以及其他的基础指标。在这个过程中，LinkedIn的技术团队在多个特性和领域都进行了有意义的探索。
Linkedln在Kafka上的主要关注领域
配额（Quotas）
在LinkedIn，不同的应用使用同一个Kafka集群，所以如果某个应用滥用Kafka的话，将会对共享集群的其他应用带来性能和SLA上的负面影响。有些合理的使用场景有可能也会带来很坏的影响，比如如果要重新处理整个数据库的所有数据的话，那数据库中的所有记录会迅速推送到Kafka上，即便Kafka性能很高，也会很容易地造成网络饱和和磁盘冲击。
KartikParamasivam绘图展现了不同的应用是如何共享KafkaBroker的：
为了解决这个问题，LinkedIn的团队研发了一项特性，如果每秒钟的字节数超过了一个阈值，就会降低这些Producer和Customer的速度。对于大多数的应用来讲，这个默认的阈值都是可行的。但是有些用户会要求更高的带宽，于是他们引入了白名单机制，白名单中的用户能够使用更高数量的带宽。这种配置的变化不会对KafkaBroker的稳定性产生影响。这项特性运行良好，在下一版本的Kafka发布版中，所有的人就都能使用该特性了。
开发新的Customer
目前的KafkaCustomer客户端依赖于ZooKeeper，这种依赖会产生一些大家所熟知的问题，包括ZooKeeper的使用缺乏安全性以及Customer实例之间可能会出现的脑裂现象（splitbrain）。因此，LinkedIn与Confluent以及其他的开源社区合作开发了一个新的Customer。这个新的Customer只依赖于KafkaBroker，不再依赖于ZooKeeper。这是一项很复杂的特性，因此需要很长的时间才能完全应用于生产环境中。
在Kafka中，目前有两个不同类型的Customer。如果Customer希望完全控制使用哪个分区上的Topic的话，就要使用低级别的Customer。在高级别的Customer中，Kafka客户端会自动计算如何在Customer实例之间分配Topic分区。这里的问题在于，如果使用低级别Customer的话，会有许多的基本任务要去完成，比如错误处理、重试等等，并且无法使用高级别Customer中的一些特性。在LinkedIn这个新的Customer中，对低级别和高级别的Customer进行了调和。
可靠性和可用性的提升
按照LinkedIn这样的规模，如果Kafka的新版本中有什么重要缺陷的话，就会对可靠性产生很大的影响。因此，LinkedIn技术团队一项很重要的任务就是发现和修正缺陷。他们在可靠性方面所做的增强包括：
MirrorMaker无损的数据传输：MirrorMaker是Kafka的一个组件，用来实现Kafka集群和KafkaTopic之间的数据转移。LinkedIn广泛使用了这项技术，但是它在设计的时候存在一个缺陷，在传输时可能会丢失数据，尤其是在集群升级或机器重启的时候。为了保证所有的消息都能正常传输，他们修改了设计，能够确保只有消息成功到达目标Topic时，才会认为已经完全消费掉了。
副本的延迟监控：所有发布到Kafka上的消息都会复制副本，以提高持久性。当副本无法“跟上”主版本（master）的话，就认为这个副本处于非健康的状态。在这里，“跟上”的标准指的是配置好的字节数延迟。这里的问题在于，如果发送内容很大的消息或消息数量不断增长的话，那么延迟可能会增加，那么系统就会认为副本是非健康的。为了解决这个问题，LinkedIn将副本延迟的规则修改为基于时间进行判断。
实现新的Producer：LinkedIn为Kafka实现了新的Producer，这个新的Producer允许将消息实现为管道（pipeline），以提升性能。目前该功能尚有部分缺陷，正在处于修复之中。
删除Topic：作为如此成熟的产品，Kafka在删除Topic的时候，会出现难以预料的后果或集群不稳定性，这一点颇令人惊讶。在几个月前，LinkedIn对其进行了广泛地测试并修改了很多缺陷。到Kafka的下一个主版本时，就能安全地删除Topic了。
在Kafka中，这是参与者最多的特性之一，众多的公司互相协作来解决这一问题。其成果就是加密、认证和权限等功能将会添加到Kafka中，在LinkedIn，预期在2015年能使用加密功能，在2016年能使用其他的安全特性。
Kafka监控框架
LinkedIn最近正在致力于以一种标准的方式监控Kafka集群，他们的想法是运行一组测试应用，这些应用会发布和消费KafkaTopic数据，从而验证基本的功能（顺序、保证送达和数据完整性等）以及端到端发布和消费消息的延时。除此之外，这个框架还可以验证Kafka新版本是否可以用于生产环境，能够确保新版本的KafkaBroker不会破坏已有的客户端。
当拿到新的Kafka开源版本后，LinkedIn会运行一些故障测试，从而验证发生失败时Kafka新版本的质量。针对这项任务，LinkedIn研发了名为Simoorg的故障引导框架，它会产生一些低级别的机器故障，如磁盘写失败、关机、杀进程等等。
应用延迟监控
LinkedIn开发了名为Burrow的工具，能够监控Customer消费消息的延迟，从而监控应用的健康状况。
保持Kafka集群平衡
LinkedIn在如下几个维度保证了集群的平衡：
感知机柜：在进行平衡时，很重要的一点是Kafka分区的主版本与副本不要放到同一个数据中心机柜上。如果不这样做的话，一旦出现机柜故障，将会导致所有的分区不可用。
确保Topic的分区公平地分发到Broker上：在为Kafka发布和消费消息确定了配额后，这项功能变得尤为重要。相对于将Topic的分区发布到同一个Broker节点上，如果Topic的分区能够均衡地分发到多个Broker上，那么相当的它有了更多的带宽。
确保集群节点的磁盘和网络容量不会被耗尽：如果几个Topic的大量分区集中到了集群上的少数几个节点上，那么很容易出现磁盘或网络容量耗尽的情况。
在LinkedIn，目前维护站点可靠性的工程师（SiteReliabilityEnginee，SRE）通过定期转移分区确保集群的平衡。在分区放置和重平衡方面，他们已经做了一些原始设计和原型实现，希望能够让系统更加智能。
在其他的数据系统中，将Kafka作为核心的组成部分
在LinkedIn，使用Espresso作为NoSQL数据库，目前他们正在将Kafka作为Espresso的备份机制。这将Kafka放到了站点延迟敏感数据路径的关键部分，同时还需要保证更高的消息传送可靠性。目前，他们做了很多的性能优化，保证消息传输的低延迟，并且不会影响消息传递的可靠性。
Kafka还会用于异步上传数据到Venice之中。除此之外，Kafka是ApacheSamza实时流处理的一个重要事件源，同时Samza还使用Kafka作为持久化存储，保存应用的状态。在这个过程中，LinkedIn修改了一些重要的缺陷，并增强了Kafka的日志压缩特性。
LinkedIn的Kafka生态系统
除了ApacheKafkaBroker、客户端以及MirrorMaker组件之外，LinkedIn还有一些内部服务，实现通用的消息功能：
支持非Java客户端：在LinkedIn，会有一些非Java应用会用到Kafka的REST接，去年他们重新设计了Kafka的REST服务，因为原始的设计中并不能保证消息的送达。
消息的模式：在LinkedIn，有一个成熟的“模式（schema）注册服务”，当应用发送消息到Kafka中的时候，LinkedInKafka客户端会根据消息注册一个模式（如果还没有注册过的话）。这个模式将会自动在Customer端用于消息的反序列化。
成本计算：为了统计各个应用对Kafka的使用成本，LinkedIn使用了一个Kafka审计Topic。LinkedIn客户端会自动将使用情况发送到这个Topic上，供Kafka审计服务读取并记录使用情况，便于后续的分析。
审计系统：LinkedIn的离线报告job会反映每小时和每天的事件情况，而事件从源KafkaTopic/集群/数据中心，到最后的HDFS存储是需要时间的。因此，Hadoopjob需要有一种机制，保证某个时间窗能够获得所有的事件。LinkedInKafka客户端会生成它们所发布和消费的消息数量。审计服务会记录这个信息，Hadoop以及其他的服务可以通过REST接获取这一信息。
支持内容较大的消息：在LinkedIn，将消息的大小限定为1MB，但是有些场景下，无法满足这一限制。如果消息的发布方和使用方是同一个应用的话，一般会将消息拆分为片段来处理。对于其他的应用，建议消息不要超过1MB。如果实在无法满足该规则的话，消息的发送和消费方就需要使用一些通用的API来分割和组装消息片段，而在LinkedIn的客户端SDK中，他们实现了一种特性，能够自动将一条大的信息进行分割和重组。
目前，越来越多的国内外公司在使用Kafka，如Yahoo!、Twitter、Netflix和Uber等，所涉及的功能从数据分析到流处理不一而足，希望LinkedIn的经验也能够给其他公司一些借鉴。
LinkedIn很早以前就把自己定位成一家数据公司，并创造了数据驱动的公司文化。在过去的几年中，现任LinkedIn资深经理李海鹏带领的团队不断探索数据中的价值，通过创造数据产品来产生商业影响。这些数据产品对LinkedIn营收的高速增长产生了重要的贡献。仅在2015年一年，LinkedIn就在其营收中高达10亿美金的部分，大量地使用了这些数据产品。
在QCon2016北京站上，他分享了LinkedIn如何从数据中挖掘价值的一些案例。同时也探讨，LinkedIn是如何把商业、数据和开发相结合，通过数据产品的形式来驱动商业价值的。
后台回复关键词【领英】，获取演讲视频及PPT下载链接！
延展阅读（点击标题）：
万亿级调用系统：微信序列号生成器架构设计及演变
分布式系统事务一致性解决方案大对比，谁最好使？
从PHP到Node，聊一聊淘宝首页背后的技术
6月16日（周四）晚8：30，大咖说不见不散，戳阅读原文了解更多！
原始网络：
LinkedIn的Kafka：我是如何做到1秒发布450万+条消息！
博客等级：
博客积分：0
博客访问：458
关注人气：0
荣誉徽章：如何做到1秒发布450万+条消息_百度知道在LinkedIn的数据基础设施中，Kafka是核心支柱之一。现在，LinkedIn每天利用Kafka处理的消息超过1万亿条，在峰值时每秒钟会发布超过450万条消息。近日，来自LinkedIn的高级工程主管Kartik Paramasivam撰文分享了他们使用和优化Kafka的经验。LinkedIn在2011年7月开始大规模使用Kafka，当时Kafka每天大约处理10亿条消息，这一数据在2012年达到了每天200亿条，而到了2013年7月，每天处理的消息达到了2000亿条。在几个月前，他们的最新记录是每天利用Kafka处理的消息超过1万亿条，在峰值时每秒钟会发布超过450万条消息，每周处理的信息是1.34 PB。每条消息平均会被4个应用处理。在过去的四年中，实现了1200倍的增长。随着规模的不断扩大，LinkedIn更加关注于Kafka的可靠性、成本、安全性、可用性以及其他的基础指标。在这个过程中，LinkedIn的技术团队在多个特性和领域都进行了有意义的探索。Linkedln在Kafka上的主要关注领域配额（Quotas）在LinkedIn，不同的应用使用同一个Kafka集群，所以如果某个应用滥用Kafka的话，将会对共享集群的其他应用带来性能和SLA上的负面影响。有些合理的使用场景有可能也会带来很坏的影响，比如如果要重新处理整个数据库的所有数据的话，那数据库中的所有记录会迅速推送到Kafka上，即便Kafka性能很高，也会很容易地造成网络饱和和磁盘冲击。Kartik Paramasivam绘图展现了不同的应用是如何共享Kafka Broker的：为了解决这个问题，LinkedIn的团队研发了一项特性，如果每秒钟的字节数超过了一个阈值，就会降低这些Producer和Customer的速度。对于大多数的应用来讲，这个默认的阈值都是可行的。但是有些用户会要求更高的带宽，于是他们引入了白名单机制，白名单中的用户能够使用更高数量的带宽。这种配置的变化不会对Kafka Broker的稳定性产生影响。这项特性运行良好，在下一版本的Kafka发布版中，所有的人就都能使用该特性了。开发新的Customer目前的Kafka Customer客户端依赖于ZooKeeper，这种依赖会产生一些大家所熟知的问题，包括ZooKeeper的使用缺乏安全性以及Customer实例之间可能会出现的脑裂现象（split brain）。因此，LinkedIn与Confluent以及其他的开源社区合作开发了一个新的Customer。这个新的Customer只依赖于Kafka Broker，不再依赖于ZooKeeper。这是一项很复杂的特性，因此需要很长的时间才能完全应用于生产环境中。在Kafka中，目前有两个不同类型的Customer。如果Customer希望完全控制使用哪个分区上的Topic的话，就要使用低级别的Customer。在高级别的Customer中，Kafka客户端会自动计算如何在Customer实例之间分配Topic分区。这里的问题在于，如果使用低级别Customer的话，会有许多的基本任务要去完成，比如错误处理、重试等等，并且无法使用高级别Customer中的一些特性。在LinkedIn这个新的Customer中，对低级别和高级别的Customer进行了调和。可靠性和可用性的提升按照LinkedIn这样的规模，如果Kafka的新版本中有什么重要缺陷的话，就会对可靠性产生很大的影响。因此，LinkedIn技术团队一项很重要的任务就是发现和修正缺陷。他们在可靠性方面所做的增强包括：Mirror Maker无损的数据传输：Mirror Maker是Kafka的一个组件，用来实现Kafka集群和Kafka Topic之间的数据转移。LinkedIn广泛使用了这项技术，但是它在设计的时候存在一个缺陷，在传输时可能会丢失数据，尤其是在集群升级或机器重启的时候。为了保证所有的消息都能正常传输，他们修改了设计，能够确保只有消息成功到达目标Topic时，才会认为已经完全消费掉了。副本的延迟监控：所有发布到Kafka上的消息都会复制副本，以提高持久性。当副本无法“跟上”主版本（master）的话，就认为这个副本处于非健康的状态。在这里，“跟上”的标准指的是配置好的字节数延迟。这里的问题在于，如果发送内容很大的消息或消息数量不断增长的话，那么延迟可能会增加，那么系统就会认为副本是非健康的。为了解决这个问题，LinkedIn将副本延迟的规则修改为基于时间进行判断。实现新的Producer：LinkedIn为Kafka实现了新的Producer，这个新的Producer允许将消息实现为管道（pipeline），以提升性能。目前该功能尚有部分缺陷，正在处于修复之中。删除Topic：作为如此成熟的产品，Kafka在删除Topic的时候，会出现难以预料的后果或集群不稳定性，这一点颇令人惊讶。在几个月前，LinkedIn对其进行了广泛地测试并修改了很多缺陷。到Kafka的下一个主版本时，就能安全地删除Topic了。安全性在Kafka中，这是参与者最多的特性之一，众多的公司互相协作来解决这一问题。其成果就是加密、认证和权限等功能将会添加到Kafka中，在LinkedIn，预期在2015年能使用加密功能，在2016年能使用其他的安全特性。Kafka监控框架LinkedIn最近正在致力于以一种标准的方式监控Kafka集群，他们的想法是运行一组测试应用，这些应用会发布和消费Kafka Topic数据，从而验证基本的功能（顺序、保证送达和数据完整性等）以及端到端发布和消费消息的延时。除此之外，这个框架还可以验证Kafka新版本是否可以用于生产环境，能够确保新版本的Kafka Broker不会破坏已有的客户端。故障测试当拿到新的Kafka开源版本后，LinkedIn会运行一些故障测试，从而验证发生失败时Kafka新版本的质量。针对这项任务，LinkedIn研发了名为Simoorg的故障引导框架，它会产生一些低级别的机器故障，如磁盘写失败、关机、杀进程等等。应用延迟监控LinkedIn开发了名为Burrow的工具，能够监控Customer消费消息的延迟，从而监控应用的健康状况。保持Kafka集群平衡LinkedIn在如下几个维度保证了集群的平衡：感知机柜：在进行平衡时，很重要的一点是Kafka分区的主版本与副本不要放到同一个数据中心机柜上。如果不这样做的话，一旦出现机柜故障，将会导致所有的分区不可用。确保Topic的分区公平地分发到Broker上：在为Kafka发布和消费消息确定了配额后，这项功能变得尤为重要。相对于将Topic的分区发布到同一个Broker节点上，如果Topic的分区能够均衡地分发到多个Broker上，那么相当的它有了更多的带宽。确保集群节点的磁盘和网络容量不会被耗尽：如果几个Topic的大量分区集中到了集群上的少数几个节点上，那么很容易出现磁盘或网络容量耗尽的情况。在LinkedIn，目前维护站点可靠性的工程师（Site Reliability Enginee，SRE）通过定期转移分区确保集群的平衡。在分区放置和重平衡方面，他们已经做了一些原始设计和原型实现，希望能够让系统更加智能。在其他的数据系统中，将Kafka作为核心的组成部分在LinkedIn，使用Espresso作为NoSQL数据库，目前他们正在将Kafka作为Espresso的备份机制。这将Kafka放到了站点延迟敏感数据路径的关键部分，同时还需要保证更高的消息传送可靠性。目前，他们做了很多的性能优化，保证消息传输的低延迟，并且不会影响消息传递的可靠性。Kafka还会用于异步上传数据到Venice之中。除此之外，Kafka是Apache Samza实时流处理的一个重要事件源，同时Samza还使用Kafka作为持久化存储，保存应用的状态。在这个过程中，LinkedIn修改了一些重要的缺陷，并增强了Kafka的日志压缩特性。LinkedIn的Kafka生态系统除了Apache Kafka Broker、客户端以及Mirror Maker组件之外，LinkedIn还有一些内部服务，实现通用的消息功能：支持非Java客户端：在LinkedIn，会有一些非Java应用会用到Kafka的REST接口，去年他们重新设计了Kafka的REST服务，因为原始的设计中并不能保证消息的送达。消息的模式：在LinkedIn，有一个成熟的“模式（schema）注册服务”，当应用发送消息到Kafka中的时候，LinkedIn Kafka客户端会根据消息注册一个模式（如果还没有注册过的话）。这个模式将会自动在Customer端用于消息的反序列化。成本计算：为了统计各个应用对Kafka的使用成本，LinkedIn使用了一个Kafka审计Topic。LinkedIn客户端会自动将使用情况发送到这个Topic上，供Kafka审计服务读取并记录使用情况，便于后续的分析。审计系统：LinkedIn的离线报告job会反映每小时和每天的事件情况，而事件从源Kafka Topic/集群/数据中心，到最后的HDFS存储是需要时间的。因此，Hadoop job需要有一种机制，保证某个时间窗口能够获得所有的事件。LinkedIn Kafka客户端会生成它们所发布和消费的消息数量。审计服务会记录这个信息，Hadoop以及其他的服务可以通过REST接口获取这一信息。支持内容较大的消息：在LinkedIn，将消息的大小限定为1MB，但是有些场景下，无法满足这一限制。如果消息的发布方和使用方是同一个应用的话，一般会将消息拆分为片段来处理。对于其他的应用，建议消息不要超过1MB。如果实在无法满足该规则的话，消息的发送和消费方就需要使用一些通用的API来分割和组装消息片段，而在LinkedIn的客户端SDK中，他们实现了一种特性，能够自动将一条大的信息进行分割和重组。目前，越来越多的国内外公司在使用Kafka，如Yahoo!、Twitter、Netflix和Uber等，所涉及的功能从数据分析到流处理不一而足，希望LinkedIn的经验也能够给其他公司一些借鉴。文章推荐Study一直以来，关注InfoQ的小伙伴们都在问我们，“能不能多推荐些移动开发的内容”？“可不可以多分享些前端的东西？”等等等等……小Q眼观屏幕，手操键盘，惭愧汗颜，憾不知如何回复。小Q一直有个愿望，就是整理出一套完整的内容架构，把更丰富更全面，更深入浅出由表及里的技术知识推送给真正有需求的人，不止有料，还要有趣，更要把学习变成一件好玩儿的事儿。一直未果。直到有一天，我们一个同事拿出了一张知识图谱，涵盖了Web前端，智能硬件，开发语言多个领域，从基础入门到实战案例都囊括了，嗯，是小Q一直以来想为大家呈现的，有体系，有内容，有目的的学习更好地循序渐进。其实，这不就是每个想在技术领域里有所积累和突破的技术人，都得走的学习与精进之路吗？这位同事来自InfoQ的分享在线教育平台StuQ。图谱内容分类很多，列表很长。我问他，你是怎么耐下性子整理这么多这么详细的。他说，做的时候很痛苦，完成的时候很快乐，当我意识到这件事能给很多人带来价值的时候，我就实现了做这件事的意义。InfoQ(infoqchina)　
　文章为作者独立观点，不代表微头条立场
的最新文章
本周四晚八点半，大咖说直播等你来！这样很难，因为这意味着你要受委屈，你要放下，你要接受很多挑战，最重要的是，你要坚持。“云原生机制下的微服务”技术沙龙会议上，来美国硅谷的Pivotal 的Spring技术专家Josh Long进行了题为“云原生Java”主的分享，InfoQ对Josh进行了采访，探讨了企业如何落地微服务和Spring的相关工具等问题。对于初创公司来说，软件开发的要点有哪些？程序员的重要性到底有多大？外包、内包能够包治百病吗？热修复是很多开发者关心的技术，8月27日晚，阿里百川组织了“百川解码”在线直播，以“热修复的坑和阿里的解”为主题，邀请了三位业界嘉宾对热修复技术进行了探讨，并介绍了阿里百川全面接受公测的热修复解决方案：阿里百川HotFix。今晚八点半，直播等你来！8月29日，冯大辉先生在2016 GTLC全球技术领导力峰会上发表了题为《浅谈如何抓住技术浪潮变革的红利》的演讲，这也是他作为CTO的最后一次演讲。本文根据其演讲整理而成。InfoQ就平安金融云的CaaS服务技术选型，对云平台事业部总经理方国伟进行了采访。此外，方国伟将在CNUTCon全球容器技术大会上分享题为《平安金融云之CaaS服务建设和应用》的演讲。在大数据的时代，大家都在重视数据存储和一系列大数据相关技术，但是很多人忽略了数据是需要管理的，没有经过管理的数据，只能叫数据，而不能成为信息，无法真正体现出其内在价值。奥运会、王宝强、傅园慧、孙杨PK霍顿，面对这股洪荒合力，新浪微博这样用技术支撑起瞬时高压的业务。被逼出来的创新往往不够让人惊喜，所以好的创新更多的要靠自发。本文根据张海龙在中国技术开放日苏州站走进同程的演讲内容整理而成。程序员如何实现经济、精神双自由？独立开发者带你玩转跨界今日直播！超过500位CTO的大会直播，看技术人如何展现领导力！一句话怎么说得清楚……本文根据石佳宁在InfoQ举办的2016ArchSummit全球架构师（深圳）峰会上的演讲整理而成。StuQ联合美团 iOS 技术专家臧成威，共同出品 《ReactiveCocoa 编程思想与开发实战》精品小班课第二期！工欲善其事，必先利其器。小Q倾情推荐，这10个工具一定能帮助你的远程合作事半功倍！大部分的软件工作者都对Redis、RabbitMQ、Greenplum、Spring等开源项目有所了解，其实实施DevOps的核心目标是加速团队、企业的IT精益运行，从根本上提升IT的生产效率，加速部门、企业的业务创上下班路上，北京瘫的沙发上，就看看这8个号的文章吧~不同的环境，对技术领导力有着怎样不一样的要求？CTO如何才能更好的跟CEO沟通呢？技术领导力就将包含哪些要素？大咖说是InfoQ推出的视频直播节目，每周四晚八点半和您见面！回复：陈天，获得直播完整版视频。回复：Info2011年，极光成立，并推出了核心产品极光推送JPush。经过5年不断的努力，持续的专业服务，极光推送已经服使用Docker可实现对环境和资源的隔离，但是与此同时也需要一套容器集群管理系统对分散的容器进行整体性的应用今晚八点半，大咖说直播等你来！金秋十月，QCon上海2016将如期而至。每次QCon，我们都会尽力邀请最好的专家，挖掘最新的技术干货。这次本文来自EGO技术管理公开课上，才云科技创始人兼CEO张鑫的线上分享。8月6号，阿里巴巴在西雅图举办技术论坛，经过4个月的思考，张建锋选择这个场合，首次围绕数据、计算和算法三个核心，系统阐述了阿里的技术布局。RxSwift 出现后，响应式编程下的 iOS 开发有了多种选择，RxSwift 可能是更优雅的方案。更多的人感觉这是个和 MVVM 都很“高大上”的东西，事实上这只是个思维方式的改变。本课程将结合实践让大家可以在项目中真正开心的用起来。回复：陈天，获得直播完整版视频。回复：InfoQ，加入大咖说直播交流群。本视频时长1小时45分，建议在Wif在数据爆炸的时代，机器学习是有效挖掘信息的途径，怎样顺势而为设计与搭建大规模机器学习平台？本文整理自Twitter机器学习平台组负责人郭晓江在ArchSummit深圳2016的演讲。过去十年云计算的发展，在IT领域为共享经济提供了新的机遇；而过去五年移动互联网的兴起，更是在诸多方面给原有的直播这么火，那么，其背后，有哪些具体的技术支撑呢？成立四年，估值已超260亿美元，公司指数级发展、业务爆炸式增长，在此背景下，滴滴出行业务系统的架构升级是怎样进行的？（文中有惊喜：课程专属优惠码先用先得）Scala 是一种全新设计的通用的面向对象和函数式编程语言其设计目标是今晚八点半，大咖说直播等你来！一个优秀的CTO需要具备哪些素质？CTO如何跟CEO沟通？如何平衡业务迭代与团队技术积累的关系？从每秒400单交易量到每秒1万单，25倍的增长背后，是怎样的优化与实践？这其中的障碍，蘑菇街技术团队如何跨越应对？这是一个关于创新的故事885年夏天，凉爽的德国曼海姆，一名年轻女子正在试驾他丈夫研制的0.9匹马力的三轮汽车“异地多活”的方案价值非常大，尤其是互联网行业，规模稍微大一点几乎都必须是标配；但同时大家都觉得“异地多活”的方案设计又很难，网络、数据、事务等各种问题混杂在一起，很多问题看似是无法解决的。但其实只要避开这几大思维误区，异地多活也没那么难。1997年首都在线开始经营拨号上网业务，19年的时间这家公司已逐渐从ISP服务商、IDC托管服务商，成功转型Growth不仅在硅谷大热，在国内也是一个十分火爆的概念。Growth到底讲的是什么？它在移动领域又有何用处？更多关于「云计算太祖长拳」系列之“可用区技术”文章，请关注「细说云计算」（ID：CloudNote）并回复““ 怎么才能成为一个合格的技术领导者呢？为了找到答案，EGO特意拜访了普元董事长兼CEO刘亚东，他在IT企业新框架层出不穷，每一个框架都得评估数不清的问题。那么选择Angular 2的理由是？这是一期真正有酒、有肉、有妹子的互联网直播！全球首届APMCon，带你给“应用性能”把把脉！经历了近10年的发展，前端从刀耕火种到百花齐放，繁荣下孕育着一些趋势和变革。立足当下，如何看前后端分离？如何看全栈？面向未来，前端工程师的未来是怎样的？LinkedIn的高级工程主管Kartik Paramasivam 分享LinkedIn使用及优化Kafka经验。infoqchina关注中高端技术人员的社区媒体，促进软件开发领域知识与创新的传播热门文章最新文章infoqchina关注中高端技术人员的社区媒体，促进软件开发领域知识与创新的传播