【架构设计】41-互联网架构模板:“网络层”技术

41-互联网架构模板:“网络层”技术

前言

除了复杂性,互联网业务的另外二个特点就是高性能和高可用。通常情况下,我们在设计高可用和高性能的系统的时候,主要关注点在系统本身的复杂度,然后通过各种手段来实现高可用和高性能的要求,如计算高性能架构模式、存储高可用架构模式等。但从一个公司的角度来思考架构时,单个系统的高可用和高性能并不等于整个业务的高可用和高性能。互联网业务的高可用和高性能需要从更高的角度来设计,这个高度就是“网络”。

负载均衡

负载均衡就是将请求平衡地分配到多个系统上。使用负载均衡的原因:每个系统的处理能力有限,为了应对大容量的访问,必须使用多个系统。

  • DNS

    DNS是最简单也是最常见的负载均衡方式,一般用于实现地理级别的负载。

    DNS的优点是通用(全球通用)、成本低(申请域名、注册DNS即可)。

    其缺点是:

    • DNS缓存时间比较长,即使将某台业务机器从DNS服务器上删除,但由于缓存的原因,还是会有很多的用户访问已经删除的机器。
    • DNS不够灵活。DNS无法感知后端服务器的状态,只能根据配置策略进行负载均衡,无法做到更加灵活的负载均衡策略。

    对于时延和故障敏感的业务,有实力的公司可能会尝试实现HTTP-DNS的功能,即使用HTTP协议实现一个私有的DNS系统。HTTP-DNS主要应用在通过App提供服务的业务上,因为在App端可以实现灵活的服务访问策略。

    HTTP-DNS的优缺点:

    • 灵活:HTTP-DNS可以根据业务需求灵活的设置各种策略。
    • 可控:HTTP-DNS是自己开发的系统,IP更新、策略更新无需依赖外部服务商。
    • 及时:HTTP-DNS不受传统DNS缓存的影响,可以非常快的更新数据、隔离故障。
    • 开发成本高:没有通用的解决方案,需要自己开发。
    • 侵入性:需要App基于HTTP-DNS进行改造。
  • Nginx、LVS、F5

    DNS实现地理级别的负载、而Nginx、LVS、F5用于对同一个地点内机器级别的负载均衡。基于Nginx是软件的7层负载均衡,LVS是内核层的负载均衡、F5是硬件的4层负载均衡。

    软件和硬件的区别在于性能、硬件远远高于软件,nginx的系统是万级、LVS的系统是十万级、F5的性能是百万级。虽然硬件的性能高,但是单台硬件的成本也很高。通常情况下,如果性能要求不高,可以使用软件负载均衡、如果性能要求高,推荐用硬件负载均衡。

    4层和7层的区别在于协议和灵活性。Nginx支持HTTP、e-mail协议、而LVS和F5是4层负载均衡,和协议无关,几乎所有应用都可以做,例如聊天、数据库等。

CDN

CDN是为了解决用户网络访问时的“最后一公里”效应,本质上是一种“以空间换时间”的加速策略,即将内容缓存在离用户最近的地方,用户访问的是缓存的内容,而不是站点的实时内容。

Alt CNS请求示意图

CDN经过多年的发展,已经变成一个庞大的体系:分布式存储、全局负载均衡、网络重定向、流量控制等都属于CDN的范畴,尤其在视频、直播等领域。如果没有CDN,用户是无法实现流畅观看内容的。

CDN作为网络的基础服务,独立搭建的成本很大,很少有公司自己设计和搭建CDN系统,从CDN服务商购买CDN服务即可。如网宿和蓝讯等。

多机房

从架构上来看,单机房就是一个全局的网络单点,在发生比较大的故障或灾害时,单机房难以保证业务的高可用。如:停电、机房网络中断、地震、水灾都可能导致一个机房完全瘫痪。

多机房设计最核心的因素是如何处理时延带来的影响,常见的策略是:

  • 同城多机房
    同一个城市多个机房,距离不会太远,可以投入重金,搭建私有的高速的网络,基本上能够做到同一个机房的效果。

    这种方式对业务影响很小,但是投入较大,如果不是大公司,一般是承受不起的。而且遇到极端的地震、水灾等自然灾害,同城多机房也是有很大的风险的。

  • 跨城多机房

    在不同的城市搭建多个机房、机房间通过网络进行数据复制,但由于跨城网络时延的问题,业务需要做一定的妥协和兼容,比如不需要数据的强实时一致性、只要保证最终一致性。

  • 跨国多机房

    和跨城多机房类似,只是地理上的分布更远,时延更大。由于时延太大和用户跨国访问实在太慢,跨国多机房一般用于备份和服务本国用户。

多中心

多中心必须以多机房为前提,但从设计的角度来看,多中心比多机房是配制上的飞跃,难度也更高。

多机房的主要目标是备灾,当机房故障时,可以较快速地将业务切换到另外一个机房,这种切换操作允许一定时间的中断,而且业务可能有损失。相比多机房来说,多中心的要求更高。每个中心都同时对外提供服务,且业务能够自动在多个中心之间切换,故障后不需要人工干预或者很少人工干预就自动恢复。

多中心设计的关键在于“数据一致性”和“数据事物性”如何保证,这二个难点和业务紧密相关,目前没有很成熟且通用的方案,需要基于业务的特性进行详细的分析和设计。


   转载规则


《【架构设计】41-互联网架构模板:“网络层”技术》 孤独如梦 采用 知识共享署名 4.0 国际许可协议 进行许可。
 上一篇
【架构设计】43-互联网架构模板:“平台”技术 【架构设计】43-互联网架构模板:“平台”技术
43-互联网架构模板:“平台”技术当业务规模不大时,系统复杂度不高时,运维、测试、数据分析、管理等由各自的系统或团队完成。随着业务规模越来越大,系统复杂度越来越高,子系统数量越来越多时,如果继续使用各自为政的方式来实现这些功能的话,重复工作
2019-05-29
下一篇 
【架构设计】40-互联网架构模板:“开发层”和“服务层”技术 【架构设计】40-互联网架构模板:“开发层”和“服务层”技术
40-互联网架构模板:“开发层”和“服务层”技术开发层技术开发框架 指定一个大的技术方向,然后使用统一的框架。 对于框架的选择,有一个总体原则:优先选择成熟的框架,避免盲目追逐新技术。 成熟的框架资料文档齐备,各种坑基本上都有人
2019-05-29
  目录