笔记 – 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 – 太远了

来自支付宝架构师的一些体会

来自支付宝架构师的一些体会,主要来源是支付宝架构师blog和dbanotes。记录一些有启发的架构细节和成长体会,让自己能够更准确的找到自身提升的方向方法。

今天的支付宝已经是一个用户超过2亿用户,每天交易笔数超过400万笔,交易量超过7亿的庞大平台。

现在,程立的团队依然保持着每周一次的发布速度,坚持每周系统更新。在准确性和时效性方面都要受到挑战。“技术是一个相对枯燥的部门,但是一旦沉进去之后却发现这真的是很有意思的一个部门,因为有挑战,所以有意思。”程立表示。

对于技术人才的成长,程立认为技术人员必须把自己的发展和公司的发展结合在一起。刚进公司的时候,他简单地认为只要愿意加班或者负责好自己的事情,就是敬业,但后来他才明白,做好一件事情并不代表敬业,敬业还要考虑做的这件事情的背后的意义是什么,公司和客户真正想要达到的结果是什么。将被动的工作转为主动,每个人都会发现自己有很多潜力可以去挖掘。

的确,支付宝的数据堪称海量,但相比之下,主要的压力还是来自对交易事务的处理上。我们也有一些密集型的后台计算,但相对规模不算特别大,当前的计算能力足以支撑, Continue reading “来自支付宝架构师的一些体会”