交易型系统设计的一些原则
如果应用的设计是无状态的,那么应用比较容易进行水平扩展。实际生产环境是:应用无状态、配置文件有状态。
如果应用的设计是无状态的,那么应用比较容易进行水平扩展。实际生产环境是:应用无状态、配置文件有状态。
技术架构,是将产品需求转变为技术实现的过程。对于所有的架构师而言,能够将产品需求分析透彻是非常基本也是非常重要的一点。很多系统刚建成没多久就要被推翻,最根本的原因还是没有解决好产品真正的需求。我所在的日志服务团队在日志这块有近10年的经验,几乎服务阿里内部所有的团队,涉及电商、支付、物流、云计算、游戏、即时通讯、IoT等领域,多年来的产品功能的优化和迭代都是基于各个团队的日志需求变化。
差不多十年前,随着功能机的淘汰和智能机的普及,互联网开始进入移动互联网时代,最具代表性的产品就是微博、微信,以及后来的今日头条、快手等。这些移动化联网时代的新产品在过去几年间借着智能手机的风高速成长。这些产品都是Feed流类型产品,由于Feed流一般是按照时间“从上往下流动”,非常适合在移动设备端浏览,最终这一类应用就脱颖而出,迅速抢占了上一代产品的市场空间。
架构不是静态的,而是动态演化的。只有能够不断应对环境变化的系统,才是有生命力的系统。所以即使你掌握了以上所有的架构思维,仍然需要演化式思维,在设计的同时,借助反馈和进化的力量推动架构的持续演进。
今天我们就来实现一个合约交易系统的设计与开发。
合约交易,通常指期货合约。现货合约我们以后再讨论。这里我们仍然以数字货币的期货合约为例,实现一个基于BTC/USD价格指数的期货合约。
所谓期货交易,就是指以约定的价格在未来进行交割。
期货交易的目的原本是以当前约定的价格锁定未来某个时间段的价格,这样企业生产就可以合理地锁定采购成本,避免了价格涨跌带来的经营风险。
哔哩哔哩(以下简称B站)的日志采集肩负了B站的所有业务的日志收集并传输,提供离线数据和实时数据以满足离线或实时计算以及业务方订阅的需求。B站日志收集系统是基于Flume设计和搭建而成的。
数据采集是大数据的基石,近几年随着业务的高速增长,产生的数据量越来越大,并且会持续快速增长。因而对采集系统的实时性,稳定性以及可靠性也提出了更高的要求。
本文主要介绍了日志采集系统Lancer的整体架构包括各组件设计及优化。