《谈谈企业应用架构的进化和服务集成》上篇
本文系作者本人原创，如需转载，请务必写明出处，谢谢！
一 引言--IT的进化论
达尔文的进化论同样适用于IT世界，能大行其道的IT技术，确实是优胜劣汰，自然的选择。有人说J2EE想解决很多东西，可惜它不够人性，有人说，SOA多么美好，可惜它生不逢时。所以在经历多年的发展之后，J2EE也好，SOA也好，终于碰到了天花板，逐渐被其他IT技术所取代。而最近炒得火热的中台概念，是不是因为手中握着被自然法则锻造出来的利剑？
首先让我们看看中台是个什么鬼？
二 手握利剑--从中台说起
让我们先来看看Thoughtworks 王健在华为CBG IT技术合作峰会上的分享《中台战略到微服务架构》中的一张图：
（图片来源:《中台战略到微服务架构》Thoughtworks 王健,March 16, 2019）
从这张图可以看出，所谓中台就是基于领域驱动设计的微服务架构，以各个中心为单位提供各种核心业务处理能力，并可以通过RestAPI将服务暴露给前台接入的一组对外服务能力。
再来比较下面这两张SOA的示意图，各位是不是就清楚了，原来中台要做的事情只是当初SOA 要做的事情的一部分，也就是Enterprise Service这部分。
（图片来源：Microservices vs. service-oriented architecture By Mark Richards July 6, 2016）
（图片来源：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、孤岛系统、竖井式结构。
企业应用越来越多，这时候，在新开发系统的时候，大家发现，许多数据和功能，在已有的系统里已经有了。
- 我们将来能不能建立这样的新系统（或者改造老系统），在架构上能支持其他应用来调用一些特定功能？
- 如何在已有的老系统上，增加一个服务集成组件，使系统间能互相调用？
（图片来源: Integration architecture: Comparing web APIs with service-oriented architecture and enterprise application integration Kim J. Clark March 18, 2015）
针对第一个问题，“我们将来能不能建立这样的新系统（或者改造老系统），在架构上能支持其他应用来调用一些特定功能？” Web Service 的概念应运而生,如下图的J2EE架构：
一个企业应用，它的用户，已经不再只是在客户端点击菜单和按钮的人，更是企业的其他应用。所以，我们由 Web Service衍生出服务提供者，和服务消费者的概念。以SOAP协议为主的Web Service大行其道。
随后，我们又进入了移动互联网时代，这个时代被称作VUCA的时代。企业应用开始直面最终消费者，也就是2C了。谁能更快地让应用上线，谁就能取得市场先机。在组件服务化的前提下，围绕着云原生技术的企业应用架构的发展脉络清晰可见。
1，前后端分离，使前端从应用服务器分离出来，快速提高软件开发的效率
对于原来由J2EE应用服务器提供的MVC的功能分拆成两个部分,将View和Control的功能交给node.js来处理，而应用服务器只处理业务封装。
也就是说，应用服务器作为后端，对业务逻辑进行封装，提供服务接口；而前端node.js调用后端服务，对后端服务进行协议转换、数据转发、路由和页面渲染。
此时，服务的提供方已经不再局限于一个应用服务器，而是分布于各个企业应用中了，但此时服务协议依旧是多样化的。这样，企业应用的架构就演进到了下图所示的架构： 
（图片来源：Building an API Gateway using Node.js Péter Márton,August 3rd ,2017）
2，以康威定律为理论基础的微服务，伴随着容器技术和DevOps（以敏捷和CICD为基础）的发展，开始蓬勃发展
下图是大家最熟悉的微服务应用的架构图，在微服务应用中，每个微服务都以Restful 风格提供自己的服务，而API gateway 就像前后端分离中的Node.js一样，对各微服务进行服务编排、路由等操作，将服务提供给用户。
（图片来源：Building Microservices: Using an API Gateway Chris Richardson of Eventuate, Inc. June 15, 2015）
3,前后端分离和微服务架构的融合
随着前后端分离技术的深入人心和微服务架构在应用中的广泛使用，结合1和2，形成了以RestAPI为技术核心的、以API Gateway为桥梁连接不同前端和分布式后端服务的应用架构。
这时候，我们就可以把两张图拼起来了。
五 抛砖引玉
通过以上分析，我们可以得出这样的结论：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 王健