刚毕业那会一直听大牛说，架构是个很玄的东西，你懂好像也不懂，反正我不懂...
跟很多同行闲谈中，挺多人都认为，当没访问量时，架构就是扯，只有到一定量之后架构才有意义。乍一看，好像是那么回事，读完本书渐渐改变了一些曾经的无知。书中解答了小白们的疑惑，我也是从书中所得且也结合这几年的工作经验，我更觉得架构是一种支持由小至大的弹性设计框架，具有灵活伸缩性、稳定性，楼无架不起、桥无樑不通。
大神们常说架构是虚的，少谈少看，多夯实基础为上策。虽未成大神，但日积月累的坑让我明白，早一点熟悉，就少踩一些坑，架构不是那么容易随随便便操作的，但却可以轻松松松入门开始，通读完本书，所得的知识也补充了我曾经认知上的空白，架构是一种技术视野与设计思想，是力能扛鼎的技术壁垒，是技能与经验碰撞的展现，没多少年老老实实的经验积累，少谈，不然就送你一个高并发，试试？
跟着作者的思路，逐步理解从一个小型网站开始一步一步随着业务量与日剧增，架构师需搭建能顶住系统增长的新设计体系。我试着借作者思路，根据访问量分一次级别。
第一级:业务量很小的门户或者同类访问量的站点，单服务器使用lamp、lnmp、wamp、wnmp等就足够了。
第二级:有一定访问量且数据有一定重要性的系统，将业务逻辑跟数据库分离，增加一下业务服务器和数据服务器的硬件配置，此时足够撑起需求；
第三级:有一定访问量且数据量已经很多，页面直查数据库难以满足响应时间，系统访问撑不住了查询太慢，可以考虑加入memcache、memcached、redis、ssdb等缓存，在查库之前就返回给页面的功能，也需要考虑cdn了，至于资源文件缓存这些就不啰嗦了。
第四级:访问量够大了、数据量够大了，单服务实例已经不够了。少年，赶紧叫你老板拿钱出来，开始升级服务器了，根据需要依次将业务服务器、数据库服务器、缓存服务器换成主从或集群吧，对了，数据如此重要，就要考虑数据库灾备服务器实时备份数据了。
第五级:访问量、数据量已经到很大的级别，集群是唯一选择了，根据业务逻辑不断的拆分子系统子模块，每一个功能模块作为一个子项目单独运营了。
第六级:慢慢摸索吧...
我目前接触的系统进入了第五级，日访问3亿，并发达3W，日统计明细数据近TB级，数据记录为几十亿或者百亿级，统计结果的数据库存储为TB级；
架构这么虚的东西，慢慢探索吧~
2017.9.20
