- 主题:微服务带来了新的问题
外包项目瞎用啥微服务，业务复杂到那个程度了吗，团队大到那个程度了吗，真要到了那个程度，还不自己建团队来搞，那纯属把自己的饭碗放别人头顶。
【 在 changtuiniu (此id已换人) 的大作中提到: 】
: 一个项目动不动几十个进程，客户方服务器受不了，明确要求进程数不能超过一定数量，要求我们合并服务
: - 来自 水木社区APP v3.4.2
--
FROM 221.220.225.*
docker又不会减少你的进程数量，反而会增加
【 在 licy (上网不便, msg收不到) 的大作中提到: 】
: docker啊
--
FROM 221.220.225.*
微服务和docker完全两个方向，正交的
docker可以说我扔一个给你就完，微服务怎么可能呢，一堆依赖在那里呢，微服务往极端了说，其实是交付给自己，如果还是烟囱模型，指望扔一个image给运维，开发就下班撸串去了，十有八九都是做梦。
【 在 guestking (无) 的大作中提到: 】
: 其实微服务和git关系不大
: 我的观点是，微服务，或者说是docker，最大的作用是改变了交付方式
: 现在越来越少听到诸如“在我这里是好的啊”这类的话了
: ...................
--
FROM 221.220.225.*
所以这种项目完全没有微服务的必要，客户的要求蛮合理的，开发运维资源节省下来多做几个功能他不香吗
【 在 changtuiniu (此id已换人) 的大作中提到: 】
: 多年的产品积累，你想做就能做的吗？1千万左右的标不大不小
: - 来自 水木社区APP v3.4.2
--
FROM 221.220.225.*
也许机架资源紧缺呗，其实更可能是运维看甲方部门不爽，什么破业务跟运维kpi又不挂钩，搞这么多进程监控、部署都要运维来搞，这一千万又没运维什么事情...
【 在 guestking (无) 的大作中提到: 】
: 随便砍掉点人日就够买很多服务器资源了
--
FROM 221.220.225.*
如果部署自动化了，监控自动化了，运维只是维护这些平台，那就不是运维干啊。
部署变成开发自己主导，运维只是给你搭台子，自己的业务自己管，运维才不会关心你多少个进程。
如果仅仅是微服务了，结果运维的工作增加十几倍，你是运维你乐意么。
【 在 guestking (无) 的大作中提到: 】
: 不管是什么部署方案，最终不都得运维么
: 是嫌部署单元太多运维起来麻烦？
--
FROM 221.220.225.*
你那是os大，选个alpine的，几十M而已，况且即便是几百M也不是每次都要传所有layer
【 在 Donaldcuc (Donald) 的大作中提到: 】
: 而且jvm的docker 随便就好几百兆
: 微服务大家都可以需要，和语言关系不大，主要是和领域模型有关
: java最不需要docker，这点倒是部分同意
: ...................
--
FROM 221.220.225.*
这就是思路还没转过来，开发当然要管业务，作为开发你的价值在哪里，如果仅仅是出了问题上去处理，那就把自己定位成救火队员呗，成天处理问题，你怎么做向上管理，特别是微服务以后，链条可能很长，你自己都不关心自己的业务，谁又会关心你的业务到底发挥了多大作用。
【 在 nikezhang (难得糊涂) 的大作中提到: 】
: 开发还要去管业务的话开发也不太乐意，一般开发都是出问题了才上去看看
--
FROM 221.220.225.*
分几层是你自己设计的啊，如果你的依赖比较稳定，完全可以分出去。
退一步说，别的部署方案你不也得传这么多东西么，如果别的方案能摘出来少传点，docker也可以
【 在 Donaldcuc (Donald) 的大作中提到: 】
: 用alpine，加上程序也時不時超200M，除了基礎鏡像，layer只有一個。。。 可能是我們優化的有問題吧
--
FROM 221.220.225.*
看楼主的描述，大概率不会有k8s这种近现代的东西，物理机裸部署的可能性很大
【 在 childewuque (childewuque) 的大作中提到: 】
: lz这个不是说的几十个进程吗？这是什么问题
: 如果是k8s node一个节点几十个进程，这个数不是非常小吗？
--
FROM 221.220.225.*