好文章：参考
个人认为：架构是一步步演进的，
- 性能提升：对于架构的一个地方不足以满足需要时，往往我们可以水平扩展，这样既可以做到负载均衡，又可以做到高可用
- 业务迭代：这需要我们要做到高可复用，明白应用的设计规范，职责清晰，比如通过微服务抽离公共模块，并且使用总线来规范化接口访问
下面是学习到的架构迭代过程
- 单机架构
好处：简单
问题：Tomcat和数据库之间竞争资源 - 分布式，
好处：各自占用服务器，根据按需提升
问题：并发量的继续增长，并发读写数据库成为瓶颈 - 引入本地缓存(如memcached)和分布式缓存(如Redis)
好处：绝大多数请求在读写数据库前拦截掉，大大降低数据库压力
问题：并发量的继续增长，缓存抗住了大部分的访问请求，并发压力主要落在单机的Tomcat上，响应逐渐变慢 - Tomcat集群并使用反向代理实现负载均衡
单机的Tomcat得到有效缓解
问题：并发量的增长继续增长，更多请求穿透到数据库，单机的数据库最终成为瓶颈 - 数据库读写分离(如mycat)
把数据库划分为读库和写库，读库可以有多个，缓解了大部分读库的压力
问题：用户继续增长，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能 - 业务分库
把不同业务的数据保存到不同的数据库中，使业务之间的资源竞争降低，对于访问量大的业务，可以部署更多的服务器来支撑
问题：用户继续增长，单机的写库会逐渐会达到性能瓶颈 - 大表拆小表
只要实时操作的表数据量足够小，请求能够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高性能
问题：并发量的继续增长，最终单机的Nginx会成为瓶颈 - Nginx集群，LVS/F5使得Nginx负载均衡，并让LVS/F5高可用
单个访问的大门更宽敞
问题：并发量的继续增长，LVS服务器最终会达到瓶颈 - 轮询机房
好处：系统入口处的请求并发量不再是问题。
问题：随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库无法解决如此丰富的需求 - 引入NoSQL数据库和搜索引擎等技
海量文件存储：分布式文件系统HDFS
key value类型的数据：HBase和Redis
全文检索场景：ElasticSearch
多维分析场景：Kylin或Druid
问题：一个应用中包含了太多的业务代码，业务的升级迭代变得困难 - 大应用拆分为小应用
按照业务板块来划分应用代码，使单个应用的职责更清晰，相互之间可以做到独立升级迭代
问题：不同应用之间存在共用的模块，由应用单独管理会导致相同代码存在多份，导致公共功能升级时全部应用代码都要跟着升级 - 复用的功能抽离成微服务
公用代码抽出为服务，可以使用springcloud框架实现
问题：服务的调用链将会变得非常复杂 - 引入企业服务总线ESB屏蔽服务接口的访问差异
应用统一通过ESB来访问后端服务
问题：新增的服务上准备运行环境，部署服务等，运维将变得十分困难 - 引入容器化技术实现运行环境隔离与动态服务管理
Docker配合Kubernetes(K8S)，使服务的部署和运维变得简单
问题：非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低 - 上云
利用公有云的海量机器资源，解决动态硬件资源的问题
