Feed流系统设计-总纲
差不多十年前,随着功能机的淘汰和智能机的普及,互联网开始进入移动互联网时代,最具代表性的产品就是微博、微信,以及后来的今日头条、快手等。这些移动化联网时代的新产品在过去几年间借着智能手机的风高速成长。这些产品都是Feed流类型产品,由于Feed流一般是按照时间“从上往下流动”,非常适合在移动设备端浏览,最终这一类应用就脱颖而出,迅速抢占了上一代产品的市场空间。
差不多十年前,随着功能机的淘汰和智能机的普及,互联网开始进入移动互联网时代,最具代表性的产品就是微博、微信,以及后来的今日头条、快手等。这些移动化联网时代的新产品在过去几年间借着智能手机的风高速成长。这些产品都是Feed流类型产品,由于Feed流一般是按照时间“从上往下流动”,非常适合在移动设备端浏览,最终这一类应用就脱颖而出,迅速抢占了上一代产品的市场空间。
技术架构,是将产品需求转变为技术实现的过程。对于所有的架构师而言,能够将产品需求分析透彻是非常基本也是非常重要的一点。很多系统刚建成没多久就要被推翻,最根本的原因还是没有解决好产品真正的需求。我所在的日志服务团队在日志这块有近10年的经验,几乎服务阿里内部所有的团队,涉及电商、支付、物流、云计算、游戏、即时通讯、IoT等领域,多年来的产品功能的优化和迭代都是基于各个团队的日志需求变化。
关于Feed流的架构设计,包括以上场景中的很多业内专家给出了相应的思考、设计和实践。本人是大数据方向出身的技术人,所在的团队参与了阿里手淘、微淘Feed流的存储层相关服务,我们的HBase/Lindorm数据存储产品在公有云上也支持着Soul、趣头条、惠头条等一些受欢迎的新媒体、社交类产品。我们在数据存储产品的功能、性能、可用性上的一些理解,希望对真实落地一个Feed流架构可以有一些帮助,以及一起探讨Feed流的未来以及数据产品如何帮助Feed流进一步迭代。
架构不是静态的,而是动态演化的。只有能够不断应对环境变化的系统,才是有生命力的系统。所以即使你掌握了以上所有的架构思维,仍然需要演化式思维,在设计的同时,借助反馈和进化的力量推动架构的持续演进。
今天我们就来实现一个合约交易系统的设计与开发。
合约交易,通常指期货合约。现货合约我们以后再讨论。这里我们仍然以数字货币的期货合约为例,实现一个基于BTC/USD价格指数的期货合约。
所谓期货交易,就是指以约定的价格在未来进行交割。
期货交易的目的原本是以当前约定的价格锁定未来某个时间段的价格,这样企业生产就可以合理地锁定采购成本,避免了价格涨跌带来的经营风险。
如果应用的设计是无状态的,那么应用比较容易进行水平扩展。实际生产环境是:应用无状态、配置文件有状态。
哔哩哔哩(以下简称B站)的日志采集肩负了B站的所有业务的日志收集并传输,提供离线数据和实时数据以满足离线或实时计算以及业务方订阅的需求。B站日志收集系统是基于Flume设计和搭建而成的。
数据采集是大数据的基石,近几年随着业务的高速增长,产生的数据量越来越大,并且会持续快速增长。因而对采集系统的实时性,稳定性以及可靠性也提出了更高的要求。
本文主要介绍了日志采集系统Lancer的整体架构包括各组件设计及优化。
博主16年认识Sping Boot,17年才开始学习。自己学习的时候也查阅了很多资料,也看到很多优秀的博客,但是整体上感觉没有我想象中的那么强大,一是版本有点旧了,大多是1.4版本的,博主自己看的时候已经1.5了。二是网上资料太多,质量参差不齐。每次查资料都要在海量资源中去挑选自己想要的好累啊。所以打算自己总结下,希望后面学习的小伙伴可以不用查看那么多的资料,因为博主所写的每一篇都是查阅了大量的资料和电子书后才整理出来的。所以相信在时间战争上,博主能帮你省下一些投入的学习时间。