SOA（Service-Oriented Architecture），中文全称：面向服务的架构。
SOA让把系统分离成不同的服务，使用接口来进行数据交互，终于达到整合系统的目的。
专业的词总是让人懵懵懂懂，看起来高大上。但就是不知道在BB什么.... 我们换种讲法。
非常多开发者，做系统的时候是这样合作的：
小明负责【考勤】，小王负责【薪资】。
小王说： 小明，我要用【考勤】数据，你做好了没？
小明说： 早做好了，表名叫Attenance, 字段A代表员工ID。字段B代表....自己去数据库查。
相信非常多人看到这样的情景非常熟悉。 数据交互全然通过数据库，模块件没有全然分离，错综复杂！
用不了多久，你的系统就成了一碗美味的“意大利面”
要说明一下。这样的开发方式不符合SOA的理念，那么SOA是怎样处理的呢？
1.考勤作为单独模块，成为一个考勤服务。公布了一个考勤数据接口（WebServices）
2.小王须要使用考勤数据，调用考勤服务的接口就可以
SOA是模块分离，模块间要进行数据交互。通过接口来完毕。
非常多程序猿看了预计会不屑一顾，我们从不SOA，也过了这么多年，并没有什么问题！看起来SOA并没有什么卵用！
假设你这样想。我们来看看接下来这些需求，要怎样应付。
1. 平台越来越庞大，有10几个开发者都要用你负责模块的数据。
假设没有统一接口，你要同全部人讲你的数据库结构。一旦变更。你还要通知全部人
2. 系统执行越来越慢，老板说分离【考勤】和【薪资】使用不同的数据库和server
因为功能间没有严格分离。数据交互也是直接通过数据库。分拆系统基本不可能，所以也就无从谈论分开部署
3. 客户的其它系统须要调用平台的数据进行计算。你还要开放数据库结构吗？
功能没有严格分离，当系统发展到一定层次。开发就会感觉越来越吃力。往往牵一发而动全身。也不符合软件设计原则！
可是假设你的系统本身就非常小，一周就搞定了！要实行SOA，搭建个架构花费了一个月。这就得不偿失了！
是否实行SOA，是要依据平台的定位去调整的！假设你的平台定位不高，强制实行SOA，就好比高射炮打蚊子，不仅浪费炮，还TMD打不到蚊子！所以不要“过度设计”，“恰如其分”非常重要。
到这里，大家都已经懂得SOA的主要思想：严格分离模块。通过接口来链接。那么，怎样链接呢？
上面我讲的WebServices是一种经常使用的链接方式。
除了WebServices还有。ESB，JMS，以及近期几年大热的REST方式。
详细的链接方式，我们就不多讲了。有兴趣能够去查百度百科。