V2EX = way to explore V2EX 是一个关于分享和探索的地方
Sign Up Now For Existing Member Sign In
This topic created in 1817 days ago, the information mentioned may be changed or developed.
背景： A,B 部署环境独立，版本管理是 SVN 。
我们现在有一套 SpringCloud 开发的系统 A，里面有大概有 10 来个微服务。
现在要新开一套系统 B，能复用 A 的 5 个微服务，要复制 A 的 5 个微服务形成一个新系统，再基于这个开发新的业务系统。
这个 5 个微服务包含基础支撑服务，那么这些通用的微服务如何同步更新呢？
我现在能想到的就是：A 的 5 个微服务形成主干，然后每次有新的系统都从 A 分支出来，每次维护完 A，其他分支都从 A 更新，这样所有子系统都最新了。
请问大家有什么好的办法吗？
 | 1 sujin190 May 8, 2021 系统 A 里 10 个微服务是个啥逻辑。。你是不是对微服务有啥误解？既然是微服务当然必须是独立项目，独立数据源，独立配置，独立部署的啊，所以复用本来就没啥问题啊，你都放到一个项目里了还叫啥微服务 |
 | 2 18500592934 May 8, 2021 这个是代码复用还是服务复用？？？ “我现在能想到的就是：A 的 5 个微服务形成主干，然后每次有新的系统都从 A 分支出来，每次维护完 A，其他分支都从 A 更新，这样所有子系统都最新了。” 这种情况下测试计划该怎么安排啊？ 坐等大佬指导，帮顶了！！！ |
 | 3 w292614191 OP @sujin190 #1 @18500592934 #2 创建的是一个聚合工程，有父级 POM 的依赖，所以每次在 jenkins 部署都在 update 整个项目。 我可能有哪里理解错误了，我感觉这样是不对的。 |
 | 4 buliugu May 8, 2021  1 不应该建聚合工程，而是一个微服务一个 repo，我司亲身实践 |
 | 5 limuyan44 May 8, 2021 有没有想过，你们这也能叫微服务吗，不是用了 cloud 就是的，微服务根本不会存在这个问题 ，这 5 个服务 ab 都可以调用而不是塞在 ab 里面。 |
| 6 w292614191 OP @limuyan44 #5 是的，现在想确实不是正确的方向。 |
| 7 w292614191 OP @buliugu #4 你好，能详细的说说吗？ |
 | 8 yule111222 May 8, 2021 需要复用的 5 个微服务需要拆分基础服务（领域服务）和应用服务，有兴趣可以学学 DDD 领域驱动设计 |
| 9 buliugu May 8, 2021 微服务根据领域拆分，一个微服务一个 repo，服务间通过 feign 通信（也可以用其他的），通用依赖抽出来发布到 maven 私库 |
 | 10 zhazi May 8, 2021 微服务本来也不是为了处理复用问题的 Highly maintainable and testable Loosely coupled Independently deployable Organized around business capabilities Owned by a small team |
| 11 w292614191 OP @buliugu #9 大概就是每个项目都是独立维护，发布的时候才挑选需要的微服务发布到一起吗？ 那么是怎么处理配置文件的呢？比如 A,B,C 三套环境下数据源、注册中心、redis 链接、等等相关配置。 如果通过 spring.profiles.active 来配置，这样配置文件应该会很拥挤吧？ 另外，能加你微信、QQ 之类的交流下吗？ |
 | 12 wqhui May 8, 2021 每一个微服务都是一个独立的项目，独立部署的，为啥还会分属于哪个系统，基础服务是跟 MQ 一样的东西，完全可以多个系统用同一个。个人认为不同的系统只是负责实现业务的服务和流程不同，对于基础的服务跟设施，如果能保证高可用以及数据互不影响的时候可以共用，就像多个项目也是用着同一个 gitlab |
| 13 w292614191 OP @wqhui #12 那请问你是怎么处理多环境部署问题的呢？比如有十套不同的环境，是如何处理呢？ |
| 14 buliugu May 8, 2021 @w292614191 所有配置都走配置中心啊，例如 Apollo 、nacos |
 | 15 chogath May 8, 2021 1 建议阅读《走出微服务误区：避免从单体到分布式单体》 |
 | 16 tairan2006 May 8, 2021 您这不叫微服务，建议还是玩儿单体吧 |
 | 17 aragakiyuii May 8, 2021 via iPhone 就算聚合在一起那也可以打包部署不同 module 下的服务吧 |
 | 18 passerbytiny May 8, 2021 via Android 第一，你在玩火。如果你要复用服务，那么这服务就是独立的，即不属于 A 也不属于 B 。你要么复制然后当成不相干的服务独立开发，要么把共用服务提升到与 A 、B 同级甚至更高的级别。 第二，（针对楼上）微服务必定独立部署，但是不是必须独立开发。假如（当前以及 1-2 年的短期内）只有一个系统，那么它的多个微服务是可以放在一个项目中的。因为这时候微服务本质上只是超高度解耦合的模块，还不是独立子系统。 |
| 19 wqhui May 8, 2021 @w292614191 不是很理解为什么会有这么多套环境，你的环境是指生产环境、测试环境、开发环境这些？如果你是指生产环境但多套业务系统复用服务导致这些基础服务要弄多个环境配置的话，我不是很认同，个人认为这些基础服务的数据源是独立于业务系统的，尽量避免业务变更影响这些系统，可以把它看作是一个公用的平台，比如说支付宝，它不会因为有其他商户的接入就需要多部署一套不同环境的支付宝系统啊，只是有些商户信息需要加上去，不同业务系统来源的数据可以通过某些标识做区分 |
 | 20 Newyorkcity May 8, 2021 @chogath 谷歌了一下发现这东西已经被一大抄了 能给下原作者的原文链接吗 |
 | 21 xuanbg May 8, 2021 一般来说，不管多少服务都在一个环境里面。搞成多套的，不算微服务，而且也很别扭。 |
 | 22 zoharSoul May 8, 2021 微服务不是为了这么搞的 |
Select Language