首先说冗余设计，冗余包含逻辑冗余，数据冗余，应用冗余等。这里以应用冗余为例。一方面为了提高应用服务器性能，另一方面为了提高系统的可靠性，可拓展性等，我们采用了负载均衡技术。常见的负载均衡技术有F5硬件，LVS软件，Nginx服务器配置等。出于便捷与成本的考虑，我们采用了Nginx服务器配置负载均衡技术。通过对Nginx服务器中upstream模块的配置，就可以实现在多台服务器的反向代理家在负载均衡。为了提高负载均衡服务器可靠性，我们采用双机热备机制。但采用负载均衡后，应用服务器集群出现了Session问题无法统一的问题。解决方法有Session Sticky，Session Replication，Session数据集中存储，Cookie Based四个方案。Session Sticky是通过确保同一个会话的请求都在同一个Web服务器上处理实现。Session Replication是增加Web服务器间会话数据的同步来保证不同Web服务器间的Session数据的一致。但一方面同步Session数据会造成网络带宽的开销。另一方面，每台Web服务器都要保存所有Session数据，消耗大量内存。经过考虑，我们采用了第三种方案-Session数据集中存储。Session数据集中存储通过令每台服务器从专门的session服务器获取session数据来解决问题。优点是可靠性，可移植性与可拓展性的大幅提高。缺点是一方面读写Session数据引入了网络操作，对数据读取存在时延和不稳定性，但对于使用内网通信的系统并没有太大影响。另一方面，如果Session服务器或集群出现问题，将会影响整个应用。我们通过双机容错机制解决该问题。Cookie Based就是通过Cookie传递Session数据完成。实现简单，但是存在如Cookie长度限制等问题。除此之外，还有心跳线，看门狗等诸多技术。限于篇幅，不再赘述。
再者就是降低复杂度设计，我们从架构风格选择，技术选型等角度实现。由于系统的复杂性和综合性，我们决定采用层次架构风格，将系统架构分为接入层，应用层，服务层，数据层四个层次。接入层负责多平台的接入，以及API网关，负载均衡等方面。API网关的使用使得对外资源与服务获得统一，保持系统结构的明确，从而提高了系统可靠性。应用层分为视图层与业务逻辑层，视图层负责App与网站的表现效果，业务逻辑层负责业务层的逻辑处理。为了解决系统日益复杂，应用日益臃肿问题，我们将系统按照应用横向划分，将系统划分为课件管理系统，课程管理系统等十余个子系统。这样的划分使得系统体系变得清晰明了，极大降低系统复杂度，提高系统可靠性。应用层采用基于J2ee的MVC框架-Structs框架。服务层提供通用服务。系统在应用层中按照应用横向划分，有效降低系统复杂度。但系统代码仍然存在冗余，比如用户信息的调用在诸多应用子系统中都有相关模块。另外应用的大小依旧十分巨大，复杂，而过小的应用划分会增加数据库连接数负担，故我们提出服务化解决方案。服务化方案就是提取出各个应用的通用服务，如账户服务，Session服务等。出于技术成熟度与技术支持等考虑，我们最终采用了阿里的dubbo服务框架，建立服务层。数据层涉及缓存，文件系统，数据库，数据通知服务，搜索系统等模块。由于用户对数据访问具有集中性，故我们基于Spring Cache与Redis实现缓存机制。数据访问方面，Java已经有很多成熟技术，大致分为专用API方式，JDBC方式，给予ORM或类ORM接口方式三种。最终我们采用了成熟的ORM框架-Mybatis框架，再将框架包装一层。这样一方面提高系统开发效率，另一方面提高系统可移植性与可靠性。除此之外，还采用了solr作为数据层搜索引擎，数据访问层物理部署采用Proxy方式。限于篇幅，不再赘述。
最终项目成功上线，正常运行了近一年半，收到各方好评。尤其是H5课件的良好互动性，使得大量业界同行争相模仿，改用H5制作课件。还有我们的服务化方案架构被作为许多传统互联网企业系统重构的经典方案。在系统的架构设计中，我们引入了层次架构的设计思想，有效地降低了维护成本，提高了系统的开放性，可扩展性，可重用性以及可移植性。当然还是存在一些问题的。如H5课件采用http协议，易被非法劫持，嵌入广告，可以将协议修改为https来解决。还有我们采用的负载均衡算法是加权轮转算法，过于简单，常常出现资源分配不合理的现象，可以将算法改为加权最小连接数算法来解决。这些都是我在今后的系统设计和开发中需要注意与改进的地方，也是日后我应该努力的方向。