数据API 案例 开发者 关于
掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道

一个面试题:在SOA架构中,服务系统间的交互流程是怎样的?

以前我在谈架构的时候,都是通过组织架构和需求来说明架构的取舍的,都是大道理。这次我想通过具体的技术和指标来量化的讨论去中心化。我在一篇文章中曾经探讨过服务的最小颗粒度,是不可拆分的原子行为,本文中我会以这个颗粒度为微服务的代表颗粒度,看看去中心化随着系统颗粒度变小所面临的问题。

实现服务所需的技术

无论是实现SOA的大服务,还是实现微服务,所需的技术都有哪些呢?我们假设这是一个去中心的架构,所有业务和控制都在服务系统中完成,那么从一个服务系统被访问的全部流程分析(以下步骤可能顺序和实际有差异):

首先是通讯协议。这个可以理解,不能少。

第二是身份认证。相信为了安全,这一步为了确认是个合法用户或系统也没法避免。

第三是权限控制(包括简单的IP白名单,复杂的用户角色控制等等)。这一步能不能省值得商榷,但我相信大多数客户都是需要的。

第四步报文防篡改验证。不用说这是必须的。

第五步报文解密。大多数都有,至少是关键字段,毕竟家贼难防。

第六步报文解析。必须有。

第七步报文合法性校验。这步没有可能导致后面发生不可预期错误,甚至系统宕机。

第八步启动流程(如果采用工作流则需启动流程引擎,如直接编码则进入业务逻辑代码)

第九步本地业务运算。

第十步数据库访问。

第十一步如果要访问外部服务,则需进入外部服务访问流程。

  • 由于是去中心化系统,所以系统启动时必须与注册中心建立通讯,并完成全局路由信息的加载,同时保证发布订阅是实时性。这需要建立一个应用内部的管理子系统。

  • 第一步完成路由的查找,找到目标服务的地址。

  • 第二步建立与目标服务之间的通讯协议物理链接,如果采用完全去中心方式(客户端负载均衡),则需在系统内部建立负载均衡子系统。

  • 第三步生成目标系统报文或远程对象(依据实现方式不同)

  • 第五步防篡改

  • 第六步加密

  • 第七步完成通讯

  • 第八步等待返回报文

  • 第九步验证返回报文防篡改

  • 第十步返回报文解密

  • 第十一步返回报文解析

  • 第十二步返回报文合法性校验

  • 第十三步返回上级流程

第十二步等待外部访问结束,技术上包括可能的同异步转换、超时控制、外部服务错误捕获、完整的出错补偿机制(或全局事务)。

第十三步,业务流程完全结束,需要做返回前的工作,包括反向执行6、5、4、1最终完成一次调用。

以上十三步主流程外加十三步子流程,一般来说是少不了的,很可能由于我水平有限还有遗漏的。这些步骤中只有两步是做本地业务的,剩下的技术全都是支撑。如果是SOA的大服务系统,这些都不是问题,因为这些技术被大单体应用中的数百个服务共享,就像我们一座综合写字楼里的服务设施一样,分摊到每个用户身上就花费的很少了。

但是如果这个系统只有一个微服务业务,大家可想而知浪费有多严重。可以胡乱的估算一下,想要做好上述所有的技术,10万行代码是打底的,虽然你可以都采用开源的技术自己只是组装,但人力可能能省(这里打个问号)系统开销却省不了,这10万行代码只为区区几百行业务代码服务,这显然是不合理的。我们列个表来看看有中心和去中心技术上的开销:

从上表可以清晰的对比出,去中心化导致微服务系统过于沉重,而且随着安全和监管的需求不断增加,系统会进一步变重;而相应的S++提出的本征服务只需要通讯协议、报文加解密和打拆包就足以支撑微服务系统了,未来几乎所有的安全和监管需求都可以在调度中心实现。这就是业务和技术彻底分离所带来的好处之一,在《探索Service本源》中我们对去中心化带来的架构问题,比如系统耦合度等已经做了充分的分析,本文就不在赘述了,后面我们要讨论去中心这种业务和技术混杂的“重”带来的问题。

去中心化的重导致系统难以维护

我们即便不考虑为几百行业务代码引入10万行技术代码的浪费,也要考虑系统复杂度上升带来的维护问题。可以想象,这10万行开源代码引入后,系统中的坑会有多少,为了踩这些坑和填这些坑需要花费多少成本。可能有人会说,这些东西调度中心也要实现啊。没错,但是调度中心只有很少的运行实例,而微服务可是成千上万的实例,即便同样的问题更新起来都要简单的多。从运维和开发角度看,调度中心归技术部门维护,而业务系统对技术的依赖越少越容易被部门维护。

将业务和技术彻底分离,可以让业务和技术之间冲突减少,不会因为技术的变化而影响业务系统。

去中心的重导致资源冲突

由于去中心化的业务系统中会包含各种技术模块甚至子系统,比如发布订阅子系统、出错补偿子系统,这回导致各系统之间的资源包括CPU、内存、IO等发生冲突,给系统监控带来困难,需要计算补偿技术模块对业务质量的影响,这样的冲突也可能会导致自动伸缩控制器的误操作。
去中心的重影响云的伸缩能力

由于去中心化的业务系统含有众多业务模块和子系统,在系统启动时就要加载大量的配置信息和路由等信息,不但占用内存还会导致加载缓慢。我在讲述PaaS的文章中给出了一个系统那个频率的公式,其中R就是单服务系统的启动时间,r是单服务系统的关闭时间。根据这个重要的公式,我们可以知道整个PaaS系统对外来冲击的响应时间是受到系统启动时间限制的,系统启动时间越长PaaS对外部冲击的响应速度越慢,系统就需要更大的余量来保证突发的业务冲击。可以进一步的推出,当系统启动时间慢到一定程度后其实PAAS就可以近似为一个固定容量的集群,PAAS的自动伸缩变得毫无意义了。

所以去中心的微服务会降低云的伸缩能力,随着业务对安全和监管的需求不断增加,去中心化的微应用系统会变得越来越大,对云的伸缩能力的影响就会越来越严重。

哲学私货

有中心的优缺点我就不去推论了,以前讲了很多,余下还是夹带点儿私货吧。从中国人的经历来看,按说应该对潮流之类的东西十分警惕才对,我们经历了十年动乱,应该知道潮流往往是非理性,任其发展下去就会演变成更加非理性的运动。但实际看来,我们国人个顶个都是弄潮的高手,互联网浪潮在我看来已经快发展成互联网运动了。科学是破除迷信的法宝,去中心化我觉得是源于人们对自由的迷信(当然也可能是因为缺失自由导致的渴望),这种迷信是禁不住科学分析和推敲的。追求自由是正确的,但是形成组织和社会也是正确的,形成组织和社会就必须让渡一部分自由,我认为这就是去中心化与中心之间的关系。

如果中心节点可以类比政府,我们希望政府对经济管的越少越好,但是不是无政府就好呢?恰恰相反,无政府社会连生命都得不到保障,更不要提赚钱了。所以,政府应该做什么呢?安全、监管、基础设施服务等等那些不赚钱的事情,我觉得就是政府的职责。IT系统其实就是组织和社会的映射,中心调度节点扮演的就是IT系统中的政府角色,所以赚钱的业务肯定不能让它来做,但是对业务的安全、监管、基础技术设施服务,理所应当是中心节点的职责。

tsDDDnp7Pewvx6XHs0ND (2).png

原文来自:聊聊架构

掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道
一个面试题:在SOA架构中,服务系统间的交互流程是怎样的?
发布:2017-01-16

以前我在谈架构的时候,都是通过组织架构和需求来说明架构的取舍的,都是大道理。这次我想通过具体的技术和指标来量化的讨论去中心化。我在一篇文章中曾经探讨过服务的最小颗粒度,是不可拆分的原子行为,本文中我会以这个颗粒度为微服务的代表颗粒度,看看去中心化随着系统颗粒度变小所面临的问题。

实现服务所需的技术

无论是实现SOA的大服务,还是实现微服务,所需的技术都有哪些呢?我们假设这是一个去中心的架构,所有业务和控制都在服务系统中完成,那么从一个服务系统被访问的全部流程分析(以下步骤可能顺序和实际有差异):

首先是通讯协议。这个可以理解,不能少。

第二是身份认证。相信为了安全,这一步为了确认是个合法用户或系统也没法避免。

第三是权限控制(包括简单的IP白名单,复杂的用户角色控制等等)。这一步能不能省值得商榷,但我相信大多数客户都是需要的。

第四步报文防篡改验证。不用说这是必须的。

第五步报文解密。大多数都有,至少是关键字段,毕竟家贼难防。

第六步报文解析。必须有。

第七步报文合法性校验。这步没有可能导致后面发生不可预期错误,甚至系统宕机。

第八步启动流程(如果采用工作流则需启动流程引擎,如直接编码则进入业务逻辑代码)

第九步本地业务运算。

第十步数据库访问。

第十一步如果要访问外部服务,则需进入外部服务访问流程。

  • 由于是去中心化系统,所以系统启动时必须与注册中心建立通讯,并完成全局路由信息的加载,同时保证发布订阅是实时性。这需要建立一个应用内部的管理子系统。

  • 第一步完成路由的查找,找到目标服务的地址。

  • 第二步建立与目标服务之间的通讯协议物理链接,如果采用完全去中心方式(客户端负载均衡),则需在系统内部建立负载均衡子系统。

  • 第三步生成目标系统报文或远程对象(依据实现方式不同)

  • 第五步防篡改

  • 第六步加密

  • 第七步完成通讯

  • 第八步等待返回报文

  • 第九步验证返回报文防篡改

  • 第十步返回报文解密

  • 第十一步返回报文解析

  • 第十二步返回报文合法性校验

  • 第十三步返回上级流程

第十二步等待外部访问结束,技术上包括可能的同异步转换、超时控制、外部服务错误捕获、完整的出错补偿机制(或全局事务)。

第十三步,业务流程完全结束,需要做返回前的工作,包括反向执行6、5、4、1最终完成一次调用。

以上十三步主流程外加十三步子流程,一般来说是少不了的,很可能由于我水平有限还有遗漏的。这些步骤中只有两步是做本地业务的,剩下的技术全都是支撑。如果是SOA的大服务系统,这些都不是问题,因为这些技术被大单体应用中的数百个服务共享,就像我们一座综合写字楼里的服务设施一样,分摊到每个用户身上就花费的很少了。

但是如果这个系统只有一个微服务业务,大家可想而知浪费有多严重。可以胡乱的估算一下,想要做好上述所有的技术,10万行代码是打底的,虽然你可以都采用开源的技术自己只是组装,但人力可能能省(这里打个问号)系统开销却省不了,这10万行代码只为区区几百行业务代码服务,这显然是不合理的。我们列个表来看看有中心和去中心技术上的开销:

从上表可以清晰的对比出,去中心化导致微服务系统过于沉重,而且随着安全和监管的需求不断增加,系统会进一步变重;而相应的S++提出的本征服务只需要通讯协议、报文加解密和打拆包就足以支撑微服务系统了,未来几乎所有的安全和监管需求都可以在调度中心实现。这就是业务和技术彻底分离所带来的好处之一,在《探索Service本源》中我们对去中心化带来的架构问题,比如系统耦合度等已经做了充分的分析,本文就不在赘述了,后面我们要讨论去中心这种业务和技术混杂的“重”带来的问题。

去中心化的重导致系统难以维护

我们即便不考虑为几百行业务代码引入10万行技术代码的浪费,也要考虑系统复杂度上升带来的维护问题。可以想象,这10万行开源代码引入后,系统中的坑会有多少,为了踩这些坑和填这些坑需要花费多少成本。可能有人会说,这些东西调度中心也要实现啊。没错,但是调度中心只有很少的运行实例,而微服务可是成千上万的实例,即便同样的问题更新起来都要简单的多。从运维和开发角度看,调度中心归技术部门维护,而业务系统对技术的依赖越少越容易被部门维护。

将业务和技术彻底分离,可以让业务和技术之间冲突减少,不会因为技术的变化而影响业务系统。

去中心的重导致资源冲突

由于去中心化的业务系统中会包含各种技术模块甚至子系统,比如发布订阅子系统、出错补偿子系统,这回导致各系统之间的资源包括CPU、内存、IO等发生冲突,给系统监控带来困难,需要计算补偿技术模块对业务质量的影响,这样的冲突也可能会导致自动伸缩控制器的误操作。
去中心的重影响云的伸缩能力

由于去中心化的业务系统含有众多业务模块和子系统,在系统启动时就要加载大量的配置信息和路由等信息,不但占用内存还会导致加载缓慢。我在讲述PaaS的文章中给出了一个系统那个频率的公式,其中R就是单服务系统的启动时间,r是单服务系统的关闭时间。根据这个重要的公式,我们可以知道整个PaaS系统对外来冲击的响应时间是受到系统启动时间限制的,系统启动时间越长PaaS对外部冲击的响应速度越慢,系统就需要更大的余量来保证突发的业务冲击。可以进一步的推出,当系统启动时间慢到一定程度后其实PAAS就可以近似为一个固定容量的集群,PAAS的自动伸缩变得毫无意义了。

所以去中心的微服务会降低云的伸缩能力,随着业务对安全和监管的需求不断增加,去中心化的微应用系统会变得越来越大,对云的伸缩能力的影响就会越来越严重。

哲学私货

有中心的优缺点我就不去推论了,以前讲了很多,余下还是夹带点儿私货吧。从中国人的经历来看,按说应该对潮流之类的东西十分警惕才对,我们经历了十年动乱,应该知道潮流往往是非理性,任其发展下去就会演变成更加非理性的运动。但实际看来,我们国人个顶个都是弄潮的高手,互联网浪潮在我看来已经快发展成互联网运动了。科学是破除迷信的法宝,去中心化我觉得是源于人们对自由的迷信(当然也可能是因为缺失自由导致的渴望),这种迷信是禁不住科学分析和推敲的。追求自由是正确的,但是形成组织和社会也是正确的,形成组织和社会就必须让渡一部分自由,我认为这就是去中心化与中心之间的关系。

如果中心节点可以类比政府,我们希望政府对经济管的越少越好,但是不是无政府就好呢?恰恰相反,无政府社会连生命都得不到保障,更不要提赚钱了。所以,政府应该做什么呢?安全、监管、基础设施服务等等那些不赚钱的事情,我觉得就是政府的职责。IT系统其实就是组织和社会的映射,中心调度节点扮演的就是IT系统中的政府角色,所以赚钱的业务肯定不能让它来做,但是对业务的安全、监管、基础技术设施服务,理所应当是中心节点的职责。

tsDDDnp7Pewvx6XHs0ND (2).png

原文来自:聊聊架构

电话 0512-88869195