从高并发的角度来看系统架构演进_高并发技术架构演进

如果从高并发的角度来思考架构的演进过程，大体思路是怎样的呢？

如果是单体应用，那么与很多分布式的解决方案是没有关系的，缓存用ehcache，搜索引擎用lucence，不需要rpc，不需要注册中心，不需要分库分表，不需要考虑很多分布式问题带来的复杂性。

但是单体应用能够承受的并发量是很有限的，所以才会有分布式。

1、拆分系统：通过拆分系统，可以将各个子服务部署到不同机器上，使用不同机器上的资源，突破tomcat应用容器的并发量瓶颈，同一个服务部署多个实例，增加并发上限的同时保证服务高可用。

2、拆分系统之后，服务之间的调用怎么办？调用过程不能太复杂，调用失败怎么办，重试机制怎么来搞，负载均衡机制怎么实现，所以有了Dubbo。服务地址等配置维护怎么办，配置如何动态感知，所以有了ZK。

3、缓存：当并发量继续飘升，数据库的压力持续增大，如何降低数据库的压力，如何提高某些需要耗时且复杂计算接口的响应速度，那么Redis等分布式缓存机制就排上用场了，redis可以扛 几万每秒 的并发量。

4、MQ：虽然MQ在非高并发系统中可能就会被使用，比如用于微服务架构中服务之间的解耦，异步场景的业务，保证分布式事务的一致性等等。但MQ同样可解决高并发的一些问题，高峰期访问量过高，但过了高峰期访问量很低的场景，使用MQ来削峰，MQ作为一个屏障保障数据库不会被请求打死。

5、ES：对于搜索的场景，单机的lucence不再适用，选择支持分布式的缓存机制，比如ES等，ES可以扛 几万每秒 的并发量。

6、分库分表与读写分离：单个Mysql的并发量很有限，2000/s，超过这个限度sql执行效率就会变慢。系统设计之初，就应该根据业务进行分库，垂直分库，也就是保证不同的子服务使用自己单独的数据库。即使这样也远远不行，并发量继续飘升之后，要考虑库内分表、跨库分表、水平分表、垂直分表；数据库数据拆分到多个库中、主备模式、读写分离等等，还有对应的数据库路由访问机制等。

思考：

what并不值钱，值钱的是why和how：

what关注了是这个技术是上面东西？有哪些特点？架构是怎样的？

why关注的是它有什么优缺点？为什么要这样设计？满足了什么业务场景？

how关注的是它的特性是否适合我们公司的场景？如何和公司场景结合起来实现某些效果？

平时学习技术，不仅仅是要把握某种技术的架构、知识体系、API（现用现查），更要思考为什么要使用这种技术，可以带来哪些好处，同时会带来哪些弊端，利大于弊的情况下再选择使用，这种技术适用于哪些场景，自带哪些解决方案等等问题，这些背后的思考才是价值所在！