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

[t298]

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

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

[zsc8917zsc]

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

[LeegoYih]

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

[nothingistrue]

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

[litchinn]

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

[wu00]

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

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

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

[sentinelK]

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

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

问题 4
是。

[xiangyuecn]

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

[yufeng0681]

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

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