对SOA(面向服务架构)的理解

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打不到蚊子！所以不要“过度设计”，“恰如其分”很重要。