你的位置:首页 > 软件开发 > ASP.net > 干货|建议初创团队起初也要构建分布式应用

干货|建议初创团队起初也要构建分布式应用

发布时间:2016-04-11 12:00:04
干货|建议初创团队起初也要构建分布式应用  本文内容整理自W-Time技术分享沙龙-天津站现场演讲《一切都是分布的》,演讲者:李傲,问啊联合创始人,前中交车联网总架构。  好多人都会问什么是架构师?其实架构师的定义很宽泛,前端后端的定义都不一样。作为后端出身的架构师,我认为后端并 ...

  干货|建议初创团队起初也要构建分布式应用

  本文内容整理自W-Time技术分享沙龙-天津站现场演讲《一切都是分布的》,演讲者:李傲,问啊联合创始人,前中交车联网总架构

  好多人都会问什么是架构师?其实架构师的定义很宽泛,前端后端的定义都不一样。作为后端出身的架构师,我认为后端并不是大家想的封装组件,它要定义的是规划,规划模块之前的关系。在一台机器搞不定时怎么办?答:集群!这词说着很容易,但真要给你,你发现how?怎么去加?

  有人问我,架构师要做什么?我认为,架构师就是要在软件起初阶段就能够从情景当中预先想到这问题,通过架构分布式解决方案,预先把问题都埋好。可能有人会说这算不算重度设计?其实所谓重度设计,要看团队的基本能力,如果团队写代码还写不利索的情况下,那么这个设计就很重要。因为不能指望一个代码都没有写过几行的人去写架构,这个是不可能的,做分布式都很难。如果团队能力属于中上层,那么有两种可能:1、团队做过十几年的代码,但架构差一些,那么也会把程序写的非常漂亮,因为对代码有把控能力,对底层的研究比较透彻;2、代码写的并不是很好,但是架构师对新技术有了解,那么也是有可能做好分布式的。如果你的团队做不到以上这些,那只有一种方法--用服务器抗。但服务器是一回事,团队能力也不能太差。

  下面就我们“问啊”来说给大家做一下简单的分享,“问啊”是一款订制化IT教育平台,可以一键呼叫大牛解决IT 问题。

  关于分布式存储

  “问啊”利用了一些分布式的概念,也就是分布式存储。我们都知道,每一台服务器资源占用都是有限的,我们用的是云服务器,一般上来都会去买本地磁盘,但无论容量多大,总有一天会用完,当这一天到来的时候,有两种可能:1、在你不知道的时候,服务死了,怎么也起不来。可能会不运行、cpu过高,有人会问,这什么原因导致的?计算量太大了?其实不是,因为一直在做无谓的io操作;2、无从下手,有个公司叫emc的做的磁盘可以解决,可是太贵,300万左右的价格初创公司老板肯定不批,而且性能也不能保证。

  但是分布式存储就把这个事解决了,将要存储的文件预先就散出去,而不是放在一个地方。拿的时候就很快的知道在哪了。举个例子,就像大家都有房子,每个房子都有地址,这个地址都是预先规划好的,就跟分布式存储一样,在规划的时候就解决了未来如果数据膨胀会怎么样的问题。

  关于高速缓存

  接下来再说高速缓存,这也是一个分布式缓存的概念,对存储和缓存来讲,在算法的选择上是不一样的,数据分为两种,维度数据和事实数据。维度数据可以理解为是一种属性,人也是一种维度数据,这个数据是有尽头的。事实数据就是我出门的时候可能会踩死一只蚂蚁,但我不知道我这一路会踩死多少只,这就是事实数据。包括广大的女性同胞养活了淘宝,这也是最好的例子,都是事实数据。

  事实数据存储和维度数据是不一样的,大家一般按时间存储是最多的,这样数据在取得时候有一些优势--可以单独拿一段出来。在数据结构中,拿一段怎么拿?肯定得是连续存储,这样对cpu的消耗则是最小的。那维度数据呢,数据量本身就不大,我们用hash是比较靠谱的。

  对于内存和磁盘的存储来讲,磁盘是一个盘片,我们在寻找一个道的时候,我们会连续去打,这样是最快的。因为不会跳针,跳针速度是最慢的。但内存不是,内存是随机存储,我们在利用存储的时候也会考虑到,如果对于连续存储来讲,内存就一定比磁盘快吗?在我看来,不一定。

  关于任务队列

  我之前做车联网,包括现在的滴滴打车都是一样的,大家之所以能打到车,是车的位置信息已经上传上来了。因为在同一时间内会爆发很多小高峰,导致我存数据的时候很慢,所以我不直接存储,我先存到另一层去。为什么要存到另一层呢?我们存储的目的就是为了要拿出来,简单的说:存的目的就是拿。其实存和拿是一个悖论,好存不好拿,好拿不好存。举一个例子,这么说可能可以直观一些。上大学时,放学回宿舍,书包就扔在地上。为什么?因为懒,扔的速度特别快,但是你可能转天再找就找不到了。问题就出在存储快但是没有索引。想要快速查到怎么办?那就在存的时候分门别类,细致存好。这样拿比较快,存的时候就会费一些时间。如何解决这个悖论?读写分离。存和查的时候一定要做分离。软件有一个理论叫“解偶”,如何解偶?简单来说,a层和b层之间加一个c层就是解偶。只要你发现两层之间有一个很紧密的联系,你就往里面加一个。

  所以,任务队列就是这样,我们先把东西写到队列里,让它慢慢的去消费。也就是说你把数据拿到队列里面来的时候,我就认为你存了。等你取得时候,看你的消费水平,消费水平慢,最多就一个感觉:这个更新好慢,仅此而已。然后下一步就该研究怎么把这个消费做快,你是有这个机会的。但如果你这个事儿不这么做,你就会发现,在你存的时候就已经死了。这样用户的感受可能会有两种,一个是用户并不知道,他只会觉得你们公司的数据比较少;二是我知道,你们已经死了。这样的用户体验度是非常不好的。

  关于高速查询

  这里我要讲一下我们查询的数据结构。对于每种查询来说,数据结构都不太一样。现在有一种比较好的既能查又能存的数据结构叫LSM-TREE,就是hbase一个数据结构,大家有兴趣可以看一下。

  如果你是一个应用,你可能会发现其实没有现成的东西可以用,怎么办?那就用最短的时间研发出来一个轻量级的分布式,像任务下发。这种东西其实比较占资源,当你的服务器数量不够庞大,节点数量也不够庞大的时候,你拿到的结果可能跟你最初的预想不太一样。

  互联网公司都有个比较难受的事儿,就是做运维不敢动机器。我们在做“问啊”的时候也没有完全做到不停机,这个挺难的。有的时候为了尝试试错,我们需要做降级指标,其实有时候比升级指标难的多,会丢数据、丢节点,之后数据还能够均摊,这个是挺难的。我们现在降级指标还没有做到完全不停机,但升级指标已经能够做到了。其实这就是各种负载均衡,通过负载均衡来代替ha,那么这两个概念是什么概念呢?ha,高可用。负载均衡,就是就是你一个人搞不定,四五个人一起上!ha是什么?一个活着,另一个就得死。一般用负载均衡来解决高可用有个问题,就是机器不闲着。一般来讲,做机器空闲的话,总有一台机器是不干活的,这个对于初创公司来说成本比较高,配置选择就是个难题。所以各种ha方案一般就是共用,那个节点可能会分摊好多个节点的共用,但是突然间发现两个小高峰,两个死了这个也就算死了。对于loadbalance本身有个非常大的优势,就是本身来讲,只要有1/2以上活了,这服务也就认为是活的,这个是比较好保证的。但是有一点,做lb算法就一定要做到线上的配额一定要高于你目前的配额,否则你是没法做的。

  下面分享一下我们用过得一些东西:

  Redis

  一个基于内存的存储。最大优势就是单get='_blank'>线程处理的。肯定有人问为什么做单线程,很慢的!但是如果你测过的话就会发现,单线程多任务有时候不一定就比多线程多任务慢,多线程多任务有个空闲的概念,交替的概念,我要去调度。这个就完全省去调度,只要存储速度特别快,能让一个线程别空闲了,远比多线程多任务要快。单线程有一个不可替代的优势:无锁,可以做到一致性。多线程本身来讲只要并发对一个数据操作的时候,你就必须得加锁。你的锁如果设计不合理的话,你这个数据本来可以加到5的,结果才加到2就没了。

  如果用redis完全不用考虑这些事。包括我们做订单号的话,单号取一个数,这是个最普通业务。我们对单号+1就会考虑一个线程去做,如果可以搞定的话,那速度就快了,那我为什么要去做多线程?那么做多线程有一个方法,你可以先把订单号切割,就是预计今年的订单号能有多少,你先把他分好了。然后每一个进程怎么样操作,这样不会出问题。但是订单是跳跃,永远不要用订单号去做排序,这是最不合理的。就像大家都玩过摇红包,其实都是一样的,摇红包为什么能做到这么快。其实不可能快,这个事情不是一个快的动作,有交互就不可能快。只能先把交互的红包预先切好了,存在缓存里。甚至最狠的是用一些空池,就是没奖。结果你的ip正好打到这一核了,hash到这一核里。不换ip拿不出来。

  Redis本身来讲,它的存储速度包括查询速度是可以上到10万级的,是非常快的。但是我们线上测的话。可能也是因为我们用的是云平台的一个服务,它本身是基于codis做的分布式服务。我们没有时间去做自己的分布式redis,所以codis已经成为我们的瓶颈了。它大概的速度也就是1w,对于刚起步的应用来说应该够用,那如何做到更快,只有一个方法:当你对一个事儿做到不能更快了,就三个字解决:分布式。这样就肯定能解决,下一步再去琢磨这一个事该怎么解决,这个就更高深了,有机会我会再详细的为大家讲解。

  Hbase

  有人说Hbase是大数据,其实我觉得很诧异,我认为大数据更偏重于分析。这个东西本身就是一个nosql ,为什么要放到大数据呢?也许因为存的数据多?

  一开始起步的时候是三个节点,这算大数据吗?这算是实验。其实不是,它就是一个数据库,大家不要对它有偏见,认为非要数据到多少的时候我把它迁过来,记住,数据量大的那天,你再想迁就迁不过来了。我的经验告诉我,重构可以做局部模块重构,但绝对不能做大迁移。只要做大迁移:丢数据、版本核对,动态版本核对,特别头疼。

  我最怕跳槽,因为我的位置是救火的。经验告诉我这个最好提前设计好。因为到那天了你难受,有两方都不满意:第一,用户那里,一直在用,你就得天天看着,怎么还有用户用?不知道该用高兴还是该不用高兴;第二,产品经理、运营就会使劲催你问你好了吗?但是提前规划好,就可以避开这些问题。

  Hbase本身来讲呢,既然它能存这么多数据,我们也不想太浪费。有两套出报表的方案,一套是大家熟知的spark,可能用的比较多。对于一个初创团队来讲,spake本身它的worker节点配置有点高,因为它专门吃内存的。还有一种。Tkeyang24:06,替代hadoop,但是它本身没有计算模块,你还是上s,逃不过去。我们的方案呢,作为一个初创团队来讲,对于运营这一块可能有点残忍,但是没有办法,没有这么大的数据量,没有必要。

  那么插入数据方案呢,就两个:

  1、通过集成phoenix序列化方法使用原生Hbase API插入更新数据,数据装载速率并没有降低;

  2、插入数据时采用双保证,缓存和hbase均需要完全插入成功,否则记录日志进入修复队列异步保证数据同步。

  高速缓存

  关于高速缓存,刚刚有说过, redis最好的方案就是hash。这里说两个应用,Redis本身有个pub/sub,做数据队列的,并列时队列比较麻烦的是,如果想用它做一对一队列,你是做不了的,其实一对一有很多队列。但是作为初创团队没必要,那如何来解决这个问题呢?很简单。我们分布式里,分三个redis,我这一个应用先用三个redis,写数据的时候我在三个里面做shard,你这一个应用shard这三个,那这一个应用就可以把这三个归过来我用,如果两个应用怎么办?有两种方法,一种方法从k上,我监控不同的shard的队列,a监控a队列,b监控b队列,每个人都监控三个,没问题,但还有一个问题,redis本身来讲,提供一个key失效的概念,缓存一定会有时效时间,但是缓存失效之后,他所定义的队列的名字是写死的。是跟十六库绑定的,我们可以切16个作为拓展。如果十六不够的话,切两组作为拓展,这样的话就可以无限的扩大。B监听b的零号库。这样可以无限的扩大这样可以通过阔机器,来提升一个人的消费能力。另一方面通过纵深,来分散消费能力。

  关于Redis2.8.22,可能用的比较多。3.0和3.2用的并不多。这有个毛病,TTL只要move一次库,这个TTL就废了,就是失效时间。本来是想用什么巧妙的方法来做黑科技的,结果发现2.8.23解决了,所以大家用的时候从2.8.23以上用。

  我们在任务队列主要做的事是,我们应用有个红包的概念,为了让大家都有学习的机会,能够去问问题,所以我们有个红包。如果用分布式的话,会有很多坑就可以绕过去了。

  Pub/sub,有一个比较恶心的事,当你消费的时候,如果消费函数,你没有消费下一条的时候,pub/sub是不往后挪数据的,所以他会大量的堆积在redis里出不来,这个一定要注意。

  我推荐一个工具,现在有不少公司都在用这个:ES。这个还是比较好用的,但是现在有个问题:随机函数。它里面可以随机抽量数据,在随机抽量数据的时候我们发现两个坑,1、散不开,大部分都一样,随机不太好;2、随机速度特别慢,100w就开始特别慢了。做抽量的话,其实还有很多可以试一下。

  关于我们自主研发的,主要就是以下这几点:1、针对服务节点运行数据决定任务的下发;2、任务之间没有任何牵扯;3、任务死亡可以实时分裂新任务继续执行;4、支持定时消息及红包的应用。

  我发现很多人有个误区,不写代码就真的省事吗?我觉得吧,不写代码满足需求最省事,用现成的有时候还不如自己写,有什么问题也好找。

  关于不停机运维

  Zookeeper这个东西挺好的。我现在注册一些服务,立刻就会建上临时的链接,临时文件。比较坑人的地方就是它的存储是限量的。每个节点存储都一样。一定要注意,存储要省着使用,别写进数据,不要用它做分布式事务所。Zabbix挺好用的,我们运维现在就使用这个。


原标题:干货|建议初创团队起初也要构建分布式应用

关键词:

*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。

可能感兴趣文章

我的浏览记录