
1.使用微服务框架 2.直接 k8s 不知道大家生产环境 golang 的微服务方案怎么做的,希望一起讨论学习下
1 SethShi 2024-06-28 09:58:18 +08:00 1. go-zero 2. k8s |
2 coderxy 2024-06-28 10:05:37 +08:00 微服务框架在 k8s 内部署。 |
3 concernedz 2024-06-28 10:07:59 +08:00 k8s |
4 shakaraka PRO 1 、go-kratos 2 、k8s 、k3s |
5 koala9527 2024-06-28 10:23:54 +08:00 gin+consul+阿里云 ACK |
6 mightybruce 2024-06-28 10:26:02 +08:00 简单的直接用 k8s , 复杂一点的通过 istio 改造 |
7 lavvrence 2024-06-28 10:28:16 +08:00 好奇怪的问题,K8s 和业务没什么关系啊,只是用来做 declarative 运维的。 |
8 fakerqtter 2024-06-28 10:28:50 +08:00 字节的 hterz + kitex 可以考虑下 |
9 mightybruce 2024-06-28 10:53:05 +08:00 现在连过去大型国企的 java spring cloud 都在改造为 service mesh, 还搞微服务框架真的是逆历史潮流。 service mesh 多数还能尽可能做到无侵入式, 微服务框架能有几个做到。 看看蚂蚁金服的 sofastack ,istio 和 微软的 dapr 吧。 相关报道很多很多 https://www.sohu.com/a/508786560_515599 |
10 chinaguaiu 2024-06-28 11:46:37 +08:00 |
11 szdev 2024-06-28 12:01:24 +08:00 一个项目一个镜像,k8s 多 pod 发布就可以了,大部分企业完全够用 |
12 wenyuhe 2024-06-28 12:01:39 +08:00 @jaylee4869 dns 作为服务发现注册也算吧 |
13 wenyuhe 2024-06-28 13:35:56 +08:00 看了下正文)微服务上不上 k8s 并没啥关系。直接一个服务一个 vm 我也见过,不上 k8s 好处就是没学习成本,坏处就是资源浪费。至于运维 cicd 弄好了都一样 |
14 LanLiang 2024-06-28 15:15:54 +08:00 springcloud 和 service mesh 并不是替代的关系,架构是会演进的,springcloud 仍然适合大多数中小企业 |
15 coyove 2024-06-28 15:29:50 +08:00 冷知识,蚂蚁 sofa ,字节 kitex ,但内部的核心应用都是巨型单体(编译产物几个 g ,分钟级启动时间) 所以如果你是一个人,建议一把梭 |
16 zzhaolei 2024-06-28 15:40:28 +08:00 微服务架构并不适合中小企业。推荐用 gin ,负载均衡。(面向简历编程,当我没说。) |
17 whrss9527 2024-06-28 18:11:48 +08:00 @jaylee4869 作为配置管理也算吧 |
18 DefoliationM 2024-06-28 18:36:55 +08:00 via Android grpc+etcd ?不推荐 go-zero ,bug 多,难维护。其他的没用过。 |
19 maocat 2024-06-28 20:17:05 +08:00 via iPhone 大道归一,单体项目,前后端不分离 |
20 maigebaoer 2024-06-28 20:21:52 +08:00 via Android 首先问,不用微服务行不行?行?那用它干嘛呢。 |
21 morebuff 2024-06-28 22:35:31 +08:00 单体 YYDS |
23 byehair 2024-06-29 00:53:00 +08:00 @coyove 如果我没理解错,你说的是这个是大仓模式,但其实,只是项目代码是一个单体,编译是一个单体,但服务是可以按需启动的。 腾讯内部很多项目也是采用大仓模式 |
24 bzj 2024-06-29 01:34:37 +08:00 grpc+consul ,说 k8s 的都是运维吧 |
25 kkk9 2024-06-29 02:42:51 +08:00 99%的公司不需要 k8s |
26 R4rvZ6agNVWr56V0 2024-06-29 05:32:31 +08:00 Dapr |
27 jackge0323 2024-06-29 06:29:56 +08:00 不用框架,需要什么自己简单封装一个就可以了。 |
28 Int100 2024-06-29 06:31:32 +08:00 用微服务平台,还是 k8s ,取决于公司/项目组的运维能力以及架构考量。 上个月碰到的一个西门子的项目组,就是 all-in AWS ,完全不搞 k8s ,但也说了内部有其他部门选择维护自己 k8s 集群。 |
29 Cola98 2024-06-29 08:33:47 +08:00 grpc+k8s |
30 homewORK 2024-06-29 10:35:58 +08:00 @DefoliationM 能细说一下吗? 因为个人项目刚开始用 go-zero 。go-zero 目前只是感觉有点臃肿。 |
31 DefoliationM 2024-06-29 10:55:14 +08:00 via Android @homewORK struct 不支持 time.Time ,自带的(生成的代码) json unmarshal 有严重 bug ,某些情况会没有值。生成的代码又乱又多,前期代码少的时候还好,后面多了没法维护。还有其他很多问题已经不记得了。 后面就是发现什么的问题,就把它自带的组件换成自己写的。所以还不如一开始就自己把所有东西弄好,不用这玩意。 |
32 DefoliationM 2024-06-29 11:02:46 +08:00 via Android @DefoliationM 而且这东西更像 Java 搞得那一套,什么东西都搞得又臭又长,真的一言难尽。 |
33 tangqiu0205 2024-06-30 17:32:00 +08:00 kratos + k8s, 目前这套用的很爽. |
34 dayeye2006199 2024-07-01 05:38:54 +08:00 微服务和 go 也没啥关系。 就是拿 go 写个服务,然后外面整个 k8s 把几个服务穿起来。 grpc + protobuf 随便撸啊 |
35 changz 2024-07-01 13:29:13 +08:00 via Android kratos 二开 |
36 wenyuhe 2024-07-01 16:54:24 +08:00 @timothyye iac 编排也可以,其实小公司 k8s 不一定是最优解可能会是最差解;甚至伸缩也不一定是需要。至于微服务的话,我觉得刚开始最好别怎么拆。前期拆两个(用户中心+主业务)就是够了,然后生成 http 接口直接给前端。 |
37 konakona 2024-07-04 12:48:28 +08:00 1. go zero 中文友好 2. kubernetes 或 TKE 3. +CI/CD+helm |
38 qloog 2024-07-04 23:08:47 +08:00 eagle + docker image + k8s protobuf -> http + gRPC(服务间) 大部分 脚手架直接生成 PS: https://github.com/go-eagle/eagle |
39 securityCoding 2024-07-08 19:30:30 +08:00 trpc+k8s |