关于微服务设计的一个问题

[Aliberter]

公司关于微服务项目的设计中，打算把所有关于数据库的操作都集中到单独的服务中，每一个其他微服务有数据的增删改查都要去调用这个服务获取，我想问这有必要吗，甚至说这是不是已经违背了微服务的设计原则了？我感觉除了带来服务之间耦合性之外，也让数据事务的控制变得很难，增加了网络消耗，甚至也让开发层面变得异常困难与繁琐，想不通为什么要这么搞，感觉毫无优点可言。请大佬们指点一下。

[index90]

怀疑你们公司想搞数据中台。
还有微服务的设计原则是什么？什么原则说只能这样做不能那样做？微服务提出纵向切分服务的可能，但也没有否定横向切分吧。

软件架构符合康威定律，什么样的团队结构，会有什么样的软件架构。

[vtychx]

把数据库操作从业务层中解耦是非常有必要的，将来业务复杂了，或者 DB 数据量上去后，对 DB 的扩容和修改会非常容易，不会导致业务出问题。
但是解耦的方案很多，不一定非要用微服务，用了也没错。我觉得主要看你们公司 cto 擅长什么。

[mawenjian]

一般把增删改查用独立服务实现是因为微服务数量众多，每个服务单独连接数据库会对数据库连接构成压力。贵司把所有数据库 curd 操作放到一个服务里边，明显不是因为这个原因。

根据我的理解，微服务在数据库层面，一般应该是先根据业务功能进行垂直拆分，也就是分库分表，如果数据库连接有压力，再考虑把 curd 操作独立成服务，或者应用数据库代理。

贵司这么搞，感觉像是为了做成一个类似数据库代理的东西，以后分库分表对上层就透明了。但是如果业务层面不先做拆分，一旦 SQL 复杂了些（比如多表联合查询），最开始的愿望未必能实现。

[mawenjian]

这样设计最大的一个问题是，理论上 CURD 服务变动了，对上层所有服务都可能会带来未知的影响，因为你不知道有几个消费者在使用这个服务。CURD 服务只做代码追加还好，一旦涉及代码修改，鬼知道会出什么奇奇怪怪的问题。

[fcten]

数据事务本来就不应该让各个开发自己处理。这个设计从大方向上没啥问题
数据中台了解一下

当然，如果项目本身并不大，可预见的未来也没有扩展的可能性，那就没有必要了

[xsen]

微服务最大的两个优点呢，就是
1. 解耦
包括不限于技术栈、开发、运维、数据库等，就是每个服务这些都是独立的，彼此之间不会相互影响

2. 业务集群动态扩展

而你非要搞个数据库服务；那么，就通过数据库服务把所有服务都耦合到一起
而对于采用微服务框架的，还引入一个数据库服务的系统来说，就是数据库服务是修改最频繁的服务——那么，就会影响到所有的其它服务，给所有服务引入不可预知的问题

一句话，决定这么搞的确实是脑子进水了

当然，真要搞，那就更彻底点——可以参照 TiDB 那样，把所有的 crud 还是在各个服务；做个代理，实现标准的 DB 协议（比如 SQL 等）

[boyhailong]

@fcten 第一次听说 数据中台

[nezhaxiaozi]

这不就是数据库中台吗，所有的连接地址都到这个中间件服务中，然后这个组件就可以对上层微服务的 SQL 操作进行一系列的检查或者分库分表操作，而对于上层微服务其实是无感知的

[janxin]

@boyhailong 你不关注中台吧，前端能力都中台化了了解一下

[boyhailong]

@janxin 游戏后端 表示很落后的说 (/ □ \)

[janxin]

@boyhailong 游戏场景不一样，所以正常啦

[lovedebug]

基于业务场景拆分，不要总是按通用的定律做。 如果你们需要做集中式 DB 管理和缓存刷新，有一个 DB 服务也是没问题的。

[iConnect]

你们老板是想避免成为微盟第二。

通过服务的形式，减少外围直接操作数据库的权限，降低数据库被破坏的风险。

[sdfqwe]

这样的话强依赖了，没必要这么干吧

[wmhx]

面向 PPT 编程.

[gaius]

更新的 rpc 操作还要考虑事务，幂等性等等。这个服务还是所有要操作数据库的地方都需要依赖的，每次更新一个服务可能都要重启这个数据库统一操作服务，除了做统一查询缓存外想不到这样有什么好处。

[konakona]

首先，你的这种架构设计，首先应该是对研发人员无感知的，并将有状态的服务抽离。

上面这段话仔细阅读，品一品。

就拿容器化来说，工程师研发的项目打包成 docker-compose，由 CICD 自动化部署，可以依靠一些打包工具比如 helm 来实现环境变量的初始化和程序部署工作。并且在 helm 里可以获得有状态服务的信息，比如数据库地址、帐号、密码。每个环境单独一份，而工程师全程不需要知道这些。

都是 devops 的东西。

[konakona]

工程师只需要写代码，然后写一份 docker-compose，按照约定 EXPOSE 传统端口，比如前端工程师是 80，后端工程师的是 8080 或者 8000，反正前后分离，2 份 docker-compose file。

然后给 CICD 跑，CICD 里调用 helm 这种部署工具包，helm 根据 yaml 配置去设定环境里的变量，让程序代码自动做出环境切换，再自动的部署到集群中。

这些都是 devops 的事，不需要工程师知道什么。

[hantsy]

数据没有微服务化啊 https://dzone.com/articles/breaking-the-monolithic-database-in-your-microserv

[kinge]

你们这种不算微服务，我工作的大公司，后端微服务架构就是完全的拆分，业务拆分给不同的部门去维护开发，各自的部署各自的数据库集群。各个部门甚至一年不用交流都不影响业务的上线