写在前面
你有没有遇到过，修改db地址需要同时修改上有多个服务的配置？者某个db不可用了导致上有多个服务不可用？
这是架构耦合问题，多个服务之间相互依赖，当某个服务不可用或者做出修改，需要上游服务同时做出修改。这就是你的问题，导致我需要修改（其实我不需要关心），明细不合理
解决方案
架构耦合可以用反向依赖解决
case1:上游服务B、C、D依赖下游db
方案一：代理服务
这种情况下，可以使用代理服务来转发db流量。也就是B、C、D服务链接的ip是db的代理服务，这个代理服务仅做流量转发，其他都不做。
当db因不可用而临时替换成备用服务或者db变更ip，仅仅需要修改代理服务的配置，B、C、D服务无感知。
方案二：服务化
将db服务化，B、C、D服务使用服务发现来调用服务后的db，这样db的ip变化对上游不会在影响。
case2: 公共库耦合
假如A、B、C服务都依赖某个公共库common，当A在common中做修改的时候，会影响B、C服务。
这种没有比较好的办法解决，只能是做好业务判断，跟业务无关的操作或者所有服务都会用到的业务才放到common中，某一个服务的业务尽量只放在自己服务中。如果是新的、跟业务无关的操作、其他服务将来可能会用到的，则需要在common中新加接口，而不应该修改老接口。
总结
一、对于db一般不会通过服务化来解决上下游依赖，因为没有必要将链路增加一个不可控的节点，还得加一个服务，对db封装，写大量增删改查但是没有具体业务逻辑的代码（遇到过这样的公司）。db一般是通过代理ip来解决上下游依赖问题。可以封装成一个公共包，包中还可以增加探活机制防止db不可用（上家公司就是这样用的）。
二、公共库问题，这个没啥好说的，一般都是这样用，关键是要区分清楚公共逻辑和特殊逻辑。
