很多朋友经常问我以下问题。
58到家了你在用数据库中间件吗
你在使用什么样的数据库中间件，自研还是第三方？
它是如何实现的，是基于客户端的中间件还是基于服务端的中间件
使用中间件后，如何解决join/子查询/集函数/事务等问题
.
你也有同样的疑问吗？
但是，几乎没有“为什么要部署数据库中间件”的问题。 “架构师之路”的文章构想，以解决“为什么”为优先，通过最近撰写网络分层结构系列文章来谈这个核心问题。
为什么要部署数据库中间件
经过连续分层体系结构演进、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水平切分的base-service越来越多以后，此时分层架构会变成下面这个样子：
底层的复杂性会扩散到各个base-service，所有的base-service都要关注：
patition key路由
非patition key查询，先mapping，再路由
先全库，再合并
先分析，再按需路由
夸库分页处理
…
这个架构图是不是看上去很别扭？如何让数据的获取更加高效快捷呢？
数据库中间件的引入，势在必行。
这是“基于服务端”的数据库中间件架构图：
base-service层，就像访问db一样，访问db-proxy，高效获取数据
所有底层的复杂性，都屏蔽在db-proxy这一层
这是“基于客户端”的数据库中间件架构图：
base-service层，通过db-proxy.jar，高效获取数据
所有底层的复杂性，都屏蔽在db-proxy.jar这一层
结论：
当数据库水平切分，base-service层获取db数据过于复杂，成为通用痛点的时候，就应该抽象出数据库中间件，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性。
任何脱离业务的架构设计，都是耍流氓。
“为什么”比“怎么样”更重要。
阅读前序文章，“分层架构设计”的背景与来龙去脉更加清晰：
若有收获，随手帮转哟。