今天准备再聊下在当前微服务，中台和云原生技术下，传统的SOA是否已经过时这个话题。现在出去跟别人交流，谈到SOA的时候有些客户直接的反馈就是过时的技术怎么还在用？或者一说到SOA就认为过时了没必要采用，因此今天还是有必要就SOA是否过时进一步说明。
我们可以来看下SOA本身的定义，即：
SOA是一种架构方法，将传统的单片式应用打破，分解为离散的、自治的业务服务，利用标准提升他们的互操作性，从而可以更好地共享、重用和组装，快速构建复合的应用从而满足业务需求的变化。
在面对企业遗留IT系统架构的时候，SOA本身实际也是做两个重要的事情，其一是找到各个遗留系统共性的可复用的业务能力；其次就是在构建上层业务流程的时候通过服务组装和编排来完成。
因此SOA更多的是一种架构思想，进一步总结是：
基于遗留系统已有可复用的能力，分层组装的方式来构建上层业务应用。
只要我们在架构设计的时候符合这个思想即是SOA。当在谈SOA的时候一般会将SOA和ESB服务总线结合起来谈。即认为SOA即是一个类似ESB总线的进行业务系统间接口集成和统一管控的集成平台。
而ESB总线仅仅是实现SOA架构思想的一个工具，在前面谈SOA架构思想谈到一个是识别可重用的接口服务并统一管理，这个即是需要ESB总线来完成；另外一个就是对可复用的服务进行服务组装或编排，而这个能力往往通过BPEL或BPM来完成。
如下图所示：
即SOA架构思想的实现涉及到ESB总线和BPM产品的使用。同时接口的识别和定义是依托在遗留IT系统已有的能力暴露，而不是新产生的能力。
因此ESB总线一般也用于多个遗留系统之间的接口服务集成和统一管理。
首先看下微服务的一个定义，如下：
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。
在原来的文章中我曾经谈到过SOA和微服务的区别，即：
微服务架构强调的第一个重点就是原来的单体业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。
如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。
对于微服务实际本身又强调了几个重点，简单总结如下：
拆分后的微服务从数据库，逻辑层到前端都完全独立松耦合。
微服务间通过轻量HTTP API接口交互
微服务间以去中心化方式调用，不需要中心化总线平台
上面三点实际上是我们谈微服务的时候经常会谈到的三点。而对于微服务这个概念本身实际包括了微服务模块和微服务API接口两个部分内容，即：
传统单体=拆分多个微服务（微服务模块+暴露Http API接口）
当谈微服务的时候一定是和传统的单体应用对比来说的，如果没有传统单体应用，也没有当前的微服务的概念。单体应用太大，太重了所以需要拆分，同时拆分微服务还需要通过轻量高性能的接口完成交互和协同。
当把这个理解清楚后，你会看到SOA和微服务实际出发点和目标完全是不同的，虽然两者都会针对传统的单体应用或遗留系统来谈，但是要达到的效果不同。
SOA和ESB：遗留单体应用暴露可复用接口，并通过接口完成多系统集成
微服务：遗留单体应用进行拆分，拆分为多个微服务，再去中心化集成
如果从一个单体应用改造为微服务，那么微服务将通过类似服务注册中心等去中心化的方式完成集成。但是如果一个单体应用需要类似APP应用等前端访问，往往仍然需要一个统一的代理网关来对外暴露接口，这个即常说的API网关。
API网关可以理解为一个轻量的ESB总线能力实现。
API网关不仅仅实现了服务代理和API接口的位置透明，同时也实现了类似服务安全，限流熔断，日志，监控等关键的服务治理管控能力。
SOA是否过时？
再回到这篇文章的主题，即在微服务和云原生时代，微服务是否过时的问题。在前面已经解释了SOA和微服务的一些概念和区别。实际上你会看到SOA和微服务反而不是同一个层面的两个概念。原来业务系统构建中的组件化才是和微服务对等的一个概念。
在云计算不断发展演进过程中，整个IT架构也在不断地发展演进，新的技术也在层出不穷，有些老的技术过时也是常见现象。但是当前实际是很多人连SOA是什么都还没有搞清楚，就在说SOA已经过时，这种人就是典型的追热点，炒概念的人。
包括最近已经听到很多人在说中台过时了，阿里在拆中台了，同样这些人连中台究竟是什么？中台思想本质在哪里都没有搞清楚就在批评中台。包括有些提供中台服务的厂商，把中台吹得天花乱坠，无所不能，结果一到了客户内部最终建设实施发现无法落地，发现原来的业务问题同样无法解决，反而引入了更加难以管理的IT复杂度。
任何一个概念重点是理解思想，基于思想来考虑如何应用和落地实践。
对于SOA，经常看到的过时说法主要包括如下几点：
微服务是去中心化的，SOA还是中心化集成老架构
微服务是Http API轻量接口，SOA下还是SOAP WS接口
SOA和ESB很重并紧耦合，而微服务下轻量集成并松耦合
当然还有其他的一些说法，重点都是在强调SOA中心化，SOA架构是很重的架构不再能够灵活地适应业务变化和扩展。
因此，基于以上问题，再逐一展开分析和描述。
注意API网关本身也是一个中心化的API接口集成架构。
在微服务架构体系下本身是去中心化的架构，通过服务注册中心来实现服务注册发现和消费调用，那么为何又需要使用API网关？
在传统的ESB总线进行服务集成的时候我们就经常谈到一个概念就是位置透明，即需要屏蔽底层业务模块提供API接口服务地址信息，并实现多个微服务API接口的统一出口。即类似设计模式里面经常谈到的门面模式。
如何给API网关一个定义？
简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来，统一接入进行管理，也正是通过统一拦截，就可以通过网关实现对API接口的安全，日志，限流熔断等共性需求。如果再简单说下，通过网关实现了几个关键能力。
内部的微服务对外部访问来说位置透明，外部应用只需和网关交互
统一拦截接口服务，实现安全，日志，限流熔断等需求
从这里，我们就可以看到API网关和传统架构里面的ESB总线是类似的，这些关键能力本身也是ESB服务总线的能力，但是ESB服务总线由于要考虑遗留系统的接入，因此增加了：
大量适配器实现对遗留系统的遗留接口适配，多协议转换能力
进行数据的复制映射，路由等能力
对于两者，我原来做过一个简单的对比，大家可以参考。
因此一个应用内部的微服务模块之间可以去中心化集成，但是这个应用需要和传统的遗留IT系统，需要和外部APP等进行接口集成的时候，往往就需要借助API网关的能力来完成。
API网关本身也是中心化的架构。
即使对于一个应用内部，只要存在类似外部APP前端需要访问后端服务接口，那么就引入了API网关，整个架构就很难说是一个完全意义上的去中心化架构。
因此，简单地说微服务完全去中心化，这个说法是不成立的。
新老架构并存时仍然需要ESB总线
同时在微服务架构实施过程中，一个微服务应用本身还需要和传统的遗留IT系统之间集成，只要还存在这种传统的遗留IT系统，那么这种集成场景就存在，仍然需要通过类似ESB总线或轻量的SOA服务总线来完成接口集成和管控工作。
我们以一个集成场景来进行说明，即企业遗留系统集成采用ESB服务总线，而对于新建设的一个微服务应用采用API网关，那么就存在两者协同和集成的过程，整体集成架构如下：
可以看到，在这种集成架构下，微服务整体应用系统中所有的需要和遗留系统交互的接口全部首先接入和注册到API网关，同时API网关暴露的服务进一步集成和注册到ESB服务总线，形成两级服务集成的方式。
在这种两级服务集成模式下好处包括
微服务应用体系里面的各个微服务仅仅需要暴露特定的API接口到网关和ES
内部微服务间的Rest API交互仍然可以走注册中心，而且对外透明
可以进一步使用ESB总线协议转换和适配能力，完成SOAP和Rest接口转换和适配
虽然两级集成模式下增加了一定的性能损耗，也拉长了整个服务调用链路。但是在新旧架构并存的过程中，这种两级集成仍然是我们推荐采用的方式。既满足了微服务应用内部的微服务治理要求，又实现了和外围系统间的集成。
接着再谈下如果一个企业所有的IT系统都全新构建，同时都采用微服务架构方式进行构建。那么这个时候是否可以做到完全意义上的去中心化架构，所有的微服务间都通过注册中心去中心化的方式调用和集成。
对于企业信息化来说，即使全微服务化，那么传统应用的虚拟边界还在，这个短期并不能马上改变。即类似供应链应用，合同应用，HR应用都采用微服务架构开发，但是这个应用的虚拟边界还在，这个应用边界存在的作用包括了：
通过应用需要划分不同的开发组织或开发团队
应用之间是粗粒度的API接口集成，而非整个微服务集成
当谈到这里的时候，你会看到仍然存在多个应用之间的集成问题需要解决。这个集成即可以采用轻量的API网关来完成。
举例来说，合同应用拆分为10个微服务，10个微服务间可以去中心化集成。同时其中有一个APP前端微服务，这个在合同应用建设中引入了微服务网关来解决统一代理和出口问题。同时合同应用自己搭建了服务注册中心，服务限流熔断能力等。
在合同应用内部，管控的粒度是到微服务粒度即可。
但是当合同应用需要和供应链应用交互的时候，这个时候不可能将某个合同的微服务模块完全暴露给供应链应用，而是只能够暴露一个个粗粒度的API接口服务。
如果合同，供应链，HR三个应用只搭建一个类似Eureka服务注册中心，那么三个应用之间的访问和边界将出现完全混淆和不可控。这个不仅仅是安全类问题，也同样存在接口乱用导致的紧耦合集成等问题。
从一个企业整个IT应用架构来看，打破虚拟应用的边界，做到完全去中心化是一个艰难并漫长的过程。这个涉及到组织级IT管控治理能力成熟度，组织，开发，运维各个过程间的标准规范制定等。
所以不要简单地说全新架构和全微服务化后，整个应用域就能够做到完全的去中心化。实际上每个应用之间仍然难以去中心化，最佳的方式仍然是通过API网关或SOA总线来完成集成和交互。
对于SOA来说，重点不是ESB总线引擎，而是SOA参考架构思想。SOA架构思想里面虽然也有遗留系统的适配和集成，但是更加重要的是从传统的竖向应用构建思路转变为横向分层构建思路，同时抽取和识别可重用服务，通过服务组装来满足上层业务应用。
在谈中台的时候我就指出过，中台思想实际上SOA思想和微服务两者的融合。为何这样讲，我们来讲中台思想和中台实现两个层面来说。
共性可复用业务能力下沉，并提供给前台应用使用=》SOA思想
共性能力构建时候尽量大拆小，可扩展，松耦合=》微服务思想
当前互联网企业谈的中台基本就是SOA架构思想和微服务两者的一个融合，既体现了共性业务能力下沉，又体现了共性能力要大拆小的微服务方式构建。如下图：
当我们理解了这个核心概念后，我们才能够认识到如下几点关键认识。
中台是一个业务层面概念，微服务是一个技术层面概念。中台核心仍然是共性业务能力下沉和复用，只是互联网企业在实现中台架构的时候，将中台技术实现和微服务做了融合。
因此企业内业务中台实现，只要满足共性业务能力统一提供给上层使用，即使底层提供能力的仍然是传统遗留业务系统，那么也可以将构建了一个业务服务能力中台。
同时也可以看到微服务仅仅是中台中应用到的一个技术实现，你可以在很多非中台场景下采用微服务，小到原来一个业务系统拆分后全新构建这种场景。
在中台构建中，中台和前台之间实际还需要一个中台提供的API接口服务的组装和编排层，也可以理解为进一步的领域服务整合能力，而这个服务组合层，实际上和前面谈到SOA里面的服务组装编排思想是完全一致的。
当重新思考中台这个概念的时候，你会发现中台本质还是SOA架构思想。在我们最终规划和建设SOA集成平台，ESB总线的时候就希望构建一个企业内部的服务能力共享平台，为新的应用构建提供可复用接口服务能力。
这个和当前中台思路是完全一致的。也就是说企业传统SOA架构规划实施中都难以落地实施的事情，绝对不是简单地将概念包装为中台就能够落地的，包括当前中台还涉及到传统IT架构的微服务化，更加难以推进。这个也是大量中台项目建设失败或夭折的原因。
结语
最后简单总结下前面谈到的内容，即：
SOA架构思想从来就不存在过时的说法，同时当企业存在遗留IT系统，包括遗留IT系统逐步迁移和微服务的情况，往往同时存在ESB服务总线和API网关并存的情况。或者也可以采用ESB总线来提供API网关应该具备的能力。
随着这个技术发展，企业IT治理管控能力加强，云原生整体技术推进，治理能力的提升，才可能逐步做到完全的去中心化架构。
我们实施了很多大型的SOA集成平台和ESB总线项目，同时也实施了微服务架构规划咨询和迁移类项目，更加认为企业IT架构微服务化是一个漫长过程，一定要围绕业务目标驱动，逐步迁移和演进，最终达到一个目标架构。
