所有当前系统几乎都部署了数据库中间件。 但是，很多人不知道中间引进的作用是什么，也不知道可以采取不引进的方式。 今天的编辑将讨论为什么要部署数据库中间件。
经过连续分层体系结构演进、DAO层、基础数据服务化、通用业务服务化、前后端分离，一个业务系统的后端结构如下：
web-view层通过http接口从web-data获取json数据(例如
web-data层通过RPC接口从biz-service获取数据(通用业务服务) )。
biz-service层通过RPC接口从基本服务获取数据(基础数据服务)
基本服务层通过DAO从db获取数据(DAO )
数据库存储数据
随着时间的推移，数据量增加，基本服务通过DAO访问数据库的性能降低。 需要开始考虑对数据库进行水平分割。 数据库水平拆分后，有许多SQL支持的功能，因此需要基本服务层来进行特殊处理。
一些数据必须路由到特定的水平库
如果存在不知道在哪个级别分割库的数据，则必须访问所有库
某些数据可能需要访问全局库，获得数据的全局视野，并对服务层进行附加处理
.
更具体地说，对于前台高合并的业务，在数据库层面进行分割后，有这样典型的业务场景和应对方案。 需要特别强调的是，这里对应的是“前台”“高并发”“数据库水平分割”的场景，后台需求由前台和后台分离的架构处理，这里不讨论。
(一) parTITIon key中的单行查询
典型场景：通过uid询问用户
场景特征：
用paTITIon key咨询
一次只返回一行记录
解决方案：基本服务层通过patition key路由库
上图：
作为用户服务基础的用户库、分区库patition key是uid
uid上的查询，用户服务可以直接放在库中
二.非patition key中的单行查询
典型场景：在login_name中询问用户
场景特征：
使用非分区密钥进行咨询
一次只返回一行记录
解决方案1 :基本服务层访问所有库
上图：
用户服务通过login_name首先调查全部库存
结果在用户服务中重新集成，最终返回一条记录
解决方案2:base-service检查映射库，然后通过patition key进行路由
上图：
创建新的映射库并记录login_name与uid之间的映射关系
如果有非patition key查询，请首先在login_name中查询uid
然后用patition key进行路由，最终返回一条记录
解决方案3 :基因法
有关使用“基因法”解决非patition key搜索需求的详细信息，请参阅《分库后，非patition key上访问的多种解决办法》。
三. patition key上的批量查询
典型方案：用户列表uid中的IN查询
场景特征：
用patition key咨询
一次返回多行记录
解决方案1 :基本服务层访问所有库，并将结果集成到基本服务中
解决方案2:base-service分析路由规则并在必要时访问
上图：
基于对路由规则的分析，base-service确定某些数据位于库1中，而某些数据位于库2中
base-service根据需要访问相关库，而不是整个库
基本服务合并结果集并返回列表数据
四.非patition key下哇塞寻呼要求
分库后，夸库分页的查询需求详见《业界难题，夸库分页的四种方案》。
五、其他需求…
写到这里，上面的一、二、三、四、五其实不是重点。 基本服务层可以通过各种奇技淫巧解决数据库水平分割后的数据访问问题。 只是，有以下问题。
基本服务层的复杂性提高了
数据获取效率降低了
随着需要数据库水平划分的基本服务增加，层次结构如下：
基本复杂性扩展到每个基本服务。 所有基本服务都需要关注。
分区密钥路由
映射非分区密钥查询，然后路由
先全部库存再合并
分析后按需路由
引用分页处理
.
这个体系结构图看起来不协调吗？ 如何更高效、更快地获取数据？
中间件的引入是必须的。
这是一个“基于服务端”的数据库中间件体系结构图。
基本服务层像访问数据库一样访问db-proxy并有效地检索数据
所有基础的复杂性都隐藏在db-proxy这一层
这是一个“基于客户端”的数据库中间件体系结构图。
基本服务层通过db-proxy.jar有效地检索数据
所有基础复杂性都隐藏在名为db-proxy.jar的层中
结论：
当数据库被水平划分，基本服务层获取数据库数据过于复杂，造成共同的伤害时，应该对数据库中间件进行抽象，简化数据获取过程，提高数据获取效率，向上游屏蔽低层的复杂性。