这是一个创建于 569 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们公司的产品使用的 java 微服务（别管用不用得到，上就是了），比如果其中开发的功能点 A,B,C,D,E 。然后有个项目地只想要其中的 A,B 项目，在单独给开发一个 F 功能，但是这个 F 功能我们产品又想要，还想要源码。我们就不能把微服务的直接给出去，只能重新开一个项目来专门来交付，然后又进行重复开发把 F 功能集成到微服务上去。我说的可能有点乱，
- 就是自研产品和快速交付的项目之间的关系是怎么处理？
- 如果其中很多相同的功能只能来重复开发嘛？
- 能不能从微服务的平台剥离功能到项目中去？
- 如何客户要源码是不是只能单独开项目去做了？
 |
1
zsc8917zsc 2023-06-06 09:56:40 +08:00
产品线区分 saas 版，部署版～～～部署版看客户要求是否需要完全部署～～
|
 |
2
LeegoYih 2023-06-06 09:57:59 +08:00
项目背景是什么？交付是什么形式，SaaS 还是私有化部署？数据需不需要隔离？
|
 |
3
nothingistrue 2023-06-06 10:14:28 +08:00
一鱼多人吃，是低成本软件开发特色模式，技术上是无解的。如果是常规技术架构，每个客户 /项目，最少也要当成独立分支来做，一般都是要当成独立产品做的——这本来就是不同的鱼。
|
 |
4
litchinn 2023-06-06 10:27:57 +08:00
代码解耦，通过引入依赖的方式选择需要的内容，但是项目杂了维护成本爆炸，工作量并不少，而且有时候你会发现同样是 F 功能到最后也会变得不一样，所以不如摆烂
|
 |
5
wu00 2023-06-06 10:53:12 +08:00
理想中的结构：
服务层作为积木，上层任意组合。P1{ABCD}，P2{ABEF} ABCD...各服务都是独立项目，只提供单纯的业务逻辑以 http/rpc 暴露到上层，服务之间互相依赖的逻辑部分放到上层去聚合。 除了服务层可以复用，"上层"一定是各做各的，不然应付不了一定会出现的变种 P1{AB¹DE}，P2{AB²EF} |
 |
6
sentinelK 2023-06-06 10:58:45 +08:00
问题 1 、2
尽量将功能解耦。这样产品和项目都使用相同的“功能”，可以通过引用类库等方式解决。 问题 3 这是你使用的微服务架构的问题，理论上讲理想的微服务规划，应该是可以快速的通过模块构建符合需求的平台，而不是相反（所有的产品需求都用一个微服务平台承载，那么微服务的意义就少了一大半） 问题 4 是。 |
 |
7
xiangyuecn 2023-06-06 11:12:38 +08:00
什么微服务不微服务 关系不大，统统面向 ctrl+c ctrl+v 编程，后面要是还来一个新客户 再复制一份，问题解决
|
 |
8
yufeng0681 2023-06-06 18:59:35 +08:00
公司小，abcdef 打包一起交付。源码也全部给。
始终保证自己就一个版本打天下。 如果有些功能互斥，尽量就从业务上引导多个用户，用一种功能 [没办法引导的就定制分支接口，还是一个版本] 只要甲方不是拿着源码自己去开干，就无所谓。 |
Select Language