这是一个创建于 1710 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司关于微服务项目的设计中，打算把所有关于数据库的操作都集中到单独的服务中，每一个其他微服务有数据的增删改查都要去调用这个服务获取，我想问这有必要吗，甚至说这是不是已经违背了微服务的设计原则了？我感觉除了带来服务之间耦合性之外，也让数据事务的控制变得很难，增加了网络消耗，甚至也让开发层面变得异常困难与繁琐，想不通为什么要这么搞，感觉毫无优点可言。请大佬们指点一下。
 |
1
iConnect 2020-03-11 07:28:02 +08:00 via Android
微服务本质上是不合理的结构。打造一个产品没必要把手工作坊全改成工厂，但是大规模制造必须上流水线了，各司其职，专人专事提高效率。所以你说的问题这样看才是合理的。
|
 |
2
puncsky 2020-03-11 07:36:43 +08:00
|
 |
3
Aliberter OP @iConnect 我感觉没有太能说服我，专人专事，按照业务去划分为不同的服务不就是已经专人专事了吗，为什么单独要把数据操作抽出来？它提升效率的点在哪？现实中可能我接触的项目还不够多，我还没遇到过这样设计的，如果只是因为理论的合理性而不去考虑执行效率开发成本我觉得就是在耍流氓，我现在需要的是大佬能说服我，或者是给我理由让我去说服公司的项目设计。
|
|
4
Aliberter OP @puncsky 看了一下这个设计就很正常啊，每个服务去单独的操作 db 就 ok 了，我现在说的是一个比较奇葩的设计场景，相当于在业务层和 db 之间又加了一层，所以我问加这个干啥…
|
 |
5
opengps 2020-03-11 07:49:23 +08:00 via Android
你的想法属于按软件功能组拆分，不是按需求功能组拆分，各有所长。
微服务出发点是将来集群下针对压力大的服务单独扩容节点，实现全局压力均匀，缺点是每个微服务都是个全面的个体 你的出发点更符合小而全的整体打包，比较符合以前的类似于三层架构，但是将来做大之后需要每个团队成员提交时候都得对整个代码库进行获取和编译 |
 |
6
watzds 2020-03-11 08:24:39 +08:00 via Android
你说的是各个服务直接读自己相关的数据 ，还是专门搞了一个读数据的服务
|
|
7
iConnect 2020-03-11 08:28:10 +08:00 via Android
@Aliberter 不清楚你那边是什么业务，具体业务具体分析吧，比如电商类的，以后做秒杀是要考虑到的高并发和限流，如果数据请求很分散，就不容易全局控制。
|
 |
8
magicdu 2020-03-11 08:49:43 +08:00
单独把 Dao 拿出来作为了一个服务？不是分库分表吗？你们怕不是搞“数据中台”吧。
|
 |
9
k9982874 2020-03-11 08:50:50 +08:00 via iPhone
吃饱撑的
|
 |
10
wangxiaoaer 2020-03-11 09:00:41 +08:00
1 不要微服务而微服务
2 “公司关于微服务项目的设计中，打算把所有关于数据库的操作都集中到单独的服务中” 微服务不是你这么微的 |
 |
11
passerbytiny 2020-03-11 09:19:18 +08:00
这是一个很蠢的、拍脑袋的、错误的设计，如果上面的人强行推这种架构，赶紧跑路。
这种架构的优点是：我本质上不是微服务，但我表面上看着像。缺点那是一大堆，单说一点：关于数据库的操作都集中到单独的服务中，就没有数据库级别的事务了，而一旦没了数据库级别的事务，不管是强一致性（要添加 2 阶段提交等分布式事务导致性能大降），还是最终一致性（需要对每个原子 SQL 操作都准备好补偿措施导致开发难度剧增、可用性降低），都很难做到了。 |
 |
12
IMCA1024 2020-03-11 09:21:10 +08:00  1
我看看怎么发 PDF。。。。有两张 PDF 想发上来
|
 |
13
technode 2020-03-11 09:22:40 +08:00
DAOService 是很多新手想做微服务又怕团队搞不下去的一个折中办法 其实没啥鸟用 建议直接不用微服务
|
|
14
IMCA1024 2020-03-11 09:24:01 +08:00
|
 |
15
zr8657 2020-03-11 09:30:47 +08:00
就是说所有服务想要操作数据库都要调用同一个数据库服务吗？就像游乐园入园排队排了 5 排，但是入口一次还是只能入一个人，那 5 排有什么意义呢？
|
 |
16
janxin 2020-03-11 09:36:18 +08:00
可能是个数据中台 23333
|
 |
17
cabing 2020-03-11 09:39:05 +08:00
微服务现在都是公司的标配了。
这是硬核微服务。。 难道是因为你的 boss 偶然看了贝佐斯提出的服务的 6 个原则？ |
 |
18
popesaga 2020-03-11 09:48:35 +08:00
上一家公司的工作，应用沿用了两三年的架构就是这么干的。当时没觉得有多大问题，还觉得展示层做展示层，业务层做业务层，数据操作层做数据操作层挺好。后来说往 DDD 和 serverless 上靠，划分领域后一个领域的所有操作在一个应用，展示层到底层代码都在一起。不过这个架构没整完我已经走了，不清楚最终形态是什么。现在工作又要考虑架构，讨论下发现这个确实有问题。我说下我一开始理解的可能成立的理由哈，抛出引玉让大家批判下。如果对同一份数据的操作散布在不同应用里，那么每次一个数据模型的变更。要么选择所有相关应用都变更，要么根据这次需求的影响范围变更。前者可能造成应用多发布，后者则造成不同应用对同一份数据操作不一致。数据库操作集中在一个应用是一种解法，那么只要变更数据库操作应用和业务应用即可，能做最小发布。新的问题来了，考虑到单纯变更就是可能引起故障的一个风险点，那么更合理地减少变更并且满足业务需求法是怎样？
|
 |
19
a852695 2020-03-11 09:57:26 +08:00 1
说白了就是把 CRUD 给全部统一在一起，感觉这个拆分不是很合理。一是 CRUD 本身就和业务关联很大，微服务是要划清楚边界，这下又把边界给混在一起了。二是还得维护好 CRUD 的接口，这成本恐怕不能接受吧。一般来说是按照业务领域进行划分的。
|
 |
20
dovme 2020-03-11 10:01:46 +08:00
个人觉得微服务里面的每一个服务,应该可以不依赖别的服务而运行,除非个别地方调用了别的服务的接口,但是, 你现在这个如果没有数据库服务就完全无法工作了.
|
 |
21
index90 2020-03-11 10:04:50 +08:00
怀疑你们公司想搞数据中台。
还有微服务的设计原则是什么？什么原则说只能这样做不能那样做？微服务提出纵向切分服务的可能，但也没有否定横向切分吧。 软件架构符合康威定律，什么样的团队结构，会有什么样的软件架构。 |
 |
22
vtychx 2020-03-11 10:11:33 +08:00
把数据库操作从业务层中解耦是非常有必要的，将来业务复杂了，或者 DB 数据量上去后，对 DB 的扩容和修改会非常容易，不会导致业务出问题。
但是解耦的方案很多，不一定非要用微服务，用了也没错。我觉得主要看你们公司 cto 擅长什么。 |
 |
23
mawenjian 2020-03-11 10:34:02 +08:00 via Android
一般把增删改查用独立服务实现是因为微服务数量众多，每个服务单独连接数据库会对数据库连接构成压力。贵司把所有数据库 curd 操作放到一个服务里边，明显不是因为这个原因。
根据我的理解，微服务在数据库层面，一般应该是先根据业务功能进行垂直拆分，也就是分库分表，如果数据库连接有压力，再考虑把 curd 操作独立成服务，或者应用数据库代理。 贵司这么搞，感觉像是为了做成一个类似数据库代理的东西，以后分库分表对上层就透明了。但是如果业务层面不先做拆分，一旦 SQL 复杂了些（比如多表联合查询），最开始的愿望未必能实现。 |
|
24
mawenjian 2020-03-11 10:42:18 +08:00 via Android
这样设计最大的一个问题是，理论上 CURD 服务变动了，对上层所有服务都可能会带来未知的影响，因为你不知道有几个消费者在使用这个服务。CURD 服务只做代码追加还好，一旦涉及代码修改，鬼知道会出什么奇奇怪怪的问题。
|
 |
25
fcten 2020-03-11 10:55:09 +08:00
数据事务本来就不应该让各个开发自己处理。这个设计从大方向上没啥问题
数据中台了解一下 当然，如果项目本身并不大，可预见的未来也没有扩展的可能性，那就没有必要了 |
 |
26
xsen 2020-03-11 11:04:26 +08:00
微服务最大的两个优点呢，就是
1. 解耦 包括不限于技术栈、开发、运维、数据库等，就是每个服务这些都是独立的，彼此之间不会相互影响 2. 业务集群动态扩展 而你非要搞个数据库服务；那么，就通过数据库服务把所有服务都耦合到一起 而对于采用微服务框架的，还引入一个数据库服务的系统来说，就是数据库服务是修改最频繁的服务——那么，就会影响到所有的其它服务，给所有服务引入不可预知的问题 一句话，决定这么搞的确实是脑子进水了 当然，真要搞，那就更彻底点——可以参照 TiDB 那样，把所有的 crud 还是在各个服务；做个代理，实现标准的 DB 协议（比如 SQL 等） |
 |
27
boyhailong 2020-03-11 11:18:38 +08:00
@fcten 第一次听说 数据中台
|
 |
28
nezhaxiaozi 2020-03-11 11:20:44 +08:00
这不就是数据库中台吗，所有的连接地址都到这个中间件服务中，然后这个组件就可以对上层微服务的 SQL 操作进行一系列的检查或者分库分表操作，而对于上层微服务其实是无感知的
|
|
29
janxin 2020-03-11 11:23:20 +08:00
@boyhailong 你不关注中台吧，前端能力都中台化了了解一下
|
|
30
boyhailong 2020-03-11 11:31:37 +08:00
@janxin 游戏后端 表示很落后的说 (/ □ \)
|
|
31
janxin 2020-03-11 11:34:09 +08:00
@boyhailong 游戏场景不一样，所以正常啦
|
 |
32
lovedebug 2020-03-11 11:36:56 +08:00
基于业务场景拆分，不要总是按通用的定律做。 如果你们需要做集中式 DB 管理和缓存刷新，有一个 DB 服务也是没问题的。
|
|
33
iConnect 2020-03-11 11:49:30 +08:00 via Android
你们老板是想避免成为微盟第二。
通过服务的形式，减少外围直接操作数据库的权限，降低数据库被破坏的风险。 |
 |
34
sdfqwe 2020-03-11 11:53:29 +08:00
这样的话强依赖了，没必要这么干吧
|
 |
35
wmhx 2020-03-11 11:58:37 +08:00
面向 PPT 编程.
|
 |
36
gaius 2020-03-11 12:14:06 +08:00 via Android
更新的 rpc 操作还要考虑事务，幂等性等等。这个服务还是所有要操作数据库的地方都需要依赖的，每次更新一个服务可能都要重启这个数据库统一操作服务，除了做统一查询缓存外想不到这样有什么好处。
|
 |
37
konakona 2020-03-11 12:52:06 +08:00
首先，你的这种架构设计，首先应该是对研发人员无感知的，并将有状态的服务抽离。
上面这段话仔细阅读，品一品。 就拿容器化来说，工程师研发的项目打包成 docker-compose，由 CICD 自动化部署，可以依靠一些打包工具比如 helm 来实现环境变量的初始化和程序部署工作。并且在 helm 里可以获得有状态服务的信息，比如数据库地址、帐号、密码。每个环境单独一份，而工程师全程不需要知道这些。 都是 devops 的东西。 |
|
38
konakona 2020-03-11 12:54:09 +08:00
工程师只需要写代码，然后写一份 docker-compose，按照约定 EXPOSE 传统端口，比如前端工程师是 80，后端工程师的是 8080 或者 8000，反正前后分离，2 份 docker-compose file。
然后给 CICD 跑，CICD 里调用 helm 这种部署工具包，helm 根据 yaml 配置去设定环境里的变量，让程序代码自动做出环境切换，再自动的部署到集群中。 这些都是 devops 的事，不需要工程师知道什么。 |
 |
39
hantsy 2020-03-11 12:54:52 +08:00
|
 |
40
kinge 2020-03-11 13:27:44 +08:00
你们这种不算微服务，我工作的大公司，后端微服务架构就是完全的拆分，业务拆分给不同的部门去维护开发，各自的部署各自的数据库集群。各个部门甚至一年不用交流都不影响业务的上线
|
 |
41
gemini767 2020-03-11 14:42:54 +08:00
只能说🦐**设计。。微服务解耦业务，不是解耦代码设计
|
 |
42
neilq 2020-03-11 15:19:24 +08:00
很巧，之前我在一家公司就是搞得你说的这种模式，主要有两个几个原因：
1. 人多，项目大，合作开发，我们大概有 15 个人搞一个系统的 crud 后端，为了抢时间。但是这么多人搞同一个项目，哪怕你代码分支管理的再好，也很有各种合并啊，冲突啊，而且人员水平层次不齐，很难管好所有人都按照标准执行，浪费很多精力，干脆分开来。我们大概分了什么通用服务，人事服务，工作流服务，产品服务，订单服务等等，3 人一组，水平差的开发简单的服务，水平高一点的开发难一点的服务。开发时先定接口标准，这样有业务耦合时不用等其他人。 2. 各个服务请求量不等，像人事服务这种基本没什么量，用差一点的服务器，像产品服务请求量就相对比较大，用好一点配置的服务器，遇到性能优化什么的，代码、架构改起来不会影响其他服务，部署万一出问题也不会影响其他服务，万一宕机，这个服务不能用了，但人事那边业务也会正常展开。 3. 为了试一试新技术新架构，体验体验，就这么简单。 我的理解是，不要为了用微服务而去用微服务，而是因为单体服务对这个项目，在当前这个时间点，有这样那样问题，才要去考虑用微服务。如果你很难说出现在用单体应用有什么问题，那我不推荐用微服务。 |
 |
43
wingyiu 2020-03-11 15:19:37 +08:00
看看 DDD 啊
|
|
44
neilq 2020-03-11 15:28:38 +08:00 1
有同学提到 DDD，其实微服务应该就是领域模型在架构层次的拆分，我看现在网上的博客，很多都是在同一个项目里搞代码层级的划分。甚至有些人在某一个单独的微服务里面还在搞 ddd 划分，我觉得没有意义
|
 |
45
purensong 2020-03-11 15:49:35 +08:00
说下 我之前公司的微服务架构吧
就是数据中台。 数据中台有很多服务，用户权限， 供应链，CMS 等等 然后是各种网关，主要分两种，一种 API 网关，一种 filter 网关，用 groovy 开发的，上线后可以在控台修改脚本立即生效。 利用 spring cloud 的 kv 存储去上报下载接口的权限配置信息。 微服务框架是 dubbo sc 混用，后面多数迁移到了 sc 上，代码用 feign 调用 。 对于开发者来说，每个微服务使用都是根据模块去划分。将一个大中台分割成多个模块，我没遇到数据库中台，各自项目里数据库还是独立的，如果用到别的数据库数据基本都有微服务去包装。 顺便问大家，因为微服务调用就跟本地方法调用一样，但是微服务变更上线了新版本，该怎么友好的通知使用者呢。我遇到有的方法 deprecated 但是没注解，导致我一直用错，带来的影响是数据有差异，这不坑爹嘛 |
 |
46
uleh 2020-03-11 16:14:19 +08:00
还是要看你们实际的环境。
标准的“微服务”只是一种实践方式。 实践是没有对错，只有“适合”和“不适合”。 如果你们按照单体模式进行开发 /部署 /运维，只是通过微服务获取了一些团队解耦、数据解耦的话，这样做也未尝不可…… 不过全部依赖一个“数据操作微服务”，容易造成系统整体单点故障和性能瓶颈。 |
 |
47
lolizeppelin 2020-03-11 16:48:17 +08:00 3
不要纠结微服务的名词, 这里提供一个具体项目的实现给你参考,这个项目就做了类似你说的事
openstack 的 nova, nova 之前也是服务自写数据库,后来拆分出了一个叫 conductor 的服务,后续版本各个服务都通过 conductor 来处理数据。 虽然我没参加过大型的项目开发,但是 openstack 就反馈出了大型项目开发会遇到的问题以及产生的解决办法 这个 conductor 解决的问题就是 大型项目中会产生很多版本迭代,对应的数据表结构会有各种变化 在微服务时代产生的更大的问题是, 大家不能一起升级！！还要一起跑！ 举两个例子： 例 1： 比如说服务 A 和服务 B 都要写同一个表, 服务 A 有需求在表上变更的字段 最好的解决办法当然是服务 A、服务 B 同步表结构,但是因为各种问题 B 目前不能更新,这下咋办？ 例 2： 有 1000 台服务器在跑服务 A,如果服务 A 升级变更表结构,怎么做到无缝升级？ 为了解决问题, openstack 弄了一个叫 versioned objects 的玩意来解决上面的问题 通常的 orm 都是 model 映射到数据库的表,对 model 对象操作直接反馈到表上 而 versioned object 就是 model 上再加了一层（作用并不是简单的类似 java 的那个叫 dao 层的东西） 代码不在操作 model 层转而操作 versioned object 对象 versioned object 对象的操作落地操作就是将 versioned object 对象序列化后,rpc 到数据落地服务,也就是上面说的 conductor, conductor 还原 versioned object 对象再进行 model 的对应操作 versioned object 的主要属性就是 model 字段和对应值,以及 versioned object 的版本号, conductor 会根据 versioned object 版本的不同做对应兼容操作以便正确映射到 model 上, 对不兼容的版本报告错误 这样的结构就解决了上面的问题,兼容了不同版本的服务,也让升级变得平滑 微服务很多做法都是解决大型项目版本迭代而产生的,不一定是为了解决性能问题,从性能上找原因方向就错了 |
|
48
lolizeppelin 2020-03-11 16:54:02 +08:00
顺便,versioned object 的 rpc 是可选项,一般情况 select 操作是不启用 rpc 也就是不走 conductor 的
并不是有了 conductor,就要所有数据库操作都走 conductor 的,要酌情考虑 |
 |
49
tom 2020-03-11 17:09:00 +08:00
我想问一下，微服务是划分成多个工程吗？那那些工具类、组件怎么复用呢？
|
 |
50
v2Geeker 2020-03-11 17:41:33 +08:00
你们公司这样的原因我不知道，单从局外人来看这种设计，感觉好奇葩，没用。这样玩风险很大，会影响整体服务的稳定性！
|
 |
52
wengang285 2020-03-11 21:37:14 +08:00
如果所有的服务都访问数据库，有以下几个问题：
1、日志，流水不能集中管理，当然你可以用远程日志解决； 2、访问权限问题，比如 A 服务需要扩容，那么扩容的机器都要申请访问 db 的权限，如果通过集中的数据操作服务 B，则无需申请权限，在线扩容的时候，很容易忽略这一步； 3、增加的那点网络消耗其实无关紧要； |
|
53
wengang285 2020-03-11 21:38:30 +08:00
@uleh 数据操作服务肯定需要多机部署啊，怎么会成为单点呢？
|
 |
54
Xbluer 2020-03-11 22:29:11 +08:00
@wengang285 #52 #53 我看你的意思似乎是整个系统就一套数据库系统。微服务中推荐的设计方式是每个服务有独自的数据库系统。所以不会存在你提出的第二个问题。A 服务要扩容，扩自己的数据库服务器就好了。
如果数据库访问都集中到了一个专门的 DaoService 里面，会被所有其他服务依赖，这就存在单点问题。 |
 |
55
psirnull 2020-03-12 01:41:22 +08:00
只要那个 db 服务是 HA 高可靠的， 你管他让你联到哪干什么。 没必要浪费那么多脑细胞。
|
|
56
wengang285 2020-03-12 09:36:09 +08:00
@Xbluer 理论是工程是两回事，就像数据库的范式，外键这种东西，在工程领域几乎没人用，至少我见到的微服务系统，没有说每个独立的服务，都有一个自己的 db，而且，即使一个服务，被其他服务依赖，也不能表示这个服务就是单点，你可以通过多机热备来解决这个问题，极端点的例子，所有的服务都依赖接入层，那接入层也存在单点问题吗？
|
 |
57
fuxiuyin 2020-03-12 09:47:10 +08:00
我的理解是，这就跟设计电路板的时候，是按照升压模块、显示模块等划分还是按照所有电阻放一块、所有电容放另一块等这样划分的问题一样。
|
 |
58
tairan2006 2020-03-12 11:22:00 +08:00 via Android
大哥，你这么设计，数据库还是瓶颈啊
|
 |
59
TingHaiJamiE 2020-03-12 11:40:34 +08:00
@tairan2006 这么设计不光数据库瓶颈了，这个操作数据库的服务本身也成了潜在的瓶颈。
|
 |
60
mreasonyang 2020-03-12 11:45:31 +08:00 via iPhone
把数据库操作抽象为服务已经是比较高阶的领域实践了，本质是不同领域在存储层也需要做到隔离，如果不同上下文需要操作其他上下文的数据则需要通过服务间调用。这样的好处就是各个领域切实被隔离开了，各限界上下文间只关心其他上下文提供的接口不关心存储方式，存储的逻辑也不再需要共享，在团队人员进行拆分时也可以彻底解耦，而在你的 DB 数据量巨大时也方便了你分库分表。坏处也显而易见，如果你的项目不够复杂或者领域的划分不够稳定，那性能、维护的开销会大大增加。所以这个操作本身没问题，主要还是要看你们的使用场景是否合理。
|
 |
61
sampeng 2020-03-12 12:53:39 +08:00 via iPhone
100 人以下别玩微服务。1000 万级访问量别玩微服务。年盈利亿以下别玩微服务
|
 |
62
no1xsyzy 2020-03-12 15:18:17 +08:00
@TingHaiJamiE 本身成为瓶颈太少见了，服务本来就可以伸缩…… 不能的话那根本就不是微服务，只是进行分离的一大块。就好像说，我不会称竞泳为比基尼。
|
|
63
no1xsyzy 2020-03-12 15:25:26 +08:00
这样的做法还想要符合微服务，有一种办法：多版本数据服务共存。A 组件依赖数据服务 1.0，B 组件依赖数据服务 1.1
最终都读同一个数据库，并且相互不影响。某天 B 组件想升 2.0 也就升了，仍然不需要考虑 A 是否能兼容 2.0。 |
 |
64
xmsz 2021-08-17 15:57:10 +08:00
不知道是你们公司架构的问题还是你理解的问题（因为初期的表现确实就是个数据库增删改查的接口封装）
一般架构思想其实很简单，就是 原来都是单体应用，维护麻烦，崩得也很彻底 维护麻烦怎么办？拆应用呗，1 个单体应用拆成 5 个业务应用，每个业务应用还可以不同人维护，这样不就解决了。 --------------- 我们知道了用拆可以解决问题，那理论上拆得越多问题解决越彻底，当然这肯定有副作用（需要自己权衡） -------------- 而你遇到的问题其实在于怎么拆？ 如果仅仅只是把数据库的读写拆出来，那这个肯定是很无语的，因为根本没有解决问题 |
Select Language