前言

在架构这一层思考了一些方案，目标其实比较清晰明确，即省钱、省心！要做到即省钱又省心，这很显然在你没有量的情况下最简单的方案就是无为，即自己最熟悉的单机架构。但是在学习力的驱使下，得去了解下现在别人是怎么做的。比如上一代架构、新一代架构、经典架构，但愿起量后能有实战的机会。

经典架构

Routers53：提供DNS的域名解析服务
ELB：提供负载均衡服务
ASG：提供根据运行系统信息，动态的调整scale out / scale in 的服务
RDS：提供M/S的高可用性的DB服务
DynamoDB：提供KVS结构的数据存储服务
S3：提供应用程序，DB备份功能的存储服务
CloufFront：提供静态资源的的快速分发CDN服务

这个出处是AWS简单的三层架构示例图，这个就比较简单了，就是费钱，业内应该不少都是使用了该方案。说的好听一点是可以专注业务，不好听则是买服务，因为所有的运维和机器都交给了AWS来做了，扛不住了加ECS或扩容就可以了。
付费点：DNS域名解析+负载均衡ELB+N台云服务器+持久化的DB+云内存+备份+CDN服务+带宽成本。

一些思考

上图其实本质上是解决集群问题，只不过实现的手段是花钱买AWS的服务。那么我们是否可以去想一下其底层本质是什么，以及如果量做起来，如何可以不动任何代码完成扩容。

如何省钱

2台云服务器（其中一台还是送的），丐版实现

负载均衡：Nginx  
持久化DB：Mysql  
KVS内存：Redis
消息队列：Kafka
全文检索：ES

云服务器上直接搭，单机架构。前期核心诉求是跑通业务，可用性更为重要，一台业务向，一台统计向。
这里面其实比较重要的一个环节是负载均衡这一项，丐版配置本质上是这样：

上图实际上已经通过DNS实现了第一层的负载均衡，如果还发生高并发那么一般会出现在下面两处：
负载均衡；
数据存储；

负载均衡

负载均衡这一块优化空间，上面主要依托的是Nginx的处理能力，但是Nginx有个特点无法做到上行请求和下行请求分离，如果能做到上行请求转发给具体业务服务器，再由业务服务器处理并直接返回给用户，则能大大提高入口请求的处理能力，很幸运业内也有成熟方案，即LVS（Linux Virtual Server）。
LVS的变种DPVS据说是LVS性能的几倍，由爱奇艺开发，看着应该也是成熟的技术，Github地址
此时负载均衡的架构变为LVS（DR模式）：

数据存储层

持久化存储压力，主要在于数据库的设计，包括典型的如读写分离，写入操作为master节点，读操作为slave节点，具体到代码层面可以用aop来拦截dao层方法，根据方法名称就可以判断要执行的sql类型(即是read还是write类型)，进而动态切换主从数据源。其次读写操作可以使用文章中丐版说的redis、消息队列挡在mysql前面，最终就变成了集群Redis、Kafka、Mysql。据说开源出来的Anna可以替代redis作为KVS内存方案牺牲的是一致性，性能是redis 10倍，有待考量。

如何省心

本质是如何偷懒，主要工作量实际是部署和监控上的事，部署问题可以容器化，即Docker解决该问题。监控可以利用keepalive 、crontab、三方管理工具表盘来做监控。这些后面会特意做为专题来练习和实战。

接下来就是实战，实战才是最关键的理论落地，关注接下来的实战落地

0xFF 参考链接

www.cnblogs.com/klb561/p/92…
www.cnblogs.com/majiang/p/1…
blog.51cto.com/u_7961702/3…