那么，这么做是否真的能解决上述问题了呢？不玩虚的，一个一个来说 。
对于问题一，由于拆分成多个子系统，系统的压力被分散了，而各个子系统都有自己的数据库实例，所以数据库的压力变小 。
对于问题二，一个子系统A的数据库挂了，只是影响到系统A和使用系统A的那些功能，不会所有的功能不可用，从而解决一个数据库挂了，导致所有的功能都不可用的情况 。
对于问题三、四，也因为拆分得到了解决，各个子系统都有自己独立的GIT代码库，不会相互影响 。通用的模块可通过库、服务、平台的形式解决 。
对于问题五，子系统A发生改变，需要上线，那么我们只需要编译A，然后上线就可以了，不需要其他系统做通向的事情 。
对于问题六，顺应了康威定律，我部门该干什么事，输出什么，也通过服务的形式暴露出来，我部门只管把我部的职责、软件功能做好就可以 。
对于问题七，所有需要我部数据的需求，都通过接口的形式发布出去，客户通过接口获取数据，从而屏蔽了底层数据库结构，甚至数据来源，我部只需保证我部的接口契约没有发生变化即可，新的需求增加新的接口，不会影响老的接口 。
对于问题八，不同的子系统需要不同的权限，这个问题也优雅的解决了 。
对于问题九，暂时控制住复杂性，我只需要控制好大方面，定义好系统边界、接口、大的流程，然后再分而治之、逐个击破、合纵连横 。
目前来说，所有问题得到解决！bingo！
但是，还有许多其他的副作用会随之产生，如RPC、MQ的超高稳定性、超高性能，网络延迟，数据一致性等问题，这个就不展开来讲了，太多了，一本书都讲不完 。
另外，对于这个模式来说，最难把握的是度，切记不要切分过细，我见过一个功能一个子系统，上百个方法分成上百个子系统的，真的是太过度了 。实践中，一个比较可行的方法是：能不分就不分，除非有非常必要的理由！
优点：相对高性能，可扩展性强，高可用，适用于中等以上规模公司架构 。
缺点：复杂、度不好把握 。指不仅需要一个能在高层把控大方向、大流程、总体技术的人，还需要能够针对各个子系统有针对性的开发 。把握不好度或者滥用的话，这个模式适得其反！
七、多级缓存模式这个模式可以说是应对超高查询压力的一种普遍采用的策略，基本的思想就是在所有链路的地方，能加缓存的就加缓存，如下图所示：
文章插图
如上图所示，一般在三个地方加入缓存，一个是客户端处，一个是API网关处，一个是具体的后端业务处，下面分别介绍：
客户端处缓存：这个地方加缓存可以说是效果最好的一个——无延迟 。因为不用经过长长的网络链条去后端业务处获取数据，从而导致加载时间过长，客户流失等损失，虽然有CDN的支持，但是从客户端到CDN还是有网络延迟的，虽然不大，具体的技术依据不同的客户端而定，对于WEB来讲，有浏览器本地缓存、Cookie、Storage、缓存策略等技术；对于App来讲，有本地数据库，本地文件，本地内存，进程内缓存支持，以上提到的各种技术有兴趣的同学可以继续展开学习，如果客户端缓存没有命中，那么会去后端业务拿数据，一般来讲，就会有个API网关，在这里加缓存也是非常重要的 。
后端业务处理：这个我就不用多说了，大家应该差不多都知道，什么redis、Memcache、Jvm等等，不赘述了 。
实践中，要结合具体的实际情况，综合利用各级缓存技术，使得各种请求最大程度的在到达后端业务之前就被解决掉，从而减少后端服务器压力、减少占用带宽、增强用户体验 。至于是否只有这三个地方加缓存，我觉得要活学活用，心法比剑法重要！总结一下这个模式的优缺点：
优点：抗住大量读请求，减少后端压力 。
缺点：数据一致性问题较为突出，容易发生雪崩，即：如果客户端缓存失效、API网关缓存失效，那么所有的大量请求瞬间压向后端业务系统，后果可想而知 。
八、分库分表模式这种模式主要解决单表写入、读取 、存储压力过大，从而导致业务缓慢甚至超时，交易失败，容量不够的问题 。一般有水平切分和垂直切分两种，这里主要介绍水平切分 。这个模式也是技术架构迭代演进的必经之路 。
这种模式的一般设计见下图：
推荐阅读
- 处理器|打破x86/ARM垄断：第三大CPU架构RISC-V的春天来了
- gRPC入门知识
- Node.js架构剖析
- 健身训练后，加快身体恢复的8种方法
- 架构师修炼之微服务部署 - 深入理解Docker镜像
- 扩展我们的AWS基础架构
- SaaS 架构设计的参考指南
- 高并发秒杀系统架构解密，不是所有的秒杀都是秒杀！
- 适合春天饮用的8种花茶,花茶不只是女人专属
- 8种运动能“治”病，一动见效!