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

[RedrumSherlock]

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

[FucUrFrd]

外部包依赖呀，Linux 内核也这样干，跟微服务有什么关系？难道你自己写高性能日志库，自己写高并发网络库？

[ifconfig]

git sub modules?

[FucUrFrd]

@ifconfig 你这个不建议，python pip, Ja*a maven, go mod

[togou]

公共服务 与 公共工具 这不一样

[RedrumSherlock]

@FucUrFrd 不是说那些 util，是指业务逻辑啊。只是个比方，假设微服务做的 ERP 系统里，一个管订单的和一个管记账的，可能都会用到 customer 这个类或者相关的逻辑方法？

[snappyone]

@RedrumSherlock customer 不就应该是一个独立 domain 做成 service 吗，别的服务调用他不就复用了

[maemual]

@RedrumSherlock #5 那么也许 customer 应该抽离出一个服务

[FucUrFrd]

@RedrumSherlock 客户当然是一个服务呀，万一 customer id 由 int32 变 int64,你耦合在代码里面，你能确保 order 和 wallet 同时升级发版吗

[cassyfar]

微服务就是要精简服务的业务逻辑，这才是避免代码冗余，提高代码复用率啊。比如你写了个卖书的网站，那支付，购物车，账户这些都是微服务，等你再想扩展搞一个线下签售书籍预约平台，直接就可以复用账户和支付这两个服务啊。

[ch2]

class lib，动态链接库

[xuanbg]

@RedrumSherlock 单独 customer 服务呀

[RedrumSherlock]

@cassyfar 理是这个理，所有教程也都这么说，但是很多时候做起来还是有重复又太小不足以单做一个微服务的业务逻辑。举的 customer 的例子不太合适，但是很多时候还是会有这种情况。

[xuanbg]

@RedrumSherlock 哈！我们搞了个公共服务，什么文件上传、字典维护、4 级地址，和业务无关的功能，都往里面怼。

[huijiewei]

@RedrumSherlock 你一个人搞微服务 当然觉得哪里都需要定义 不要拿一个人小视角看微服务

你的问题我也思考过 其实就是觉得 各种服务里面重复定义一些实体类麻烦

这过麻烦是因为你一个人写而已

[RedrumSherlock]

@FucUrFrd customer 这个例子比较大是这样的，但是如果重复的是比较小的一个类呢？比如身份证作为一个很小的类，偏偏多个地方都要用，像这种情况，微服务的理念是只要有多个服务依赖的业务逻辑类，就要拿出来再做一个微服务么？

[RedrumSherlock]

@huijiewei 对的，就是一两个人搞麻烦。其实麻烦还是次要，关键实体类一旦要动维护更麻烦，还有命名也容易混淆搞得头大

[huijiewei]

@RedrumSherlock 所以 1，2 个人搞微服务就是自己找不自在啊。。

微服务的核心理念是，没有公共逻辑和实体。只有公共微服务。。按照这个核心进行思考。

实体类每个服务维护自己的就好了。

[shyangs]

沒有銀彈.

微服務肯定要付出代價.

原本單體用 ORM 從 DB 讀出來, 變成 Object 在內存操作處理多快. 微服務要物件序列化在網路間傳來傳去, 可以多付點雲服務商流量費.

[DoctorCat]

谁说复用就一定要 copy 代码了？ 打个包做个库、提供 API 服务 这些不都是复用么。

[charlie21]

难道单体应用（微服务的对立面）里就没有和代码复用冲突的事吗？ 微服务和代码复用根本是两个层次的语素