读书 – 软件架构师应该知道的97件事

-摘自”软件架构师应该知道的97件事”

“…但在现实世界中,最好的架构师不是要去解决难题,而是要围绕难题开展工作.架构师要能够将四处弥漫的软件问题圈起来,并画出其中的各种边界(接口),确保对问题有稳定的,完整的认识.”
–Stable problems get high-quality solutions
“架构师要从整体上看待杂乱无章的数据/概念/数据处理逻辑,架构师要能够将他们作为整体看待,并将它们分解为更小的片段或”块”.重点在于,这些问题必须是稳定的,它们在范围上有限且稳定,可以作为系统模块解决.”
–Stable problems get high-quality solutions
–上面两点说的无外两点: 正确的确定scope, 合理的架构拆解

“从架构师角度看,困难的所在,是要找到设置边界的自然之处,并定义出构建可工作系统所需要的合适接口.大型的企业系统,其自然边界稀少及多个领域之间互有纠缠,做到这点尤为困难.”
–Architects’ focus is on the boundary and interfaces

“称职的架构师应该勇于接受新观念,敢于尝试新的设计思路和工具,促进项目/团队,甚至整个行业的发展;他不会浪费大把的时间参与管理层会议,或者妄想独自编写所有代码;他应该采纳好点子,营造活跃的思考氛围.只有思想开放的架构师才能平衡各种矛盾因素,顺利完成项目.”
–Janus the architect

“将程序设计–或者更准确的说,软件开发, 看作发现和学习的过程,而不是生产和建造的过程.”
“如果把编写代码看成设计行为,而不是生产行为,我们就能采用一些已经被证明有效的管理方式,这些方法过去用于管理具有不可预测性的创新工作,比如研发新车/新药/新的电脑游戏.我所指的是敏捷的产品管理方法和精益生产方法,比如scrum,它们关注如何为客户实现最大的投资收益”
–Programming is an act of design

“沉下心来改善系统的生产效率,缩短流程,避免各行其是,才能缩短开发时间.采取一切可行的措施,例如运用模拟方法,降低依赖性,细致划分系统模块,等等.总之要杜绝一起草率提价任务的念头”
–Commit-and-run is a crime

做事的人

有的人, 只需要告诉他做什么,就可以自己去想办法完成.
有的人,必须要坐在他旁边,无论是不是提供指导,才能把事情做好.但这里又有两种,一种人不喜欢别人坐在旁边,以后有可能会成为第一种人,还有一种很喜欢别人坐在他旁边.因为这样他自己就不需要动脑子了,这种人可能会变成下面那种人.
有的人,就算是坐在他旁边,也无法把事情做好.

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

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

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

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

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

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

使用AOP处理事务重试

以下摘自<pojo in action>备查. 算是比较有用的东西,以后可能用到.

Using an AOP interceptor to retry transactions
A Spring application can use a custom AOP interceptor to catch the Concurrency-
FailureException and automatically retry the transaction. Here is a custom
Spring AOP interceptor that does this:
public class TransactionRetryInterceptor
implements MethodInterceptor {
protected int maxRetryCount = 3;
public void setMaxRetryCount(int maxRetryCount) {
this.maxRetryCount = maxRetryCount;
}
public Object invoke(MethodInvocation invocation)
throws Throwable {
int retryCount = 0;
while (true)
try {
ReflectiveMethodInvocation inv =
(ReflectiveMethodInvocation) invocation;
MethodInvocation anotherInvocation = inv.invocableClone();
return anotherInvocation.proceed();
} catch (ConcurrencyFailureException e) {
if (retryCount++ > maxRetryCount)
throw e;
else {
continue;
}
}
}
}
This class has a maxRetryCount property whose default value is 3. The invoke()
method catches the ConcurrencyFailureException and loops at most maxRetry-
Count times, retrying the transaction. Because proceed() can only be called once,
invoke() clones the MethodInvocation before calling it. The TransactionRetry-
Interceptor is a good example of the power and flexibility of the Spring framework.