searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享
原创

基于Service On Service 的系统构建理念和SideCar模式在系统构建中的应用

2023-03-27 01:51:54
37
0

一、前言

在某些情况下,系统的设计没有经过完整的思考和对历史演进方向的推演。最开始,用户的需求仅仅是需要一个工具类型的软件,用来替代重复、复杂和易出错的人工工作。随着需求的变化和用户业务量的增长,传统的工具型软件无法胜任工作,所以工具进一步演变为一个平台,可以支持简单的多人登录,记录操作日志;拥有自己独立的数据库和其他中间件组件。随着平台的继续演进,一个服务已经不足以满足业务需求,可能需要多个服务相互协作,需要有专门的认证鉴权服务,配置库,工单系统,操作系统等等,所以一个平台已经无法满足需求,需要有一个多平台协作的系统来完成用户需求。但是因为整个演进过程是业务需求驱动,自下而上所有的服务中都包含了大量的业务代码,无法进行拆分,就导致了平台无法演变成系统,继而无法演进成为解决方案的情况。

在大型公司中,最开始计划构建某个服务时,瞄准的目标方向是行业内的解决方案级别的系统,此时传统的演进路线无法满足需求。需要在最开始的时候就制定完善的系统级别的架构,并且能够支持针对业务功能进行插件式的新增,这样才能构建完善的系统架构,并且进而形成系统生态。这样的好处在于既能解耦内部复杂的业务逻辑,在支持业务增长的同时不增加系统的复杂度,同时又可以良好的支持外部平台接入,从而构建自己的系统生态。

二、Service On Service

Service On Service 即基于服务构建服务,是一种新的大型系统的构建理念。在该理念中,系统分为两层,下层为基础服务层,基础平台不感知业务场景;上层为业务层,基于基础服务提供的功能构建所需要的业务服务,面向系统的用户。由这种架构,最终完成系统级别的解决方案。下文中,我们将以IDC解决方案为例,分析这种架构带来的便利。

我们目前需要构建公有云底层IDC级别的解决方案,在这个方案中,我们需要提供完善的配套服务,解决在IDC场景中遇到的多种问题,如下图所示:

如上图所示,整个解决方案中,包含了多达几十个业务平台,各个平台之间业务互相关联。而且部分平台需要工单,流转,配置库等功能,这些功能虽然承载的业务不同,但是实现方式类似,可以抽象成为一个基础服务进行实现。

由以上的例子,可以归纳出来Service On Service的几个基本特点:

  1. 基于基础服务构建出复杂的业务平台。
  2. 基础服务具备通用的编排能力,可以编排出复杂的功能。
  3. 基础服务具备标准化能力,业务服务的独特性由编排的内容承载,而不是由底层平台承载。基础服务不感知上层业务内容。
  4. 上层业务平台不完全由基础平台构成,基于平台的易用性,可以保存自己的系统数据,有自己的交互页面。

上图为基于基础服务构建系统的架构图。其中底层为IAM统一进行身份认证和鉴权,基于IAM构建的每一个基础服务,都可以独立运行,并且可以通过接口进行交互,从而完成一个复杂的业务场景。

基础服务的形态主要有编排态和运行态,这两种形态针对不同的用户。每个基础服务都将本服务的具体内容进行抽象,类似于面向对象编程中的class,而编排则是定制class的行为。所以编排态的用户门槛相对较高,它的用户主要有两种,一种是不需要业务服务层,直接使用基础服务的外部用户;还有一种就是依赖基础服务来构建业务层应用的内部用户。用户将自己想要的功能编排成一个个class,平台根据每个class的编码提供实例化的接口。仅有class还不能完成业务功能,class需要转变为实例才能完成业务功能。Class转变为实例的过程称为实例化,由用户在页面点击,或者通过对外接口生成,实例化之后,则用户可以通过实例化的任务完成自己想要的工作。

例如,用户需要构建一个服务器运维平台,完成服务器的重启操作,则可能涉及到审批,选择服务器,获取服务器登录口令,重启四个步骤。那么基于基础服务,则可以按照如下的步骤进行操作:

1.在CMDB中编排一个服务器的模型,该模型拥有主机名、ip地址、运维账号、口令四个属性。

2.在工单平台中,编排一个重启服务器的流程,流程中有三个节点,分别为审批、调用低代码操作平台、操作结果回写。

3.在低代码操作平台中,编排一个重启服务器的任务,该任务有三个节点,分别为获取服务器信息,重启服务器,重启结果回写。

需要注意的是,以上所有的操作均不需要编码实现,仅在页面编排即可完成。整体的流程如下图所示:

三、SideCar模式

SideCar模式一般用于微服务架构中,它是一种将应用功能从应用本身剥离出来作为单独进程的方式。该模式允许我们向应用无侵入添加多种功能,避免了为满足第三方组件需求而向应用添加额外的配置代码。

对于系统集成来讲,SideCar的理念同样适用,在被频繁调用或者有与业务不相关的需求时,可以通过构建SideCar的方式来降低这类代码与业务逻辑的耦合度。通常来讲,对于某个服务的全部调用均来自于SideCar,服务本身对于所处的网络环境及其他服务可以做到无感知,仅仅需要接受SideCar的指令,从SideCar中获取任务执行所需的资料,并且将结果返回给SideCar。

0条评论
0 / 1000
w****n
2文章数
0粉丝数
w****n
2 文章 | 0 粉丝
原创

基于Service On Service 的系统构建理念和SideCar模式在系统构建中的应用

2023-03-27 01:51:54
37
0

一、前言

在某些情况下,系统的设计没有经过完整的思考和对历史演进方向的推演。最开始,用户的需求仅仅是需要一个工具类型的软件,用来替代重复、复杂和易出错的人工工作。随着需求的变化和用户业务量的增长,传统的工具型软件无法胜任工作,所以工具进一步演变为一个平台,可以支持简单的多人登录,记录操作日志;拥有自己独立的数据库和其他中间件组件。随着平台的继续演进,一个服务已经不足以满足业务需求,可能需要多个服务相互协作,需要有专门的认证鉴权服务,配置库,工单系统,操作系统等等,所以一个平台已经无法满足需求,需要有一个多平台协作的系统来完成用户需求。但是因为整个演进过程是业务需求驱动,自下而上所有的服务中都包含了大量的业务代码,无法进行拆分,就导致了平台无法演变成系统,继而无法演进成为解决方案的情况。

在大型公司中,最开始计划构建某个服务时,瞄准的目标方向是行业内的解决方案级别的系统,此时传统的演进路线无法满足需求。需要在最开始的时候就制定完善的系统级别的架构,并且能够支持针对业务功能进行插件式的新增,这样才能构建完善的系统架构,并且进而形成系统生态。这样的好处在于既能解耦内部复杂的业务逻辑,在支持业务增长的同时不增加系统的复杂度,同时又可以良好的支持外部平台接入,从而构建自己的系统生态。

二、Service On Service

Service On Service 即基于服务构建服务,是一种新的大型系统的构建理念。在该理念中,系统分为两层,下层为基础服务层,基础平台不感知业务场景;上层为业务层,基于基础服务提供的功能构建所需要的业务服务,面向系统的用户。由这种架构,最终完成系统级别的解决方案。下文中,我们将以IDC解决方案为例,分析这种架构带来的便利。

我们目前需要构建公有云底层IDC级别的解决方案,在这个方案中,我们需要提供完善的配套服务,解决在IDC场景中遇到的多种问题,如下图所示:

如上图所示,整个解决方案中,包含了多达几十个业务平台,各个平台之间业务互相关联。而且部分平台需要工单,流转,配置库等功能,这些功能虽然承载的业务不同,但是实现方式类似,可以抽象成为一个基础服务进行实现。

由以上的例子,可以归纳出来Service On Service的几个基本特点:

  1. 基于基础服务构建出复杂的业务平台。
  2. 基础服务具备通用的编排能力,可以编排出复杂的功能。
  3. 基础服务具备标准化能力,业务服务的独特性由编排的内容承载,而不是由底层平台承载。基础服务不感知上层业务内容。
  4. 上层业务平台不完全由基础平台构成,基于平台的易用性,可以保存自己的系统数据,有自己的交互页面。

上图为基于基础服务构建系统的架构图。其中底层为IAM统一进行身份认证和鉴权,基于IAM构建的每一个基础服务,都可以独立运行,并且可以通过接口进行交互,从而完成一个复杂的业务场景。

基础服务的形态主要有编排态和运行态,这两种形态针对不同的用户。每个基础服务都将本服务的具体内容进行抽象,类似于面向对象编程中的class,而编排则是定制class的行为。所以编排态的用户门槛相对较高,它的用户主要有两种,一种是不需要业务服务层,直接使用基础服务的外部用户;还有一种就是依赖基础服务来构建业务层应用的内部用户。用户将自己想要的功能编排成一个个class,平台根据每个class的编码提供实例化的接口。仅有class还不能完成业务功能,class需要转变为实例才能完成业务功能。Class转变为实例的过程称为实例化,由用户在页面点击,或者通过对外接口生成,实例化之后,则用户可以通过实例化的任务完成自己想要的工作。

例如,用户需要构建一个服务器运维平台,完成服务器的重启操作,则可能涉及到审批,选择服务器,获取服务器登录口令,重启四个步骤。那么基于基础服务,则可以按照如下的步骤进行操作:

1.在CMDB中编排一个服务器的模型,该模型拥有主机名、ip地址、运维账号、口令四个属性。

2.在工单平台中,编排一个重启服务器的流程,流程中有三个节点,分别为审批、调用低代码操作平台、操作结果回写。

3.在低代码操作平台中,编排一个重启服务器的任务,该任务有三个节点,分别为获取服务器信息,重启服务器,重启结果回写。

需要注意的是,以上所有的操作均不需要编码实现,仅在页面编排即可完成。整体的流程如下图所示:

三、SideCar模式

SideCar模式一般用于微服务架构中,它是一种将应用功能从应用本身剥离出来作为单独进程的方式。该模式允许我们向应用无侵入添加多种功能,避免了为满足第三方组件需求而向应用添加额外的配置代码。

对于系统集成来讲,SideCar的理念同样适用,在被频繁调用或者有与业务不相关的需求时,可以通过构建SideCar的方式来降低这类代码与业务逻辑的耦合度。通常来讲,对于某个服务的全部调用均来自于SideCar,服务本身对于所处的网络环境及其他服务可以做到无感知,仅仅需要接受SideCar的指令,从SideCar中获取任务执行所需的资料,并且将结果返回给SideCar。

文章来自个人专栏
文章 | 订阅
0条评论
0 / 1000
请输入你的评论
4
3