大型网站架构读后感

Posted 2020-09-05 牙吃多了糖疼

读了这三章，再回过头来看自己的系统倍感羞愧。因为编写这套系统的时候，是秉着完成作业的心态去写的，所以好很多功能由而不完善，根本不能实际运行，究其原应连这么几个。一是自己的态度不认真，二是因为自己的理论基础不牢固，因为前期的学习过程中有点偷懒，所以在设计的时候又很多东西是想不到的，这也导致了系统的不完善。

      全读者三章之后，发现要改善这个系统，必须要存这三个方面入手。可用性，易用性和可扩展性。

      先来了解一下可用性。可用性与系统故障及其相关后果有关。当系统不再提供其规范中所说明的服务时，就出现了系统故障。系统的用户（人或其他系统）可以观察到此类故障。系统可用性是系统正常运行的时间比例。一般将系统可用性定义为：α=平均正常工作时间/（平均正常工作时间+平均修复时间）。有两个著名的例子。2011年4月12日，亚马逊云计算服务EC2发生故障，其ESB服务不可用，故障持续了数天，最终还是有部分数据未能恢复。这一故障导致美国许多使用亚马逊服务的知名网站受到影响，并引发了人们对使用云计算安全性、可靠性的大规模讨论。2010年1月12日，百度被黑客攻击，其DNS域名被劫持，导致百度全站长达数小时不可访问。

      网站不可用也被称为网站故障，业界通常用多少个9来衡量网站的可用性，对于大多数网站而言，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站的年度不可用时间小于53分钟，比如QQ就是4个9；5个9是极高可用性，网站年度不可用时间小于5分钟。可用性指标是网站架构设计的重要指标，是网站或者产品的整体考核指标。网站可用性是更加看得见摸得着的质量属性，所以在架构设计上，系统可用性的部分就需要花费更多的时间和精力了。而实现高可用架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。所以就我们的《XXX系统》来说，不是只要完成系统的功能就等于完成了这个系统，根据系统的可用性，做好数据的备份和还原是最重要的保障之一。但是我们在设计和开发这个系统时，却把大部分精力放在了功能的实现上，这是一个很大的误区。在数据库的设计方面也是很重要的，加密存储、及时备份、保存日志都不失为是一个好的方法。保证数据的可持久存储，数据的可访问性，在数据有多份副本的情况下的一致性，都可以更好的维护我们的系统，提高我们系统的可用性。在服务器宕机时，进行失效转移可以保证数据访问不会失败，失效确认、访问转移、数据恢复都可以保证网站的数据不会丢失。对于我们的这个系统，为了保障高可用运行，我们还可以使用发布脚本来完成网站的更新发布，可以减少重启服务器和重新部署，而且不会影响用户使用。

      上面说了可用性和易用性，可用性就是系统要能用，不能三天两头的出故障，这样会造成用户的大量流失。易用性是基于可用性的，在能够实用的基础上还要好用。下面说一下可扩展性。这一点主要是为了满足随时可能改变的用户需求和可能增加的系统功能。

      现如今的网站，想要引人瞩目，在激烈的竞争市场上生存下来取决于谁能更快更好地推出新产品。也就是意味着我们需要一个更具有扩展性的网站架构实现一个效率更高、可用性更好的网站。这也就是网站架构的意义所在。