上两篇我们说完了流量解析、流量接入、流量服务三大块的内容,这一篇主要从数据交换的维度阐明数据交换的过程如何影响到线上流量;最后会引入两个常用的防范措施:全链路压测和安全生产演练。
本文主要介绍我们最近在利用 Service Mesh 架构解决海外业务问题中一些实践和价值探索。我们在海外业务引入 Mesh 架构过程中,充分利用 Istio 的基于 yaml 来描述和定义路由的抽象能力,制定了企业流量治理标准,并将集团海外业务发展多年的多种路由模块统一成使用 Mesh 的统一路由框架,且在今年双十一支撑了全量的海外业务。也希望通过我们的经验介绍,可以给其他还在探索如何落地 Mesh 的同仁一些参考。
我们都知道以 RocketMQ 为代表的消息(队列)起源于不同应用服务之间的异步解耦通信,与以 Dubbo 为代表的 RPC 类服务通信一同承载了分布式系统(服务)之间的通信场景,所以服务间的消息分发是消息的基础诉求。然而我们看到,在消息(队列)这个领域,近些年我们业界有个很重要的趋势,就是基于消息这份数据可以扩展到流批计算、事件驱动等不同场景,如 RocketMQ-streams,Kafka-Streams、Rabbit-Streams 等等。
作为一线的开发人员,大家是不是都经历过和产品吵得不可开交的经历,甚至最后谁也无法说服谁,只能将问题上升。最后由老板出面解决,而大多数情况下老板还真能够以某种方法去解决,并且是一个双方都能接受的方案。这个时候可能大部分同学会认为是老板的权威,地位导致了这一结果。
软件架构设计本身就是一个复杂的事情,但其实业界已有一个共识,那就是“通过组件化完成关注点的分离从而降低局部复杂度”。其实现在我们用的无论是容器、中间件、消息、数据库等,在某种意义上都是组件化的产物。这样的好处是在不同的系统里可以复用。在云原生兴起的今天,以通用的、组件化的服务形式更容易为我们所用,所以说现在如果还不享用云原生技术红利,那你就会被时代抛弃。
软件是以持续迭代的方式去不断演进的。某种程度上,我们并不担心软件不完善,但担心软件的迭代速度太慢而影响了完善的速度。在分布式软件领域,如何快速、安全地验证新的软件版本一直是大家所关心并探索的。服务网格(Service Mesh)的出现将这个领域的探索推向了新的高度。“泳道”这一概念在分布式软件领域并非新词,只不过,这次我们是以服务网格为基础技术去构建,充分发挥云原生技术天然具备灵活治理流量的优势。