《谈谈企业应用架构的进化和服务集成》上篇

本文系作者本人原创,如需转载,请务必写明出处,谢谢!

 

一 引言--IT的进化论

达尔文的进化论同样适用于IT世界,能大行其道的IT技术,确实是优胜劣汰,自然的选择。有人说J2EE想解决很多东西,可惜它不够人性,有人说,SOA多么美好,可惜它生不逢时。所以在经历多年的发展之后,J2EE也好,SOA也好,终于碰到了天花板,逐渐被其他IT技术所取代。而最近炒得火热的中台概念,是不是因为手中握着被自然法则锻造出来的利剑?

首先让我们看看中台是个什么鬼?

二 手握利剑--从中台说起

让我们先来看看Thoughtworks 王健在华为CBG IT技术合作峰会上的分享《中台战略到微服务架构》中的一张图:

《谈谈企业应用架构的进化和服务集成》上篇_第1张图片 ​​​(图片来源:《中台战略到微服务架构》Thoughtworks 王健,March 16, 2019)

从这张图可以看出,所谓中台就是基于领域驱动设计的微服务架构,以各个中心为单位提供各种核心业务处理能力,并可以通过RestAPI将服务暴露给前台接入的一组对外服务能力。

再来比较下面这两张SOA的示意图,各位是不是就清楚了,原来中台要做的事情只是当初SOA 要做的事情的一部分,也就是Enterprise Service这部分。

《谈谈企业应用架构的进化和服务集成》上篇_第2张图片

(图片来源:Microservices vs. service-oriented architecture By Mark Richards July 6, 2016)

《谈谈企业应用架构的进化和服务集成》上篇_第3张图片

 

(图片来源:Microservices vs. service-oriented architecture By Mark Richards July 6, 2016)

那么,这些中台解决方案提供商凭什么敢做曾经没有取得大成功的事情?他们手握的自然法则锻造出来的那把利剑究竟是什么?我们得先从Web Service 说起。

三 Soap Web Service VS RESTful Web Service 后来者居上

遵循自然法则优胜劣汰,目前最主要的Web服务实现方案有两种:
1)SOAP:即简单对象存取协议(Simple Object Access Protocol),是XML Web Service 的通信协议。当用户通过UDDI找到你的WSDL描述文档后,他通过可以SOAP调用你建立的Web服务中的一个或多个操作。SOAP是XML文档形式的调用方法的规范,它可以支持不同的底层接口,像HTTP(S)或者SMTP。

2)REST:表征状态转移(Representational State Transfer),使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 将所有 Web 系统的服务抽象为资源,REST从资源的角度来观察整个网络,分布在各处的资源由URI确定,而客户端的应用通过URI来获取资源的表征。REST是一种软件架构风格而非协议也非规范,是一种针对网络应用的开发方式,可以降低开发的复杂性,提高系统的可伸缩性。

如果你开始用Spring boot来编写Web应用,你一定会发现用Rest风格来写Web Service实在是太方便了,用起来也方便,于是越来越多的Web服务开始采用REST风格设计和实现。

那么我们为什么要用Web Service? 这要从企业应用的发展历史来谈。

企业应用架构的发展史

我们省略掉最初期刀耕火种的原始计算机时代,实际上,当计算机技术开始用于企业应用的时候,应用的结构是这样的:只要有个业务,我们就建一个业务系统。这个时代的应用,我们称之为monolethic application 、silo system、孤岛系统、竖井式结构。

《谈谈企业应用架构的进化和服务集成》上篇_第4张图片

《谈谈企业应用架构的进化和服务集成》上篇_第5张图片

企业应用越来越多,这时候,在新开发系统的时候,大家发现,许多数据和功能,在已有的系统里已经有了。

  1. 我们将来能不能建立这样的新系统(或者改造老系统),在架构上能支持其他应用来调用一些特定功能?
  2. 如何在已有的老系统上,增加一个服务集成组件,使系统间能互相调用?
  3. 《谈谈企业应用架构的进化和服务集成》上篇_第6张图片

(图片来源: Integration architecture: Comparing web APIs with service-oriented architecture and enterprise application integration  Kim J. Clark March 18, 2015)

针对第一个问题,“我们将来能不能建立这样的新系统(或者改造老系统),在架构上能支持其他应用来调用一些特定功能?” Web Service 的概念应运而生,如下图的J2EE架构:

《谈谈企业应用架构的进化和服务集成》上篇_第7张图片

一个企业应用,它的用户,已经不再只是在客户端点击菜单和按钮的人,更是企业的其他应用。所以,我们由 Web Service衍生出服务提供者,和服务消费者的概念。以SOAP协议为主的Web Service大行其道。

随后,我们又进入了移动互联网时代,这个时代被称作VUCA的时代。企业应用开始直面最终消费者,也就是2C了。谁能更快地让应用上线,谁就能取得市场先机。在组件服务化的前提下,围绕着云原生技术的企业应用架构的发展脉络清晰可见。

1,前后端分离,使前端从应用服务器分离出来,快速提高软件开发的效率

对于原来由J2EE应用服务器提供的MVC的功能分拆成两个部分,将View和Control的功能交给node.js来处理,而应用服务器只处理业务封装。

《谈谈企业应用架构的进化和服务集成》上篇_第8张图片

也就是说,应用服务器作为后端,对业务逻辑进行封装,提供服务接口;而前端node.js调用后端服务,对后端服务进行协议转换、数据转发、路由和页面渲染。

《谈谈企业应用架构的进化和服务集成》上篇_第9张图片《谈谈企业应用架构的进化和服务集成》上篇_第10张图片

​  此时,服务的提供方已经不再局限于一个应用服务器,而是分布于各个企业应用中了,但此时服务协议依旧是多样化的。这样,企业应用的架构就演进到了下图所示的架构: 《谈谈企业应用架构的进化和服务集成》上篇_第11张图片

​(图片来源:Building an API Gateway using Node.js Péter Márton,August 3rd ,2017)

2,以康威定律为理论基础的微服务,伴随着容器技术和DevOps(以敏捷和CICD为基础)的发展,开始蓬勃发展

下图是大家最熟悉的微服务应用的架构图,在微服务应用中,每个微服务都以Restful 风格提供自己的服务,而API gateway 就像前后端分离中的Node.js一样,对各微服务进行服务编排、路由等操作,将服务提供给用户。

《谈谈企业应用架构的进化和服务集成》上篇_第12张图片

(图片来源:Building Microservices: Using an API Gateway Chris Richardson of Eventuate, Inc. June 15, 2015)

3,前后端分离和微服务架构的融合

随着前后端分离技术的深入人心和微服务架构在应用中的广泛使用,结合1和2,形成了以RestAPI为技术核心的、以API Gateway为桥梁连接不同前端和分布式后端服务的应用架构。

这时候,我们就可以把两张图拼起来了。

《谈谈企业应用架构的进化和服务集成》上篇_第13张图片

五 抛砖引玉

通过以上分析,我们可以得出这样的结论:Web Service 转向 Rest风格,使得前后端分离和微服务架构的融合成为可能;企业的架构,由于自然法则的作用,已经进化到了以RestAPI为技术核心、以API Gateway为桥梁,连接不同前端和分布式后端服务的应用架构。而中台解决方案提供商,正是依靠了RestAPI这把利剑,才能重新举起SOA的大旗,以实现企业服务资源的价值最大化。

然而,放眼望去,一个诺大的企业,依旧存在大量的遗留应用(老的SoR System of Record,如无法取代的SAP),它们没有提供RestAPI,第四章提到的第二个问题“如何在已有的老系统上,增加一个服务集成组件,使系统间能互相调用?”这个问题该如何解决?请看下篇分解。

原文 [谈谈企业应用架构的进化和服务集成【上篇】]

参考文献

1.从中台到平台(上)

2.从中台到平台(下) 

3.Building Microservices: Using an API Gateway

4.Integration architecture: Comparing web APIs with service-oriented architecture and enterprise application integration

5.Building an API Gateway using Node.js

6.《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》阿里 钟华

7. 《中台战略到微服务架构》Thoughtworks 王健

你可能感兴趣的:(IT技术)