architect bootcamp笔记

tranditional system asumption通常认为系统都不是分布的,系统是由一个集中的应用构成,并且大多数操作都是本地的,所有的交互都是可预测的,并且所有的全局状态都是可见的.
–这是大多数人仍然保有的观念,随着复杂度的增强,系统将变得越来越难以维护,原有的”简单”早就了后续工作的复杂度的剧增.

为了避免这种错误的观念,书中列出了两种方法:
1.proactive thinking leads to architecture,
2.design and software reuse

由于当前所使用的编程语言和系统容量,大多数的软件模块是不可维护的,除非是由原本创造的程序员.每年有30%的的开发人员更新率是的很多文档不全或者是由某些英雄主义程序员开发的系统变成不可维护的烟囱系统.

好的程序员是必要的,但不是使系统成功的充要条件.

没有计划,很多个人的成功并不足以让整个项目成功.
Without planning, it becomes apparent that many individual success are not sufficient for overall project success.

architecture-centered process(以架构为中心的过程)
步骤:
1.System envisioning(系统总览):决定purpose,focus,assumptions,and priority
2.requirement analysis(需求分析)
3.architecture planning(架构规划) :以下是Open Distributed Processing(ODP)的基本概念:
a.business enterprise architecture:关注业务建模
b.logical information architecture:关注数据库建模
c.computational interface architecture:关注接口设计
d.distributed engineering architecture:关注操作系统
e.technology selection architecture:关注网络工程
–ODP的主要贡献是提出了”关注点分离”的概念,可以让以上的每个架构concern由不同专业的人来分工完成.
4.mockup(界面模拟)
5.architecture prototype(架构原型)
6.project management planning(项目管理计划)
7.parallel incremental development(并行增量开发)
8.system transition(系统切换)
9.operations and maintenance(操作和维护)
10.system migration(系统升级)

时间安排:
50%的系统计划
50%的开发(其中编码占一半,测试和培训占一半)

通过架构来管理复杂度:
造成复杂度增加的原因有:
1.认为管理复杂度是不关紧要的
2.不重视教育/培训和实践理复杂度的模式
管理复杂度的常用方法:
1.封装
2.repository architecture
3.横向架构
4.分层架构
5.纵向架构

A software architect is sometimes required to mediate between conflicing demands of project management and higher-level stakeholders in  a devleopement project.
某种程度来说,每个项目计划都是”梦想”,是程序员一砖一瓦早就了交付的软件.架构师必须非常积极的去通过沟通和管理来满足程序员的需求,预估各种工具的采购,保证团队的被认可.架构师最终的价值在于让程序员可以高效有效的工作.

软件开发的一个常识:好的架构不是偶然发生的.而是必须经过规划,监控和不断的经受各种质疑的挑战之后才铸就的.如果作为架构师不能持续的监控软件的执行情况并确认是否按照约定和设计的运行,那么就是架构师的失职.

成功架构师的七个习惯:
1.keep it simple:和团队沟通时尽量沟通思想而不是技术细节.
2.let others defend the architecture: 让其他人来提出/回应技术方面的质疑.
3.act , dont argue: 争论伤感情,无产出,百害无一利.
4.keep an eye on the prize:始终想着最终目标
5.be willing to change , but never too much at once:不要引入太多风险,变化带来不可控,不可控就是风险点.
6.learn where to stop:不要过多的做细节的事,不要在设计决策方面进行微观管理
7.know how to follow:虚心跟随,打造专注高效的团队气氛

hessian的异常处理和异常监控机制

现在项目中用到大量hessian, 虽然做到了系统间的解耦和方便的调用.但并不确定当出现系统异常时如何在最快的时间发现并能自动重置.今天想了一些办法,记录下来可以在后续的工作中尝试. 这些方法并不一定只适用于hessian.

1. 拦截hessian调用异常,然后将异常请求放到重试mq中.由专门的mdb对这些调用异常进行重试.对于非实时的调用可以用这种方式, 调用方需要同样适用mdb对这些”异步的异常重试处理”进行处理. 这样做是不是反而增加了系统复杂性? 遇到异常通常是哪些原因: 无非是服务端挂掉(包括重启中),网路连接异常. 只要是暂时性的大不了重试呗. 保证数据正确性和完整性就可以了. 如果能在第一时间做到报警就很不错了.

2. 对所有的远程接口进行定期心跳测试,当满足某些规则时报警.这样可能是增加服务器的负载. 会不会因为这些反而影响到吞吐量?

3.有点类似第一条,将所有hessian调用都变为异步,充分利用mdb和mq.同步请求的处理是否能够满足要求? 还是在系统设计时就考虑一些这方面的东西 – 尽量不要使用客户端直接发起的同步业务操作; 业务操作接口设计为无状态的,避免操作之间的过度依赖 …

先就想到这么多. 休息一下,准备晚上看西班牙和荷兰的决赛!

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

笔记 – 互联网产品业务级别划分

摘自支付宝架构师程立的演讲ppt – SOA在互联网系统中的应用

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

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

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

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

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

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

某对架构师的要求

从网上看到的某架构师的招聘要求:

The Senior Solution Architect (Systems) has a broad range of technical skills on systems solution. He/she involves leading the architecting and designing of systems solution consisting of Server, Blades, cluster, and management.

The Architect has overall responsibility for gathering customer’s business requirements, translating those requirements into cost-effective solution, strategies, architectures, and guiding the implementation of those solutions to deliver high quality outcomes to meet or exceed customer expectations in a timely manner.
Responsibilities and Accountabilities:
-Develop trusted advisor status with customers and provide technical leadership in architecting technical solution for customers.

-Act as lead architect, or as a member of a team of Architects to lead and oversee solution implementation and project delivery, including creation of detailed designs of storage solution. Continue reading “某对架构师的要求”

关于SOA

今天被一位兄台问起什么是SOA,虽然知道这个名词,但还是很老实的说不了解。既然不了解,那就再去尝试了解一下。SOA是针对企业架构(EA)或者整个IT系统网络。Webservice只是一个工具去把这些服务连接起来。另一个重要的工具是message,或者说的牛x一点 – message-oriented middleware,面向消息的中间件。message体现在哪里呢?

举个简单的例子,平时在写程序的时候常常说方法调用,这方法调用有两种形式,主动和被动。主动调用很简单就是A.call(B),这种调用很常见,但是有一个问题 – 它是同步调用,也就是在这个调用过程中程序不能做其他事情,直到调用结束。另一种被动调用,有点像是事件监听响应的意思(设计模式里的观察者),调用形式如: A.notifyListeners->[queue]->B.onEvent,或者也说异步调用,解决常见的并发问题。

那么webservice就用来定义一个统一的接口,主要是主动调用,而message queue则是用来被动调用时发送消息。SOA的目标(猜得):所有的应用系统都被设计为对外提供服务的一个个节点,节点之间要么通过主动调用发布消息(webservice),要么通过message queue发送相应来自其他节点的消息。

SOA是从整个IT系统网络的角度去考虑分布式系统的整合,重用,优化。另一点要提到,通常的应用系统之间的webservice调用都是无状态,因为“有没有状态”不是SOA要解决的问题,而是工作流来解决的吧(也是猜得)!

面向服务架构SOA(Service-Oriented
Architecture)是一种架构模型和一套设计方法学,其目的是最大限度地重用应用程序中立型的服务以提高IT适应性和效率。它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。
SOA的关键是“服务”的概念,W3C将服务定义为:“服务提供者完成一组工作,为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化,但也可能使提供者的状态改变,或者双方都产生变化”。