单机的nginx成为瓶颈，端口有限，当你达到5万并发的时候， 单机的nginx请求入口撑不住就会有问题，
解决：多台nginx + LVS/F5（硬件）
LVS/F5都工作在传输层，可支持几十万个并发的请求转发，实现负载均衡
（Linux 虚拟服务器）运行在OS内核，可对更高层次的网络协议进行转发，类似于指路的，不查看内容，直接告诉请求走哪个nginx
F5
是专门的硬件，性能要比LVS更高，价格更贵
LVS/F5为了避免宕机，同样需要备份结点，但一个ip地址只能绑到一台机器，所以引入keep alived 软件提供虚拟IP
当主LVS服务器宕机时，keepalived软件自动去更新路由器的路由表，将虚拟的ip重新定向到另一台运行的LVS服务器
个人认为：架构是一步步演进的，
- 性能提升：对于架构的一个地方不足以满足需要时，往往我们可以水平扩展，这样既可以做到负载均衡，又可以做到高可用
- 业务迭代：这需要我们要做到高可复用，明白应用的设计规范，职责清晰，比如通过微服务抽离公共模块，并且使用总线来规范化接口访问
下面是学习到的架构迭代过程
- 单机架构
好处：简单
问题：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)，使服务的部署和运维变得简单
问题：非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低 - 上云
利用公有云的海量机器资源，解决动态硬件资源的问题
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
