一个面试题：在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系统中的政府角色，所以赚钱的业务肯定不能让它来做，但是对业务的安全、监管、基础技术设施服务，理所应当是中心节点的职责。

原文来自:聊聊架构

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com