随便砍掉点人日就够买很多服务器资源了

【 在 changtuiniu (此id已换人) 的大作中提到: 】
: 我们也这么想，人说他们几十个项目在跑呢，实际上就是某大证券公司，机房每天还要保证交易软件优先，我们这种属于后台项目要让位于交易软件
--
FROM 180.167.95.*

他们是机房的机柜都塞满了，不能添资源了吗

【 在 changtuiniu (此id已换人) 的大作中提到: 】
: 机房资源整体调配
--
FROM 180.167.95.*

这种一千万的标，肯定是带全套运维工具的，或者对接到已有的运维工具上面

【 在 sayinger (言者) 的大作中提到: 】
: 如果部署自动化了，监控自动化了，运维只是维护这些平台，那就不是运维干啊。
: 部署变成开发自己主导，运维只是给你搭台子，自己的业务自己管，运维才不会关心你多少个进程。
: 如果仅仅是微服务了，结果运维的工作增加十几倍，你是运维你乐意么。
: ...................
--
FROM 180.167.95.*

如果是这样的话，拆成微服务就很好

【 在 rimer (胖拖拖) 的大作中提到: 】
: 呵呵，这个还真不担心，因为根本没有服务间互相调用的情况，调用链很短：客户端->服务->数据库。每个服务功能单一，可以单独更新吧。这次合并也只是针对测试这一块，生产环境还是多进程，毕竟线上内存不是大问题，未来因为要上k8s有进程数限制这个变化也有用。
--
FROM 180.167.95.*

如果只是密码的话，那根本不需要k8s
启动命令里面加参数就好了
或者搞个配置中心，简单点zk之类的就行了

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 我们目前是的。实际上不使用密码，配置到只验证 IP 段。
: 不过改动一下也太容易了，编译脚本里面让布署的人输入一下密码就行了。这种方案的布署都是由脚本控制的，提供的能力并不会比 k8s 图灵不完备的描述文件差。只是有些事情麻烦，有些事情方便，各有优劣。
: 并不是鼓吹 k8s 没用，说的是对于中小项目，应该寻求 k8s 之外的方案。
: ...................
--
FROM 180.167.95.*