本段比较长，建议先看到底。

如果你要说是上层开发，那么前端吃掉后端是必然的，也是合理的。随着分工更细化，Java 和 C#，已经不再定位成全栈语言了，以后可以更专注于中层和底层的开发。

先说一下我理解的开发层次：
上层，主要是客户端、终端或者人机交互界面，另外也包括直观数据的增删改查、简单文件操作等，基本都是可以看见的（或者简单的说，就是非程序员——例如画图经理——也能告诉你要干什么的）
中层，数据建模、业务处理、工作流等等，基本都是不可见的，小规模程序基本用不到；
底层，语言、算法、通用（例如 Apache Common、Hibernate、Netty ）工具等等，基本都是业务无关的，可见但是仅黑盒可见。

本着简化开发的目的，上层使用的技术应当是单一的，最好是所见即所得的。这一点以前的 PHP （ HTML+脚本）就很好，JavaEE 带了歪路，ASP.NET 跟着也歪进去了。(请注意，此时 PHP，以及只用来做增删改查的 JaveEE、ASP.NET ，都算作前端)现在只不过是 ES、TS、Node 等，替换掉了他们，并没有实质性的变革。JavaEE 原本的目的也是简单化——单一语言就跨平台的提供页面展示、数据模型、业务处理、底层工具等全栈功能，然而现实很骨感，大杂烩吃力不讨好，最终还是被抛弃了。

回到楼主说出来的现象和两个问题：
star 多，并不代表总体高。例如：富士康员工比苹果多，并不表示富士康赚的比苹果多。而且本身你也没给出来数据，受主观观点的影响，star 多这个结论也不一定对。
前端的技术肯定能做出复杂的应用，然而能做不代表就要用他。技术选型的唯一标准是好不好做，“能不能”是必要条件，但永远也不会是首要条件。
前后端压根就没有过界限。以前 PHP、JSP、ASP 开发要从 HTML 到数据库通吃，以后上层开发也要从 JS 到数据库都通吃，现在只不过是个过渡阶段。

楼主眼里的“后端”，肯定是要消失了，要么转为上层开发，要么深造后转成中层开发。不过，最大的可能还是转成管理或者转行。

@ipwx 你的这种方式，是要使用人自己定义镜像的，自然可以进一步限制他们不能用 yum install/apt-get install，不能编辑 /usr/local/systemd ……等等，所以没啥可担心的。然而他哪种懒惰的方式，估计是啥也不会限制，等用户一通 install/remove 后，容器占用空间就可能爆了。

以前用电信宽带的时候，经常干微软的网络，比干谷歌都积极，原因不明。

优酷以前不是在服务器或者 CDN 出口那里做半程限速（广告和开始半段流畅，然后就开始卡）的吗？现在要还是这样那就是无解的。

@1194129822 #31 错的离谱

ini 直观性最好，并且原生支持大量注释，对非专业人员来说比较友好。然而只有平铺的数据结构，程序解析麻烦（程序并不能将其方便的转换成对象），配置量大的时候也容易被注释淹没，总体来说可读性（尤其是对程序的开发者）并不高。

json 是最完美的配置方式，配置文件可以无缝的转换成程序使用的对象，但是非专业人员可能看不懂。

yaml 算是取了上面两个的中间点吧，即让它看起来跟程序使用的对象类似，又让非专业人员只需要几分钟学习就能看懂。

说到这里我也大致明白了，关键点就是，程序开发者使用方便，所以以后用 yaml 的非商业软件回更多。

因为没有 yum，apt-get 纯命令行又用着不爽，所以还是 hyper-v 加 centos

我还以为是衣服...

@zmj1316 #28 问一下，有没有出现过容器占用空间爆掉的情况，印象中容器中也是分层的，占用空间只增不减。
@ipwx 你也看一下，他这种这么懒的情况，估计也不太可能把易变的目录都挂载成卷。

@ssll #55 白瞎了我废功夫去写回复：把推广营销完全当成骚扰；阿里这种电商模式的营收来源不知道；“爸爸”是反话看不出来；煽动闹事跟合法施压区分不开；认为所有成本都能转嫁……

请楼主先参考此回复 @BOYPT #20 [没关系的，淘宝商家都会预留了一定利润来处理这些退货产生的成本，也就是说转嫁给其他正常交易的卖家。] 还有他下面紧接着的“损人不利己”的回复。

你现在干得就是损人不利己的事，并且损的还不是商家，是正常买家，商家基本无损。

现在来回复你的方案。我不站在道德的制高点来评判你这种行为，我也给不出一个不流氓且易行的方法，我只是认为你这种行为没用，甚至还会给自己惹麻烦。你自己也说了： [大多数都是那种你以前在他那买过东西，他掌握了你的手机号然后就无耻的发送垃圾短信了] ，所以你应该要猜到所有商家——不管是不是无良商家——都会这么干的。因此，如果你采取了你所说的行为，别的不说，光 AL 爸爸就会把你拉入黑名单，要是弄成群体事件，起诉你煽动群体闹事都有可能。AL 爸爸才不管你是否诚信是否道德，你现在跟它的衣食父母——商家——对着干，它就要弄死你。更别说 AL 爸爸才是最大的骚扰信息发送商。

“增加发送垃圾短信成本”这个思路是对的，但实施的方案错了。你可以发动群众向 AL 爸爸、电信运营商、监管部门等施压，让它们去增加发送垃圾短信的成本，比如说短信实名制、提高价格、加大处罚力度等（当然这是一个很难的方案，因为你此时仍然是跟 AL 爸爸、电信运营商的短期收益对着干的）。

新税制下，税是按年计算的，年终奖跟工资一样。至于跟以前比较是高是低就不知道了，以前的年终奖税计算太麻烦。

最开始不能用的时候就问过，搜索到的最多的原因就是：购买人的分布情况、每次支付的大致商品名等等信息，还有最重要的支付流水情况，通过支付宝都能被阿里掌握。当时还不理解，现在理解了。

货到付款不能成为理由，如果你当时仔细看看货到付款的收款方，是京东的支付宝账户。京东当时穷的连专业收款机构都没有，啥都用支付宝的，后来有钱了，就自己搞了。

@zmj1316 结合你楼下的回复，大致推测你的管理方式：来一个人或任务就给一个容器，搞坏了或者不想用了，容器直接销毁；每个人有一个专门的数据卷。

首先要说明一点，你这种环境，数据卷只起到了外置可共享磁盘的作用，或者就叫做：可挂载的网盘。

你这种方式正好应了我原来的推测： [不会是不挂载数据卷，出问题的时候直接销毁并重建容器吧，相当于“快速重新安装系统”。]

你这种工作，不用 docker，换成 hyper-v、vmware、virtualbox 都能做，而且制作镜像、挂载和管理共享盘、配置网络等等更方便。

看了一下 snowflake 算法，跟 UUID 相比，最主要的优势就是“有序”了，“有序”了自然可读性就高了、索引就好弄了。长度优势（ 64bit vs 128bit)并不重要，而且 64bit 并不是算法要求的，而是习惯要求的（正好等于一个 Long ）。

因为要“有序”，劣势也是有的：算法复杂，生成方式易用性和生成速度上不及 UUID ；系统内全局唯一，但出了系统并不是全球唯一。在不需要“有序”的地方，还是用 UUID 更好。

这么长的序号，反解意义不大，我觉得在“业务>性能”的前提下，还不如一个 findByID 接口。

粗略有序性这一块应该大有看头，不过楼主并没有实验。

最后再提一点偏见，程序员不应该使用脑图。