这是一个创建于 871 天前的主题，其中的信息可能已经有所发展或是发生改变。
93 条回复 • 2022-06-28 18:30:07 +08:00
 |
1
mazhiyuan 2022-06-22 16:33:56 +08:00
你不卷就被别人卷~
|
 |
2
pepesii 2022-06-22 16:34:56 +08:00  4
或许是管理问题吧，拆分服务和容器化应该不是很相关 😄 ，我是这样觉得的
|
 |
3
nguoidiqua 2022-06-22 16:35:44 +08:00
是的
|
 |
4
knightdf 2022-06-22 16:45:36 +08:00 6
确实是的，现在做个日活 10 个人也要上微服务
|
 |
5
wd 2022-06-22 16:52:37 +08:00 via iPhone 10
容器化 ！= 微服务 吧
|
 |
6
pengtdyd 2022-06-22 16:56:29 +08:00
只有卷 S 别人自己才有机会上位啊
|
 |
7
cheng6563 2022-06-22 17:00:27 +08:00
容器化 ！= 微服务啊
啥服务都可以容器化啊，一方面便携化，另一方面容器可以直接当 systemd 用 |
 |
8
microxiaoxiao OP |
 |
9
AS4694lAS4808 2022-06-22 17:24:24 +08:00 2
泛滥的是微服务，不是容器化。单体应用也可以容器化，容器化=香
|
 |
10
HWY12 2022-06-22 17:30:23 +08:00
应该是微服务很泛滥，就像我们公司，一个后台系统，撑死了就是那百八十个运营数据分析师和一些项目组的负责人使用，并发啥啥没有，非得拆分为四个微服务，图啥呀。
|
 |
11
nullpoint007 2022-06-22 17:36:40 +08:00 3
因为搞微服务架构导致应用数量指数级增长,就有了容器技术打包环境快速批量部署的发展，不是所有服务都非得微服务化
|
 |
12
wtfedc 2022-06-22 17:46:00 +08:00
粒度不合适的话，跨库查询是梦魇
|
 |
13
min 2022-06-22 17:50:20 +08:00
容器化本身没什么问题吧，挺好的东西
至于微服务多不多，是微服务本身的问题 完全不妨碍起一堆容器跑批处理 |
 |
14
sujin190 2022-06-22 17:53:27 +08:00 1
有了 devops 工具、链路追踪、服务注册发现和容器化，微服务化后大大省事了吧，而且每个项目只负责一点点事情了，发布和测试也省心很多，分明是节省工作量的吧
|
 |
15
iosyyy 2022-06-22 17:54:15 +08:00
容器是真的好东西 但是微服务我个人并不看好因为大多数项目都没多大的访问量 java 线程池就够用非得要加个微服务典型的画蛇添足
|
 |
16
darkengine 2022-06-22 17:54:37 +08:00 1
什么相互依存，容器化怎么可能会依赖微服务呢。
|
|
17
cheng6563 2022-06-22 17:55:46 +08:00
@microxiaoxiao 容器和微服务本来就是两回事啊。
容器有啥复杂的，你服务上线总要整 systemd 什么的吧，那换成 docker-compose 也没多费功夫吧。 |
 |
18
wangpugod2003 2022-06-22 18:01:09 +08:00
容器和微服务是两回事；
微服务很考验 devops ，怎么划分，数据库... 大公司可以尝试，有利于不同编程语言的工程师一起来 working(k8s)；小公司的话，很多就是瞎折腾。 |
 |
19
abersheeran 2022-06-22 18:19:58 +08:00 1
容器化又不是微服务化。容器化很香啊，不用考虑环境。现在现成的服务基本都提供 docker-compose 启动方式。
|
 |
20
anubu 2022-06-22 18:25:06 +08:00 1
微服务的确在泛滥，但标题取的有问题，容器化和微服务是两回事。这两个技术栈是独立发展的，不是什么相互依存，甚至连相互促进都谈不上。只是近来微服务和云原生的泛滥，导致这两个技术有相互促进演化的趋势，但也只是各自技术蓝图中的一部分。
微服务泛滥是管理、业务、研发跟风卷的后果，容器技术只是更方便的让这种卷落地而不仅仅停留在 PPT 。没有容器的时候，还是会拿着 springcloud 实现的。 同时，容器带来的云原生跟风，让大家卷的更带劲了。 |
 |
21
binge921 2022-06-22 18:25:14 +08:00
容器化才是王道 微服务都卷冒烟了
|
 |
22
acmore 2022-06-22 18:29:47 +08:00
容器化 = You build it, you run it.
微服务是完全不同的另一个领域 |
 |
23
dcsuibian 2022-06-22 18:33:38 +08:00 via Android
容器化方便配置啊，单体应用都能从中收益的。我 NAS 都能用 docker 装 qBittorrent 了。
而且只是多了个选择，又不是不让你直接安装。 微服务只是受益者之一，泛滥是设计问题，跟容器化没啥关系。 |
 |
24
cloverzrg2 2022-06-22 18:38:00 +08:00
我一个人用的工具箱也是容器化部署
|
 |
25
Buges 2022-06-22 19:09:29 +08:00 via Android
因为微服务确实好用。无状态、易扩展、易调试。
|
 |
26
HankAviator 2022-06-22 21:10:41 +08:00 via Android 3
想起一个笑话
哭的 doge：“救命，为什么我的 hello world 有 1 个 G” 狗旁边印了个 docker 图标 |
 |
27
yrj 2022-06-22 21:32:01 +08:00 1
要是不找点活折腾，容易被优化掉啊
|
 |
28
DamonLin 2022-06-22 21:42:48 +08:00
容器化不等于微服务，不过现在确实没点微服务的实操真的很难找到工作，说白了就是分布式技术吧
|
 |
29
potatowish 2022-06-22 21:45:20 +08:00 via iPhone
我见过拆了一堆微服务，每个服务只有一个实例，共用一个数据库的
|
 |
30
liuhuansir 2022-06-22 22:10:53 +08:00
@potatowish 我先所在的项目就是这样
|
 |
31
hallDrawnel 2022-06-22 22:20:43 +08:00
@pepesii 确实是这样的。遗憾的是由于容器化等让服务拆分的代价小了很多，导致很多不合格的开发者害怕对现有服务做迭代，随意拆分导致整个系统乱成一团。
|
 |
33
WOLFRAZOR 2022-06-22 22:38:39 +08:00 via Android
op 指的是微服务泛滥吧？（泛滥是人造成的问题，你不内卷就等着被别人卷），容器化是好东西
容器化和微服务不是相同的东西。 |
 |
34
nightwitch 2022-06-22 23:54:38 +08:00
容器化我觉得很方便，清清爽爽一个 dockerfile ，比手动配置应用环境方便多了。
|
 |
35
luozic 2022-06-23 00:16:12 +08:00
统一部署和运维标准； 如同货柜就是垃圾也用货柜装的。
|
 |
36
imycc 2022-06-23 00:54:08 +08:00
复杂的业务和庞大的开发团队，更容易从微服务及容器化中受益。
一般情况是 A 团队负责某一堆业务，B 团队负责某一堆业务，还有 CDEF 团队等等，通过微服务框架统一业务间调用、日志追踪和部署管理等技术问题，方便管理。 其实容器化也是。之前我们负责一些边缘业务的维护，就单个团队的服务，领导硬要我们做容器化改造。但是算了下资源利用率、扩容效率和成本都没什么收益，折腾了几个月又放弃了。 |
|
37
imycc 2022-06-23 00:56:00 +08:00
#36 哦不对，更正一下，容器化不是没什么收益，而是在那种业务场景下，业务改造的时间+风险，大于收益。
|
 |
38
Chad0000 2022-06-23 06:43:09 +08:00 via iPhone
容器是针对运行环境，微服务更侧重开发方式。
即便共享数据库，微服务还有一个好处是避免不同服务相互影响，比如项目想升级而里面有一个比较古老的报表业务不支持，这时候报表放在独立的微服务里面就不受影响了。 |
 |
40
chendy 2022-06-23 07:56:41 +08:00
容器化挺方便的，统一运维管理
微服务对于大多数场景大可不必 |
 |
41
skys215 2022-06-23 08:03:24 +08:00
不搞点微服务怎么跳槽啊
|
 |
42
jorneyr 2022-06-23 09:18:28 +08:00
领导要跟上时髦。
|
 |
43
sagasu0000719 2022-06-23 09:22:09 +08:00
@knightdf hahahh 那你可以用一个微服务给他实现吧，可能 LD 吹牛吹出去了
|
 |
44
frank1256 2022-06-23 09:28:03 +08:00
1 、为了跟上时髦
2 、连表查询的时候，看你怎么写 |
 |
45
salmon5 2022-06-23 09:42:28 +08:00 1
不然怎么搞 KPI 、简历镀金
|
 |
46
hoopan 2022-06-23 09:54:08 +08:00
docker 是真的香，微服务多数是跟风，拆分不好就是灾难
|
 |
47
wu00 2022-06-23 09:56:44 +08:00
不搞点微服务怎么找得到薪资“满意”的工作，面试的时候问你一堆造火箭的最新技术，不管是线上项目还是私底下你好歹要用过几个吧。
上班时间写什么代码不是写，用户都没几个的项目更适合上新技术，又拿工资又学习，说出去还倍儿有面子 |
 |
48
ecloud 2022-06-23 10:05:01 +08:00
容器不就是个 linux 版的 wine 嘛，把应用程序跟 wine 打个包一起发布，不就跟什么 docker 一回事。我寻思这玩意儿十多年前就有了，咋新起个名字就立马高大上了起来...
至于微服务，绝大部分人是为了拆而拆，真的能把业务拆分设计好的，都得是既非常熟悉业务又具有深厚技术背景的人，这种人的行业保有量基本相当于东北虎。 举个例子，要想把一个进销存软件拆得好，得是一个干了 10 年程序员后来转行干了几年采购，几年出纳 /会计，或者自己开过公司，报过税，对过账，盘过库。 |
 |
49
littlewing 2022-06-23 10:15:09 +08:00
容器化就是微服务？
|
 |
50
3kkkk 2022-06-23 10:17:47 +08:00
容器化不等于微服务，容器是减少了我们对依赖环境的搭建时间，只是降低了微服务搭建难度。就我而言见到的微服务后面都是一堆垃圾，还不如单体应用了。
|
 |
51
gkeeno 2022-06-23 10:22:02 +08:00
现在新能源是不是太泛滥了？动不动就看到电车
|
 |
52
bomb77 2022-06-23 10:52:44 +08:00
容器表示微服务的锅我不背。
单就容器节约了无数人搭建环境安装配置的时间、大大提高了效率这点来说，容器是个好东西。 |
 |
53
xzysaber 2022-06-23 10:57:32 +08:00
容器化跟微服务没有直接关系，只是容器化(K8S)使得微服务更好部署或运维。
|
 |
54
Mrxx 2022-06-23 11:00:29 +08:00
前端框架表示不服气
|
 |
55
dxpy 2022-06-23 11:14:35 +08:00
其实单机+容器就挺好
|
 |
56
Tabjy 2022-06-23 11:34:05 +08:00 1
 |
 |
58
simonlu9 2022-06-23 11:48:35 +08:00
大多数的服务都是 io 类型，而非 cpu 类型，每个容器都需要 redis 和 mysql,不扩展 mysql 和 redis ，就是做个服务隔离，我觉得没太大意义
|
 |
59
lolizeppelin 2022-06-23 11:55:32 +08:00
容器是为了多实例隔离.....
不需要在一台机器上跑多实例就根本不需要隔离,不需要隔离就不需要容器化 很多人喜欢 docker 的原有和家用 nas 跑 docker 原有差不多,自不会配置,运行别人做好的个 docker 就起来了不怎么需要自己配置,简单来说就是菜 |
|
60
sujin190 2022-06-23 11:59:57 +08:00 1
@mengdodo #57 自然是每个项目启动的容器自己创建连接池了，数据库这边确实会连接数会高很多，但不是一个特别大的问题，而且换个方面来说每个容器的项目做的事情都少了，所以每个项目的连接数量也会低很多，虽然整提连接数量还是增长了，但也不是线性增长的，问题并不会特别严重
容器这边的话网络栈是独立的，所以连接数限制自然也是独立的，只是 k8s 连接集群外数据库的话需要走宿主机的 nat ，但是毕竟你宿主机的资源也不是无限的，实际也不大可能会超过宿主机的连接数量限制 |
 |
61
libook 2022-06-23 12:16:29 +08:00 1
工具服务于需求，没需求硬上肯定添堵。
比如我一开始在电脑上直接跑服务，装各种依赖会污染系统环境，而且也不容易备份还原，后来出于方便就把服务都搬到容器里了。 用不用微服务取决于是否真的需要复用部分服务模块来达到节省开发成本的目的，比如我自己写了几个爬虫来爬小姐姐，但是每个爬虫都单独引一份 Puppeteer 环境导致每个服务程序本身都会占用上 GB 的空间，为了节省空间我打算迁移到 Browserless ，多个爬虫实例共用一个 Browserless 微服务。 |
 |
62
chenmobuys 2022-06-23 12:47:47 +08:00
微服务跟容器是两个概念吧，用容器的话，就不用再费力的去搭建环境了
|
 |
63
duke807 2022-06-23 12:52:51 +08:00 via Android
用 docker 這樣的容器就感覺是在脫褲子放屁
大多數用 docker 的人只是因為自己不熟悉 linux 而已 |
|
64
duke807 2022-06-23 12:56:53 +08:00 via Android
很多人說什麼環境不統一，我表示我主力電腦和服務器都統一是 gentoo 系統
|
|
65
ecloud 2022-06-23 13:10:05 +08:00
@duke807 环境不统一也是屁话，现在真正在生产系统里用的也就是 debian 系跟 rh 系，debian 系的 debian 跟 ubuntu 在底层而言差异极少； rh 系就更不用说了，神马 centos, oracle, redhat 本质上就是一个东西。绝大多数正经的客户那边，都有现成的 debian/ubuntu/rh/centos 虚拟机给你用，你想换哪个就换哪个
|
 |
66
MengiNo 2022-06-23 13:31:40 +08:00 via iPhone
主要是大幅度提升交付效率和提升了延续性。系统、环境问题倒真是其次。docker 或者 k8s 的那些 yml 最大的好处在于具象化的描述了这个服务。
|
 |
69
blless 2022-06-23 14:26:57 +08:00
容器化跟微服务是两码事，微服务相关的容器化我猜你是想说容器编排（ K8S ）？
容器化是运行环境的虚拟化+隔离，很多代码依赖比较复杂的时候，用容器化就可以省很多功夫。 微服务是因为复杂业务架构需要支持更多开发人员同时迭代业务开发。 因为微服务的交付比常规服务更复杂，所以才需要更规模化的容器编排交付方案。 所以内在逻辑是 容器化+微服务+大规模交付 =》 容器编排，容器编排这个步骤在我看来已经需要专业运维团队去支撑了。 |
|
70
blless 2022-06-23 14:32:59 +08:00
@ecloud 容器化除了本身的环境隔离之外，其实对运维来说更重要的是一套交付系统。即镜像库+docker pull/run/stop 。以前运维部署要么自己实现一套，要么就 ftp+ssh ，高级一点上 ansible 啥的。
|
 |
71
Mithril 2022-06-23 14:40:39 +08:00
微服务才是泛滥了。
有些一共几百个用户，功能加一起不过十几张表的项目，也硬是要拆几个微服务出来。 然后每个微服务跑一个实例，共用一个数据库。 再扔容器里，套个 k8s 集群。 最后发现网络通信里面，k8s 自己的占了一大半。 随便碰哪都是瘫给你看。 然后码农就可以拿着微服务集群化大规模部署的项目经验去找下家了。 当然最好还是做个 ppt ，找几个会议一同吹，这样更好找工作。 |
 |
72
samin 2022-06-23 14:42:26 +08:00
你说的都是云原生的内容，去了解一下云原生吧，现在所有架构基本都偏向云原生
btw：云原生的四大特点，微服务、DevOps 、容器化、持续交付 |
 |
73
Daiwf 2022-06-23 15:20:37 +08:00
我司系统最多千人并发，还在搞微服务。我感觉是搞架构的实在想不到搞什么了。硬卷
|
 |
74
FrankFang128 2022-06-23 15:29:29 +08:00
我现在 dev 环境都开始容器化了啊
|
|
75
ecloud 2022-06-23 15:43:01 +08:00
@blless 简单来说就是运维水平差，不会写 shell 脚本，不会做 deb,rpm 包。以前那些重量级的软件，还不都是./install.sh 之后下一步下一步就完了。十多年前的 RHCE 要考 troubleshooting 的，grub 配置参数，内核参数，fstab 给你改的乱七八糟的让你 5 分钟恢复。现在的 RHCE 就是个笑话。
|
 |
76
guanhui07 2022-06-23 16:09:20 +08:00
容器化 是趋势
|
 |
77
fifa899 2022-06-23 16:29:25 +08:00
没错.可没有一些新概念,这些你能吹开发量吗.KPI 工作量怎么吹.
|
 |
78
zmal 2022-06-23 16:47:51 +08:00
有时觉得程序员之间的认知差异真的是很大...容器化都已经成为标准了，还有这么多人认为容器是多此一举。
|
|
79
ecloud 2022-06-23 17:37:16 +08:00
还是那句话，新瓶装旧酒，炒作概念而已。早年 wine ，dosbox 什么的，很多人就是为了玩个游戏，你要我配什么注册表 EMM386 的鬼东西我哪学的会。于是就有人把程序跟 wine/dosbox 打包做好，配置文件都配好，扔给你，直接双击就能玩。
海峡对岸管这个叫懒人包，只少 20 年前就出现了。像什么 playonmac/playonlinux ，就是个 wine 构建 /打包工具，就是 docker 的直系祖宗 后来苹果 Mac OS/X 的.app 封包也是差不多类似的目的，把一大堆依赖.dylib 都给你扔在 app 里，杜绝了传统*nix 系统的动态库依赖灾难，也杜绝了 win 上面的第三方瞎 J8 覆盖系统动态库的弊端。坏处是，app 真特么大 之后 linux 来了个有样学样搞了个 AppImage ，就是苹果.app 的山寨 你不会，你懒，你用懒人包，没问题。我会，我闲的蛋疼，所以我每装个游戏都去做一下 autoexec.bat/config.sys 我乐意。但是，别装 13 说你那个懒人包多么高大上。 |
 |
81
alexmy 2022-06-23 17:57:27 +08:00
小项目，甚至是梯子，都是用的 docker-compose ，容器化，超级方便。
|
 |
82
tairan2006 2022-06-23 19:57:29 +08:00 via Android 1
@ecloud docker 的原理不是这样的…只是做了资源隔离，并不是虚拟机…docker 的创新之处在于 layer 。
|
|
83
ecloud 2022-06-23 22:19:42 +08:00
@tairan2006 难道你以为 wine 是虚拟机吗？还是你觉得 cygwin 也是虚拟机？
|
|
84
tairan2006 2022-06-24 08:42:46 +08:00 via Android
@ecloud wine 加了一层转译, docker 基本无性能损失，差别还是很大的…
|
|
85
ecloud 2022-06-24 10:04:22 +08:00
@tairan2006 这里说的这些内容跟性能有一毛钱关系吗？拼性能你拼得过 configure/make install
|
|
86
tairan2006 2022-06-24 10:40:22 +08:00
@ecloud 主要你 48 楼说的是错的，这些技术并不是换了个名字，根本不能混为一谈。docker 能流行有他的自己的原因，性能损失小是个必不可少的条件……
|
 |
87
ShareDuck 2022-06-24 11:13:43 +08:00
@AS4694lAS4808 对对对。我们单体应用也用容器，贼方便。
|
|
88
ShareDuck 2022-06-24 11:15:02 +08:00
我认为容器没有泛滥，但微服务泛滥了。
|
|
89
ecloud 2022-06-24 11:47:37 +08:00
@tairan2006 我哪里说错了，不就是 playlinuxonlinux 嘛。咋地你还要跟异构 ABI 比性能？你还要不要脸了？同构的是 chroot 你敢比还是 jail 你敢比？甚至 AppImage 你都不敢比。
你先把同构 ABI ，异构 ABI ，userland VM ，kernel VM ，cpu VM 几个概念先搞清楚吧。把 wine 叫“虚拟机”还停留在管手机里的 HD 叫“内存”的程度。 |
|
90
tairan2006 2022-06-24 12:02:35 +08:00 via Android
@ecloud 行叭 你牛逼 大家都是炒作概念 二进制刻光盘才是大牛行了吧。
|
 |
91
xuanbg 2022-06-24 14:30:59 +08:00
容器化不等于微服务，但微服务需要容器化。容器化没坏处吧？自从容器化以来，不容器化都有点不会了。。。
|
 |
92
qianhun 2022-06-24 16:38:48 +08:00
容器其实是个特殊的进程，把进程放进了 namespace 的隔离环境中，通过 cgroup 去限制资源的使用，容器化虽然带来了复杂性，但是可以隔离进程，减少进程间的相互影响，同时解决了运维的 CICD 部署繁琐的问题。
微服务把一个大型的项目拆分成多个小的服务，微服务松耦合，扩展方便，开发更灵活了。 容器化泛滥并不是错的，搞微服务也不是错的，技术都是好技术，要考虑使用的技术符不符合当下 |
Select Language