我有一个项目架构的问题。

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 561 天前的主题，其中的信息可能已经有所发展或是发生改变。

我们公司的产品使用的 java 微服务（别管用不用得到，上就是了），比如果其中开发的功能点 A,B,C,D,E 。然后有个项目地只想要其中的 A,B 项目，在单独给开发一个 F 功能，但是这个 F 功能我们产品又想要，还想要源码。我们就不能把微服务的直接给出去，只能重新开一个项目来专门来交付，然后又进行重复开发把 F 功能集成到微服务上去。我说的可能有点乱，

就是自研产品和快速交付的项目之间的关系是怎么处理？
如果其中很多相同的功能只能来重复开发嘛？
能不能从微服务的平台剥离功能到项目中去？
如何客户要源码是不是只能单独开项目去做了？

项目

功能

开发

要源码

8 条回复 • 2023-06-06 18:59:35 +08:00

zsc8917zsc

2023-06-06 09:56:40 +08:00

产品线区分 saas 版，部署版～～～部署版看客户要求是否需要完全部署～～

LeegoYih

2023-06-06 09:57:59 +08:00

项目背景是什么？交付是什么形式，SaaS 还是私有化部署？数据需不需要隔离？

nothingistrue

2023-06-06 10:14:28 +08:00

一鱼多人吃，是低成本软件开发特色模式，技术上是无解的。如果是常规技术架构，每个客户 /项目，最少也要当成独立分支来做，一般都是要当成独立产品做的——这本来就是不同的鱼。

litchinn

2023-06-06 10:27:57 +08:00

代码解耦，通过引入依赖的方式选择需要的内容，但是项目杂了维护成本爆炸，工作量并不少，而且有时候你会发现同样是 F 功能到最后也会变得不一样，所以不如摆烂

wu00

2023-06-06 10:53:12 +08:00

理想中的结构：
服务层作为积木，上层任意组合。P1{ABCD}，P2{ABEF}

ABCD...各服务都是独立项目，只提供单纯的业务逻辑以 http/rpc 暴露到上层，服务之间互相依赖的逻辑部分放到上层去聚合。

除了服务层可以复用，"上层"一定是各做各的，不然应付不了一定会出现的变种 P1{AB¹DE}，P2{AB²EF}

sentinelK

2023-06-06 10:58:45 +08:00

问题 1 、2
尽量将功能解耦。这样产品和项目都使用相同的“功能”，可以通过引用类库等方式解决。

问题 3
这是你使用的微服务架构的问题，理论上讲理想的微服务规划，应该是可以快速的通过模块构建符合需求的平台，而不是相反（所有的产品需求都用一个微服务平台承载，那么微服务的意义就少了一大半）

问题 4
是。

xiangyuecn

2023-06-06 11:12:38 +08:00

什么微服务不微服务关系不大，统统面向 ctrl+c ctrl+v 编程，后面要是还来一个新客户再复制一份，问题解决

yufeng0681

2023-06-06 18:59:35 +08:00

公司小，abcdef 打包一起交付。源码也全部给。
始终保证自己就一个版本打天下。
如果有些功能互斥，尽量就从业务上引导多个用户，用一种功能 [没办法引导的就定制分支接口，还是一个版本]

只要甲方不是拿着源码自己去开干，就无所谓。