SOA（Service-Oriented Architecture），中文全称：面向服务的架构。
怎么理解呢？
简单来说就是把系统分解成一个个功能，然后用接口的方式进行交互
为什么这么搞？
来来看看网上
SOA对需要使用信息技术解决关键业务问题的企业（包括希望减少冗余架构、创建跨客户和员工系统的公共业务接口的企业；需要基于角色和工作流对用户提供个性化信息的业务的企业；希望通过Internet实现跨区销售、升级销售和经由移动设备的访问来提升客户服务的组织）很有价值。
面向服务架构的业务好处
效率：将业务流程从"烟囱"状的、重复的流程向维护成本较低的高度利用、共享服务应用转变。
响应：迅速适应和传送关键业务服务来满足市场需求，为客户、雇员和合作伙伴更高水准的服务。
适应性：更高效地转入转出让整个业务变得复杂性和难度更小，达到节约时间和资金的目的。
面向服务架构的IT好处
复杂性降低：基于标准的兼容性，与点到点的集成相比降低了复杂性。
重用增加：通过重用以前开发和部署的共享服务，实现了更有效的应用程序/项目开发和交付。
遗留集成：用作可重用服务的遗留应用程序降低了维护和集成的成本。
来看看一个例子
很多开发人员，做系统的时候是这样合作的：
小明负责【考勤】，小王负责【薪资】。
小王说： 小明，我要用【考勤】数据，你做好了没？
小明说： 早做好了，表名叫Attenance, 字段A代表员工ID，字段B代表....自己去数据库查。
相信很多人看到这种情景很熟悉， 数据交互完全通过数据库，模块件没有完全分离，错综复杂！用不了多久，你的系统就成了一碗美味的“意大利面”
这种开发方式不符合SOA的理念，那么SOA是如何处理的呢？
1.考勤作为单独模块，成为一个考勤服务，发布了一个考勤数据接口（WebServices）
2.小王需要使用考勤数据，调用考勤服务的接口即可
SOA是模块分离，模块间要进行数据交互，通过接口来完成！
很多程序员看了估计会不屑一顾，我们从不SOA，也过了这么多年，并没有什么问题！看起来SOA并没有什么卵用！
在看看老板活着需求放提出的问题
1. 平台越来越庞大，有10几个开发人员都要用你负责模块的数据。
如果没有统一接口，你要同所有人讲你的数据库结构。一旦变更，你还要通知所有人
2. 系统运行越来越慢，老板说分离【考勤】和【薪资】使用不同的数据库和服务器
由于功能间没有严格分离，数据交互也是直接通过数据库。分拆系统基本不可能，所以也就无从谈论分开部署
3. 客户的其他系统需要调用平台的数据进行计算，你还要开放数据库结构吗？
功能没有严格分离，当系统发展到一定层次，开发就会感觉越来越吃力，往往牵一发而动全身，也不符合软件设计原则！
但是如果你的系统本身就很小，一周就搞定了！要实行SOA，搭建个架构花费了一个月，这就得不偿失了！
是否实行SOA，是要根据平台的定位去调整的！如果你的平台定位不高，强制实行SOA，就好比高射炮打蚊子，不仅浪费炮，还TMD打不到蚊子！所以不要“过度设计”，“恰如其分”很重要。
閱讀更多 程序員一代碼搬運工 的文章
