笔记 – SOA架构

SOA在互联网系统中的应用

三个话题 – 应用,系统,平台

soa规划
应用级:pojo,当团队更大,重新组织。应用级内部面向服务的问题 – 通过组件平台
企业级:系统之间的集成,支撑平台:bpm,esb,epm。企业服务库
产业级:变化快,更好的协同。作为服务提供者和协调者

application object — facade(策略+决策)-?
business object — manager(能力+操作)

spring帮助我们解决了关注点的分离

pojo编程模型 – validator的例子,todo:思考

组件模型抽象:
对象 – 操作和属性
组件 – 更多:生命周期,服务,扩展点,属性

交易流程 – 流程引擎组件

OSGi – java动态模块规范
bundle – 部署单元(模块)

既要引用模块化组件引入,又要让开发人员适应这种组件开发
spring dynamic modules
每个bundle独立的上下文-bean factory
只有允许发布服务的应用才可以被引用

三者的整合

jvm – 开发的场景
组件支持层 – 组件支持模型

交易支持不同交易方式 – 作为插件

安全可靠 -》互联网,用户需求,行业需求变化快

三层结构中,服务集成是最核心的部分,也是最难的部分
怎样把握服务内容以及抽象,从而更容易集成是目前我们有待解决的问题

《服务仓库》 — 不是很明白
从组件到服务,首要是组件模型的搭建,如果搭建好,自然很容易的国度
甚至可以对开发人员是透明的 – -我们目前可以做到吗?应该不可以

具体的例子《服务@alipay》
多个系统的协作
请求交易核心 – 创建交易
想银行集成平台请求,组装请求报文给银行请求划拨
银行向账户充值
银行向交易核心确认
支付宝内部的账户更新
返回商户平台
商户平台发出通知

在这样的规模(1秒以下)是可以做到的。

业务整理的过程
达到产品和业务核心的区分,核心全部通过服务完成

支付宝整合方式 – ESB企业服务总线(mule开源实现)
我们用esb做了什么?

<服务总线应用@alipay》
统一的事件封装和元数据模型,通过事件机制达到很好的协调

业务分布,数据分布 – 难题 – 事务

事务ACID -》BASE
BA – 业务处理主题必须是可用的,其他的可能不是可用的
交易,资金处理必须可用,消息发送可以不做,或滞后做

Soft state允许业务有偏出 – 只要不是关键部分
E – 对某些业务操作允许过一段时间再一致

“柔性事务” – “补偿性事务”

在大的业务里,对子业务进行区分,有些可以允许时间稍微晚一些,比如会计分录和交易通知
处理一致性的方法 – TCC模型
转钱的例子:1.完成检查,钱是否足够 2.预留钱
cancel或者confirm完成

有了服务的支持,通过协调框架完成协调 – 可以满足每天上千万的处理要求

第三部分:
生态圈的服务

企业内部服务化

开放平台,和合作伙伴更好的协同,超越企业的边界
传统网关方式三种:不需要讲
1.表单post
2.web rpc
3.异步通知

mashup – 太远了

Comments are closed.