13｜云时代的挑战（下）：如何保持弹性边界的独立性？

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

“业务天生是异步的。同步是简化” 大佬，怎么理解

云带来了哪些运营模式的变化？像例子中，举动极客时间专栏提供了企业版，这个变化跟 云的关系在哪呢？请教老师细细解释下呢

如果把异步技术引入到模型中，就相当于把事务性引入了业务当中，所以复杂度可能会发生质的变化

下次去上海我也去这家咖啡店体验一下。言归正传，为了解除弹性耦合，就需要使用异步的方式实现业务流程，将响应时间的依赖转变为对吞吐量的依赖。从一致性这个角度看，就是系统从保证强一致转变为最求最终一致性，通过各种兜底逻辑保证所有中间态都能到达最终最终状态。

O.P.S. Cafe 这家不足10平方米的顶流大店，咖啡确实不错，排一个小时队是常态，现制咖啡还是受制于咖啡师，咖啡师无法被Clone，水平扩张无从谈起。

我有个疑问，关于点餐和厨房的例子的，不管是异步还是同步，厨房的吞吐能力不行，还是没解决顾客耐心耗尽的问题。

事实是，我们的现实世界就是异步的，软件也是越来越向现实世界靠拢。从同步走向异步，从强一致走向最终一致。

2024年01月18日09:00:16 异步交互的确会引来很多问题，这些问题属于同步无得，所以人还是喜欢同步，那蛮期待后面如何解决异步交互带来的问题，比如一致性、状态机、整个流程的编排、轮询时间等等

看了几遍本文，也看了asyncapi和netflix zuul2的异步改造，我对文中的“异步”的理解，是采用nio方式发起请求，这节省了线程数，但在使用侧看来，依然是同步的。 然后对 【弹性依赖】 应该秉持 允许 的态度，对 【弹性耦合】 应该通过异步避免。 希望老师点评