write once , run everywhere

@jxf2008 因为这些东西一开始设计出来就是给傻瓜用的，用来提升生产力，tcp 就是 这边 往里倒数据，然后那边按顺序出东西，啥？还有滑动窗口 慢启动 半连接？ 这跟我有啥关系，写应用的 知道什么时候倒进数据 服务器取数据就好了，其它的东西都要了解一遍，还怎么提高生产力，真正遇到网络相关的问题，基本上要请教对应领域的专业人士，当然一般也不会遇到这种特殊场景

@collector 上月的政策 全面开放 专科以上，只要杭州工作 就行

楼主这是哪里落户的消息，杭州已经事实上全面开放了专科及其以上学历人的落户限制了。

多说几句吧，可能说多了不好听，你女朋友被骗这个事情可能没这么简单。

做任何事情的原则是预计机会成本和风险以及收益，这是人的天性，无时无刻都写在潜意识里面的，开各种理财产品，开了一个两个可以理解成为上当受骗，开了 2 个以上，可以断然认为你女朋友受到了某方面的引诱或者威胁，人性是有弱点的，若没有引诱或者胁迫，一般高风险的事情重复 2 次以上，人肯定会产生警觉，何况每条相关的短信验证都是有警告提示的，前面是万丈深渊 前面是万丈深渊 你开在平坦的路上，只要有两次这样的提醒，你也会小心翼翼减慢速度，确保前面不是万丈深渊吧，因为开快一点的节省的时间相比死亡而言实在太不值当了。

希望最好调查清楚背后真实情况，人有的时候真的很会掩饰事实的，绝不只是表面上单纯上当受骗这么简单。

@jimliang #53 因为微博是我的图床.. 我顺带截图了

我特么招行申请信用卡 ，电话打回家 调查下信息，结果我爸以为是诈骗 给拒接了，
现在信用卡都申不下来

https://ws2.sinaimg.cn/large/005DO33Hgy1g4bys1wwpcj30n40nw48a.jpg 这是 20 年前的网站

https://ws2.sinaimg.cn/large/005DO33Hgy1g4byslms00j30w70qyqif.jpg 这是 20 年后的网站

20 年后的网站 无论是交互体验 还是实时动态化 ，从交互功能上来讲 碾压 20 年前的网站 100 倍
我举的还是微博这种 社交网站，你要去用一些看板类的网站就明白了

@shanlan #2 敞开大门做生意，换个姿势就不让插了？ 真的是搞笑，哪天说不定我浏览器打开一下淘宝，就被定义为爬虫把我给抓走了，口袋罪何患无辞

@quanjw #3 被野生动物观赏？

在实际生产使用中有很大炒作嫌疑， 就目前我接触到很多在中小公司从业的同事朋友来说，
Micro Service 真的夸大其词了

第一大块，Micro Service 是有使用代价的，基础设施跟不上，在调试 /运维 /发布 /开发 /验证
等各个环节都是要大幅度降低生产效率的。

恰好 中小型公司对改进开发效率没有任何动力，
因为很多所谓的互联网公司，业务才是王道，各级开发领导都是背着业务开发任务指标的，
基本上很难有动力做这些基础设施的改进。

1.我知道的 目前就有 3 种 httpclient 在我们服务中使用 ，
其中还有一个 3 年前封装的半成熟的 httpclient 也在使用当中，既没有文档 又没有注释，
正确的使用方式全靠猜解跟参照过去的历史遗留代码。

2.模块化依赖做得很不合理，我不知道谁在哪里看了几篇 maven 的最佳实践，硬是要把 maven 默认的 scope 尽量换成 provided，虽然 Java 本身是一门静态语言，但实际上有很多动态特性，使用 provided 做 scope 很多时候导致动态序列化的时候 ClassNotFoundException，测试一方面无法保证所有的代码路径都被测试到，只能把这种依赖问题就被推迟了线上，目测未来要擦很多次屁股，本来 maven 推荐使用最短依赖路径版本来取胜，通过 exclude 来排除依赖冲突，到了我们这里就全变了。

3.服务间的接口不存在静态检查了，需要人工保证接口参数 /版本 一致，人这种东西，没有规章流程，就很容易出问题，遗漏是在所难免的，导致很多时候晚上发布，不同的团队在线上一起来修各种 BUG。

4.脱裤子放屁的事情太多，consumer 服务 监听消息队列 或者 task 服务 定时触发任务，然后又将消息的数据通过 http 调用 传回给 对应的业务服务，实际处理业务运算的仍然是 业务服务，中间加了一层脱裤子放屁的 task consumer 服务，task 配合的定时调度框架既无法在 task 服务中执行上下文中监视任务执行过程（因为真正执行业务代码的在 对应的业务服务里面 task consumer 没有 mapper 无法直接跟数据库打交道） task consumer 访问业务服务 通过 http 调用 经常直接超时，从而导致定时调度框架根本无法判断任务是否执行成功，最后导致定时任务调度框架的后台日志功能 完全变成摆设，如果想查看定时任务的执行结果 只能每天查看打印在阿里云的业务服务系统的日志。

第二大块，

1. 拆分不合理 导致调用网跟蜘蛛网一样混乱，拆分没有可行的原则，导致很多本应该拆分到对应服务的领域模型，全被美名其曰弄到基础服务里面了，实际上所谓的基础服务 既没有边界上下文 又没有领域定义，是个啥都能往基础服务里面装，结果将商品系统里面的 sku product 商品属性 全往基础服务里面装，整个商品系统服务 定价系统服务 成了一个空架子，每次干啥都要往基础服务里面取东西，而整个拆分的决策在一开始是非常不成熟的，最后由于各个系统调用的混乱的原因，基本上不太可能再对服务做拆分演化了，同之前的理由，由于业务压力，技术方面只能是继续腐烂下去，不存在改进的可能，开发人员只能在这种泥潭里面继续挣扎