最近在项目里面遇到一个比较难以解决的问题，简单的说就是查询问题。
某一张表的数据量比较大，很多业务都会根据条件来查询相关的数据，查询主要分为两类，一类是业务查询，能够根据指定的条件查询出相关的数据，数据量比较小，查询速度快，一类是后台查询，偏向数据分析，特点是查询耗时长，查询数据量比较大。
由于大量系统访问这个数据库，那么对数据源连接的实时性要求就比较高，如果后台查询大量占用数据源的连接，会影响到外部业务，从而影响业务功能的稳定性。
如何解决这个问题，在一般的情况下，我们首先会考虑设置一个合理的超时时间，由于业务查询都是大多是根据关键字查询，耗费时间都会在几十毫秒之下，很少会有大量长耗时的sql，后台的查询耗时比较长，如果设置较小的查询超时时间，会导致无法查询出来结果。那么就根据后台的查询耗时的平均时间，设置一个合理值。这种做法相对来说比较简单，但是会有潜在的风险。可能在默写特殊情况下，业务的查询也会存在热点数据，就是根据这些业务关键字的查询普遍耗时比较长，如果业务系统短时间内大量的热点数据查询，则会占用大量的数据源连接，从而影响正常的业务。尤其是在查询系统无法评估有那些潜在的长耗时查询的时候，系统就处于这种不可预测的有风险的阶段。
第二种方案，就是简单的区分这两种查询。我们先解决的问题是后台查询超时的问题，如果采用上面的方案，则会影响其他的业务系统。那么可以考虑把影响面局限于后台查询。把问题所涉及到的关注点进行分离。就是长耗时和短耗时的问题，那么就配置两个数据源，一个负责提供给业务系统，超时时间设置短一点，连接数设置大一点，一个负责提供给后台查询系统，连接数设置小一点，超时时间设置长一点。通过这种方式，能够把缩小影响面，也能够解决目前的问题。
从上面的一个简单的案例分析，在任何一个系统里面，都存在矛盾的两个方面（也可能存在多个方面）。解决这个矛盾有两个思路，第一个思路是通过两方对话和博弈使其达到一个均衡的过程。在不同的维度进行平衡，比如稳定性和复杂性，安全性和简单性，从不同的角度去考虑，通过加权和降权的方式使其达成一个平衡。还有一个考虑的思路就是对矛盾进行分离，单独进行处理，就是所谓的关注点分离。
类似上面的案例还有很多，我们所说的分层模式，也是把一个大系统中不同层面的所具备的特性不一致，并且有很多矛盾。拿我们最经常使用三层模式：web层，biz层，dal层举例，web层变化非常频繁，同时要快速的满足需求，biz层变化相对来说比web层少，而dal层则不容易变化。分层模式主要是利用系统中不同关注点所面对的问题，每个层次的特性明显不同，这些都是可以才哟过分层的思路来设计。从系统分层到架构分层，都可以看到其背后隐藏着系统内部的矛盾。
不止在IT领域的系统设计存在这个问题，在组织架构上也面临着同样的问题。大公司都会存在一套特定的业务流程满足公司内所有的部门。但有一些部门涉及到的业务要求快，有一些业务要求稳，这两个就是矛盾。这也是金融互联网公司内部面临的主要问题，互联网要求简单，快速，创新，金融则是复杂，稳定，保守。如果解决这些矛盾，也是这类公司面临的问题。