当前位置:首页 > 企业官网建设

一个运维工程师对网站制作的看法

2020-01-01

杭州网站建设照片中的人物是杰夫德恩、谷歌分布式系统的灵魂人物,具体内容都可以在谷歌看到。 他的许多分布式系统设计思想影响着技术趋势。 用谷歌实现具体工作,领导未来。

由于目前网络上有很多类似的文章,该文仅仅记述了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 )框架是进化而来的,不是设计的。 它是业务主导框架的改版,随着业务量和业务模式的变化,框架也同时考虑变化。

免费获取报价

  • 29923329

  • 杭州市丰庆路498号北软智慧科创大厦203

  • 0571-85815193

  • pady@1t2.cn

网站地图 版权所有 © 2008-2021 杭州派迪科技有限公司  Copyright © 2008-2020  www.hzpady.com  All Rights Reserved    浙ICP备14029905号-1     公安备案:33010802008411    软著登字第3457658号