三十多个服务多数都是 crud,一般每个服务的实体不会超过三个,实体之间相对独立。参与开发的人也很多,不仅重复劳动比较大,各个服务内的代码统一也是个大问题。
现在在考虑:
你们在实践中有什么好的方案吗?
1
dbskcnc 2020-04-17 17:30:45 +08:00
protobuf 定义表,grpc 直接模块生成
|
2
xcstream 2020-04-17 17:32:30 +08:00
自定义 dsl 代码生成代码
|
3
vevlins OP 我再提供一个思路,可以利用元编程组装 sql,不过有弊端。
|
4
1490213 2020-04-17 17:56:42 +08:00 via Android
有较多人力,可以考虑低代码方式,使用 DSL,甚至是可视化网页加部分自定义代码的方式。
有少量人力,进一步封装一些框架代码。 |
5
xizismile 2020-04-17 21:31:04 +08:00 via Android
每个服务三个实体,不用拆这么细吧。。
|
6
hooopo 2020-04-17 21:35:44 +08:00 via Android 1
在做一个根据 db 结构自动生成 graphql 接口的服务
|
7
Yuicon 2020-04-17 22:00:36 +08:00
你这是什么鬼微服务
|
10
oneisall8955 2020-04-17 22:09:08 +08:00 via Android
一个服务 3 张表左右,我去,感觉太神奇了。按业务模块划分一个业务三张表左右,这也太细了
|
11
passerbytiny 2020-04-17 22:15:00 +08:00
我注意到你说了“相对独立”,这样只有 crud 的话,大概现在还好,不出两个月就会出现大量数据不同步问题。
而如果完全独立,又都是重复工作的话,一百多个实体完全可以放到一个微服务中。 |
12
dingyaguang117 2020-04-18 00:50:31 +08:00
学习 django 制作脚手架框架
|
13
swulling 2020-04-18 01:04:45 +08:00 via iPhone 2
相信我,把三十多个微服务改成一个或数个大服务,才是正道。
过度微服务就是天坑 |
14
xuanbg 2020-04-18 04:04:39 +08:00 1
服务拆细本身没有问题,只要服务能够独立,不过度依赖其他服务就行。数据库我的建议是按领域拆分,不一定要一个服务一个库,可以多个相同领域的服务使用同一个库。
为什么同一个领域还要拆分服务,我的经验是为了平衡稳定性和灵活性。基本上是领域服务和管理服务拆开,领域服务负责稳定,发布后基本不动,管理服务负责灵活,可以随时迭代。而且这两个服务本来就是同一个业务,用的是相同的数据,你数据库怎么能不一样呢。 搞微服务不能教条主义,要按业务的实际需求来。 |
15
xuanbg 2020-04-18 04:07:54 +08:00
楼主这种情况我们开发过程中也遇到很多,这其实是一个代码规范的问题,如果像我们这种代码都是套同一个模板的话。复制粘贴改一改就是一个新服务了呀……
|
16
yangxin0 2020-04-18 06:56:20 +08:00 via iPhone
服务越多状态越多出错的概率越大。而且你搞为服务可以但是别拆成几十个 repo 啊。放在一个 repo 里面不就好了。
|
18
swulling 2020-04-18 08:16:11 +08:00 via iPad
|
19
vevlins OP 我对微服务的理解确实不深。解释下现状由来:
1. 我们是负责广告投放的,服务都是管理端使用的服务,有很多纯粹是小工具性质,比如管理预览白名单\媒体操作服务。 2. 开发的成员不专业,我们是前端组管理了 30+的 rpc 服务,对于服务拆分的思考可能不够,也有服务过大过于混乱的担心。 3. 版本迭代非常频繁且存在很严重的并行,因为我们是开发管理端不是对外服务,基本上是有需求就做,做完每周两个窗口发布。当然这跟管理制度有关,但我也没法解决。如果把多个功能放在一个服务,测试环境占用\git 管理冲突都很麻烦(巅峰时期一个服务有三四个需求同时开发和测试),当然这也是技术上可以解决的,但是从人员现状来看,很难做。 大家在实践中对于微服务如何理解呢?一般有几个实体?如果不存在关联的实体(比如上面提到的预览服务和媒体操作服务)也会因为业务靠近放在一个服务内吗? |
20
ihciah 2020-04-18 12:53:32 +08:00 via iPad 1
faas ?
|
23
swulling 2020-04-18 21:57:23 +08:00 via iPhone
@vevlins
如果单体服务划分好模块,需求都在各个模块内部,也不会有什么冲突,反而是对公共依赖的修改可以更容易的发现对其他代码的影响。 单体服务也好,微服务也好,其实后面都是同样的设计方法。只不过微服务更灵活,难度也更大而已 |
24
WispZhan 2020-04-19 09:21:48 +08:00
典型的反模式。
30+个 Service,每个 Service 就 3 个 Entity,这哪里有什么业务内聚了。 合并,@swulling 的说法很对。 μ 的架构演进,(在没有经验的情况下)合理的情况应该是从一个单体架构开始的。 因为在单体架构是你的业务在内部非常清晰,逻辑完整,内聚程度也相对较高。 |
25
artandlol 2020-04-19 15:18:28 +08:00 via Android
告别码农
|