微服务数据查询,微服务使用同一数据源数据库连接信息共享

微服务，每个微服务配置一个数据源好还是在微服务中配置多个号好...在我们这边，所有服务使用同一个数据源，数据库连接信息配置到环境变量中，所有微服务统一读取这组环境变量。主服务器更新、插入和删除复制的数据；从服务器负责查询(读写分离，减轻服务器压力)，2.主服务器同时更新从服务器的数据(数据备份)，3.当文件出现在主服务器上时，从服务器可以代替主服务器保证网站的正常运行，并检测主服务器存在的问题。

申请提交微服务获取订单中心发送的开户申请预订单，其中，开户申请预订单包括用户身份信息、用户选择的号码和产品类型，并根据开户申请预订单对应的产品详细数据获取消息，抢占用户选择的号码；开户提交微服务解析消息并进行费用处理，获得开户信息，并将开户信息提交给业务支撑系统；写卡数据查询微服务根据开户信息获取写卡数据，并将写卡数据存储在白卡中；卡数据同步微服务占用用户选择号码的资源，写回开户指令，从而完成用户在业务支撑系统的开户。

当我们的数据库压力主键变大时，我们会尝试增加一些从节点来分担主节点的查询压力。一般来说，我们采用一主多从的结构作为读写分离的基本结构。一般来说，我们有两种常用的方法来实现读分架构:客户端直接分离数据库，由客户端或者我们的微服务直接选择。将阅读选择路由到主图书馆，将查询路由到从主图书馆。

使用数据中间件代理的方法是一个代理层分布数据读写，业务层通过代理实现所有请求。这种方式的好处是业务层不需要知道数据库的存在，但问题是对数据中间件的性能要求高，需要专人进行优化和维护，整体架构复杂。但是我们发现，虽然这两种方法各有利弊。但核心是通过数据写入和查询请求路由来实现的，所以这样会导致题头的问题:主备同步有延迟，所以在延迟时间内查询插入的内容找不到最新的事务。

简单来说，API主导的连接方法可以看作是API设计的分层方法(至少在本文中)。其中，系统API公开了系统的资产数据信息；中间是流程API，与系统API排列组合；顶级体验API公开来自后端数据源的数据，并提供最终用户体验。这种API分层方法与细粒度的SOA模式结合得很好。通常，这两者可以共存，或者细粒度SOA模式演变为基于细粒度SOA的分层API模式。

然而，基于细粒度SOA的分层API模式也有一些类似于细粒度SOA模式的深层问题(这很直观):在细粒度SOA模式执行单个API调用的地方，基于细粒度SOA的分层API模式现在必须通过层执行多个调用。从“网络跳数”的角度来看，这种模式可能是低效的。但是在基于细粒度SOA的分层API模式中，层次结构的存在并不强制每个API跨网络调用。