仔细想想，微服务架构相比于单体服务架构来讲优势也没有很大

[petelin]

我的观点是微服务从技术上使得每个服务不在和其他服务分享资源，所以更加独立和健壮一点（更分布式一点）

但是，只要有依赖关系我看不出来通过 rpc 调用和直接方法调用有什么区别
诸如吐槽单体应用存在 业务边界模糊，调用关系复杂，难以重构等等问题 难道一个治理的不好的微服务里就不会发生了？ 我们不可以在单体应用中分模块来解决吗？

我们可以在代码层面依然分出来不同的服务在不同的目录下 只是不用 rpc 还按照领域驱动模型拆分出来子模块 按照微服务的思路去治理这个大的单体应用（权限验证 调用关系等等） 每个模块也可以有自己的数据库 而不是一个公用的数据库等等

每个子模块就相当于一个微服务 这样的思路会有什么问题？

[fox1955]

非常正确，微服务只是属于抽象解耦的一个层面: 部署。
解耦分三个层面: 代码，类库，部署。

Robert C. Marti 专家对此有明确的建议: 做好逻辑上的解耦，这样，(如果有必要，比如人员过多，单一部署不便管理)即使(将解耦)从代码层面上升到部署层面，也是非常轻松的。

所以软件质量的核心全在业务的抽象解耦划分上，而不要纠结在所谓微服务什么乱七八糟的东西上面。

具体可参考阅读 <Clean Architecture A Craftsman's Guide to Software Structure and Design>

[qqxx520]

发明新的名词，大家一拥而上，干的热火朝天，不好吗？否则，老板们会说: IT 部门看不到产出，该节省点了，裁员？

[whileFalse]

理解不了是因为你没接触到这个量级的业务

[sanmaozhao]

还有一个重要的优势：
每个服务可以选择最适合本业务的技术栈，比如编程语言方面有的用 Go、有的用 Java。
单体模式一般都要保持统一的技术栈。
就算是统一的技术栈里面已经有多种编程语言，如果新上的服务想引入新的编程语言也会遇到比较大的阻力。

[MoHen9]

单体架构的服务小一点还好，如果较大，会有很多问题，比如某个模块使用了老的依赖，升级或替换是个问题；模块太多，对于新员工熟悉业务，心智负担也会很重；引入新框架，依赖冲突，需要升级也可能会有问题；启动速度更慢，debug 都烦；这些都还只是开发上的，部署时也不灵活，运行时的监控等，都不如分布式方便。

[huijiewei]

然后呢，你因为改了一个模块的内容，所有服务器都编译个新版本部署一次？

[areless]

crossbar.io 一样的概念。就是业务的拆分。方便管理多人维护自己的开发模块。负载方面不是主要的，豆瓣早年的技术文章里讲过，他们用一台服务器扛全国流量的事情。后来 python 就开始流行了。

[areless]

你想想 08 年豆瓣，好像是双核 amd 服务器一台。那个服务器可能比现在手机速度还慢很多好不好（笑）

[whp1473]

假如你把阿里所有业务写到一个项目里，项目大小 300G，项目占用内存 300G，加载字节码时间 1 小时。。。你感觉吓人不。
还有随着项目规模增大，人员投入和项目效率会呈现反比，划分微服务有利于扩容、维护、和推迟这种情况到到来。当然这是建立在你项目复杂，并且开发人员很多的情况，要是外包或者很少开发人员，就是应该写在一个项目里。

[suikatw]

@whp1473 应用拆解这个事情和微服务并没有直接关系，在微服务概念提出之前 BAT 已经有十万级别的项目、应用、git 仓库了。
相反微服务在当前情况下还有副作用需要考虑。服务拆解可以无限细分，但是部署能力的细分是有限度的，管理成本也是有限的，可能造成了机器资源浪费，也增加了管理成本。目前在拆解的粒度上还没有一个统一的指导思想。
比如一个业务拆成了 20 个微服务，这个业务在试跑阶段，可能 2 台 4C8G 的服务器就足够负载了。可当我们设计微服务的部署资源时，我们发现目前成熟的最小微服务部署资源 * 20 份之和，远远大于 2 台 4C8G。这个业务的支撑开发团队可能也只有不到 10 个人，平均每个人要至少负责 2 个微服务，对于人员之间信息互备和管理稳定性也有很大风险。

[fcoolish]

工作多久了，，有一年了吗？

[maemual]

？？？建议楼主增加工作经验，或者随便把这两本书看任意一本 ：
《微服务架构设计模式》 https://book.douban.com/subject/33425123/
《微服务设计》 https://book.douban.com/subject/26772677/

[HowardTang]

monorepo 和 multirepo
各有各的優勢

[NoKey]

做开发的，不要拘泥于名字
重要原理相通，可以理解为差不多的东西
我觉得微服务体现的更多的就是系统分拆，分开部署
各个服务之间如何通讯什么的，根据实际情况来
现在太多公司，所有服务在一个 war 里，或者在一个 tomcat 里
然后要重启或者重新部署一个服务。。。你懂的。。。
老外经常猛推一些概念什么的，那个是有利益在里面的
做 java 的，了解微服务最多的就是 spring cloud 那一套
别人搞这一套，不吃饭的么。。。

[optional]

代码 /人员解耦，状态监控，隔离部署，自动发现都是要优点。

你可以把微服务想象成一个分布式的 ioc, 可以在大部分模块不重启的情况下替换某一个模块。

[sujin190]

微服务提高的是开发维护效率，伸缩性提高，业务快速变更适应性明显增强，运行效率必定是降低的，稳定性要求必定更复杂，这不用说啊

[petelin]

@optional 最后 ioc 的比喻很好，可是代码人员的解耦难道不做微服务就实现不了了吗？比如我可以采用代码层面的解耦，一个目录就是一个微服务，交由一个团队来管理
状态监控也是可以做的
自动发现如果没有微服务根本不用引入

[petelin]

@sujin190 能解释一下相比于多个模块组成的单体应用
"开发维护效率，伸缩性提高，业务快速变更适应性明显增强" 是怎么得出的结论吗?

[est]

@cyaki monolith monorepo 都可以单模块部署、单独更新。

[est]

@fox1955 其实 monolith 可以单独部署的。。比如 /api/thing/update 和 /api/author/update 两个 api，如果你要单独更新 author，那么新起一个 web 逻辑的进程，然后 nginx 新增加一个路由过去到新进程就行了。

如果有代码调用依赖，也有办法解决。。。

（虽然其实这样其实离微服务就差最后一步 服务化了。。。