序：
从第一次玩DOS到如今n年了，想当初将5.25吋盘锁入电脑后，输入dir，看到屏幕的输出兴奋不已。
毕业后写基于C/S的VB/VC应用，写ASP/PHP/JSP/ASP.NET的网站，一直就是简单的系统。
曾经以为代码写得简洁无BUG就是最高境界了。不曾想过其他，直到开始带一队人写平台才了解了架构的重要。
本文编撰于2018.12.16
本文简单描述基于B/S从简单单体应用到分布式的应用的架构演变，作为故事也许不够完美。
1.
故事开始
故事开始于某年月日，七哥读了几本书，写了几年代码，忽觉胸有点墨，不吐不快，于是乎准备做一个技术日记站。既能记录点滴又能分享给别人，岂不快哉？
2.
主从库分离
随着时间的推移，七哥的博客写的内容多了，兴许日记内容还有点价值，访问的人慢慢多了，同时小伙伴们开始抱怨网站访问速度慢。
七哥咬咬牙，升级了硬件配置，访问速度暂时得到了缓解。
可惜好景不长，很快又被小伙伴们抱怨太慢了。
如上图，读写分离之后，写库操作不影响读库。主从库的调整对于日记分享这种读多写少的情景是非常有利的。经过数据试验实际效果相当不错，似乎可以高枕无忧了。如此简单而经济的提升方式，想想都开心。
3.
应用、数据、文件分离
七哥的博客有了流量之后，七哥的很多小伙伴要求也要加入码字的行列，因此程序进行了升级变成了多人博客系统。
一时间，流量有了平方数的增长，大家不亦乐乎。
紧接着服务器无响应的事情发生的频率越来越高。甚至有些小伙伴码字半天提交的东西，不见了？？？
然而故事并没有结束。
4.
动静分离、加缓存
在多服务器的支撑下，服务质量提升了，但是光靠硬件提升服务水平，似乎稍逊风骚了。琢磨片刻，七哥一整键盘飞舞，在DB和应用间增加了缓存服务。如下图：
这次赢回了码民的面子，关键还提升了服务效用。感觉整个世界都为之喝彩。
5.
负载均衡
随着博客的流量越来越高，七哥的博客也增加了相应的服务，诸如：积分，笔记，礼品等。
如上图，至此，七哥的系统已经可以服务相当大的一群人了。
6.
服务拆分+NOSQL
在经历一段高速发展之后，七哥的博客也升级成了一个阅读平台，平台必须有个好听的名字，该叫什么呢，比如luckread.com？并且电商功能、朋友圈等功能也迅速让系统臃肿起来，犹如铁链串起来的一批船，着实壮观，但行动缓慢。
7.
分布式
终于，经过多轮应用的分拆，系统渐渐向分布式演变。如下图：
上图，每个应用都成了独立服务，负责单独的业务，简单而简洁。
撇开成本不表，分布式的引入，对于不爱写Java的Python小伙伴是极开心的；对于写Java的小伙伴来说，再也不用看那么多无关的文档了，简单而快乐。对于七哥来说，luck read 好像可以稳稳的运行了。
8.
未完
其实，故事应该编完了，有了这么一个高流量的luck read，在这流量时代，应该是收获满满的。然而这仅仅是一个故事，仅仅是为了说明架构的演变。
末尾，再附上一张图，引入了DNS轮询概念，如下：
故事结束。
