网站平台架构演变史（一）

朋友公司的产品已经做了11个年头了，在餐饮业可以说数一数二，网站架构从原始的单一应用一直演变至今，已经十分庞大了，不说完美，但是可支撑的业务量已经十分强大。最近受邀参与了他们的架构分享会，在此我也总结一下大致内容，一方面当做会议纪要，一方面也总结分享给大家看看。

先看一下初期架构，前期网站平台刚刚建立，对于访问量并发量来说并不会很高，所以采用如下的架构即可，虚线框代表服务端可以做一个主备集群，如果挂了可以使备胎立刻顶上，当然这个备胎对于有些创业小公司可以拿掉，毕竟多一台服务器也是成本

需要注意的事，前期我们并没有谈及高可用以及高并发。要这么做，那么服务器以及运维成本都要上去。

当服务端进行高可用设计，部署为集群的情况下，用户状态这个session改如何保证？

比如用户正在访问网站，session是有服务端A来提供，在nginx中可以配置不同服务器的访问权重，突然服务端A变为了服务端B或者C，那么用户session就丢失了，所以我们的session需要做粘性或者非粘性的同步，或者改为无状态session都行。

粘性和非粘性，这个可以通过tomcat来进行配置，经过测试同步session所需要的时间在半分钟-2分钟，尤其是在多集群情况下，这样的性能十分低下（参考原文链接），用户更不可能在客户端等待那么久，所有我们一般都会使用缓存来控制session使之成为无状态的。

退一步讲，我以前的公司至今都是采用cookie来存储用户的信息的，这样后端几乎没什么压力，但是对于一些人来讲，cookie总归是不安全的，但是我还是挺喜欢cookie的，如果真有人来看你的cookie那去看呗，反正加密的。因为人家淘宝初期也是这么做的

（我们目前的做法采用的是缓存+cookie中存放加密token来实现的）

那么再来看看这样的架构，朋友公司的餐饮系统（不是外卖，非外卖三巨头），在中饭以及晚餐时候的并发是特别高的，尤其是写操作，十分多，业界著名的12306在前期几乎是处于崩溃的状态，连用户都无法注册登录，主要是因为数据库的写操作出现了大并发，同时又有大量的用户在读，所以咯。再此我们要做的就是进行读写分离，可以自己实现，或者通过中间件比如mycat来做都行。如果你的电商平台设计到库存，那么读写分离还是不够的，毕竟读写库同步是需要时间的，写入的时候库存就应该减少，同步需要时间，而其他用户看到商品的库存的时候是有滞后的，所以在这里就需要引入缓存

对于读操作，很多时候可以把一些冷资源，或者说是静态的不怎么变化的数据放入缓存，这样的话可以大大提高读的并发性。

那么热资源怎么办？经常变化的数据用户也要读啊，那么在这里就要引入搜索引擎的技术，比如solr，elasticsearch

sorl和ES还是有比较大的区别，如何选择？如果索引数据是定时更新，对于用户来说实时性需求不是很大，那么使用Solr；如果索引需要事实更新的，那么就乖乖用ES吧（关于ES，过段时间空了会做一套教程）

大致先整理这么多，下篇具体讲讲数据库这块。