架构设计总体设计原则 -- 架构设计思考点

一个好的架构设计不全是考虑有多么先进的技术，相反先进的技术仅是其中一个很小的点。在此偶分享一下设计经验，主要是为了将自己的经验记录下来，以免以后忘了！毕竟已经开始慢慢不做技术了，担心再过几年已经没有能力写出这些内容来了。

在偶看看一个架构首要重要的就是要做到全面考虑问题，在此偶列出一些容易忽略的设计点（尤其是刚开始做架构设计的设计师）：

1、 设计时一定要考虑将来如何发布和更新
面对一个7X24小时的系统，如何停机更新？显然一次停机升级影响较非常大，例如：银行核心业务系统，能停机吗？停机的代价是否很大？
1） 争取做到只有在代码变更的情况下才需要停机升级，估计很多人都觉得这是废话：当然只有代码变化了才可能发布，对可能大家都是这么想的，但未必这么做了，例如：将全局变量的值写在常量类中，如果此全局变量改变，那么当然是需要更改代码的，在此我所说的这类错误的代码变更就是需要在设计过程中需要特别注意的（后面我会有文章介绍如何做常量、全局变量的设计另外，对于有些经验的架构师可能会发现做小系统的架构比较容易，但对于复杂系统的架构就完全不一样了，复杂系统通常有多台服务器，而且每台服务器上还有多个端口对外服务）；
2）在更新时也尽量保证有一台可以对外提供服务的系统，发布要分为两部分：数据库脚本和程序更新，其中：数据库脚本一定要控制不能现有应用，因为此次还有老应用正在运行；应用程序的更新可以一台一台的更新，因此需要提供一台备用应用服务器，平时不对外提供服务，每次发布时，先发布这台备用机器，在此备用机器上验证了完之后，再正式更新在线应用，在正式更新前请将对外服务指向那台备用服务器，然后再更新原来的在线应用；
3）在未做Session复制的情况一下一定要提供Failover机制，防止在更新时影响用户，有人会觉得奇怪为什么不做Clustering，利用Clustering就直接Session复制了，我请问如果有10000的在线用户，一个用户的Session有10K大（不算太大吧），请问Session的有多大？仅Session就要占掉每台应用服务器100M的内存，请问Java的堆内存最大能设多大？另外，如果频繁的Session复制AdminServer是否能撑住？

2、 要考虑在线验证方案
什么叫在线验证？就是在新上功能只能如何验证整个系统是正常的？各位是否遇到在新上功能后不知道如何合理进行验证，某些人就是直接在生产环境中用特定的数据进行测试，但请问如果是银行核心系统，要存款和取款如何测试？难道我首先存一笔，然后再取出来？看起来不太合理吧？我推荐各位一种方法：在生产系统中就是单独建立一批虚拟数据，加入是银行，那么可以建立一个虚拟机构，在此机构下建立的所有数据都是测试数据，这时就可以放心测试了。

3、 架构设计要注意当系统换代之后还希望留下些什么有价值的东东
任何一个系统都有下线的时候，那么当下一代系统开发时，当前这代还能留下什么东东？如果能留下的东东，那么就要注意设计，或者能够组件化等。