HTML5技术

架构师之路--谈业务的合理架构 - 静儿1986

字号+ 作者:H5之家 来源:H5之家 2017-05-24 15:00 我要评论( )

奶奶从路边捡来一只小鸡。它总是喳喳的叫,但是周末我坐在那里的时候,它就会蹲在我脚上,很安详的样子。然后小鲜肉就过来说:麻麻,我好想吓唬它。小鸡被吓的到处乱串。我说了挺多话没法让小鲜肉停下来。我就叹了口气在那里看着。一个5岁的孩子本来就不具备

  奶奶从路边捡来一只小鸡。它总是喳喳的叫,但是周末我坐在那里的时候,它就会蹲在我脚上,很安详的样子。然后小鲜肉就过来说:麻麻,我好想吓唬它。小鸡被吓的到处乱串。我说了挺多话没法让小鲜肉停下来。我就叹了口气在那里看着。一个5岁的孩子本来就不具备换位思考的能力。还有一个问题,我其实根本不知道小鸡是怎样想的。只是觉得它趴在我脚上的时候很安心很安静。晚上下班我会把手伸到笼子里陪它待一会儿,因为我想它是很想自己的妈妈的。

  本文首发于静儿1986的博客,原文地址是。

  先说说我们部门的业务。我们部门掌管乐视网所有的视频音频等最核心数据的信息。所有子业务都围绕着这个核心数据。最笼统的分可以分为两块:读和写。

  读数据除了直接依赖DB的内部操作之外,就是直接通过http请求的RPC调用。因为调用这个接口的业务方非常多,他们用的语言和技术非常杂,http有更好的通用性和便于运营人员等不懂技术的人排查问题,只能内网访问,也很安全。这是部门并发量最大的服务。单台机器QPS一般在2k多,低谷时在1k多,高峰时在3k多。线上11台接口服务器同时工作。但是读数据为了提高并发量,将全量的视频和专辑数据存在了memcached缓存里。所以一旦其他业务方更新了数据会直接发送MQ消息给读数据服务,读数据服务更新了缓存后要给业务方回复消息。

  读数据还有一种被叫做离线数据推送。这是由于像搜索部门这样的,需要所有视频相关的全量数据,不合适通过接口访问。之前用的是他们直接依赖我们的数据库镜像。但是这样我们这边要进行数据库改造,分库分表或者其他的表结构修改,就要通知各个依赖业务方。所以我们就改用定时全量数据推送给他们和MQ实时数据发消息的方式进行解耦。

  还有一个面向所有部门同事的服务,就是统一异常平台。部门的所有子业务的异常都会异步发送到统一的Redis中。可以在一个公共的平台统一查看。对于特定业务的,会给特定的同事发出告警邮件。

  写数据的业务方非常多,我们部门也有。其他部门也有。写数据就是创建,修改和删除。写数据QPS很低。

  创建时不仅要走我们这边,还要调用云存储,云转码等其他部门的接口。具体流程可参考之前的一篇文章:《一个请求过来都经过了什么》。

  修改是走我们部门内部系统或者调用我们的API。

  删除只能走我们部门内部系统,删除接口目前不向其他业务部门开放。

  我自己目前主要做的就是读数据的部分。离线数据算是我开发的,其他人是拷贝的我的。目前正在进行RPC接口的改造。写我也做过。PGC项目是专业用户进行视频上传的,当年是我做的。这是一个平台。我做过数据接入。就是我们购买一些版权的公司将他们的视频的介质和媒体信息直接ftp放到我们服务器上,或者给我们一种调用方式我们自己去取,这种属于后台服务。我也维护过我们的视频后台系统。是我去美国做数据接入的时候,美国运营同事总是过来找我说我们系统的问题,由于时差,我只能自己动手改了。

  后台服务可以自己想怎么写怎么写。其他的,不管是读接口,PGC还是后台系统都是采用的SOA架构将业务垂直分解为前端(对于平台来说就是和界面打交道的,对于读接口来说就是业务方调用的),使用Dubbo来调用数据服务。基于这种设计,一个子业务的代码基本模块都分为API模块,WEB模块(读接口无此模块),common模块(一些公用工具或者公用POJO), client模块(dubbo服务的接口),service服务(dubbo服务的实现,即服务提供者)。

  简单介绍一下Dubbo:Dubbo是一种透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需简单配置,没有任何API侵入。实现了软负载均衡及容错机制,服务自动注册与发现,能够平滑添加或删除服务提供者。

 

  下面是今天的重点,吐槽一下我们目前读接口的架构不合理(当然不合理是很正常的,这是一个为期三年的古董),我们新方案已经设计好了。

  读接口业务简单,并发支持需求大。如果说采用Dubbo层是为了与业务分离,提高服务的复用率,提高数据的统一性。目前一个子业务就自己弄一套Dubbo。有API和WEB两个对前端业务的也将就起到作用了。读接口就是一个api调服务,有啥复用的啊。Dubbo的读接口采用默认的阻塞模式,高并发的情况下Dubbo就会成为性能瓶颈。

  业务方可以进行数据的更新,他们更新DB后还要维护我们的缓存。我们的缓存采用的乐视统一的CouchBase集群。CouchBase是Memcached的升级版。既然是走Memcached协议,那么就可以使用Moxi代理来提高性能。

  简单介绍一下Moxi:它基于memcached开发,对于并发的gets请求,做合并来减少和memcahed server的交互。对热点访问的cache会在本地缓存,减少network hops。network hops就是网络路由跳数,距离目的网络所经过的路由器数目。对于某种类型的key,可以异步set。可配置超时时间,也有错误重试机制。

  各个业务线反馈说Memcached不好用,有性能问题。好多业务线自己换成了Redis,解决了好多神奇问题。撇开这些数据不谈,给你一个用Redis而不用Memcached理由:Memcached的各种强化和代理Memcached自己都可以做,但是没有做。Redis却在不断的更新和优化。

  还有一个专门维护这个缓存数据一致性的服务。我个人觉得我们系统过分的强调了一致性,却牺牲了性能。下面是一些基本的理论:

  分布式领域CAP理论:

  定理:任何分布式系统只可同时满足两点,没法三者兼容。

  忠告:架构师不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。

  一致性模型:

  BASE理论(CAP理论的延伸):

  核心思想:即使无法做到强一致性,但是应用可以采用合适的方式达到最终一致性。

  像我们常用的分布式存储:mysql的主从读写分离,redis缓存的master-slave形式的主从复制都是基于操作记录的,都会有时延,也就是保证最终一致性而已。

   

  题外话:基本的理论和名词概念是很实用的。比如在之前公司做搜索引擎的时候,搜索引擎需要分词,分词的分词组件叫Tokenizer。这个不是搜索引擎特有的概念。Java的rt.jar这个最基础类库里有StringTokenizer和StreamTokenizer。如果你了解了这个,就很容易理解理解搜索引擎的分词是干什么用的。

  

  再说我们项目中过分强调数据一致性而损失性能和高可用的事情。完全可以不对一致性不那么精益求精。这并不是说不追求完美。追求完美可以提现在哪些方面呢?

 

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

相关文章
  • 移动端布局 - 开发之路

    移动端布局 - 开发之路

    2017-05-24 09:01

  • 云计算之路-阿里云上:攻击火上浇油,与云盾玩起了踢皮球 - 博客园团队

    云计算之路-阿里云上:攻击火上浇油,与云盾玩起了踢皮球 - 博客园团

    2017-05-22 18:04

  • 前端架构之路:Windows下安装Nodejs步骤 - MikeXu

    前端架构之路:Windows下安装Nodejs步骤 - MikeXu

    2017-05-19 12:00

  • 云计算之路-阿里云上:攻击又来了,4个IP分别遭遇超过30G的流量攻击 - 博客园团队

    云计算之路-阿里云上:攻击又来了,4个IP分别遭遇超过30G的流量攻击

    2017-05-18 15:03

网友点评
<