这是一个创建于 726 天前的主题，其中的信息可能已经有所发展或是发生改变。
一开始我用 go 写了个单体架构的小说网站。
后来感觉业务流程没有梳理好，模型也有些乱，打算重构。
研究了微服务，ddd 什么的，我的目的是能够在用户增加的情况下能够很方便的提升负载能力。
但是我发现要划分好多微服务出来，但是就我一个人来开发，有必要弄得那么复杂吗？
而且边界也不好划分啊，就怕到最后互相调用，性能下降不说，改动一个功能，可能就得改动好几个服务，部署好几次。
能同时部署几个单体应用来负载均衡吗？
或者在单体应用里，对某些路由实现微服务？
如何监控到底是哪些接口占用资源高呢？
后来感觉业务流程没有梳理好，模型也有些乱，打算重构。
研究了微服务，ddd 什么的，我的目的是能够在用户增加的情况下能够很方便的提升负载能力。
但是我发现要划分好多微服务出来，但是就我一个人来开发，有必要弄得那么复杂吗？
而且边界也不好划分啊，就怕到最后互相调用，性能下降不说，改动一个功能，可能就得改动好几个服务，部署好几次。
能同时部署几个单体应用来负载均衡吗？
或者在单体应用里，对某些路由实现微服务？
如何监控到底是哪些接口占用资源高呢？
 | 1 ruxuan1306 2023-12-31 21:41:03 +08:00  8 没必要，微服务的架构本质来自组织架构。 |
 | 2 Hurriance 2023-12-31 22:21:49 +08:00 认同一楼的，技术的演化并不完全来自技术本身 |
 | 3 frankies 2023-12-31 22:22:56 +08:00 via Android 没必要 |
 | 4 lovedebug 2023-12-31 22:23:36 +08:00 没必要，微服务和单体都有自己的场景，千万不要为了微服务而微服务 |
 | 5 Solix 2023-12-31 22:25:55 +08:00 via iPhone 等你有十万用户量再改微服务也不早 |
 | 6 BeijingBaby 2023-12-31 22:27:46 +08:00 via iPhone 2 单体够你用到项目消失 |
 | 7 hefish 2023-12-31 22:36:36 +08:00 楼上的大佬们说的对，根据自己需要来搞。合适够用是原则。 |
 | 8 est 2023-12-31 22:41:04 +08:00 微服务是用来 ppt 的东西啊。这玩意从概念到推广到实施都是一家软件外包公司发明的啊。。 你没必要跟自己过意不去。 |
 | 9 CHUB 2023-12-31 22:48:33 +08:00 via Android 这么说吧，以前我们组人多，每个人负责自己的模块，自己交自己的，开发速度嘎嘎快 现在人也少了，项目也少了，偶尔会几个人都集中在同一个项目里干活，互相卡进度的时候想死，merge 的时候也想死，以及，维护老项目那一坨，改一个小的有很多个地方都要一起改，也很想死，有利有弊吧。 省流：微服务适合很多个开发者一起干活的场景，人少单例完全够用。 |
 | 10 bringyou 2023-12-31 23:07:40 +08:00 说一个曲线救国的歪路子： 正好 op 用 go 语言，可以试试 Google 出的[service weaver 框架]( https://opensource.googleblog.com/2023/03/introducing-service-weaver-framework-for-writing-distributed-applications.html)，它的一个特色就是允许以微服务的架构来写代码，但最终可以部署成为一个单体应用。 |
 | 11 kuituosi 2023-12-31 23:12:10 +08:00 先搞明白什么是微服务 不是用了微服务框架就叫微服务 |
 | 12 fregie 2023-12-31 23:30:45 +08:00 4 你需要的不是微服务，是容器化+无状态服务，要扩容直接加副本 |
 | 13 FrankAdler 2023-12-31 23:36:18 +08:00 via Android 你这种，模块划分清楚就行了。规模大了，团队大了，涉及到不同研发（团队）负责不同功能开发，单独迭代单独发版啥的才是考虑拆分的时候 |
 | 14 blackeeper 2023-12-31 23:46:52 +08:00 一个人开发，没必要弄得这么复杂 问题 1：可以，前面部署个 NG ，部署 N 个单体应用，然后负责均衡就可以了 问题 2：你可以在 NG 上转发到你拆分的微服务应用 问题 3：监控应用接口是多个层面的，要统计分析：有哪些接口，以及接口的 [调用频次，应用处理时间、SQL 处理时间、调用其它的时间、消耗 CPU 、内存，磁盘 IO] |
 | 15 cheng6563 2024-01-01 00:36:47 +08:00 把表弄好一点就够了 |
 | 16 Kumo31 2024-01-01 00:59:58 +08:00 微服务不解决你说的负载能力问题 |
 | 17 pigspy 2024-01-01 11:48:52 +08:00 单体架构足够你用到网站倒闭了 |
 | 18 codewld 2024-01-01 13:42:52 +08:00 via iPhone 1 微服务各模块独立自治，不会一坏皆坏，提高的是可用性，和负载能力没有直接关系。 如果只是希望提升负载能力，应该考虑将服务改成无状态，然后按需扩容服务层。 |
 | 19 fgsqqq 2024-01-01 17:35:51 +08:00 微服务 是使 单个服务 的业务内聚性更高 不同的业务 放到不同的地方 对系统解耦 维护扩展更高效 当然 还得看项目规模 和复杂度 小项目 或几个人玩的 可以不用 大厂的 服务 基本上 微服务 因为 业务复杂，承接功能多 抽取独立成一个 ，更易于 维护 |
 | 20 R4rvZ6agNVWr56V0 2024-01-01 18:16:49 +08:00 任何架构模式都是顾及了康威定律而设计的。一个人的项目不需要遵守这些复杂模式。 |
 | 21 Godjack 2024-01-01 19:52:44 +08:00 当然不是非得用微服务，前些年掀起了一阵微服务热，我最近时不会在 hacker news 首页上看到一些反思微服务的文章 https://blogs.newardassociates.com/blog/2023/you-want-modules-not-microservices.html https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices.html > 后来感觉业务流程没有梳理好，模型也有些乱，打算重构。 不管是否用微服务，都要把模块划分好 > 研究了微服务，ddd 什么的，我的目的是能够在用户增加的情况下能够很方便的提升负载能力。 单体架构也能「 方便」(对于你的小说应用来说应该够用了)提升负载能力。 有时间的话可以看看这个 https://icyfenix.cn/architecture/architect-history/ |
 | 22 hangszhang 2024-01-01 20:46:07 +08:00 组织架构决定系统架构，你这就一个人，单体就好 |
 | 23 afeiche 2024-01-02 11:32:46 +08:00 以前我们领导天天让我把系统改微服务，都让我顶回去，微服务部署、运维、监控都得有，要是公司不提供这些，自己搞折腾死了 |
 | 24 shellcodecow 2024-01-02 14:09:24 +08:00 根据实际的情况出发，流量很一般 不需要自动横向扩容，什么微服务，容器化都没必要.. 不过既然你是用 go 我觉得可以学习下一些现成的框架..没必要自己研究这些，这些都是面向领导开发的 |
 | 25 me1onsoda 2024-01-02 16:44:57 +08:00 回过头来看，很多微服务都是开发给自己简历贴金用的 |
 | 26 petergui 2024-01-02 18:22:05 +08:00 个人觉得是基于几层： 1. 开发人员和项目的数量 2. 流量特点， 热点服务（有多热？），热点路径 把这些分析清楚了，自然就清楚微服务不微服务。 楼上说的对 你需要的是高可用。 微服务架构本身提供的应该是多节点多服务隔离，管理，发现，扩展 等功能便捷性。 |
 | 27 xycost233 2024-01-03 16:22:41 +08:00 估算一下你未来的用户规模，然后纵向切割，横向扩展，只要纵向切割得好，横向业务耦合度高一点问题也不大 |
 | 28 zx900930 2024-01-04 09:44:28 +08:00 技术选型是服务实际需求的，如果你们预估的业务规模不会大规模横向扩张，没有多个项目组分开开发发版的需求，根本就没必要上微服务。 |
 | 29 danielxxx 2024-09-29 09:03:19 +08:00 14 年，后端开发 10 几个人。cto 和架构师都是新来的，上来就给原来.net 一顿重构成 java 微服务，当时微服务的 rpc 也不稳定，别说 springcloud 和 dobbo 了，那会儿 dubbo 没人用基本。 于是领导自己搞了一套 rpc ，后端基于 ddd 开发，有 facade 层，开发只关心业务代码，controller 不用管，吭哧写了 2 年后来进了阿里内网，换成了 hsf 。 所以有时候不是技术框架不合适，而是领导战略要求。 |
Select Language