这是一个创建于 1159 天前的主题，其中的信息可能已经有所发展或是发生改变。
有懂的大哥吗 这个说法对不对
 | 1 ngn999 2023 年 1 月 19 日  1 |
 | 2 thinkershare 2023 年 1 月 19 日 我感觉可以看看这本入门的书籍，你大概就了解微服务到底是个啥了，其实这个玩意没有什么准确的定义，大致上大家有一些基本共识了，因为毕竟还在发展，没有完全成熟。https://book.douban.com/subject/33425123/ 它主要还是为了应对单体架构的局限性搞出来的。 |
 | 3 ql562482472 2023 年 1 月 19 日 简单说 模块化是模块化 单体也能模块化 微服务是个相对于单体的说法 |
 | 4 justfindu 2023 年 1 月 19 日 1 不是的 微服务是拉出去就能单独成立功能 , 模块你可能还会耦合 |
 | 5 fgwmlhdkkkw 2023 年 1 月 19 日 至少要单独的进程吧 |
 | 6 hhjswf 2023 年 1 月 19 日 via Android 不对，模块化是作为依赖包来调用没有部署 |
 | 7 libook 2023 年 1 月 19 日 对也不对。 架构上的概念都是相对于某种语境下的概念。 比如前端和后端，我可以说在服务器上的部分是后端、在客户端上的部分是前端；但是同样在服务器上，负责渲染页面的部分也可以被称为前端；而且同样在客户端上，负责数据流管理的部分也可以被称为后端。前后端只是相对概念。 如果为了表明将复杂的服务拆分成多个简单功能的微服务，你可以说它是服务复杂度和复用性上的模块化。但实际上把一个复杂服务的代码按照函数组拆分到不同的目录也可以被称作代码维护上的模块化。 其实不需要对这些概念死记硬背，技术最主要的是满足需求，那么你只需要关注应用每种技术的目的就可以了。 比如应用微服务架构的目的可能是提高复用性、适应项目组式的组织结构、细粒度的部署和性能扩展、功能间的故障隔离、不同功能应用不同的技术栈和版本。只要你有这些目的中的一部分，在没有其他架构思想更合适的情况下，就可以采用微服务架构。 |
 | 8 cvbnt 2023 年 1 月 19 日 via Android 1 |
 | 9 kwh 2023 年 1 月 19 日 @thinkershare 那单体架构的集群的性能 也不行？ |
| 10 thinkershare 2023 年 1 月 19 日 1 @kwh 并不是说不行，而是开发会遇到很多问题，这个问题很复杂，不是几句话就能解释清楚的，微服务提供了 X/Y/Z 三个轴方向的伸缩性，具体的还是要去看书，因为这个东西本来就非常复杂，单体应用因为耦合度太高，不管是测试，部署，开发，都会有诸多问题，但微服务解决了单体的一些问题，它按照功能任务分解了大型系统，并使得每个系统能够独立开发，测试，运行。只是需要特别小心，不要搞出分布式单体应用程序。同时也引入了分布式固有的复杂性，因此没有谁好谁坏，要看你项目的性质，团队结构等等，微服务架构很多时候还需要基础设施的支撑(因为微服务使得部署的依赖问题变得复杂化了），如果单体没遇到什么问题，继续用单体也不是不行。 |
 | 11 MaxFang 2023 年 1 月 19 日 这两不是等同的吧。 微服务主要对应的以前的单体架构，拆分成多个小的服务部署。 模块化主要是工程内部减少耦合，增加可复用性，单体架构也可以进行模块化。 |
 | 12 chihiro2014 2023 年 1 月 19 日 微服务没有完全绝对的正确说法。 往简单了说是功能的模块化。 往公司层面上说，是业务部门的模块化 |
 | 13 mcfog 2023 年 1 月 19 日 via Android 我的理解是微服务真正的创新在于“用服务化的手段解决架构服务化改造过程中遇到的问题”，因此更贴切的说法应该是元服务而不是微服务 |
 | 14 hzxxx 2023 年 1 月 19 日 模块化的概念包含微服务，微服务就是每个模块作为主体单独存在运行，这些单独模块也称服务，可以被一个门面统合一个出入口对外提供，但单应用的模块化只是在一个主体内部被逻辑拆分 |
 | 15 ijrou 2023 年 1 月 19 日 1 微服务的每个服务都能做为以前的单体架构（即每个服务都有自己的进程） 微服务的每个服务都是可以互相调用的 微服务的难点在于互相依赖出现的各种问题（比如：集中管理的日志、互相依赖关系的解决、一键部署发布等） 微服务对外部被调用的称为网关 |
 | 16 murmur 2023 年 1 月 19 日 举个最简单的例子， /userService/getUserInfo?uid=xxx 这是微服务，userService.getUserInfo(uid)这是模块化，不准确但是大概意思是这样 |
 | 17 fkdog 2023 年 1 月 19 日 模块化是代码组织的一种方式 微服务化是系统架构的一种方式 微服务每个公司定义都不一样，碰到按照功能模块来划分服务范畴的，也有把原来老旧系统塞进一个微服务架构里单独作为一个服务的。 微服务架构我觉得就是酒瓶换新酒，RPC 已经出现了几十年了，本来 grpc 、thrift 、webservice 都能一键 call 的，微服务在这个基础上弄出了一堆监控、日志采集、链路追踪、分布式事务、服务网关、配置中心、注册中心。感觉像是云服务厂商为了卖解决方案硬弄出来的概念。。大部分非头部公司一般都用不到这么复杂的架构。。 |
 | 18 james2013 2023 年 1 月 19 日 via Android 微服务必定是模块化 而模块化不一定是微服务，有可能是单体服务 |
 | 19 helbing 2023 年 1 月 19 日 微服务只是个概念，它现阶段其实还在继续发展，甚至你也可以说它是个伪概念都没问题。当谈到微服务开发，你是不是想到了需要多个代码仓库存放不同业务代码（开发个功能往往需要打开多个仓库），每个代码仓库有自己的版本号（有版本依赖地狱的问题），还有测试，部署等问题。其实你会发现上微服务后给项目带来很多的复杂度，这也是为什么很多团队上了微服务后就说踩坑了，还不如继续用单体。其实你想想，我们用微服务更多的原因是我们希望能做到更细粒度的水平扩容（主因），如果现在是单仓开发+模块化目录划分，并且做到不同的模块能单独部署和水平扩容，是不是就解决了现在微服务开发中存在的很多问题？当然我不是再说你用 Monorepo 后就解决了问题（大仓也是个问题，你 git status 下就明白了，不过解决方案也还是有的），这背后其实还需要 DevOps 工具的配合（本地如何起一个完整的项目服务，部署问题等），但是你要知道现阶段其实是没有成熟方案的，只能一步步探索。从我个人的角度来说，如何做到简单（对于一个产品来说用户层面必然要是简单的，底层实现可以是复杂的）才是一条正确道路，也就是回归到“单体”。 |
 | 20 dk7952638 2023 年 1 月 19 日 微服务第一定律：能单体就别微服务 |
 | 21 xuanbg 2023 年 1 月 20 日 微服务是模块化思想的一种表现形式。微服务的出现，主要是为了解决这几个问题： 1 、源代码过于庞大，内部的结构过于复杂，难以维护 2 、部署过程复杂，难以进行高效横向扩展 微服务的隐藏好处是：代码会变屎山，这个是无法避免的。但微服务能让这山比较小，不是那么让人望而却步。同时，变屎的速度和程度也都会想对弱一些。 |
 | 22 2NUT 2023 年 1 月 21 日 别听他们扯得多玄乎，你的感觉就是对的。其他附加的都是模块化后自然涌现的。 |
 | 23 vinceall 2023 年 1 月 31 日 说粗略点就是把不同业务代码拆到不同 web 容器中跑，用相互调用代替 jar 集成 |
 | 24 lvjing2 2024 年 1 月 30 日 模块化确实能解决微服务里很多问题，可以用这个框架试试 koupleless.gitee.io |
Select Language