架构的设计(三)

扯淡一把：

1. 可用性
2. 可修改性
3. 性能
4. 安全性
5. 可测试性
6. 易用性
7. other:上市时间、成本/收益、系统生命周期、目标市场、推出计划、与老系统的集成

这些东西虽然不是系统的功能需求，如果可户的这些要求达不到，最终会要求退货的。下面我们来吹吹怎么实现这样的非功能需求。

上面的各个属性都是相互制约的，都会对系统产生消极的影响，甚至相互是矛盾的，就要求我们怎么去取舍，在构架的设计中去折中 处理。

(待续)

1. 从现实的系统出发，处理系统的HA，业界的方法也就是集群，在下个逢值到来之前，弄几个机器放上去，或增加web容器，或增加DB；增加cache
2. 修改性嘛，其实还是代码的质量问题，让架构对程序员写的代码做约束，限制程序员的随意性
3. 性能问题，先不说
4. 安全性，没有绝对的安全，够用就可以了，ca ,https,saml.amopoint等，
5. 易用是个问题，多和美工沟通一下吧