对SOA架构的学习心得

前言：

   本文只是作者在对SOA有了浅显认识后进行的学习心得总结，内容肯定存在很多的理解偏差，希望同行能批评指正，并一起探讨，共同学习提高。

对SOA的浅显理解：

以下图说明了产品，系统，模块，功能之间的关系。

 

系统n

系统2

系统1

产品1

产品n

模块n

模块3

模块2

模块1

功能1

功能2

功能3

功能4

功能n

 

产品是由不同的系统构成，系统是由不同的模块构成，模块是由不同的功能构成。本文的作者比较愚笨，只能这样机械的理解。

从上图看出，各层级之间的关系都是1：N的，各功能不同，各模块不同，各系统不同，各产品不同。在这种情况我们去选择功能1，功能2，就可以构建一个模块1出来。这样构建一个模块是不是效率就会很高呢？但是我们如果去重复创造出一个功能1，构建模块1所需的过程时间自然就加大了。我们只有利用现有的功能，我们的工作效率自然就提升了。（BTW：好像有点废话，现在谁不知道重用能提高效率）

未来的企业需要的信息化系统？我们谁也不知道！至少在某些领域，有专人在研究它，我们就暂且拿这些已经存在的对未来变化的分析做个自我理解吧。

SOA（面向服务的架构），是目前在产品架构方面讨论的非常火热的话题，它和MVC不一样，SOA重在解决各业务模块，系统之间的关系，而MVC重在解决具体系统设计上的问题。个人在SOA方面的理解如下：

1、  SOA的核心是组件化、松散耦合

2、  SOA的目标是能快速响应业务的变化

组件化，如何将模块组件化？我们去思考一下螺丝和螺帽，它们是有标准的，只要复合标准，任何螺帽可以套在和它配套的螺丝上。这个是一个比较简单的理解。做为业务模块，如何设定一个标准，让它能够组件化？我们暂且考虑简单一点，其实就是功能的使用和数据的展现：

1、  如何让用户能快速的获取到能操作的功能？

2、  如何能将数据快速的展现？

我们以“待办工作”（因为大量的业务系统可能都存在待办工作）为例进行分析，待办工作主要是纪录当前用户需要办理的工作，将它组件化后，在不同的平台，不同的业务系统之间就可以相互应用了。那么如何在不同的平台，不同的业务系统之间实现“待办工作”的应用呢，我们要从以下方面考虑：

(注：这里我们暂且不去考虑不同平台，不同系统之间的耦合时需要解决的统一目录，单点，权限等问题。)

1、  待办工作的数据结构

Ø         基本：待办人，待办标题，阅读标志

Ø         扩展：待办来源，待办信息发送时间，待办紧急程度

2、  待办的存在消亡：

Ø         生成待办

Ø         更新待办

Ø         删除待办

3、  待办展现的要求：

Ø         全部待办信息

Ø         根据个人待办信息

Ø         根据某时间段内个人以及全部待办信息

Ø         根据阅读标志显示待办信息

Ø         根据待办来源展现待办信息

Ø         根据紧急程度展现待办信息

Ø         展现待办对应文档的详细信息

我们将待办的存在消亡和待办的展现里面涉及到的全部看成是服务，这个时候，组件化的思路就有了。

如何去快速响应业务的变化？对于变化，作者的理解是我们能掌握住有规律的变化，但绝对掌握不了未知的变化，因为它是创造出来的，而不是推理出来的。我们无法避免业务系统的变化，业务的变化必然导致程序，架构的变化，但是我们要努力地减少系统重构的过程，新增加的功能以插入的方式介入。（BTW：这一段好像有点唐僧）

当然，围绕着这些功能，模块，系统，我们还必须提供一套完整的策划，运维，实施机制去不断的改造，以应对不同的市场要求，如下图所示。

 

策略和规划 （定期的）

服务工程 （项目实施）

生产运营 （持续优化）

（未完待续）