本人亲身体会，身为程序员，没有和产品经理吵架，拍桌子，甚至抡起键盘打架的经历，说明资历太浅。我认为是否和产品经理正面打过架并互有输赢，是一个程序员是否走向成熟的必要条件

@msaionyc 问题是大公司的架构也不是第一天就按罗马设计建造的，别提什么提前布局，提前布局这个想法就是错的，超级系统都是由最简单的系统逐步迭代出来的，到哪个阶段用哪种架构，2w 用户还真就不配用微服务，一上来就想做超级系统这就是有病，十几年前早有有人批判过这种思维，结果十几年这种思维又死灰复燃了，到什么阶段，干什么事情，上来就想搞大新闻？谁出钱？有人陪你烧着玩那你就去吧，但是更多的例子是规模还没起来，公司先被你这超大规模的系统拖死了

凡是中间加一个转换层，必然有性能损失，JSI 也是中间层。另外我个人觉得，其实很多人忽视了 JS 自身的速度问题，js 从 v8 引擎到现在，优化几乎已经到极限了。然而后来者往往比它性能要好

明确的和你说吧，微服务就是典型的用空间换时间和吞吐量的套路，如果接受不了就不要上微服务，开发者规模不够大的时候上微服务绝对是灾难，微服务的其中一条代价就是你的组织规模是必须跟着项目数量膨胀的

@wamson 手机号没了，那岂不是连手机号登录都没有了？

这条路是可行的，我就是这么干的，不过要准备一个 wifi 开关，避免死机后毫无办法的情况，如果真死机了，就用 wifi 开关重启

目前最大的问题还是网络，windows rdp 在 tcp 下的表现差强人意，但是 udp 几乎所有的运营商都会 qos，直接表现就是普通操作反应迅速，一旦画面变动比较大就会卡。

另外，那些推荐去买高性能笔记本的，都是不靠谱的建议，纯粹属于没玩明白——这个地球的科技根本不足以搞出媲美台式机的高性能笔记本，真要搞出来了，台式机立马绝迹，谁喜欢台式机的傻大黑粗啊，问题是笔记本就是性能不给力，功率墙和温度墙就是横在笔记本前面的两座大山。真能媲美台式机性能的笔记本自己都做的傻大黑粗的，根本失去了便携的能力。总之笔记本路线完全不靠谱

自从我发现 Intel 的核显在远程桌面开硬编码压缩的速度都不如一张最便宜的独显后我就深刻的明白了独显的意义

@gam2046 grpc 再不麻烦也比 REST Http 麻烦，这东西就是怕比。protobuf 直接通过编译生成接口和数据定义的方式我没找到，既有的手段都是依赖 grpc 本身的。

@Itoktsnhc 对，就是要考虑自动生成 dto/entity,swagger 这种，现在就是没有好办法自动化

@murmur 怎么用 xml 生成跨语言的接口数据结构定义？不是直接用 xml 传递

@LukeEuler 你的意思无非就是 go 历史比较短暂时没有历史包袱吗？那将来 go 如果也有了历史包袱咋办？

@cydysm 不适用劳动法的公务员，你自己不犯错上司没法让你滚蛋，适用劳动法有加班费的打工人，老板让你滚你就得滚。年轻的时候看重钱，觉得当打工人划算，年纪大了后会逐渐明白很多东西是钱换不来的，自然就会开始羡慕体制内

学人家的东西能变成大牛？你想多了朋友，应用层的东西哪个赚钱搞哪个，真想要变成大牛，不说到发论文这个级别，你先试试每年能不能去阅读并且读懂别人发的最新的论文，然后自己折腾点东西出来，比如也写个 deno 一样的东西。

@newmlp 我按照你说的设置了，结果我发现，画质变差了，尤其是颜色的场景非常明显，速度还变慢了。并没有变快，我现在怀疑是不是因为这东西需要什么硬件条件？硬解码是和显卡有关的对吧，我的显卡是 intel 的集显 630，是不是这玩意一定要用独显性能表现才好？

自己一个人的时候可以这么干，人稍微多一点这就很成问题

@newmlp 请问一下，这个 H264 编码的开启是否有什么条件，我开了发觉比不开还要慢

我用了很多远程桌面工具，可以确定在同样的网络条件下，目前没有比 RDP 更优的。其它工具有时候看起来更好，实则是他提供的线路比你自己的网络好。而类似 steam 的串流技术是为游戏准备的，响应速度更好，但是对网络质量要求更高

楼主应尽量考虑争取到赔偿房屋重建的费用，毕竟这是国家政策允许的，土地本身赔偿不可能高的，首先修路征地本身针对土地的赔偿就不允许高，这也是政策规定的，你硬要高了现实的案例也不是没有，人家直接绕过去你一毛得不到不说，以后你就住路边上天天和噪音和灰尘为伍了