微服务架构和代码复用是不是本身就是有冲突的？

[RedrumSherlock]

微服务架构里，每个微服务彼此都应该是黑盒，自己内部实现逻辑，业务逻辑不干涉。但是现实里哪有切那么完美的用例？总是会有一些类和方法多个微服务里都会用到，哪怕不是完全一样也是高度类似，在传统设计里肯定要重构复用的。但是微服务里要是分开单独写就相当于冗余代码高维护，抽出来给多个模块共用又破坏了微服务设计理念。是不是微服务设计的时就这种情况就是要牺牲可复用性的？

[CODEWEA]

没有想好为什么用微服务就不要用微服务

[chogath]

架构，框架，设计模式，都是为了解决人的问题。所有的问题都是人的问题。

举个例子，您说的场景，完全可以提炼公共组件实现复用。

[FucUrFrd]

别人说打包成包，让各个微服务 import，一提就被你否了

别人说独立成微服务，也被你否了


有讨论下去的必要吗
看来不是代码问题，是人的问题

[FucUrFrd]

举个例子日志库难道不是各个微服务都要 import 的嘛

打包个 lib 有什么问题

[SmiteChow]

讲依赖，将包的都是技术视角的答案。

微服务本身不是为了解决技术问题来的，所以从技术视角看不是很准确。

微服务本身主要是给部门增加 HC （领导才能往上升），增强系统鲁棒性是 side effect，从成本上看，得益于云计算特别是 k8s 的发展，抛开人力成本不讲（这是目的），效能是上升的。

所以，答案是不冲突，微服务架构不需要复用，需要的是更多而细的服务。

[k9990009]

没啥好办法，抽 lib 或者再抽出一层做服务

[more1sec]

究极解构，每个业务抽象类都做成一个微服务

[useben]

抽象，代理，小中台即可解决

[melkor]

@RedrumSherlock 身份证是一个单独的枚举值？我理解身份证一定关联着用户信息吧，那应该属于 customer 或者 user 这个 domain 才对

[zhiguang]

所有的问题都是制度的问题

[generic]

微服务是一种架构和部署方式，不是一种源代码组织方式。谁规定一个 source tree 只能 build 出一个微服务的？
服务间不要依赖对方的实现细节，和服务间不要共用代码，也是两回事。

[guyeu]

不能更同意#31，那些无脑抽服务的同学们，你们怕是没有经历过处理一个请求要经过几十个服务的恐怖

[kiripeng]

@guyeu 哈哈，曾经经历过经历 7 个的服务

[Variazioni]

公用代码放到依赖里。。单独一个依赖工程。。我们现在就是这么做的。

[mawenjian]

拆分成独立的微服务，公共依赖能不用就不用。

[Team]

可以在微服务的不同部分间复用代码，前提是那个代码具有极高的复用价值，例如，语言的标准库，微服务之间都是共用的。之所以拆成微服务就是从代码层面杜绝两个服务的联系，因为它们之间耦合的坏处已经远远大于好处了。
所以并不冲突矛盾，都是代码可读性和可维护性以及开发效率等等诸多方面之间的权衡。
关键是要搞清楚不同的思路，到底是解决什么样的问题，具体问题具体分析。

[Team]

还有就是，耦合这种说法本来就是不精准的，就是就算在代码级别重复使用了，也有高耦合和低耦合的写法。

[RedrumSherlock]

@generic 我觉得你说的很有道理，我们现在是每个微服务单独一个 springboot application，共用的实体类都丢一个公共模块里其他的 import，这个法子其实和楼里很多人说的一样，但我想着这样每个微服务不还是有公共的业务逻辑了么，就有点困惑

[RedrumSherlock]

@FucUrFrd 大哥我没有去否谁，我们现在也是抽出来 import，我只是接了这个摊子第一次做微服务有点困惑，想问问这个架构的思路对不对

[FucUrFrd]

@RedrumSherlock

还是那个问题，如果新创建 customer id 规则变了，你们各个服务需要相互配合上线日期，风险很大，一个回滚了，其他服务字段就对不上了，


但是 customer 微服务能解决这个问题，一个人加班就解决战斗，不需要全公司加班


就这么简单，

如果你说需求万年不变或者用户数只有一万，那就没必要单独微服务，整这些，公司倒闭了都没整完