这是一个创建于 535 天前的主题，其中的信息可能已经有所发展或是发生改变。
发现这个现象蛮普遍的，特别是中小公司。就是公司有资源，大多数时候部署到客户现场，对方也只提供 1 台虚拟机。
而且基本上开发团队也不大，一般前端、后端，架构之类全算上也就 5 人左右的团队。那这样的收益真的明显吗？
难道只是为了体现架构的先进性？
 |
1
magicyao 2023-05-31 15:11:20 +08:00
项目高级，别人更愿意买
|
 |
2
ggabc 2023-05-31 15:13:32 +08:00
说不定什么业务能做大，只是给做大时候留个活路能轻松扩展庞大的集群
|
 |
3
liuhuansir 2023-05-31 15:19:08 +08:00
我司的运营商项目，各种微服务、容器化部署，年底验收完就 OK 了
|
 |
4
limaofeng OP 发现小团队上这种 SpringCloud + k8s 整个团队也就架构懂。换人都吃不消，小白出问题都不知道该如何下手
|
 |
5
opengps 2023-05-31 15:24:03 +08:00
单一完整性也是个优势吧，总比跟其他项目混用数据库、混用缓存、混用存储合适
|
 |
6
potatowish 2023-05-31 15:27:29 +08:00 via iPhone
正常，多数人不会考虑真的合适，而只会从自己的利益作为出发点。公司需要包装产品在 PPT 中大吹特吹，技术人员既需要 KPI ，又需要丰富自己的技术栈，便于下次跳槽
|
 |
7
hhjswf 2023-05-31 15:30:00 +08:00 via Android  1
“万一以后做大了呢”
|
 |
9
zhch602 2023-05-31 15:41:51 +08:00
https://github.com/ServiceWeaver/weaver google 开源的框架，可以解决这个问题，目前只支持 go ，后面会支持 Java
|
|
10
limaofeng OP 1
@Scirocco 以我十多年干黄一众微服务架构项目的经验来说，不是说没机会，只能说机会渺茫。特别是做新产品研发的
|
 |
11
Dream95 2023-05-31 15:52:35 +08:00
不用问，肯定是搞 Java 的
|
 |
12
coderxy 2023-05-31 15:55:06 +08:00 1
就是想简简单单炫个技，没毛病。
|
 |
13
KiraMaple 2023-05-31 15:55:19 +08:00
要注意 k8s 是运维工具，很多小公司是为了这个工具才微服务化，否则自己用单机，运维的一套工具都得自己弄或者用老掉牙的甚至都没咋维护的一些东西。重点是选 k8s 做运维工具，出问题好歹你还挺好查资料的，即使里面的坑你踩了也算经验后面也能用，自己写得工具或者一些老掉牙没咋维护的运维工具，可能真的这家公司用了，以后都不会再用了。而且用 k8s ，你自己省很多文档，新来的人不会自己查网上资料学，只有自己定制的部分需要写写文档。
|
 |
14
weiweiwitch 2023-05-31 16:25:50 +08:00
正如 13 楼说的，k8s 是运维工具。最大的好处是让开发和运维以及机器环境解耦了。沟通成本极大的降低，容错率也提高了。
我们之前一个项目要上某大厂的平台。对面一个运维要负责很多项目。他们的环境也是对我们隔离，不允许我们接触的。然后我们和他们之间的沟通缓慢的不行。一个问题抛过去，可能要第二天才回答你。一个部署说明文档给过去，可能要下个礼拜才会有答复。他们运维还要学习项目架构，编写各种适配我们项目的部署脚本等。然后资源的协调和变通都是各种问题。这个不允许，那个没有。 后来我们看他们有 k8s 环境，就花时间将项目转换到容器下运行。问他们要了点 k8s 环境相关的参数配置，要了个仓库，我们自己搞定了 helm 配置，给他们。基本很快就跑起来了。 我们自己还能在内网搭建类似环境测试好了给他们。大规模环境下，我们项目还不用考虑节点通讯的复杂网络问题。省事很多。 关于单机测试环境，单机环境本身已经不考虑高可用了。部署一个 k8s ，照着笔记文档看看，其实很容易的。 复杂环境或者正式环境。对外的话，可以直接买云服务。只提供内网访问的，把事情完全交给运维就行了，开发基本没啥要参与的。 |
 |
15
nothingistrue 2023-05-31 16:39:57 +08:00
你得理解有偏差，相比与单机，微服务是部署架构麻烦，但技术架构简单。或者也可以说是实施架构麻烦但开发架构简单。大多数时候，实施成本是小于开发成本的，有时候甚至合同上都不体现实施成本，所以再小的团队，微服务架构都能带来收益。
还有一个偏差，中小公司+5 人以下的团队做得东西可不一定小。如果不是外包性质的开发而是做了往外卖，那么现在看起来的 5 人团队，算上历史开发人数可能是上百人。 当然需要注意的是，并不是所有的微服务都能使得技术架构变简单。像下面这两种微服务架构就是脱裤子放屁只会找麻烦：1 ，将层，例如 Service 、Dao 拆成微服务； 2 ，只拆代码不拆数据库，多个微服务操作同一个数据库。 |
 |
16
TyCoding 2023-05-31 16:45:16 +08:00
PPT 更好看
|
 |
17
encro 2023-05-31 16:51:57 +08:00
|
 |
18
x77 2023-05-31 16:56:47 +08:00
虚拟机不是长久之计吧，在虚拟机上开发、实验，大规模部署还得搬到 K8 上去
|
 |
20
JayZXu 2023-05-31 17:35:25 +08:00
用微服务架构的话，面对不同的小项目可以按需部署基础的微服务。精力放在业务本身就行了。
只能说这种模式对开发友好和大规模部署友好， 但是对于小体量的单机部署确实显得多余了。 |
|
21
limaofeng OP 看来 V2EX 的整体技术水平比较高，都是玩互联网的，起码高级或者架构师级别。我也是 16 年开始上 docker 19 年开始上 k8s ，也曾经强推运维搞这类架构，当然知道它的优点。但现实是，exe 程序包装的 Tomcat 对实施更简单。一般小公司，实施水平的下线是你们不能想象的。运维更是救火员，更别说很多根本没有这个职位
|
 |
22
pengtdyd 2023-05-31 19:07:09 +08:00 1
重要吗？？？？
就像月饼券一样： 送礼的人开心（有了面子）， 收礼的人开心（卖了能直接获得利益）， 月饼券回收商开心（可以赚差价）， 厂家开心（一盒月饼都不用生产就把钱赚到了）。 完美的闭环。 |
 |
23
xuanbg 2023-05-31 20:01:36 +08:00
不知道别人是不是，反正我是为了能够快速写一些纯业务 crud 代码就能上线。别的东西都封装成服务，一个脚本几分钟就部署完了。
|
 |
24
huzhizhao 2023-06-01 00:52:55 +08:00 via iPhone
不上我的简历怎么包🐶
|
 |
25
akira 2023-06-01 06:01:42 +08:00
自己做自己用当然无所谓了啊。
但是有甲方的话，那就是另外一个故事了，往小了说，可以多赚点，往大了说，搞不好你不是微服务单子都要丢。 |
 |
26
zhaokun 2023-06-01 08:24:21 +08:00 via iPhone
也有可能是写顺手了
|
 |
27
tgich 2023-06-01 09:22:28 +08:00
大多是一知半解的甲方要求的，反正你得吹，高可用微服务高内聚低耦合，小手一抖几万到手
|
 |
28
zhangtest 2023-06-01 14:18:44 +08:00
恕我直言，这一套都是搞 java 的把风气带起来的。
我上家公司，常年总用户量就 5 万左右，日活上千来个，招了个从招行出来的 java 技术头头，集群、注册中心、网关、具体服务都给来了一套，服务器成本指数增长，把原先做这个系统的 php2 个人辞退了，自己搞了 10 几个人团队，4 个 java 后端，老板不懂技术，别人反馈直接被顶回去“人家招行 APP 那么多用户都是他搞定的，要相信别人。。。” |
Select Language