架构指标（请架构师高台贵脚，华丽地飘过）

借用投资学里面的两条金科玉律，

1,永远不要亏损

2,永远不要忘记第一条

 

我理解的软件架构也有两条

1,永远不要当机

2,永远不要忘记第一条

 

近看到一些关于银行系统架构和MES 架构的帖子，写点感想。请伟大的架构师们高抬贵脚，昂起您那高贵的犄角，勇敢而华丽地飘过。

 

排名按优先级分先后，

高可用性 ，这个是底线，如果一个系统三天两头Down 掉，真的很丑

关键字：集群，负载均衡，冗余,故障转移

高性能 ，一个报表要跑两天两夜才能跑出来，一个事务要10 分钟才能处理完，这样就算穿了裤子可能也是透明的，比当机好点，但也好不到哪里去

关键字:缓存，异步(JMS)

可维护性和灵活性 ，如果客户是有序经营的，系统绝不会做出来就结束了，所以也要留后路

文档完整，架构合理

可管理性 ，方便的性能监控和问题诊断，这个对架构师来讲太重要的，否则出了问题，很要命

易实现性 ，搞了个架构，看上去很美，但无法实现，或者实现成本太高，也是个笑话

 

如果你真的在做架构的话，这些指标，特别是前两个，是万万要满足的，还要在足够的并发性(单位时间内处理事务的数量)和数据量(IO 流量)前提下满足。否则你的日子会很难过的，绝对不骗你。

 

当然要达到这些指标，架构师要考虑的问题非常多，

硬件配置

网络环境

业务模型，OLAP 和OLTP 绝不一样，一般管理系统和银行Core 系统也不一样吧

人文环境，用户群不一样，做的系统也不可能一样的

中间件支持

客户端环境

... ...

最后才是根据处理的业务选择架构模型(技术解决方案)，比如

分层架构, 比如常见的3 层模型

基于总线的架构， 如ESB

代理架构， 比如要采集全球的销售数据，可以在每个大洲设置代理分别采集，然后汇总到总部做分析

基于模板的架构 ,如CMS

传统的C/S 架构

数据仓库的ETL 模型, 如OWB

集群和负载均衡

SAAS

Grid Computing

... ...

上面的分类是我从工作中自己总结出来的，绝不是权威，若有不当之处，误导或者伤害了大人您，见谅。

架构就在你我身边，没那么高深，可是也千万不要无视它，只要你开始思考系统的架构特性，你就在做架构了。那些所谓的牛人，也只是因为上的船比较大，慢慢的越搞越大，最后自然也就比较厉害了，罗马不是一天建成的，也不是一人建成的，如此而已。

我想做什么系统起码从样子上看要像什么系统，否则效果就像吴君如穿旗袍，旗袍很好，吴君如也是很不错的 演员，只是风格不搭配，效果就不怎样了（比喻来自黄健翔的球评）。