系统内部矛盾的解决思路

最近在项目里面遇到一个比较难以解决的问题，简单的说就是查询问题。

某一张表的数据量比较大，不少业务都会根据条件来查询相关的数据，查询主要分为两类，一类是业务查询，可以根据指定的条件查询出相关的数据，数据量比较小，查询速度快，一类是后台查询，偏向数据分析，特色是查询耗时长，查询数据量比较大。

因为大量系统访问这个数据库，那么对数据源链接的实时性要求就比较高，若是后台查询大量占用数据源的链接，会影响到外部业务，从而影响业务功能的稳定性。

 

如何解决这个问题，在通常的状况下，咱们首先会考虑设置一个合理的超时时间，因为业务查询都是大可能是根据关键字查询，耗费时间都会在几十毫秒之下，不多会有大量长耗时的sql，后台的查询耗时比较长，若是设置较小的查询超时时间，会致使没法查询出来结果。那么就根据后台的查询耗时的平均时间，设置一个合理值。这种作法相对来讲比较简单，可是会有潜在的风险。可能在默写特殊状况下，业务的查询也会存在热点数据，就是根据这些业务关键字的查询广泛耗时比较长，若是业务系统短期内大量的热点数据查询，则会占用大量的数据源链接，从而影响正常的业务。尤为是在查询系统没法评估有那些潜在的长耗时查询的时候，系统就处于这种不可预测的有风险的阶段。

 

第二种方案，就是简单的区分这两种查询。咱们先解决的问题是后台查询超时的问题，若是采用上面的方案，则会影响其余的业务系统。那么能够考虑把影响面局限于后台查询。把问题所涉及到的关注点进行分离。就是长耗时和短耗时的问题，那么就配置两个数据源，一个负责提供给业务系统，超时时间设置短一点，链接数设置大一点，一个负责提供给后台查询系统，链接数设置小一点，超时时间设置长一点。经过这种方式，可以把缩小影响面，也可以解决目前的问题。

 

从上面的一个简单的案例分析，在任何一个系统里面，都存在矛盾的两个方面（也可能存在多个方面）。解决这个矛盾有两个思路，第一个思路是经过两方对话和博弈使其达到一个均衡的过程。在不一样的维度进行平衡，好比稳定性和复杂性，安全性和简单性，从不一样的角度去考虑，经过加权和降权的方式使其达成一个平衡。还有一个考虑的思路就是对矛盾进行分离，单独进行处理，就是所谓的关注点分离。

 

相似上面的案例还有不少，咱们所说的分层模式，也是把一个大系统中不一样层面的所具有的特性不一致，而且有不少矛盾。拿咱们最常用三层模式：web层，biz层，dal层举例，web层变化很是频繁，同时要快速的知足需求，biz层变化相对来讲比web层少，而dal层则不容易变化。分层模式主要是利用系统中不一样关注点所面对的问题，每一个层次的特性明显不一样，这些都是能够才哟过度层的思路来设计。从系统分层到架构分层，均可以看到其背后隐藏着系统内部的矛盾。

 

 

不止在IT领域的系统设计存在这个问题，在组织架构上也面临着一样的问题。大公司都会存在一套特定的业务流程知足公司内全部的部门。但有一些部门涉及到的业务要求快，有一些业务要求稳，这两个就是矛盾。这也是金融互联网公司内部面临的主要问题，互联网要求简单，快速，创新，金融则是复杂，稳定，保守。若是解决这些矛盾，也是这类公司面临的问题。