一个好的架构设计不全是考虑有多么先进的技术，相反先进的技术仅是其中一个很小的点。在此偶分享一下设计经验，主要是为了将自己的经验记录下来，以免以后忘了！毕竟已经开始慢慢不做技术了，担心再过几年已经没有能力写出这些内容来了。
在偶看看一个架构首要重要的就是要做到全面考虑问题，在此偶列出一些容易忽略的设计点（尤其是刚开始做架构设计的设计师）：
1、[b]设计时一定要考虑将来如何发布和更新[/b]
面对一个7X24小时的系统，如何停机更新？显然一次停机升级影响较非常大，例如：银行核心业务系统，能停机吗？停机的代价是否很大？
1）[b]争取做到只有在代码变更的情况下才需要停机升级[/b]，估计很多人都觉得这是废话：当然只有代码变化了才可能发布，对可能大家都是这么想的，但未必这么做了，例如：将全局变量的值写在常量类中，如果此全局变量改变，那么当然是需要更改代码的，在此我所说的这类错误的代码变更就是需要在设计过程中需要特别注意的（后面我会有文章介绍如何做常量、全局变量的设计另外，对于有些经验的架构师可能会发现做小系统的架构比较容易，但对于复杂系统的架构就完全不一样了，复杂系统通常有多台服务器，而且每台服务器上还有多个端口对外服务）；
2）在更新时也尽量保证有一台可以对外提供服务的系统，发布要分为两部分：数据库脚本和程序更新，其中：数据库脚本一定要控制不能现有应用，因为此次还有老应用正在运行；应用程序的更新可以一台一台的更新，因此需要提供一台备用应用服务器，平时不对外提供服务，每次发布时，先发布这台备用机器，在此备用机器上验证了完之后，再正式更新在线应用，在正式更新前请将对外服务指向那台备用服务器，然后再更新原来的在线应用；
3）在未做Session复制的情况一下一定要提供Failover机制，防止在更新时影响用户，有人会觉得奇怪为什么不做Clustering，利用Clustering就直接Session复制了，我请问如果有10000的在线用户，一个用户的Session有10K大（不算太大吧），请问Session的有多大？仅Session就要占掉每台应用服务器100M的内存，请问Java的堆内存最大能设多大？另外，如果频繁的Session复制AdminServer是否能撑住？
2、[b]要考虑在线验证方案[/b]
什么叫在线验证？就是在新上功能只能如何验证整个系统是正常的？各位是否遇到在新上功能后不知道如何合理进行验证，某些人就是直接在生产环境中用特定的数据进行测试，但请问如果是银行核心系统，要存款和取款如何测试？难道我首先存一笔，然后再取出来？看起来不太合理吧？我推荐各位一种方法：在生产系统中就是单独建立一批虚拟数据，加入是银行，那么可以建立一个虚拟机构，在此机构下建立的所有数据都是测试数据，这时就可以放心测试了。
3、[b]架构设计要注意当系统换代之后还希望留下些什么有价值的东东[/b]
任何一个系统都有下线的时候，那么当下一代系统开发时，当前这代还能留下什么东东？如果能留下的东东，那么就要注意设计，或者能够组件化等。
5.1 设计思想
5.1.1 结构化总体设计概述设计原则结构化总体设计的启发式规则结构化总体设计的方法结构化方法下总体设计的模型表示（功能结构图、IPO图、系统流程图、配置图）5.1.2 面向对象总体设计概述面向对象总体设计的原则面向对象总体设计的启发式规则面向对象总体设计的方法面向对象总体设计的模型表示（功能结构图、类图、辅助图（包括状态图、时序图和协作图）、组件图、配置图）5.1.3 数据库统计5.1.4 应用系统的安全设计程序资源访问控制安全功能性安全数据域安全5.1.5 总体界面布局5.2 结构化总体设计5.3 面向对象总体设计
转载于:https://www.cnblogs.com/Sunny-ky/p/8734434.html
//设计模式帮助我们实现可复用的组件，所谓"可复用"，就是指将类实现为"组件"，当一个组件发生改变时，不需要对其他组件进行修改或是只需要很小的修改即可应付。
//设计模式分为三大类：
//创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
//结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
//行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。//设计模式的六大原则：
//总原则－开闭原则
//对扩展开放，对修改封闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。//1)单一职责原则
//不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，否则就应该把类拆分。//2)里氏替换原则
//无论在父类类型的变量中保存哪个子类的实例，程序都可以正常工作，这种原则被称为里氏替换原则。里氏替换原则是继承复用的基石，只有当子类可以替换基类，软件单位的功能不受到影响时，基类才能真正被复用。//3)依赖倒转原则
//面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类上层的抽象接口交互，优先使用抽象类和接口来编程。//4)接口隔离原则
//接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。//5)迪米特法则
//一个类对自己依赖的类知道的越少越好。无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。//6)合成复用原则
//尽量优先使用组合或聚合的方式，而不是使用继承。//学习某种设计模式要从"角色"的角度来理解各个类和接口在模式中扮演什么样的角色，思考和理解这些"角色"的交互可以解决哪些问题，不要只是阅读书中的案例死记硬背。
