This topic created in 1976 days ago, the information mentioned may be changed or developed.
目前公司技术基础比较羸弱
外面给的方案是这一套
但我个人认为这只是谈架构的东西
如果用户不到一定规模似乎，没有必要
外面给的方案是这一套
但我个人认为这只是谈架构的东西
如果用户不到一定规模似乎，没有必要
 |
1
lecher Dec 7, 2020  14
有专职的人员维护这套基础设施吗？
没有的话，公司愿意为这套基础设施投入人力成本和机器成本吗？ 要是都没有，谁来背这套基础设施玩不转的的锅？ 做为技术人员，碰到这种新技术能实践，应该感到兴奋才对。选择成本恰当的技术方案应该是架构师头疼的事情，普通开发难道不是恨不得把业界最新方案全用上，好堆简历背景吗。 |
 |
2
loliordie Dec 7, 2020 via Android
不适合 小团队初期用 django 加 react 撸一套方案就完事了 如果跨平台就用 flutter 或者 kotlin 你们应该考虑的是开发难度而不是扩展性 因为不管你们怎么搞发展到一定规模都是要重构的 对于你们而言快速上线和敏捷开发是第一位的
等你们业务成熟了 再来考虑这样重一点的架构 不然很容易被拖死 |
 |
3
tesguest123 Dec 7, 2020 via iPhone
搞半年搞不下去跑路，🐶。
|
 |
5
Leigg Dec 7, 2020 via iPhone
你都说了技术比较弱了，你还搞这套架构那不是坑你自己，还坑了公司。
|
 |
6
coderxy Dec 7, 2020
小公司单体就可以了。
|
 |
8
wg20080215 Dec 7, 2020
有 10 前端+后端开发没？没有就直接单体就够了。
|
 |
9
kingfalse Dec 7, 2020 via Android
鲁迅说过，不要为了用而用
|
 |
10
glacial Dec 7, 2020
讲实用性 单体集群模式足以, 小团体搞微服务 基本上不是技术上的考量 ，而是商业上的考量，不搞微服务 不高大上 不好与别人讲 不好卖钱
|
 |
13
MaxFang Dec 7, 2020
@monkeydev 小团队搞这些东西投入产出比不合适。拆的过小，增加维护难度，可能多个服务是同一个人开发，小团队拆分的边界划分也是需要业务组织上分工清楚。小团队几乎没有人来弄这个东西。 不拆分，做好模块接口隔离也是可以的呀，做到底层业务模块是独立的。
|
 |
14
hantsy Dec 7, 2020
DevOps 跟不上，做不了自动化运维，全部靠人肉运维，还是别想了，额外付出的代价即使天天加班也不够补偿。
|
 |
15
SuperManNoPain Dec 7, 2020 via Android
得不偿失🌝🌝
|
 |
16
statement Dec 7, 2020 via iPhone
可以呀。 面向跳槽编程
|
 |
17
lfzyx Dec 7, 2020
运维这块可以交给专业的公司来做
|
 |
18
wdwwtzy Dec 7, 2020
不适合，太麻烦了
|
 |
19
monkeydev OP |
|
20
monkeydev OP 联系方式：c3Zlbml0eQ==
|
 |
21
liununu Dec 7, 2020 via Android
上了 k8s，就不要用 Spring Cloud 那一套笨重的东西了，k8s 生态里都有链路追踪和远程调用的替代方案。至于微服务也应该贴合具体业务上下文的关系来，如果每个业务都拆开，维护成本提升会大于利处，徒增消耗。
|
|
23
loliordie Dec 7, 2020 via Android
@monkeydev 在并发不高时 可以通过 redis 队列实现 搞几个队列 然后根据不同模块开 worker
比如 heroku 这种集成化的平台 add 一个 redis 然后根据模块开项目即可 起码这个架构 我们目前上千的并发 没啥压力 |
 |
24
namelosw Dec 8, 2020
如果可以预见的未来还是小团队的话, 单体就好, 部署的话搞个 PaaS. 你说的这些可以搞, 但是对于小团队来说就是凭空创造工作岗位.
|
 |
25
cyssxt Dec 8, 2020
没有必要的，单体应用就可以了
|
 |
26
S4msara Dec 8, 2020
不建议，上上家公司小团队，上了整套微服务方案，docker, k8s, cloud，当时我也觉得诧异，以我个人的拙见其实单体就可以，用户量上来了做单体集群即可。后来公司倒闭，发现团队 leader 是面向跳槽编程，害人不浅，当然，老板错误估计公司发展是主要问题
|
 |
27
catror Dec 8, 2020 via Android
微服务，和模块拆分功能拆分没有强相关性
|
 |
28
autogen Dec 8, 2020
cdn+nginx+springboot+redis+mysql
每分钟请求量小于 3000 的，用这套就可以了 |
 |
29
799635347 Dec 8, 2020
没必要，一个 SpringBoot 他不香么
|
 |
30
Lonely Dec 8, 2020 via iPhone
单体集群也可以用 k8s，cloud 那套倒不是必要的
|
 |
31
sampeng Dec 8, 2020 via iPhone
适合。堆简历跑路用
|
 |
32
dayeye2006199 Dec 8, 2020
取决于业务是什么。我目前的公司只有两个人，但我们是做 服务和计算集群管理的，所以使用这个架构基本是唯一的选择。如果是 CRUD boy 就没必要了。django，react 前后端做个分离，一把梭了
|
 |
33
jwangkun Dec 8, 2020 1
我们技术团队目前 20 人，外包团队加起来有 80 人左右，目前就是 SpringCloud+K8s 这一套。目前是我在主推，前期是需要花点时间来做一些基础的工作，但是对于后期来说节省了太多的时间成本，没有用过就没有发言权，那些劝你别上的，估计自己也没用过，而且上 k8s 对于开发人员来说是无感知的，至于 Springcloud 我们用了三年了，你会了 Springboot，业务大了自然后拆分，看你业务的复杂性，我们单体和 SpringCloud 都有，具体业务选择不同的架构，只要做大，上微服务是必须的，就看你们现有业务体量了
|
 |
34
xuanbg Dec 8, 2020
微服务可以搞，k8s 没必要。
楼上说小团队搞不来微服务的，我表示我一个人就搞起来了。根本没什么难度，开发反而更简单了。 |
 |
35
rapperx2 Dec 8, 2020
个人觉得和公司大小无关，看项目吧。像我们公司 10 人以下。其中一个项目最好的架构就是微服务。不管从那方便都是最好的选择。 这个项目最大的特点就是增长用户数快，前期如果不这样做，后期做架构升级，时间是不够的。而且经常需要第三方扩展
|
 |
36
ArJun Dec 8, 2020
看公司前景，公司用户多、上升快有必要用，还有有些公司融资会拿这些做噱头也有必要
|
 |
37
ThisDay Dec 8, 2020
像楼上说的，作为研发应该是好事啊，方便堆简历~
|
 |
39
a719031256 Dec 8, 2020
项目后端人数在 10 人以上可以考虑微服务，10 人以下还是算了，没必要
|
 |
40
ChevalierLxc Dec 8, 2020
看到小团队 那就算了
|
 |
41
zhanlanhuizhang Dec 8, 2020
|
 |
42
f6x Dec 8, 2020
k8 成本很高的.
人家给你的复杂方案,等你折腾半年弄懂了, 最后会发现有价值的就是服务里那几十行 php 代码. 哈哈哈. |
 |
43
yedan1206 Dec 8, 2020
不适合
|
 |
44
lamesbond Dec 8, 2020
要是能上就偷着乐吧，刷简历美滋滋
|
 |
45
q447643445 Dec 8, 2020
同意楼上的. 也就刷刷简历有作用. 实际用起来. 大半时间在维护上. 成本巨高
|
 |
46
securityCoding Dec 8, 2020
外面给的方案靠谱不 , 不如直接上 a 家的 edas 啊,我们公司在用挺不错
|
 |
47
fx Dec 8, 2020
|
 |
48
salmon5 Dec 8, 2020
面向跳槽编程，可以可以
|
 |
49
jasonkayzk Dec 8, 2020
写个 Hello-World 需要用 k8s +Spring cloud +微服务吗？
如果是为了学习，怎么折腾都可以； 如果是商用，不建议折腾，你会发现大部分时间都浪费在了运维上； |
 |
50
fengliu222 Dec 8, 2020
阿里云、腾讯云、aws 和 gcp 都有现成的 k8s 基础服务，腾讯云好像还是免费的，配置一套下来也就几个小时，成本并不是很高。
个人认为，超过三个人就需要架构，这是在降低风险而不是炫技。 是否需要微服务和 Spring Cloud 是要看你本身业务形态的，大家不知道你业务的需求，也没法给你最适合的答案。 |
 |
51
Ravenddd Dec 8, 2020
不是用微服务, 那就单体部署, 代码分模块即可, 以后转换微服务也很方便
|
 |
52
renmu123 Dec 8, 2020 via Android
小团队用微服务，k8s 没什么意义。用户起不来纯粹就是浪费，何况你们基础差，前期服务器不够加一台就是了，还是先把产品做做好吧
|
 |
53
adspe Dec 8, 2020
不合适
|
 |
54
CoderGeek Dec 8, 2020
小团队先活下去，量上来了在考虑这些
|
|
55
CoderGeek Dec 8, 2020
先代码上分层分模块即可
|
 |
56
w0nglend Dec 8, 2020
可以上没问题我们就是小厂（ PS，可以联系我远程支持，逃。。。）
|
 |
57
beneo Dec 8, 2020
本司从 k8s + springcloud + 微服务，直接搬到了阿里云 sae + 云效，不知道有多爽，以后程序员不用专职运维了，多花钱了吗？当然贵一点点，但是交付效率 biu 的往上涨
|
 |
58
snail00 Dec 8, 2020
我们后端开发不到 10 人, 架构经历是 tomcat+war => spring boot => spring boot + docker => spring boot + 阿里 k8s => spring cloud + nacos + 阿里 k8s , 以上历时一年半
|
 |
59
zoharSoul Dec 8, 2020
k8s 就不需要 spring cloud 了, spring boot 就够了
|
 |
60
a398058068 Dec 8, 2020 1
单体够用就单体，如果非得上 单独 k8s，如果非要熔断 限流这些 直接上 istio + spring boot 。 下下策是 spring cloud +k8s
|
 |
61
zc1249274251 Dec 8, 2020
没有足够的技术积累 会把自己坑死 而且根据现有业务发展基于现有技术基础 做一定的预估 再去调整技术方案 如果没有那么大的量 负载加单体都可以 一点点去迭代都可以
|
 |
62
ElmerZhang Dec 8, 2020
除非团队里有人对这些东西非常熟，能 cover 各种问题，否则还是不要去碰这些“高大上”的东西了。
如果公司有钱，直接招更牛的人来做架构带团队。否则还是会啥用啥最靠谱，只要能实现需求就好。 另外，对于完全不了解你们团队和业务上来就直接说该用 XXX 的，最好都直接忽略。 |
 |
63
kevinwan Dec 8, 2020 via iPhone
我们最早支撑小几百万日活时后端只有 6 个人，全部基于 k8s，使用自研 go 框架
|
 |
64
matatabi Dec 8, 2020
适合，这些都能为自己的简历加分
|
 |
65
iyangyuan Dec 8, 2020
这套架构，业务还没开始做，至少已经跑满 10 台服务器了
|
 |
67
devehx Dec 8, 2020
我们公司现在只有 3 个后台，运维也没有，居然搞了个微服务写后台管理系统，拆成了几个模块，全部部署到一台机器上，我都不知道做微服务有啥意义，增加了很多写代码的工作量。感觉小团队最好不要搞这玩意儿
|
 |
68
yalin Dec 8, 2020 1
听说的大佬话语：康威法则；架构是演化出来的，不是设计出来；没有银弹。
|
 |
69
0bit Dec 8, 2020
没必要着急上 k8s，但是容器化可以先做，12 factor 可以先搞起来（ https://12factor.net/zh_cn/），有这个基础之后，后续想迁移也容易了。
|
|
70
0bit Dec 8, 2020
链接 Bug 了：
https://12factor.net/zh_cn/ |
|
71
kevinwan Dec 8, 2020 via iPhone
@halk 后来开源了呀，github.com/tal-tech/go-zero
|
 |
72
muskill Dec 8, 2020
我们用 swarm +spring cloud ,搞得我这个后端开发都快变成运维了,真心建议:人员不多的小公司,不建议项目搞得太复杂,心累
|
 |
73
lavvrence Dec 8, 2020
Kubernetes 成本也不会非常高；但是如果用了，目测 10 年技术栈不会落后，K8s 的长尾效应带来的时间收益很高。
|
 |
76
kennylam777 Dec 8, 2020
一個人搞的 K8s 都比十個人維護 Swarm 強，勸退+1
|
 |
77
ydpro Dec 8, 2020
搞不搞这个技术栈看你们是赚投资者的钱还是赚用户的钱
|
 |
78
ren2881971 Dec 8, 2020
别折磨自己。
|
 |
79
vanityfairn Dec 8, 2020
DevOps 没有的话，我赶脚不得行噢，最后还是搞自己。技术薄弱么，单体不香吗？怎么简单怎么来，用户量上来以后，无论怎么样，还是会重构的。。。不然前期这么重，真滴累死
|
|
80
muskill Dec 8, 2020
@kevinwan @jaylee4869 二位说的很对,目前也在努力学习 k8s 中
|
 |
81
LichMscy Dec 8, 2020 1
我们团队现在运行维护着一整套的 k8s 平台和微服务平台，遍布全球十几个数据中心，拥有 20+套集群，最近还合并了另一个团队的 devops 平台，感觉应该有点发言权
其实用 k8s 和团队大小没有强对应关系，团队小就找两三台虚拟机搭一套小集群满足需求即可。我理解微服务所利用的 k8s 特性主要是实现滚动更新、灰度发布以及 hpa 等，还可以利用 cicd 工具一键发布，这些特性不用 k8s 甚至不用 springcloud 都能实现，只是现有比较成熟的方案的确是 k8s+springcloud 微服务。我建议楼主从最小需求做起，切忌过度架构，构建出的组件稳定可用满足最低需求即可。 可以理解基于 k8s 的模块是一套 paas 平台，基于 springcloud 微服务的模块是 saas 平台(当然我们也基于 istio 构建了一套 service mesh 模块，那个才是真正的 sass 平台）。如果从开发角度，专注实现 saas 平台的基本功能就可以了，往后团队大了，面临的问题还有日志采集，服务监控，链路追踪，网关路由，容器网络管理，底层计算资源维护等等等等。 TLDR：最小化架构的话只要能给开发部署和发布版本带来便利即可，比如使用 jenkins/搭建 k8s 进行容器化的初步集成 /使用 k8s 滚动更新 /进行微服务改造并搭建 eureka 和 gateway 管理所有的微服务等等；再发展下去就可以考虑构建一个微服务平台（ SAAS ）来管理整个微服务的生命周期，包括链路追踪 /API DOC/服务间调用 /配置中心 /分布式事务等等；最终就是一整套 k8s 管理 /微服务管理 /Devops 管理的覆盖开发全开发生命周期的工具链集合。 |
 |
82
ming7435 Dec 8, 2020
没有千万级的业务规模强行上这种技术方案简直就是找不自在
|
 |
83
vcode Dec 8, 2020
k3s，k0s
|
 |
84
zardly666 Dec 8, 2020
我司因为服务端语言很多，py node.js java 所以是 k8s 集群的微服务。感觉花一点时间熟悉以后，用起来很舒服
|
 |
85
zunceng Dec 8, 2020
|
 |
86
wizzer Dec 8, 2020
小团队，建议使用我的 https://budwk.com 框架，有微服务版本也有 mini 单应用版本
|
 |
87
wupher Dec 8, 2020
看团队水平， [小] 不影响技术使用，但是技术薄弱就不适合了，K8s 有问题，要能自己搞定的。
这种情况下，直接用云计算，多专注业务实现挣钱。 |
 |
89
JohnSmith Dec 8, 2020
上云
|
|
90
JohnSmith Dec 8, 2020
上共有云
|
|
91
xuanbg Dec 8, 2020
微服务也可以很简单。一个最简单的微服务，就是注册中心+配置中心+网关而已。需要写额外的代码吗？不需要！都是 pom 引入一个包，然后启动类一个注解，配置文件几行配置就完事。最后就是需要在配置中心分别对每个服务做一下配置。就这点事情，百度一下最多 1 天功夫就搞定了，压根没有什么难度好吧。
|
 |
92
twinsdestiny Dec 8, 2020
duck 不必
|
|
93
dayeye2006199 Dec 9, 2020
问个问题：用了 k8s 为啥还需要 spring cloud ？自带功能，最多加个 istio 就能覆盖各种特性了，而且还是语言中立的，支持各种语言写的服务。
|
 |
94
zarte Dec 9, 2020
搞这一套有问题谁加班弄？能简单就简单别像有些自以为是的程序员，到时一堆坑还要别人搽屁股。
|
 |
96
ericgui Dec 9, 2020
github 其实到了很大的规模的时候，还是 ruby on rails 单体
|
 |
97
dorothyREN Dec 9, 2020
不如先想想 你们的项目 值得上微服务吗
|
 |
100
dadagogogo Apr 27, 2021
@muskill 感同深受啊
|
Select Language