SOA学习体会

一、动机

a)   你买不来SOA，你必须理解SOA。亲自经历SOA。SOA是一个范式。SOA是和思维方式；SOA是架构和设计的评估体系。

b)   建立SOA不是一个设计新系统的项目，SOA涉及改变现有系统结构，这意味你必须和老平台及向后兼容问题打交道。SOA是对大型系统景观开展“维护”工作的方法。

c)   总线代表了高操作性。其背后的思想是，不去为不同系统间创建和维护单独的通信渠道，每个系统只和总线连接就能和所有其他系统连接起来。

d)   面向服务的架构(SOA)是个范式目的是实现和维护跨越了大型分布式系统的业务流程。它基于三个技术概念：服务，通过企业服务总线达成的互操作性。以及松耦合。

e)   一个服务是一项自足的业务功能。企业服务总线是个基础设施，它分布式系统和服务间的高互操作性成为可能。松耦合是减小系统依赖的概念。

f)   Web Services 自身也引入了一些问题，首先其标准不够成熟。尚不能保证互操作性。其次。Web Services先天不足。无法形成程度适当的松耦合。

 

二、SOA

a)   使用SOA的关键原因是，它确实有助于你的业务。

b)   灵活性总是比质量更重要。

c)   松耦合表达最小化依赖的概念。当依赖被最小化时，改动造成的影响也最小化。即使部分系统崩溃或当机。整个系统也能运转。

d)   只有平常的业务能以尽可能分散的方式来做，大系统才能顺利工作，引入松耦合的一个方法是，避免引入任何不必要的集中。

 

三、服务

a)   所有SOA都同意，服务自足(独立的，自主的，自给自足的)是个设计目标。

b)   幂等性是当你不确认服务是否完成时重做操作的能力。

 

四、松耦合

    

	紧耦合	松耦合
物理连接	点对点	通过中介者
通信风格	同步	异步
数据模型	公共复杂类型	只有简单的公共类型
类型系统	强	弱
交互模式	通过复杂的对象树导航	以数据为中心，自足的消息
业务逻辑控制	集中控制	分布式控制
绑定方式	静态	动态
平台	强平台依赖性	平台无关
事务	2PC(两阶段提交)	补偿
部署	同时进行	非同时进行
版本划分	显式升级	隐式升级

  

a)   松耦合要付出使系统更加复杂的代价。

b)   异步通信的一个难点发生在当发送都需要一个答复的时候。

c)   服务供应者定义自己提供服务中所使用的数据类型。服务消费者必须接受这些类型。注意，服务消费者应避免在自己的源代码中使用供应者的数据类型。相反，消费者应有一个薄薄的"映射层"，将供应者数据类型映射为自己的数据类型。

d)   基础服务数据类型必须稳定。

e)   永远都应使用通用接口，而非严格的类型检查。

f)   事务补偿的优点是，对系统的更新不必同步进行。缺点是你必须显式提供和调用服务，回滚之前调用的服务的影响。或者，你必须提供程序用于手动错误处理。

g)   数据类型版本划分符合松耦形式时，只是修改是向下兼容的，消费者就不必做任何事情。

 

五、企业服务总线

a)   ESB的主要角色是提供互操作性。

b)   间接方式的优点是ESB能够处理SOA景观内的动态变化。

c)   如果一个ESB技术只提供了点对点连接，你仍然可以实现松耦合。一个选择是，在实际发送请求之前，消费者可以询问中间人或名字服务器。弄清把请求发送到哪儿，这个也实现了某种类型的间接性。

d)   负载平衡和失效备援仍然是大型分布系统的核心需求。

e)   协议驱动方法带来分布式通信模式中的第三个层次。在模型的底层，有一个相对稳定的协议，在顶层有一个调用和实现服务的API。在中间有一个层负责将API映射到协议。

f)   开发ESB支持日志和监测的能力，无论投入多少工作量都不过分。

 

六、服务分类

a)   分为基本服务，组合服务，流程服务。

b)   基本服务应该隐藏技术细节。

c)   组合服务由许基本服务组成。

d)   流程服务通常有一个状态，该状态在多个调用之间保持稳定。

e)   比起短期运行组合服务来，长期运行流程服务往往要求更加健壮，软件质量更好。

 

七、业务流程管理

a)   迭代开发是在合理时间内实现复杂系统的唯一方法；

b)   BPM工具：ActiveBPEL一个开源业务流程引擎 BPEL；

c)   对一个大型分布项目而言，如果一个方法使你开始着手搞全面的系统分析，这通常是自求灾难；

d)   不要基于假设投入大量的工作，太多时候，这些假设都被证明是错的，由于系统会越来越复杂。以致你通常会在软件的整个生命周期内为自己的错误付出代价。

 

八、SOA和组织

a)   SOA是一个业务战略而非IT战略。

 

九、上下文环境中的SOA

a)   让流程引擎不但负责流程服务，还负责给流程服务添加所有有用的搜索标准。使服务可以被搜索。

  

十、消息交换模式

a)   EDA(事件驱动的架构)是一种软件架构模式，它鼓励对事件的生产，发现，消费和响应。

 

十一、   服务生命周期

a)   任何时候，如果需要修改生产中的服务的行为，你应该做的引入与服务老版本相互独立的新服务或服务的新版本。

 

十二、   版本划分

a)   对任何修改，服务提供者都应该通知现有的服务消费者，并且要与这些消费讨论。

b)   以新服务方式引入修改给你一个机会，你可以针对单独一个消费者观察运行时的行为。当确定情况良好时，再把其余所有消费者换到新的服务。

c)   如果老版本不能逐步淘汰的话，整个系统的统一性将会越来越糟。

d)   作为服务消费者，让你的代码多多少少独立于所调用服务的版本划分是个好主意。

 

十三、   SOA和性能

a)   你需要一个中间协议，消费者和供应者能用化来交换数据。

b)   如果一个消费者觉得服务的响应时间太长，而你无法能过增加系统硬件和带宽来改善性能的话，通常你必须在消费者端进行解耦。

c)   收集不同服务请求运行时统计数据，长期对这些数据进行监控是个好主意。

d)   粗粒度下，性能仍然可能成为一个问题。

e)   暂时的权宜之计总是有最强生命力的。

 

十四、   SOA和安全

a)   消息层安全通常更可取，因为它带来端到端的安全性，而传输层安全带来仅仅是点到点安全性。

b)   SOA的基础设施和架构必须互相吻合，只提供基础设施，把安全性问题留给参与者考虑，是非常不好和危险的做法。

c)   处理SOA安全性的最好办法是将安全作为服务提供。

 

十五、   技术细节

a)   一个无状态的服务是在不同服务调用之间不维持任何状态的服务。

b)   一个有状态的服务。指的是在多个服务调用之间可以保持状态服务。

c)   性能可能是引入有状态服务非常重要的原因。

d)   关联ID是ESB内部在运行时使用技术性数据处理消息的一个例子。

 

十六、   Web Services

a)   直到基础设施的细节真正发挥作用之前，不要运用任何特定于Web Services基础设施。

 

十七、   服务管理

a)   业务库从业务角度来管理服务及其制品。

b)   注册中心从技术的角度来管理服务。

 

十八、   建立SOA和SOA监管

a)   引入SOA唯一正确的方法是让它自己一步一步成长。

 

 

 

 

后记

数据库复制，海量数据处理和本地客户端尤其不是SOA的强项。