架构的变迁

一、背景

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

二、架构的变迁

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

    1、静态网页

    网页的组成都是静态的html，用户量也不大，网站的发布也不需要web容器，前面加一个http代理就可以了，静态网页内容固定，数据固定，要变更内容必须重新编写，满足不了业务的日益增长。

    2、单节点动态网页

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

   

    3、web集群

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

  

    4、cache缓冲

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

    

    5、分布式cache

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

       

    6、线程内缓存

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

    7、读写分离

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

     

    8、分库分表

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

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

    （2）、Dao层实现，相比service层实现少了业务关联，但是大量sql要改写、开发量依然巨大

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

    于是架构演变成如下的模式。

    

    9、SOA化

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

    10、关于数据

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

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

三、结束语

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

 

快乐源于分享。

   此博客乃作者原创， 转载请注明出处