4
微服务就是模块化？
source link: https://www.v2ex.com/t/909835
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
20 条回复 • 2023-01-19 23:15:45 +08:00
 |
thinkershare 12 小时 43 分钟前 我感觉可以看看这本入门的书籍，你大概就了解微服务到底是个啥了，其实这个玩意没有什么准确的定义，大致上大家有一些基本共识了，因为毕竟还在发展，没有完全成熟。https://book.douban.com/subject/33425123/
它主要还是为了应对单体架构的局限性搞出来的。 |
 |
ql562482472 12 小时 35 分钟前 简单说 模块化是模块化 单体也能模块化 微服务是个相对于单体的说法
|
 |
justfindu 12 小时 34 分钟前 不是的 微服务是拉出去就能单独成立功能 , 模块你可能还会耦合
|
1 |
fgwmlhdkkkw 12 小时 25 分钟前 至少要单独的进程吧
|
 |
hhjswf 12 小时 19 分钟前 via Android 不对，模块化是作为依赖包来调用没有部署
|
 |
libook 11 小时 30 分钟前 对也不对。
架构上的概念都是相对于某种语境下的概念。 比如前端和后端，我可以说在服务器上的部分是后端、在客户端上的部分是前端；但是同样在服务器上，负责渲染页面的部分也可以被称为前端；而且同样在客户端上，负责数据流管理的部分也可以被称为后端。前后端只是相对概念。 如果为了表明将复杂的服务拆分成多个简单功能的微服务，你可以说它是服务复杂度和复用性上的模块化。但实际上把一个复杂服务的代码按照函数组拆分到不同的目录也可以被称作代码维护上的模块化。 其实不需要对这些概念死记硬背，技术最主要的是满足需求，那么你只需要关注应用每种技术的目的就可以了。 比如应用微服务架构的目的可能是提高复用性、适应项目组式的组织结构、细粒度的部署和性能扩展、功能间的故障隔离、不同功能应用不同的技术栈和版本。只要你有这些目的中的一部分，在没有其他架构思想更合适的情况下，就可以采用微服务架构。 |
 |
kwh 11 小时 11 分钟前 @thinkershare 那单体架构的集群的性能 也不行？
|
|
thinkershare 10 小时 43 分钟前 @kwh 并不是说不行，而是开发会遇到很多问题，这个问题很复杂，不是几句话就能解释清楚的，微服务提供了 X/Y/Z 三个轴方向的伸缩性，具体的还是要去看书，因为这个东西本来就非常复杂，单体应用因为耦合度太高，不管是测试，部署，开发，都会有诸多问题，但微服务解决了单体的一些问题，它按照功能任务分解了大型系统，并使得每个系统能够独立开发，测试，运行。只是需要特别小心，不要搞出分布式单体应用程序。同时也引入了分布式固有的复杂性，因此没有谁好谁坏，要看你项目的性质，团队结构等等，微服务架构很多时候还需要基础设施的支撑(因为微服务使得部署的依赖问题变得复杂化了），如果单体没遇到什么问题，继续用单体也不是不行。
|
 |
MaxFang 9 小时 53 分钟前 这两不是等同的吧。
微服务主要对应的以前的单体架构，拆分成多个小的服务部署。 模块化主要是工程内部减少耦合，增加可复用性，单体架构也可以进行模块化。 |
 |
chihiro2014 9 小时 45 分钟前 微服务没有完全绝对的正确说法。
往简单了说是功能的模块化。 往公司层面上说，是业务部门的模块化 |
 |
mcfog 9 小时 32 分钟前 via Android 我的理解是微服务真正的创新在于“用服务化的手段解决架构服务化改造过程中遇到的问题”，因此更贴切的说法应该是元服务而不是微服务
|
 |
hzxxx 8 小时 47 分钟前 模块化的概念包含微服务，微服务就是每个模块作为主体单独存在运行，这些单独模块也称服务，可以被一个门面统合一个出入口对外提供，但单应用的模块化只是在一个主体内部被逻辑拆分
|
 |
ijrou 8 小时 42 分钟前 微服务的每个服务都能做为以前的单体架构（即每个服务都有自己的进程）
微服务的每个服务都是可以互相调用的 微服务的难点在于互相依赖出现的各种问题（比如：集中管理的日志、互相依赖关系的解决、一键部署发布等） 微服务对外部被调用的称为网关 |
 |
murmur 8 小时 11 分钟前 举个最简单的例子， /userService/getUserInfo?uid=xxx 这是微服务，userService.getUserInfo(uid)这是模块化，不准确但是大概意思是这样
|
 |
fkdog 7 小时 55 分钟前 模块化是代码组织的一种方式
微服务化是系统架构的一种方式 微服务每个公司定义都不一样，碰到按照功能模块来划分服务范畴的，也有把原来老旧系统塞进一个微服务架构里单独作为一个服务的。 微服务架构我觉得就是酒瓶换新酒，RPC 已经出现了几十年了，本来 grpc 、thrift 、webservice 都能一键 call 的，微服务在这个基础上弄出了一堆监控、日志采集、链路追踪、分布式事务、服务网关、配置中心、注册中心。感觉像是云服务厂商为了卖解决方案硬弄出来的概念。。大部分非头部公司一般都用不到这么复杂的架构。。 |
 |
james2013 2 小时 24 分钟前 via Android 微服务必定是模块化
而模块化不一定是微服务，有可能是单体服务 |
 |
helbing 1 小时 12 分钟前 微服务只是个概念，它现阶段其实还在继续发展，甚至你也可以说它是个伪概念都没问题。当谈到微服务开发，你是不是想到了需要多个代码仓库存放不同业务代码（开发个功能往往需要打开多个仓库），每个代码仓库有自己的版本号（有版本依赖地狱的问题），还有测试，部署等问题。其实你会发现上微服务后给项目带来很多的复杂度，这也是为什么很多团队上了微服务后就说踩坑了，还不如继续用单体。其实你想想，我们用微服务更多的原因是我们希望能做到更细粒度的水平扩容（主因），如果现在是单仓开发+模块化目录划分，并且做到不同的模块能单独部署和水平扩容，是不是就解决了现在微服务开发中存在的很多问题？当然我不是再说你用 Monorepo 后就解决了问题（大仓也是个问题，你 git status 下就明白了，不过解决方案也还是有的），这背后其实还需要 DevOps 工具的配合（本地如何起一个完整的项目服务，部署问题等），但是你要知道现阶段其实是没有成熟方案的，只能一步步探索。从我个人的角度来说，如何做到简单（对于一个产品来说用户层面必然要是简单的，底层实现可以是复杂的）才是一条正确道路，也就是回归到“单体”。
|
 |
dk7952638 20 分钟前 微服务第一定律：能单体就别微服务
|
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK