xPort V1.0 - 基于“Service Mesh”下一代分布式微服务框架
继发布面向量化金融的C++分布式xRPC通讯框架后,数字动能再发布用于分布式服务框架的智能代理xPort v1.0。xPort智能代理完全由C++编写,支持数字动能的xRPC通讯协议,主要用于实现多应用服务在分布式服务框架(如Service Mesh服务网格)的智能调度和管理功能。xPort v1.0智能代理的发布,标志着数字动能将掌握下一代分布式微服务架构-Service Mesh的核心开发技术。利用最新的分布式微服务架构,数字动能可具备搭建多元异构业务中台、实现复杂业务解耦和跨业务间通讯、满足多业务场景交付的能力。
一、xPort是什么?
智能代理,也叫Side Car,既是新一代分布式微服务框架-Service Mesh服务网格架构的基石构件,也是Service Mesh数据平面和控制平面的核心管理组件。
ISTO的Service Mesh通用模型
xPort是数字动能的Service Mesh核心组件“智能代理”(也叫Side Car)。xPort以分布式通讯框架xRPC为主要通讯协议,它主要负责Service Mesh服务网格节点间的数据平台与控制平面的管理。服务网格-Service Mesh被视为下一代基于分布式思路的微服务架构,它提出了利用全新的分布式、轻量级设计的Sidecar(以下称智能代理)部署模式替代原来庞大的层级式、堆叠式的集中服务框架。应用服务间的数据通讯将由智能代理接管,不再需要关注通信和控制细节,信息可在服务网格间高速通讯。而对于系统级别的功能调用,应用服务单元也无需再去关心如何调度,完全由智能代理负责数据平台和控制平面的协调。这种改进将把业务代码和技术实现进一步解耦,技术架构的变动对业务代码的影响也进一步减少。利用智能代理进行应用服务间信息通讯的方式是Service mesh服务网格设计的核心思路,数字动能提出的Direct Exchange Mesh服务网格架构对比ISTO经典Service Mesh模型更轻量级,主要针对金融行业的大数据传输、复杂计算和高速传输需求进行了场景针对设计。其智能代理xPort完全自主研发,采用大量创新设计。
数字动能的Service Mesh 改进模型
二、智能代理xPort v1.0有什么特点?
1、智能代理通讯不再经过通用模型的控制面板而是直接数据交换模式
Service Mesh通用模型中,智能节点(Side Car)区分了数据平面和控制平面。但在面向应用服务,以松耦合和高速通讯为首要目标的Direct Exchange Mesh服务网格设计中,数字动能利用xPort智能代理大胆把控制平面的部分功能下沉至智能代理内部,同时把硬件资源的调度权交回给IaaS层,让整个分布式架构设计更轻量级,以智能节点直接点对点方式进行数据交换(Direct Exchange Model)。在原Service Mesh通用模型中,应用服务的微服务化看似松耦合,实际上由于控制面板的集中通讯设计,反而加重了网络间节点传输的压力。数字动能的xPort智能代理大胆取舍了原来控制面板的功能,改为智能代理间完全点对点直接通讯,从而避免过多的节点需要同时经过控制平面通讯所产生的原生架构性能瓶颈。
2、智能代理xPort允许应用(服务)通过进程内调用的方式实现高速点对点通讯
普通Service Mesh的SideCar只是做了消息转发,xPort在满足该功能的前提下,可以更好的满足金融业务(如投研业务)间大量数据和传输。智能代理xPort直接把应用服务加载到自身的进程内, 这样应用服务和智能代理xPort的通讯无需再通过网络避免了频繁通讯产生的网络高负载,而是直接通过内存交互。如下图,应用服务A和应用服务B都是加载在xPortA的,通讯流程为:应用服务A -> xPortA -> 应用服务B。即使两个应用服务加载在不同的xPort,也只需要发起一次网络调用即可。另外,不同于原来一对一的智能代理->应用服务的单一结构,xPort允许多个应用服务同时在进程内加载。如图,应用服务A,B,C可同时通过加载在xPortA中。
利用xPort实现进程内多应用服务调用
3、智能代理xPort内置服务发现功能,降低对注册发现服务频繁访问的网络消耗
通用Service Mesh服务网格模型对服务注册中心的依赖度很高,应用服务通过智能代理必须和服务注册中心保持连接,以确保服务注册中心能观测到各个节点的状态变化。这种方式在大规模的分布式应用中容易产生单点问题,随着应用服务节点的数量增加,服务注册中心的压力会随之变大,一旦服务注册中心发生故障,所有的应用服务都将被挂起无法工作。xPort为避免此问题,在智能代理中内置了服务发现功能。当应用服务把消息传递给xPort后,智能代理会先查询内置的本地路由表,查看是否有目标应用服务的地址,如果没有才会从服务注册中心获取目标服务(应用)的地址。对于首次应用服务注册,只需要通过智能代理向服务注册中心做一次性注册,后面的所有调用或应用服务目标的状态无需再通过服务注册中心。如上图的服务(应用)A发送消息给应用服务D,当xPortA和xPortB通过服务注册中心建立连接后, xPortA和xPortB会开始自动相互各自的应用服务信息,不再需要通过服务注册中心。
4、xPort具有带消息队列的点对点通讯功能
在通用Service Mesh架构中,应用服务和智能代理、智能代理自身相互之间均是点对点通讯。点对点通讯在获得高性能的同时,却要求被调用方必须保持在线。在分布式场景中,应用服务可能会出现短时间(或极短时间)的通讯中断现象。xPort智能代理将会允许这些临时中断现象的发生,并将其视为信息在节点间传输的有效生命周期。xPort通过改进并融入ZeroMQ的技术达到此目的。应用服务把消息传给xPort之后,会在本地创建该消息目标应用服务的队列,然后再由该应用服务把消息发送给目标应用服务;如果目标应用服务不在线,那么在消息的生命周期内会存放在这个队列里面,待目标应用服务上线,该队列会继续完成消息传输。因此,智能代理间的消息传输只要在其生命周期内被处理即可,并不要求各个智能代理节点必须立即响应。与原来传统点对点的即时信息通讯方式不一样,xPort在与应用服务和智能代理间的相互调用,并不认为只要对方不在线,消息传输就是失败的,而是允许消息只要还在生命周期内,都可以队列方式进入等待响应状态。在点对点通讯效率提升方面,xPort同时借鉴了RabbitMQ一个连接可以创建多个通道(channel)的思路,大大减少了xPort之间的连接数量。xPort内置的节点智能连接算法,可让xPort智能代理会根据服务节点间线路情况自动增加连接,在空闲时自动降低连接数量。
5、xPort同时支持多线程编程模型和Actor编程模型
通用Service Mesh的架构中,智能代理(Side Car)只作为消息代理所用,xPort在实现消息代理功能的同时,允许应用服务加载到自身进程,使其具备对应用服务的调度功能。为满足高并发的使用场景,xPort进一步提供了线程池和Actor两种并发模型。线程池并发模型的多个线程间交互是通过共享内存的方式进行的,多个线程对共享进行操作,达到同步消息的目的。这种方式极大提升响应速度,降低延时,但多线程编程模型难以保证应用运行的正确性。该问题需要用到锁等机制来解决,这将会影响性能,并且容易导致死锁等问题。因此,xPort同时提供了Actor并发模型。Actor不是通过共享内存来通信,而是通过通信来共享内存的。Actor的状态由自身来进行维护,其他线程不能直接对Actor发起调用,而是要把调用的消息发送给Actor,由Actor来执行操作,这样就可以保证Actor内部的数据只有由它自身进行改变。这种编程模型大大的降低多线程编程的复杂度,容易编写出高并发的应用程序。xPort的使用对象可以根据业务选择不同的编程模型即可。
三、xPort可以解决什么问题?
xPort作为数字动能分布式微服务框架DX Mesh的核心组件,主要解决各个应用服务间的数据、通讯和控制问题,为多业务场景设计,复杂系统构建和中台业务架构方案提供了全新的实现思路。利用智能代理xPort实现的业务间互联互通,将对大型业务系统构建和拥有复杂业务逻辑的核心系统研发带来革命性的改变:
1、业务架构简单化 – 复杂业务结构通过xPort接入方式进行解耦,快速实现应用模块化。
2、以组织形态看待业务,而不是进行庞大臃肿的大架构设计。
3、通过智能代理,业务间不再考虑统一设计,而是分立设计,甚至进行动态业务逻辑设计,彼此相互联系又各自独立。
4、智能代理所形成的分布式业务群可实现快速部署,快速迁移。
5、通过智能代理,可实现异构开发语言间的相互通讯。
6、系统从集中式设计变成网络化,节点化的分布式设计,可无限延申业务体系。
7、智能代理的分布式接入架构对传统的PaaS集中接入式架构发起了挑战,但成本更低,新业务接入迅速,旧业务系统无需推倒重来。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
