读《高扩展性网站的50个原则》笔记

    个人感触比较深的如下几个原则。

     原则一：不要过度设计

      目的：防止设计中出现复杂的解决方案。
      适用情形：适用于任何项目，所有大型的或复杂的系统和项目都应该采用该原则。
      应用方式：让同行来检查解决方案是否好理解，抵制过度设计的强烈欲望。
      应用理由：复杂的解决方案实施成本高，而且会产生大量长期成本。
      要点：过度复杂的系统会限制扩展能力。简单的系统更容易维护和扩展，且成本更低。

       开发一个员工打卡系统，这个系统能够处理的员工数量是整个地球上人数的100倍，mygod。

      要测试系统是否太复杂，一个很好的办法是让负责解决复杂问题的程序员把他的解决方案陈述给公司内的一组程序员(这组程序员最好是公司内不同编码水平，不同工作年限)，
需要这组程序员中的每一位能够轻松理解该解决方案，能够在无帮助的情况下向他人陈述，而不只是他知道，如果这组程序员一位都不能理解该解决方案，那么需要讨论该系统是不是过度复杂了。

    原则三：把方案一简再简

      目的：在设计复杂系统时使用此原则简化方案的范围、设计和实施。
      适用情形：在（编程或者计算）资源有限的情况下设计复杂系统或产品时使用。
      应用方式：用帕累托法则简化范围（2-8 原则）；从成本效率和可扩展性出发简化设计；利用他人的经验简化实施。
      应用理由：只是着重于"不要复杂"不能解决需求、故事及事件编排和真正的实施带来的各种问题。
      要点：在产品开发的各个方面都要简化需求。

     原则五：尽可能减少对象

      目的：尽可能减少页面上的对象。
      适用情形：所有性能至关重要的Web页面。
      应用方式：减少或合并对象，但要与最大同时连接数进行平衡；测试修改过的页面，确保性能提高了。
      应用理由：对象数量会影响下载时间。
      要点：对象和提供它们的方法之间的平衡是一门学问，需要适时调整。这是客户的可用性、有用性和性能之间的平衡。

     如：web页面优化类。

     1. 图片精灵方式(一组小图像的集合，这些小图像被组合成一个较大的图片)，css处理这幅图片就可以显示其中一个小图片，非常常见。

     2. 每个服务器从一个域中同时下载多个对象的数量，如果采用不同的域(子域)，那么可以添加访问速度，但这个是权衡，根据不同网站的情况。

     原则七、原则八 横向复制和纵向复制

      1. 横向：复制服务或数据库来分散事务负载。  通过负载均衡实现服务器的搭建，数据库层 master/slave

      2. 纵向：数据拆分，服务拆分方式

     原则十二：横向扩展数据中心

       设计有三个或更多个的实时数据中心的系统

       传统集中化磁盘阵列的成本与其交付的性能简直不成正比，尤其考虑到服务器是以复杂纠结的方式附属在数据中心，还有存储系统与网络需要管理与监控。相反，本地存储很简单。每个人都知道是如何运作的，所以也能相对减少人为错误。其速度对于多数工作负载来说也是快的，尤其是现在多数RAID控制器提供原生固态驱动缓存。每个服务器监控工具都能监控本地存储。

   

     原则十四：合理使用数据库

       关系型数据库，文件系统，NoSQL, 在选择最合适的存储工具时，要考虑数据量、存储空间、响应时间的要求、关系以及其他多种因素。

      

     积极利用缓存：商业世界中常说的一句话“现金为王”，在技术世界中，与之相近的说法是“缓存为王”。

        

     原则二十一：使用过期头

        合理地使用过期头可以将网页内容缓存在客户端，减少客户端对服务器的重复请求，大幅提升网站性能

        要在服务器端配置，Expires 和 Cache-control。 如果在Apache2.2中，配置在httpd.conf 文件中进行。可以采用AOL为而是网页开发的一个开源工具，webpagetest.org.

     原则二十三和原则二十五 利用页面缓存和利用对象缓存

       页面缓存和对象缓存：选择一种缓存系统并部署。Ehcache页面缓存等。

       理想的缓存命中率是85%或更高，如果缓存命中率下降了，应该考虑增加更多的对象缓存服务器了。

      原则二十九：没有回退功能的设计是失败的设计

       保留一个当前可运行的版本
       适用情形：确保所有的版本都能够回退，在一个阶段或QA环境中，要实践回退功能。在生产环境中，当必须用它解决突发事件时，要使用回退功能。
       应用方式：整理代码，制定几个简单的流程，确保能够回退自己的代码。
       应用理由：如果你还没有经历过不能回退系统的痛苦，那么如果继续玩火，不停地迅速修复系统，迟早会遇到这种问题。
       要点：不要用应用太复杂或者代码发布太频繁作为借口，拒不加入回退代码的功能。一个明智的飞行员，如果没有具备让飞机着陆的能力，就不会让飞机起飞。一个明智的程序员，如果不能让系统在紧急情况下回退代码，就不应该发布代码。

        坚持几个简单的原则，所有团队都能进行回退
             1.数据库修改只能是增量的
             2.DDL和DML必须脚本化且测试过
             3.对应用中的SQL查询进行约束
             4.数据的语义修改
             5.Wire On/Wire Off， 能让有限的用户对新功能进行A/B测试

     原则三十九：确保能启用/禁用功能

        适用于有风险的或共享的服务

       实用方法：

                     1. 根据超时自动停用

                     2. 替代服务

                     3. 同步标记停用命令

                     4. 使用配置文件标记停用

                     5. 用文件标记停用

                     6. 用数据库标记停用

                     7. 采用运行时变量

   原则四十一：尽可能在浏览器端维护会话

     采用cookie在用户的浏览器端存放会话数据

     需要考虑会话被劫持，需要保护机制。推荐一种至少利用两个cookie的方法，一个cookie是授权cookie。

   原则四十九：设计能够监控的应用

      目的：在设计阶段就考虑需要如何监控应用。
      要点：把应用必须能被监控作为一条架构设计原则。此外，考虑一下你的全局监控策略，确保你能第一个答出下面的问题：“发生问题了吗？“ “哪里发生问题了？“  ”是什么问题？“
      监控工具如 cacti, ntop, nagios, zabbix等，可检查网络流量，服务器的cpu和内存用量，然后安装警报功能；还需从业务指标角度来监控系统（用户角度监控系统），如监控购物车的数量和每个时间段的购买总值。
     最后一个监控能回答的问题是：“会发生问题吗”，这类监控需结合业务监控数据，应用监控数据和硬件监控数据，可使用图形统计工具或神经网络或贝叶斯分类这类的机器学习算法来分析数据，以便预测是否会发生问题，最后一步必杀技：监控到预测将要发生问题时，系统能自我修复（自动故障切换监控）