当时的堆栈有没有，目标服务的堆栈，10s 超时，肯定有一些地方阻塞了。顺着链路找应该有下文吧

我倒是想后端转前端，就是前端 html/css 写起来实在难受，劝退

Arthas 看下，这里就不存在并发问题，并发是由于存在共享数据导致的竞争条件才成立的，这里就是一个无状态的方法。

肯定是传进来的 URL 有问题。

让自己成为有价值的人，业务也好，技术也罢，自己的价值才是实打实的。

springboot+springcloud 都是基于 Spring 的，如果 Spring 掌握的精，Springboot 和 springcloud 只需要明白他们的理念就可以很快的掌握。

Springboot: 自动装配，xml 的 package 扫描换成 class，加上其他方面做了简化，这个就跟 servlet scan 是一样的道理，Java config 作为主流（ Java config 在 Spring4 就有了），不论是 starter 也好，其他也罢，都是往 Map 里边放 Bean 。大体上的理念明白即可。其他的其实就是 Spring 那一套。

SpringCloud: 还是明白理念。

一个新技术的出现甚至是风靡一定是解决了某些问题，站在这个背景下，会对为什么用 SpringBoot/SpringCloud 的理解更加深刻。

为了用而用，掌握的肯定也一般，为了解决问题而用，至少在问题这方面有了一定的理解。

16G 还是有点那个，搞个 docker，IDEA 多来一点就顶不住了，32G 是真香。

《三体》
《毛选》 4 册

@chaleaoch 我重点在于阐述云原生是一个概念，并不是某一项特定的技术，只是拥有某些性质，虽然没有说是规范，但性质和规范差别其实不大，虽然举例有不恰当之处，但是我觉得也可以说明这个关系了。符合云原生描述的性质 /规范，就可以说应用是云原生的，并不一定说云原生必须得用 k8s

云原声，是一个概念，兄弟们，是一个概念，它描述的是一系列要求，例如服务发现，弹性扩容，自动伸缩等等，是一个描述的缩影，并不是某一项技术的特指。换句话说，可以理解为云原声是一个规范，描述了达到了某些条件的情况下就可以说是云原生，只是现在 k8s 实现了这个"规范"，是目前云原生的实现的一个最佳实践，所以大家用这个进行了特指，并不是说 k8s 就代表了云原生，它只是云原生的一个子集。例如 Servlet 只是一个规范，Tomcat 实现了 Servlet 规范这两者这件的关系。

不管是不是 WEB 业务系统，绝大部分都是 IO 密集型的业务。

瓶颈首先不在相关框架，Spring 只是提供了一个平台，你要异步也可以上异步，如果 DB/Cache/RPC 是同步的，框架提供的异步就没有意义了。

没去过大厂，不知道大厂是怎么做的，我的做法加个 cache 。哪里是瓶颈其实大家心里都有点 B tree，只是改不动撒。

1. DB(慢 SQL，机器配置，CPU...etc)
2. 链路长(网络 IO)
3. 相关链路服务抖动(GC/CPU 高...etc)
4. 代码写的糙(上千次的同步 RPC 调用)
5. 框架配置(Redis 配置导致频繁 TCP 握手挥手，全部等待链接。SQL 等待链接)
5. 机器配置不行

思考这些比起整异步更实际一点，大厂忽略我。

一群人不知道抓住个概念争论个什么，真的把 TCP 学明白了，用什么词汇都可以把这东西给人描述明白。粘拆又何妨，反正应用层能拿到完成的业务 package 。

什么，你要百度，你要百度一天，那还不如直接招一个可以不用百度的。

我觉得模型越来越重要了，可能某一种形式上模型就等同于数据，现在 99%的人都是面向数据库编程(我也是)，当然好理解，写起来应该是人花点时间都可以看懂，但是代码的复用率低的不行，搞得几年，就感觉是重复了。

但是领域模型又有点看不明白。麻木了

还是得看技术公众号的目标受众是哪些，如果目标受众是小白，那得有代码，让人有个感性认知，原来这么写可以达到这个效果。如果是比小白好一点，那么可以略微减少代码，适度补充代码的原理性说明，如果是已经入行的选手，我觉得更多的其实是理论知识的补充。

代码这个东西最终还是依托于理论来实现的，如果不明白理论基础，会有一种为啥呀的疑问。

但是这里有一个恰饭的问题，小白的数量肯定是远远大于其人目标人群的。so，大家都去吃这部分的流量了。毕竟基础性的东西首先就是目标受众少，其次是这部分目标受众都有一定的学习能力。更重要的是这部分的流量不能持续输出，谁能一周一篇原理给人讲通透了。不好恰饭呐。

@GM 30 天 100G 么，要是日志量翻个 20 倍，30 倍呢。

3.0 我还没试过，2.x 的版本，我用过的开源框架里边，dubbo 的文档和博客算是顶呱呱的了