Sealos 虽然已经超过 5k 星，数千家客户在生产环境中使用，不乏很多一线互联网公司和大厂。曾经 sealos 也令我很激动，我把一件复杂的事情做到的极简，这是核心竞争力，即便如此我还是不会夸它，因为在 sealer 面前它黯然失色。
Github 因为软件升级曾经导致过长达 6 个多小时的全球性服务中断 ... Meta(原名：Facebook) 也刚刚经历一起因为配置推送错误导致全球 6 个多小时的系统瘫痪 ... 诸如此类的大型 IT 系统故障每隔一段时间都会出来一个。为企业搭建一个安全可靠的在线应用架构，是一个系统架构师主要责任，他除了将业务系统架构吃透以安全地应对当前的业务流量之外，还需要具备构建未来的能力，即所选取的架构需要能应对业务未来几年的业务增长。这种能力，和技术潮流无关，和所选择的技术的人才市场容量有关，和企业自身业务形态和增长方向有关。
上一篇如何构建流量无损的在线应用架构 | 专题开篇 是我们基于下图，讲解了流量解析与流量接入两个位置做到流量无损的一些关键技术，这一篇我们主要从流量服务的维度，详细聊聊正式服务过程中会影响线上流量的一些技术细节。
上两篇我们说完了流量解析、流量接入、流量服务三大块的内容，这一篇主要从数据交换的维度阐明数据交换的过程如何影响到线上流量；最后会引入两个常用的防范措施：全链路压测和安全生产演练。
Dubbo 3.0 在阿里巴巴各条业务线包括淘宝、考拉、饿了么、钉钉、达摩院等已全量或开始分批上线，社区企业如小米、工商银行、平安健康等也纷纷引入了 3.0 版本的新特性。支持如此大规模的体量的业务平稳运行，对 Dubbo 3.0 的稳定性有很高的要求，尤其是考虑到社区极高的活跃度，这个挑战就更大了。目前社区有超过 600 位 contributor，近一年以来每天有大约 60 个 commits，陆续支持了 Triple 协议、多实例等功能，这些功能都会涉及到大量的代码变更。每一次提交代码的质量对 Dubbo 3.0 版本的质量、稳定性、可靠性等方面有着至关重要的影响。
本文主要介绍我们最近在利用 Service Mesh 架构解决海外业务问题中一些实践和价值探索。我们在海外业务引入 Mesh 架构过程中，充分利用 Istio 的基于 yaml 来描述和定义路由的抽象能力，制定了企业流量治理标准，并将集团海外业务发展多年的多种路由模块统一成使用 Mesh 的统一路由框架，且在今年双十一支撑了全量的海外业务。也希望通过我们的经验介绍，可以给其他还在探索如何落地 Mesh 的同仁一些参考。
我们都知道以 RocketMQ 为代表的消息（队列）起源于不同应用服务之间的异步解耦通信，与以 Dubbo 为代表的 RPC 类服务通信一同承载了分布式系统（服务）之间的通信场景，所以服务间的消息分发是消息的基础诉求。然而我们看到，在消息（队列）这个领域，近些年我们业界有个很重要的趋势，就是基于消息这份数据可以扩展到流批计算、事件驱动等不同场景，如 RocketMQ-streams，Kafka-Streams、Rabbit-Streams 等等。
2021 年是小米中国区电商部门变动调整较大的一年，小米中国区早期电商、服务体系建立在 Go 语言构建的微服务体系之上，由内部自研的 Go 语言微服务框架 koala 支撑起数以千计的微服务应用。随着业务的发展，新零售体系的成立以及业务中台普及与推广，我们更倾向于拥有丰富生态的 Java 为主的微服务体系技术选型，新项目及服务大多基于 Apache Dubbo、Spring Cloud 的微服务生态。
