本章内容 1.异步交互：如果最后践行的结果依旧是使用同步代码的方式写异步代码，那应该没问题。但如果是以异步的方式去写，感觉就有点诺曼设计了。业务建模引入异步设计的复杂性，总觉得不是一个好的形式。我认同云原生下异步交付能发挥更大价值，只是践行的方式还是有待观察。毕竟异步交互在云原生下节省的性能成本，不见得就能盖过业务建模和异步设计的叠加带来的设计成本的增长。 2.谈点实现，瞎猜：弹性伸缩必要重要的价值理应是解决峰值并发场景带来的短时吞吐量述求差异大的问题（毕竟你服务流量很平稳，我靠人工扩容好像也没啥问题）。但感觉能想到的方式都有挺多资源冗余或则说浪费。先说基本思路： （按空闲程度分发）理论上实现弹性扩容，无非就是监控服务资源水位+自动扩/缩容。但实际上，对于高并发场景这个是做不到的，毕竟高并发不讲道理，不会等着监控服务资源的实时情况做分发。服务资源的情况，监控必然有延迟，高并发会借助这个延迟直接干翻你的单个服务造成部分用户不可用；节点的扩容也必然有延迟，而这个延迟，高并发可以让你的集群都不可用。可以想到的应对的解决方案：平均分发，不依赖服务资源监控，均分流量；冷后备，预备大量冷后备节点减缓扩容的时差。但这些，似乎对资源最优分配还是有些距离，只是用冗余保可用而已。 课后题 自治，容错。 自治: 前微服务重心在以业务边界拆分独立的作战单元，讲究的是最小完备/自我履行/稳定空间/独立进化。体现就是软件产品化，数据隔离，迭代自由。 容错：前微服务我们一样接受服务总会出错的现实，所以服务间交互会是以依赖集群+自动隔离故障+自动发现新服务（也就是服务治理）的方式。每个发布单元就像人体的一个细胞，生生死死不断轮回，但都不会影响某个器官（服务）的正常运作。