杭州网站建设照片中的人物是杰夫德恩、谷歌分布式系统的灵魂人物，具体内容都可以在谷歌看到。 他的许多分布式系统设计思想影响着技术趋势。 用谷歌实现具体工作，领导未来。
由于目前网络上有很多类似的文章，该文仅仅记述了LNMP(LVS+NGINX+MYSQL+PHP )结构的个人看法，对于共同的做法，如运动分离、读写分离、cache为王、CDN等大型分布式系统的做法、灵活性、过载保护、动态运行等 介绍其他个人经验
一)简化体系结构的原则。 一定要保证框架的简化，在不引入多馀节点的情况下，尽量不引入多馀节点，保证框架的极度简化。 如果将体系结构拓扑图拆分为单个点和线，则必须基于java容器、jetty、resin和tomcat等标准来选择点。 只能选择一个。 在线定义是客户端如何实现对后端服务的调用、使用命名服务使用DNS的方案以及使用LVS和haproxy的方案。 事实上，更好的方法是使用客户端API为小型系统提供连接管理、状态管理和容错管理。 在大接入系统中，利用统一名称服务实现了从前端到后端的服务寻址，通行方式使用zookeeper，具有高分散特性，实现了高可用性( 5个节点)。
2 )框架分离原则。 这个原则似乎与第一条有些矛盾，其实不然。 业务越来越复杂，搭载的功能越来越多，必须分离不同的服务功能。 分离原则:以节点一定能够扩展为首要原则，其次参考业务逻辑分离的必要性。 在许多早期体系结构设计中，服务节点通常不具有扩展能力是致命的，通常是文件服务，通过将文件上载到web服务器，web服务器具有非常逻辑的状态。改进的一点是使用NFS。 此时，我们发现NFS仍然无法扩展，单瓶颈仍然存在，今后的发展是FastDFS/MFS等分布式文件系统，在更大规模的文件服务中，GFS ( googledistributedfilesystem )/TFS ( googledistributedfilesystem ) 需要考虑方案，并且业务在线时，业务功能单一，此时所有服务都可以软件化，随着业务量的增大，分离一些功能，构成统一的呼叫服务。
以前，体系结构隔离只有3层，但存取层、逻辑层(根据集成的server框架开发)和数据存储层( NOSQL的接口都一致，也有mysql )。
3 )避免过度的设计原则。 典型的规则是设计比当前业务容量大10倍的体系结构，而不是设计比当前容量大100倍的体系结构。 100倍的体系结构意味着需要重建。 过度的设计还会给轻量系统投入大量不必要的成本。 例如，如果业务容量较小，则单实例mysql支持足够的业务容量，但在这种情况下，不需要部署库表算法。
4 )客户端智能策略。 客户机智能是指客户机确定返回后端中哪些服务节点，并且当服务节点的健康不满足标准时直接排除服务。 对于LVS，我们知道它有很好的四层容错，但是不能彻底应用协议层容错(可以通过写少量的脚本插件实现)，后端服务容错和容错 在常规方法中，客户端收集后端服务访问错误和延迟，并使用特定算法(独立于本地代理)评估后端服务节点，以确定要在下一次访问中使用哪些节点。
5 )无状态化原则。 无状态是指任何服务节点关机都不会影响服务。 要从用户访问进入我们的服务节点，您必须始终记住此标准。 LVS我们不采用主仆，采用LVS+OSPF方案可以彻底解决主仆的问题nginx，web服务器都不保持业务状态信息，完全消除状态(常见的状态数据，例如用户的头像，用户的session数据等)。 在数据存储层，NOSQL具有很好的分布式方案(请参见bigtable和GFS )，但是我们常用的mysql仍然没有相应的群集方案( mysql cluster尚未成熟)，但库表sharding方案
6 )透明度服务原则。 Zbus是很好的例子，服务的位置关系，内部访问统一控制等。 在很多系统中，不能这样做也是运动维持只有结合子的重要原因之一。 服务具有透明能力，一些变化可以完全控制运维，大大提高运维故障处理和应急能力。 顺便提一下，有一天，当不同的系统需要不同的ZBUS服务群集时，我们将如何管理这些群集？请想想服务如何透明地应对这些群集？
7 )端到端的监视原则。 这个日志写着日志，特别是重要的错误日志。 这对初期障碍的定位非常有帮助。 运输服务必须从基础设施层到应用程序层完全监控。 更高级的方法是结合用户访问流完成端到端监控。 这个难度很大，无论这个监视设计本身如何，都选择了监视进行大量的数据分析，并且头痛，通常的通行方法是采样收集。
8 )场景决定记忆原则。 存储选择必须从场景开始。 以下几个维度在储存选择时总是要问自己的问题:高存取量和低存取量？ 单用户数据是大、小还是热点集中还是分散？ 总数据量大还是小，有事务吗？存储本身的群集能力？ 等等。 redis可以处理的不是memcache，而是mysql可以处理的不是memcache。 我们看着存储界面，知道他们的API是绝对不同的。 许多存储部署会使开发变得困难，更困难的是这些存储之间的数据同步，而且很难完全了解存储。 以前凯西和mongodb很多时候都无法切换mysql，最大的禁忌是根据网上的文章来选择记忆。
对于NOSQL，在我们现阶段，无需考虑，我们的业务增长了10倍。
建议的存储方案: mysql+redis或mysql+handlesocket具有持久性能力+cache能力。
九)数据隔离原则。 核心数据保护尤其重要，它是数据安全的重要组成部分，运输策略有很多种类，包括数据分层、数据区保护、数据审核、定时密码交换机制、数据操作可视化等。 然而，从开发角度来看，提供统一数据访问保护的重要保护措施是必要的。 我的建议在数据库之前隔离数据访问层( DAL )，该层能够完成数据库路由访问控制、库表访问控制以及过载控制。 这种分离可以进一步提高数据的安全性，并且通过以接口的形式提供外部服务，可以有效地防止数据存取信息的泄露。
10) Zookeeper的活用。 这是一个非常令人兴奋的组件，从基本算法到设计的实现，到核心应用场景的垄断，特别的东西很少，所以可以单独说。 这是google chubby的开放源代码的实现，有被广泛使用的场合，可以管理运输维的构成，可以管理业务的构成，可以提供名称服务，可以编程生产编号，可以进行分布式消息队列。 重要的是超越IDC，能够保证一致性。 在分布式系统中，这是必不可少的。
十一)控制一切的原则。 大家一定在构筑你的系统和感情。 但是，这种感情没有给予足够的自由，受到控制。 从浏览器、DNS、LVS、web服务器、逻辑层和数据存储层。 自己能开发的是自己，自己不能开发的，要深刻理解它的特性，更好地控制它。 前端浏览器需要知道IE的整体分布，尤其是IE6(影响web服务器压缩算法的部署)，不同版本的ie有多少并发连接？ IE内核与其他浏览器内核的区别chrome有什么新特性？ 对于DNS也是如此，随着系统规模的加大，必须走到自己的DNS水平，其他架构部分也是如此。 我相信中心的未来也一定会向这个方向发展。
12 )中心化和非中心化的想法。 谷歌是中心化设计的杰出代表( GFS/BigTable都是如此)，而Amazon代表非中心化( DYNAMO一致性HASH架构模型)。 我有不同的认识，在不同的时刻可以采用不同的框架策略，在前端服务框架中可以完全集中，在数据存储层个人也可以提出集中化设计，集中化设计可以减少内部消息通信量
13 )框架是进化而来的，不是设计的。 它是业务主导框架的改版，随着业务量和业务模式的变化，框架也同时考虑变化。
