中间件架构重要性

        本篇博客的内容主要是介绍中间件架构在系统中的重要性，并不涉及中间件具体的落地解决方案，各中间件具体解决方案，我会跟着实战项目逐一落地，我会讲解目前市场中常用解决方案以及为什么我会选择某种解决方案来落地在项目上。其中还有部分技术（日志收集架构、搜索系统架构）我也需要跟着项目一起学习，如果有小伙伴有生产环境实际使用经验，也请小伙伴不吝赐教，接下来介绍我在项目中常用的中间件架构。

 

缓存架构

      缓存在系统中具有重要意义，通过设计缓存架构来提高系统吞吐量、并发能力，在高并发、高流量访问的时候可以保障你系统的可用性、高性能。但是如何正确的选择缓存架构对于系统研发人员、运维人员提出了一个难题。好的缓存架构可以提高用户对产品的体验，不适合的缓存架构不仅会提高系统的维护成本，甚至由于缓存架构选择不当导致系统全盘奔溃等。

 

消息中间件架构

       消息系统中间件与缓存架构一样在系统中有着举足轻重的地位，通过消息中间件不仅可以提高系统的吞吐量、并发能力。当下微服务兴起的时机，消息中间件可以很好对各服务进行解耦，各服务可通过消息进行通讯来提高各服务的可用性。不仅如此，在企业中通过消息中间件完成流量削峰、分布式事务、日志收集等方案，消息中间件带来的好处很多，但是我们更多的要关注引入消息中间件后可能会出现的问题，比如消息如何保证可靠、消息重复消费等问题。

 

搜索系统架构

       继续更新…

 

日志收集架构

  继续更新…

 

高可用数据库架构

      我在工作中用的比较多的数据库主要是mysql、postgresql。作为一名技术人员，我必须承认数据库的架构比应用系统的架构要复杂的多，系统中出现的大多数性能瓶颈大多数与数据库有关，数据库的架构是随着业务发展一起升级的，系统刚起步时，数据库可能非常简单，但随着业务量的增长以及历史数据的增长，这时候问题就来了，当你简单的数据库架构不能支撑现有业务要求的时候，我们就需要考虑数据库如何扩展，数据如何迁移。我在实际生产中遇到过由于一条查询sql语句使用不当，导致整个数据库全部卡死，数据库直接不可用。

 

应用层负载均衡架构

       随着技术的更新迭代，成熟的负载均衡解决方案已经很多了，也有很多厂商提供在自己的框架中内嵌了常用的负载均衡策略可以在各服务直接很方便的进行调用，比如sping cloud、dubbo等，我把spring cloud、dubbo等框架提供的负载均衡调用定义为服务之间的负载均衡，所以我这里说的是应用层的负载均衡策略，该负载均衡策略主要用于访问web系统，使用java的小伙伴们都知道，一台tomcat的QPS一般在100-800之间，具体的值根据服务器所处理的业务决定，但是如果公司的业务高速增长到QPS为5000的时候，单台tomcat不足以支持如此大的业务量，此时需要在应用层部署多个实例来处理业务。