微服务架构应用跑在单机上，为什么要搞这么复杂的架构

[limaofeng]

发现这个现象蛮普遍的，特别是中小公司。就是公司有资源，大多数时候部署到客户现场，对方也只提供 1 台虚拟机。

而且基本上开发团队也不大，一般前端、后端，架构之类全算上也就 5 人左右的团队。那这样的收益真的明显吗？

难道只是为了体现架构的先进性？

[magicyao]

项目高级，别人更愿意买

[ggabc]

说不定什么业务能做大，只是给做大时候留个活路能轻松扩展庞大的集群

[liuhuansir]

我司的运营商项目，各种微服务、容器化部署，年底验收完就 OK 了

[limaofeng]

发现小团队上这种 SpringCloud + k8s 整个团队也就架构懂。换人都吃不消，小白出问题都不知道该如何下手

[opengps]

单一完整性也是个优势吧，总比跟其他项目混用数据库、混用缓存、混用存储合适

[potatowish]

正常，多数人不会考虑真的合适，而只会从自己的利益作为出发点。公司需要包装产品在 PPT 中大吹特吹，技术人员既需要 KPI ，又需要丰富自己的技术栈，便于下次跳槽

[hhjswf]

“万一以后做大了呢”

[Scirocco]

#7 @hhjswf 确实是，突然哪一天用户量暴增，这样扩容应该方便点

[zhch602]

https://github.com/ServiceWeaver/weaver google 开源的框架，可以解决这个问题，目前只支持 go ，后面会支持 Java

[limaofeng]

@Scirocco 以我十多年干黄一众微服务架构项目的经验来说，不是说没机会，只能说机会渺茫。特别是做新产品研发的

[Dream95]

不用问，肯定是搞 Java 的

[coderxy]

就是想简简单单炫个技，没毛病。

[KiraMaple]

要注意 k8s 是运维工具，很多小公司是为了这个工具才微服务化，否则自己用单机，运维的一套工具都得自己弄或者用老掉牙的甚至都没咋维护的一些东西。重点是选 k8s 做运维工具，出问题好歹你还挺好查资料的，即使里面的坑你踩了也算经验后面也能用，自己写得工具或者一些老掉牙没咋维护的运维工具，可能真的这家公司用了，以后都不会再用了。而且用 k8s ，你自己省很多文档，新来的人不会自己查网上资料学，只有自己定制的部分需要写写文档。

[weiweiwitch]

正如 13 楼说的，k8s 是运维工具。最大的好处是让开发和运维以及机器环境解耦了。沟通成本极大的降低，容错率也提高了。

我们之前一个项目要上某大厂的平台。对面一个运维要负责很多项目。他们的环境也是对我们隔离，不允许我们接触的。然后我们和他们之间的沟通缓慢的不行。一个问题抛过去，可能要第二天才回答你。一个部署说明文档给过去，可能要下个礼拜才会有答复。他们运维还要学习项目架构，编写各种适配我们项目的部署脚本等。然后资源的协调和变通都是各种问题。这个不允许，那个没有。
后来我们看他们有 k8s 环境，就花时间将项目转换到容器下运行。问他们要了点 k8s 环境相关的参数配置，要了个仓库，我们自己搞定了 helm 配置，给他们。基本很快就跑起来了。
我们自己还能在内网搭建类似环境测试好了给他们。大规模环境下，我们项目还不用考虑节点通讯的复杂网络问题。省事很多。

关于单机测试环境，单机环境本身已经不考虑高可用了。部署一个 k8s ，照着笔记文档看看，其实很容易的。
复杂环境或者正式环境。对外的话，可以直接买云服务。只提供内网访问的，把事情完全交给运维就行了，开发基本没啥要参与的。

[nothingistrue]

你得理解有偏差，相比与单机，微服务是部署架构麻烦，但技术架构简单。或者也可以说是实施架构麻烦但开发架构简单。大多数时候，实施成本是小于开发成本的，有时候甚至合同上都不体现实施成本，所以再小的团队，微服务架构都能带来收益。

还有一个偏差，中小公司+5 人以下的团队做得东西可不一定小。如果不是外包性质的开发而是做了往外卖，那么现在看起来的 5 人团队，算上历史开发人数可能是上百人。

当然需要注意的是，并不是所有的微服务都能使得技术架构变简单。像下面这两种微服务架构就是脱裤子放屁只会找麻烦：1 ，将层，例如 Service 、Dao 拆成微服务； 2 ，只拆代码不拆数据库，多个微服务操作同一个数据库。

[TyCoding]

PPT 更好看

[encro]

@nothingistrue

想起以前在深圳做外卖平台，app+服务端+管理后台，就两个开发，
一个月也做好几十万流水，
做了一年然后我们觉得不赚钱放弃了，
第二年美团和饿了么就起来了。

[x77]

虚拟机不是长久之计吧，在虚拟机上开发、实验，大规模部署还得搬到 K8 上去

[roundgis]

@Scirocco 大部分的系統就那幾個人用

[JayZXu]

用微服务架构的话，面对不同的小项目可以按需部署基础的微服务。精力放在业务本身就行了。
只能说这种模式对开发友好和大规模部署友好，
但是对于小体量的单机部署确实显得多余了。