架构的变迁

1、背景html

    目前正在作的事大部分与数据处理、机器学习、天然语言处理相关,一直想对web进行一些总结,一是想回顾一下这些年web架构的变迁,二是想记录下来方便往后查看。web

2、架构的变迁redis

    软件架构有C/S和B/S之分。C/S即client/server,用客户端与服务端来交互,咱们用到大部分桌面软件都是c/s模式的。B/S即browser/server,用浏览器与服务端进行交互,咱们经过浏览器访问的网站基本都是b/s模式的,如淘宝网、百度等等。c/s模式因为升级维护不方便,因此大部分大型应用都会采用b/s架构。下面来谈谈b/s架构的变迁。sql

    一、静态网页数据库

    网页的组成都是静态的html,用户量也不大,网站的发布也不须要web容器,前面加一个http代理就能够了,静态网页内容固定,数据固定,要变动内容必须从新编写,知足不了业务的日益增加。数组

    二、单节点动态网页浏览器

    动态网页本质上就是根据数据来动态拼装web页面,这种模式可让web系统适应复杂多变的业务。因而用web容器和数据库构成了以下的架构:缓存

   

    三、web集群服务器

    随着应用受到用户的喜好,用户量也增多了,访问量持续增大,一个web节点支撑不了访问量,因而就有了web集群,固然web集群须要解决一些问题,如session共享、定时job集群等问题。那么架构就变成了负载均衡后面跟着多个web节点的这种模式。网络

  

    四、cache缓冲

    web节点增长了,能够抵御大部分流量了,但是咱们又发现数据库这一层扛不住了,因而就有了缓冲方案,在db与应用节点之间加一个单节点cache,去缓存一些不随意变更且访问量大的热数据,缓存没命中,才走数据库查询,优秀的cache服务有memcache、redis等等,因而架构进一步演变。

    

    五、分布式cache

    随后发现大量请求涌向这个单节点cache,数据存取比较快,IOPS也上去了,可是有带来了新的问题,这个cache节点的网卡吃不消了,那么怎么办呢?加机器,横向扩展呗,分布式呗,分而治之。怎么个加法,因而有一致性hash,那么架构就是这样子。

       

    六、线程内缓存

    随着请求量的持续增大,最后仍是发现cache节点的网卡又爆了,那么就出现了二级缓存,紧贴着web容器作一层线程内缓存,优秀的线程内缓存有ehcache等,图就不画了。

    七、读写分离

    随着用户数的激增,单节点数据库最终仍是败下阵来,可是咱们会发现,读的请求会比写请求要多的多,这种场景下,咱们是否是也能够效仿web集群横向扩展呢,这时横向扩展会有点不同,一台主节点负责写请求,多台从节点负责读请求,从节点同步主节点的数据,因而读写分离就产生了,架构就变成了这样。

     

    八、分库分表

    随着应用的庞大,用户量持续增大,数据库的数据量急速增加,单表数据量爆增,B+树的索引性能直线降低,查询速度急剧降低,尽管咱们会放弃范式,对字段进行单表冗余,最终仍是敌不过数据的激增。那么接下来采用的方案是分库分表,把一张大表拆成多个小表。分库分表的思路不少:

    (1)、service层硬编码,这种方式侵入性很强,业务关联紧密,开发量大

    (2)、Dao层实现,相比service层实现少了业务关联,可是大量sql要改写、开发量依然巨大

    (3)、JDBC层实现,这种方式基于ORM层之下,拦截SQL解析改写,多线程执行,而后归并结果集。这种方式对开发透明,开发改造量不多,比较推荐的是这种方式。基于jdbc的分库分表框架有当当的sharding-jdbc等等。

    因而架构演变成以下的模式。

    

    九、SOA化

    业务的规模已经让融合在一块儿的工程变得十分臃肿,build一次要几分钟,开发变成了很大问题,另外业务应该抽象出来,变成独立的服务,精细化的分工,能够更容易的有的放矢的抵御更大的流量。因此便有了面向服务的架构。各个业务之间以远程服务的方式调用。服务器实现的方式不少,如RMI、Rest、Http等等,优秀的服务化框架如dubbo、Spring Cloud等等。经过这些优秀的框架,应用就能够被拆成小服务,服务于服务之间经过网络相互调用。服务化框架要解决的问题有不少,如序列化(枚举、数组怎么序列化)、传输协议、负载均衡、IO模式选择等等。图这里就略去了。

    十、关于数据

    第8点中,提到放弃范式作冗余,当数据量大到索引都失效的时候,咱们惟一能够查询的就是主键了,那么就产生了HBase这种列式存储的解决方案,只提供一种基于rowkey的查询,而后数据分region存储,只有rowkey设计合理,也能够很好的知足业务。

    还有,当B+树索引失效的时候,咱们会把目光更多的转向倒排索引,如Lucene,还有基于Lucene的Solr或者elasticsearch。

3、结束语

    从应用到缓存再到数据库,抵御大流量高并发,解决问题的终极思想是“分而治之”,因此最终构成一个大型应用的各个部分都走向了分布式……

 

快乐源于分享。

此博客乃做者原创, 转载请注明出处

相关文章
相关标签/搜索