对系统我们现在也不陌生了，自己用过，也开发过，体验过一个系统是怎样进行运作的，系统要能够完整正常的呈现在用户面前，必然是要经过很多环节的，那么就不能有一点纰漏，当然故障也可能会由于一些外力因素所引起，但是至少我们应该使他达到所能到达的最好的健壮性，从而保障正常情况下系统的正常运行。
一个完整的系统能否用的长久不仅要看他的流程是否清晰，功能是否完整，更最重要的一点是，他能否有一个较好的可用性度量。可用性指标是架构设计的重要指标，他是对外服务的承诺，是对内考核的指标，甚至可以直接决定系统能否上线使用，是否成功，他也是对系统全面检测的关键，之前自己开发的系统虽然能够在功能上勉强使用，但是几乎谈不上可用性，原因除了技术不成熟之外，更重要的是没有考虑到他如果真正上线使用会是在一个怎样的环境下，在人数达到多少的时候会崩溃，数据是否有备份，是否可恢复，操作是否可逆，容错又是怎样的等等，可以说当时完全是没有想到这些要点的，只是一心想要完成应该有的功能模块，忽略了系统的安全性和稳定性。当然这些远远不够，应当还包括分级管理，超时设置，异步调用服务，降级等等，在数据方面一定要有加密，安全已经成为行业里开发的重要指标。可以说整个系统做下来完全没有办法使用，可见可用性对于一个系统的重要性是关乎生死的，可用性不高的系统，频繁的出现故障，一遇到故障，系统马上瘫痪崩溃，这样的场景真的是没有办法想象的，所以在开发的时候对系统的可用性的质量属性应该做最全面的测试，以满足用户和开发人员共同的利益。
可用性对于系统来说是至关重要的质量属性，再设计的时候应着重考虑，在对这个系统而言，开发完成后，在其所在的硬件设备上能否正常的运行，能否对前台数据和操作进行预处理和反馈，前后台传递是否安全，是否实时备份，中断后能否恢复，减小损失，数据库是否加密。监控数据采集、能否对用户行为日志进行收集、能否对服务器性能进行监控、自动降级处理等。有着一系列的考虑完善，对系统而言即便功能一般，可用性很高，但我们也不能保证我们的系统毫无故障，但我们能确定在故障后，我们会有相应的处理，努力不把自己的系统逼上绝路，使系统可继续服务，那么这么做的意义就显而易见了。
当然一个系统的伸缩性也是相当关键的。要实现网站的可伸缩性，关键技术就在于如何构建良好的服务器集群。要达到良好的目标，就要求每次扩容和减少服务器时，对整个网站的影响是最小的。CAP原理就是选择强化分布式存储系统的可用性和伸缩性，而在某种程度上放弃一致性。CAP原理对于可伸缩的分布式系统设计具有重要意义，不恰当地迎合各种需求，可能会使设计进入两难境地，难以为继。我们的系统有大量的统计数据。我们的网站随时都有可能进行修改，比如发布新功能，这时就需要在服务器上关闭原有的应用，重新部署新的应用，整个过程要求不影响用户的使用。为了把对用户的影响降低到最小，通常使用发布脚本来完成发布。
可扩展性是要根据所开发的系统的需求来确定，需求改变的速度的量化也会有所影响，但是在需要进行扩充的时候必须能够扩展。扩展性指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。我们不禁想到了面向对象中一大原则：开闭原则，对扩展开放，对修改封闭。也就说，当系统新增一个功能时，不需要对现有系统的结构和代码进行修改。设计网站可扩展架构的核心思想是：模块化，并在此基础之上降低模块间的耦合，提高模块的复用性。在大型网站中，这些模块通过分布式部署的方式，独立的模块部署在独立的服务器（集群）上，从物理上分离模块之间的耦合关系，进一步降低耦合性从而提高复用性。