《XXX重大技术需求征集系统》的可用性和可修改性战术分析

阅读《大型网站技术架构：核心原理与案例分析》第五、六、七章，结合《某重大技术需求征集系统》，列举实例分析采用的可用性和可修改性战术，将上述内容撰写成一篇1500字左右的博客阐述你的观点。

　　首先，网站的可用性（Availability）描述网站可有效访问的特性（不同于另一个网站运营指标：Usability，通常也被译作可用性，但是后者强调的是网站的可用性，即对最终用户的使用价值），相比于网站的其他非功能特性，网站的可用性更牵动人们的神经，也与公司形象和利益、工程师的绩效考核有着密不可分的关系。硬件故障是常态，因此网站的高可用架构设计的主要目的就是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问。而实现这种高可用架构的主要手段就是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务转换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。在这点中，有关XXX重大技术需求系统也需要具有这种可有效访问的基础，再去实现其他的特性，经不起网络可用性的度量与考核，其他的也都是白搭的。

　　典型的分层模型是三层，即应用层、服务层、数据层；各层之间具有相对独立性，应用层主要负责具体业务逻辑处理；服务层负责提供可复用的服务；数据层负责数据的存储与访问。中小型网站在具体部署时，通常将应用层和服务层部署在一起，而数据层则另外部署；在复杂的大型网站架构中，划分的粒度会更小、更详细，结构更加复杂，服务器规模更加庞大，但通常还是能够把这些服务器划分到这三层中。

　　除此之外，网站升级的频率一般非常高，每次网站发布都需要关闭服务，重新部署系统，整个过程相当于服务器宕机，因此网站的可用性架构设计不但要考虑实际的硬件故障引起的宕机，还要考虑网站升级发布引起的宕机，而后者也是更加频繁，不能因为系统可以接收偶尔的停机故障就降低可用性的设计标准。类比到我们的XXX重大技术需求系统，也是需要很高的可用性的设计的，老师也一直在提说，我们所编写的系统发布之后十几个人同时登录的话就会瘫痪，所以今后系统的设计应该加强可用性方面的设计。可以通过负载均衡进行无状态服务的失效转移，即为主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上，以提高整体的负载处理能力。所以现阶段我们可以使用开源免费的负载均衡软件来实现失效转移功能。

　　网站高可用性的基础还要保证数据的高可用性：数据持久性、数据可访问性、数据一致性。CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性（C）、数据可用性（A）、分区耐受性（P）这三个条件。在大型网站应用中，数据规模总是快速扩张的，因此可伸缩性必不可少，规模变大以后，机器数量也会变得庞大，网络和服务器故障也会随之频繁出现，要想保证应用可用，就必须保证分布式处理系统的高可用性。所以在大型网站中，通常会选择可用性和伸缩性，而在某种程度上放弃一致性。但应用系统需要对分布式数据处理系统的数据不一致性有所了解并进行某种意义上的补偿和纠错，一避免出现应用系统数据的不正确。数据备份也是我们XXX系统应该注意的问题，避免因一时故障而造成数据丢失的严重性错误。网站更新发布时通常使用发布脚本来完成，每次关闭的服务都是集群中的一下部分，并在发布完后立即可以访问，因此整个发布过程都不影响用户使用，过程如下：

　　发布之前可以采用预发布验证程序系统的问题，与线上的正式发布不同，没有配置在负载均衡服务器上，外部用户无法访问。另外，网站的扩展性架构设计，是对现有系统影响最小的情况下，系统功能可持续扩展及提升的能力。扩展性是指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。它是系统架构设计层面的开闭原则，架构设计考虑未来功能扩展，当系统增加新功能时，不需要对现有系统的结构和代码进行修改。设计网站可扩展架构的核心思想是模块化，并在此基础上，降低模块间的耦合性，提供模块的复用性。模块通过分布式部署，独立的模块部署在独立的服务器上集群从物理上分离模块之间的耦合关系。可用性战术中，系统需要用到了错误检测，在用户进行信息填入时（即为数据库的操作），比如：修改个人信息，填写需求等，在过程中发生错误的时候，系统可以自动返回，给出提示信息，并对已经进行的操作进行撤销，保证数据库信息的完善性。

　　有关于可修改性，有两个关注点：可以修改什么（制品）？何时进行变更以及由谁进行变更（环境）？在XXX重大技术需求系统中的体现就是对于界面的修改或者其他不涉及逻辑结构的修改，也正是由于MVC模式的实现，使得界面层（系统的可修改性）变得更加容易实现。此外，还有web服务器的安全性也是XXX系统中值得关注的问题，涉及填报数据的安全，还有用户密码的加密措施都会使得信息的安全性大大提高。