三个话题 – 应用,系统,平台
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.