SOA架构是第一次被广泛使用过、通过分布式服务来构建信息系统的工程实践。它有完善的理论和工具，可以说，它解决了分布式系统中，几乎所有主要的技术问题

所以本节就系统的讨论一下SOA的设计思想与原则，找找他为什么没有成功的原因？

三种服务拆分架构模式

1.烟囱式架构

​ 前提：假设完全不会跟其他相关的信息系统之间进行协作

​ 互不交互的系统，各自使用独立的数据库、服务器，即可以完成拆分。

​ 问题就在于：不交互的系统（组织）真的存在吗？

2.微内核架构

​ 把一些公共的主数据：人员、组织 、权限等公用的服务、数据、资源，都集中到一块儿，成为被所有业务系统共同依赖的核心系统。

​ 这种模式很适合桌面应用程序的开发，如果想实现一个能够支持二次开发的软件系统，微内核架构也是一种良好的架构模式。

​ 问题在于：各业务系统不直接交互，（比如：支付系统和用户系统是独立的，但彼此会有业务的调用），这时需要找到一个办法，即能拆分出独立的系统，也能让拆分后的子系统之间可以顺畅的互相调用

3.事件驱动架构

为了能让子系统之间相互通讯，事件驱动架构就产生了

它是这样的一张种模式：在子系统之间建立一套事件队列管道，来自系统外部的消息将以事件的形式发送管道中，各子系统可以从管道中获取自己感兴趣、可以处理的事件消息，也可以为事件新增或修改其中的附加信息，甚至还可以自己发布一些新的事件到管道队列中去。

同时SOAP协议的诞生，事件驱动架构+SOAP协议==催生出=>面向服务架构

SOA架构时代的探索

探索1：更具体

SOA本身还是属于一种抽象概念，而不是特指某一种具体的技术，但它比单体架构和烟囱式架构、微内核架构、事件驱动架构，都要更具可操作性，细节也充实了很多。所以，我们已经不能简单地把SOA看作是一种架构风格了，而是可以称之为一套软件架构的基础平台。

探索2：更系统

SOA最根本的目标，就是希望能够总结出一套自上而下的软件研发方法论，让企业只需要跟着它的思路，就能够一揽子解决掉软件开发过程中的全套问题。比如，如何挖掘需求、如何将需求分解为业务能力、如何编排已有服务、如何开发测试部署新的功能，等等

过于严格的规范定义，给架构带来了过度的复杂性，这也是Web Service衰落最本质的原因。

思考题：

你是否使用过SOA的方法论来开发软件系统呢？无论有还是没有，作为一个软件开发者，你是否愿意软件开发向着工业化方向发展，让软件类似工业产品制造那样，可以在规范、理论、工具、技术的支持下，以流水线的方式生产出来？

思考：还真的是使用过某国产的ESB开发一个项目，但是受限于项目的规模只是做了课题性质的研究。虽然配套设施都很齐全，但是用起却不并不那么的流畅，再加上当时思路受制于服务编排的困扰。好不容易把思路给理顺了，同时又被微服务给冲击了。如果软件开发朝着工业化的方向发展，听起来像是很美妙的事情，那样的话，软件的质量应该会有很大的提高。但是自己会不会被淘汰，软件的定制化（灵活性）怎么体现，软件开发的工作会不会朝着工具化的思路去发展，到处去写补丁。还有一个问题，工业化产出的东西都是一样的，就算再扩展一点可以满足可以提供各种参数来配置。那这个基础工具该有多复杂呀。