这是一个创建于 1700 天前的主题，其中的信息可能已经有所发展或是发生改变。
三十多个服务多数都是 crud，一般每个服务的实体不会超过三个，实体之间相对独立。参与开发的人也很多，不仅重复劳动比较大，各个服务内的代码统一也是个大问题。
现在在考虑：
- vscode 代码片段
- 根据 rpc 定义和 sql ddl 更深一点的代码自动生成
你们在实践中有什么好的方案吗？
 |
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
告别码农
|
Select Language