关于微服务架构想请教下

1 月 18 日
 Kinnikuman

我是个前端,想学习下后端以及 devops ,懂点 docker ,懂点 linux ,自己写过 golang 和 nodejs 。自己搞的都是单体应用。

但最近公司有个项目(项目不大)使用了 Java 技术栈,也就是 spring boot 那一套,spring cloud, nacos, rabbitmq/kafuka, redis/pg/es 。

其中 redis/pg/es 是和语言无关的,不管是 Java, golang 还是 rust 都是基础设施。其中还包括一些没列出来的 minio/grafana 看板,预警通知等功能。

但关于微服务架构(nacos),有点陌生,没学过 Java ,所以想请教下论坛中的大佬,如果换成其他的语言,比如 golang node 等,是不是没有这种架构?或者说不流行这种架构?只有 spring boot 这种的才流行微服务这一套?

比如使用 serverless 的 cf worker ,把各种功能分散到各个 edge 节点上。

或者直接使用 k8s 来做具体的运维(项目够大/用户够多)。


我写的有点乱,不知道大佬们是否能 get 到我的疑惑。

4787 次点击
所在节点    程序员
28 条回复
dongdong12345
1 月 19 日
如果换成其他语言,能解决拆分后的各种各样问题,那也没什么问题,但拆分后产生的问题太多了,如果有现成的工具或组件让你使用倒是还好,只是有点学习成本。但如果没有现成的,你自己怎么解决呢?
spring cloud alibaba 这套已经被很多公司用于生产环境了,各种问题都有对应的组件或工具帮你解决,已经可以满足大部分企业了。
FrankAdler
1 月 19 日
这些东西还是去问问 ai 吧,随便找个哪怕文心一言可能都比发这个帖子强
Kirkcong
1 月 19 日
对于 k8s 和 docker ,发展过程大致是这样的:

1. 起初,dev 编写代码,编译成可执行程序传给 ops ,然后 ops 手动将程序 scp 上传至 Linux 服务器,并且安装所需的各种依赖环境,比如 jdk 1.7, nodejs 14 。对于一台新上线的机器,程序要部署上去还得考虑什么运行用户组、文件夹权限等问题。更恶心的在于,app A 的运行依赖 jdk1.7,app B 依赖 jdk 1.8,两者有冲突,得想办法解冲突。

2. 后来人们想,我们需要一种方式,把某个 app 和它运行所需要的环境全部打包起来,和外部隔离,这样不管里面要 jdk 1.7 还是 1.8,都能跑在任意 linux 环境中。于是,docker 诞生了,他不但做到了环境的隔离,还实现了环境的精简,——如果某个 app 只依赖 jdk1.7,那么这个 image 中只有 jdk1.7 这个依赖,其他什么都没有。

3. docker 发展到一定程度后人们发现,很多时候一套系统会依赖多个 container,比如前端一个容器,后端一个容器,还有个 mysql 数据库。此时,docker compose 诞生了,他可以让你在机器内部虚空创建一个网络,将这三个容器放在同一内部网络下连接在一起,运行时只需要 docker compose up 就可以启动一组 app.

4. 当 docker compose 里面的容器足够多且功能完善,比如,有的提供存储服务,有的提供监控服务,有的提供网络服务。那么此时,compose 的这些 app 内部,形成了一个功能完善的自治系统,内部和外部完全没关系。但遇到了另一个麻烦,这些儿容器太多了,compose 已经乱如麻绳了,此时 k8s 出现了。

5. k8s 的内部就是由多个容器为基础,组成的一个独立的自治系统,并且具有高可用、分布式等各种特点。需要 nfs ? pod 来提供;需要 metrics ? sidecar 进去监控每一个 pod ;你可以通过 yaml 文件定义各种配置,比如哪个 app 需要运行在所有节点上,比如 prometheus ;也可以定义 app A 和 B 跑在不同节点上,比如数据服务和业务;之前在 compose 的各种环境变量都可以放入 configmap 的一种 yaml 里,从这里加载进去。需要 ssl 证书也可以起个 k8s 版的 cerbot,给内部所有的 app 共享这个证书。

---

对于 devops:

devops 是用来解决传统开发模式上 dev 和运维协作问题的,比如 dev 开发完代码,本地编译,部署到生产环境。devops 将这一系列操作用 pipeline 连接起来,标准化的同时解决了安全性问题(比如谁手欠改错环境了。。。)


对于上面的 k8s 阶段,意味着会产生大量的 image,这些 image 有些是后端,有些是中间件,有些是前端。一个完整的对外服务可能后面有十来个微服务来提供的。此时如果再按照传统模式手动编译、制作 image 、上传到 harbor (自建的 docker hub )太麻烦了,根本来不及。

此时 pipeline 派上用场了,比如 jenkins ,和 github 对接,当某个 pr 合并后,自动触发 jenkins pipeline 启动这个流程,他会按照你定义的流程去打包并分发这个 image. devops 就是去用来实现这个流程的。
firefox12
1 月 19 日
我觉得你们写的 他肯定看不懂。

简单地说 有一个需求, 你需要用 20 个后端步骤来完成它, 你可以把 20 个步骤写在一个里面,但是太大了,所以拆成 20 个微服务,因为拆得小了 好维护。 微服务之间的通信其实是协议 和用什么语言无关。 而 nacos 只是管理微服务关系的一个基础服务, 也就是让这 20 个微服务 要知道去哪里找剩下的服务。 你完全可以用 golang 来实现 nacos 和取代 nacos, 但是这个也只是限于理论,实际没什么意义。 全套用 java 吧。
kxg3030
1 月 19 日
不建议微服务 这都 2026 了 一定要用可以使用 k8s 的 也可以自己搭建 注册中心( consul/zookeeper/nacos ) 配置中心( apollo )服务之间用 http 或 tcp 都行 再加个链路( jaeger ) 再加个分布式事务( dtm ) 再加个 elk 面板 好了 项目死了 重新找工作吧
Cruzz
1 月 19 日
自己搭一个就理解了,要不都是纸上谈兵
Gilfoyle26
1 月 20 日
人生建议:别搞 Java !!!
lujiaxing
2 月 19 日
@Gilfoyle26 不搞 java 搞什么, 炼金术么?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1186555

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX