浅谈SOA

SOA，面向服务的企业架构，近几年业界炒的火热，有的厂商以佛学来解释，有的厂商以哲学来看待，有的直接定义为一种架构模式，其实都只是视角不同，没有对与错之分，只有合理与不合理。09年业界对于SOA的宣传逐渐降温，转而投向了云计算。我们关键要剔除其商业模式的干扰，看看从中能够吸取到什么思想。从业务角度看，SOA体现的是应对业务的敏捷性和灵活性，从技术角度来看SOA主要解决系统的松耦合、资产服用和互联互通的问题。

    耦合性是指系统的功能实现分布以及之间关系的可管理性和可维护性，主要体现在运行期。耦合性是客观存在的，关键要看这种耦合性是否可管理，是否易维护，一个松耦合的系统是指其内部关系可管理易维护。通常系统的建设期几个月到1-2年不等，但其运行维护期往往5-6年或更长时间，在此过程中，需要对系统进行持续的优化或改造，一个耦合性很高或结构较差的系统，往往给运行维护带来很高的风险和成本，系统的结构以及内部的交互在建设期通常被几个核心的骨干掌握，随着不断地优化以及人员的流失和更换，很少有人能够掌握系统的结构全貌，往往修改了一个功能就导致了其他功能不可用或出错，相应的文档也由于更新不及时而失去参考价值。SOA提倡的组件化技术是解决系统耦合性问题的一个有效方法，它将系统按照组件化进行切割，当然是大粒度的，规范了组件之间的交互关系，并且组件具有相应的自描述能力，能够清晰的反映对外暴露的接口以及调用其它的服务信息，为系统的持续优化和维护提供了真实的依据。

    资产复用主要体现的是不要重复发明轮子的思想，通过复用来减少重复的开发，提升软件质量。复用主要有组件复用和服务复用两种方式，SOA在其技术实现方面标准了组件的规格和服务的接口和协议。对于国外来讲，其IT起步较早，很多业务应用已经实现，其复用主要体现在对遗留系统的资产重用方面，通常采取暴露服务的方式；对于国内来讲，由于IT起步较晚，通常会采取组件复用和服务复用两种方式，在实施过程中，通常会对划分出的组件进行同步实现。

    互联互通是主要解决系统间的交互，在企业架构中，一个系统往往不是孤立存在，会和其他的系统发生业务层面和技术层面的交互，通常采取服务的形式，服务本身不包括具体的实现逻辑，由组件来实现，服务包括了接口和协议信息，SOA规范化了交互的接口和协议，并屏蔽了不同的底层实现技术。

    上面提到的三点主要从技术视角来看待SOA，其实技术不是最终目的，而是一种手段，SOA的实施效果要看企业的业务实现是否敏捷了、变更是否灵活了，总体IT成本是否降低了，这一点是从最终业务效果来衡量SOA实施的标准，而不是简单地从技术角度谈架构多么灵活、技术多么先进，更不是从技术实现上采用了WebService、用了几个产品就以为实施了SOA，这都只是表面。

    另外，实施SOA还有一个关键就是服务，前面提到服务是由组件实现的，组件的切分以及组件的粒度是困扰很多技术人员的事情，这方面很多书籍也提到了一些原则、方法、实践等，笔者认为这些都可以参考，但是更多地要结合系统的实际，并更多地依赖架构师的经验和技能，正所谓没有对与错，只有合理与不合理，想一想，在面向对象的分析与设计中，我们对于类的划分也面临类似的问题，我们是如何解决的呢？

   总之，无论叫SOA还是叫AOS都只是一个名字，我们关键要穿透现象看本质，排除干扰因素，把握吸收SOA的思想和精髓为我所用，这样才能避免为了技术而技术，从而更好更快地满足企业业务的实现，降低IT的总体成本，体现IT支撑业务的核心价值。