学习是一件违背人性的事情。“让她产生兴趣”，你是相信你孩子是天选读书人？

静电容吧

欢迎回重庆，重庆有个很恼火的点就是，如果你这份工作没了，你想有替代的，很难。

老三样吧，没什么特色，胜在稳定。
别人能钓到的，你也能钓到。别人钓不到，你也钓不到。

export http_proxy="http://127.0.0.1:1087"
export https_proxy="http://127.0.0.1:1087"

@zzz22333 支持+1

看看你所在的地区，有的地区，怎么都养不要，有的地方你不养也很好。

@okey 这个概念就是文科生扣脑袋想出来的。不具备实践意义。，

还有个点漏掉了，就是你做这一套，还有几个点需要明确，
1 、你们运维能力够不，做这一套，不管你是否容器化，必然涉及到大量的服务需要维护，这个部分的管理和治理是一个大问题。涉及到代码管理、流水线、服务发现、日志收集等等一系列的事情。需要你们的运维具有极强的能力。或者说运维具有一定的开发功底。或者你们有 devops 团队，或者就是全局 devops 化。
2 、你们的架构师或者 leader 能把握全局不？如果是一个狗屁不懂的领导，遇到需要决策的时候就知道和稀泥的话，还是别搞。

目前的场景是，需要对产品线的微服务进行整体重构，弄个中台出来，再拆出业务层，分两拨人维护。 （也是考虑到以后复用给其他产品线，有个打通整合的基础）
目前的场景是，需要对产品线的微服务进行整体重构 。可以，把服务梳理下，技术栈整理一下，架构清理下，很好。
弄个中台出来，再拆出业务层，分两拨人维护。 （也是考虑到以后复用给其他产品线，有个打通整合的基础）。这个事情，做不得。“分两拨人维护”，这是为将来买了一个大炸弹。如果两拨人，平级，那么谁听谁的？如果以某一拨人为主，那另外以拨人能听吗？
我推荐你以网关+服务的形式来做，以业务为维度做垂直切分。千万不要把一个业务分什么前台、后台。这是祸乱根源。

那是一个 C2C 的时代

推荐买个好点的被动的耳塞。不要主动降噪的。

不是很香

先实现了，公司别死就是最好的范式。

@echo1937 你这个是对的，从互联网兴起--PC--4G 兴起--移动互联网。但是下一个点在哪里，不好说。