互联网架构演进之路

互联网架构演进之路搜狐技术产品公众号「搜狐技术产品」让你更懂产品技术4 人赞同了该文章作者 | 风之谷本文旨在介绍大型互联网架构的演进过程针对每种架构将简单介绍其原理以及特点。互联网产品常常面临庞大的用户量日均数十亿PV的高并发PB级别的数据存储等问题的挑战同时要求保证系统的高可用和弹性伸缩并且能够根据需要进行快速迭代扩展这些都对于系统架构提出了很高的要求。互联网架构从简到繁的演进经历了单体架构-集群架构-分布式架构-微服务架构以及最新的service mesh的演进过程。01. 简单架构网站架构的发展也是由简到繁早期互联网产品用户量少并发量低数据量小多数只需要单个应用服务器可以满足需要而数据库和文件服务部署在外部单个服务器上这就是最早互联网架构架构图如下所示。在该架构所有业务逻辑均由单个server处理。并且文件和数据库只部署在外部的单个server中该架构中存在的问题也比较明显server应用、文件服务、数据库均为单体服务缺乏故障转移在升级维护中必须进行停机可用性低。在现在的业务场景中已经不再适用。02.缓存与读写分离随着访问量的激增数据量的快速膨胀对应用服务器和数据库服务器的IO性能要求也越来越高。单体服务总是资源有限而单个数据库的数据流量越来越大数据的访问性能也明显下降。 为了进一步降低数据库的访问压力对数据库进行读写分离、分库分表等优化。 读写分离即将数据库分为主从数据库从库实时同步主库的更新内容。写请求访问主数据库读请求访问从数据库。分库分表即是把原本存储于一个库的数据分块存储到多个库上把原本存储于一个表的数据分块存储到多个表上。不论是读写分离还是分库分表都有效分解了数据库访问压力。基于二八定律即大部分的业务数据只集中于数据中的一小部分而有些数据是需要经常读取但是更新很少或是访问量非常大的数据块这些情况下我们就需要引入缓存层, 如果访问命中缓存既能减小数据库的访问压力又可以提高数据访问性能。缓存的发展也是由简单到复杂由单体到缓存集群由单点到高可用。本地缓存的特点就是可以提供快速访问但无法实现共享无法保证高可用。而缓存集群可以提供高可用、可共享、大容量的存储缓存层降低数据库的读写IO有效提升系统响应能力。03.动静分离随着业务的进一步爬坡需要能够进一步降低服务器的压力这时候可以采用动静分离技术。动静分离技术是将服务的静态资源与后台应用进行分开部署提高用户访问静态资源的速度降低对后台的访问压力。静态资源一般放在CDN上部署在网络提供商的机房。用户在访问静态资源时可以很好的利用CDN的优点从距离自己最近的网络提供商机房获取数据。动静分离后带来的优点是显而易见的后端应用更为服务化只需要提供api接口即可前端可以通过更加专业的技术提高访问效率。但同时静态文件的缓存更新以及前后端的更新成本都是动静分离所带来的问题。04.集群化高可用架构随着用户规模和业务量的不断上涨单个应用服务器将出现性能瓶颈对于PB级的数据和高并发用户大流量访问单一或者主备的数据库、文件系统都已经不能满足需求需要集群化来分担负载。当数据规模达到一定规模传统关系型数据库性能下滑非常严重通过分库分表也难以应对为了支撑海量数据和流量出现了NoSql数据库它关注对数据高并发地读写和对海量数据的存储。同时应用服务器从单体变为集群客户端也不再是直接接入后端应用而是转而通过负载均衡设备代理后端多个服务器集群一方面将访问压力分摊到了多个后端应用上单个应用不再是性能瓶颈另一方面可以实现服务路由以及异常熔断等特性。为了进一步降低服务端压力降低客户端访问延迟客户端与负载均衡设备之间加入CDN对静态资源进行缓存加速利用GSLB调度体系将用户请求精准调度至最优接入节点。以达到最优的访问性能。05.业务拆分与分布式同时随着业务场景的复杂化存储规模越来越庞大。将业务进行拆分并分而治之成为更好的选择。大型的业务场景被细分为单个更小的业务子场景按照系统业务功能进行划分例如对于电商系统按功能维度我们可以拆分为商品中心订单中心用户中心购物车结算等功能模块。每一个子模块由不同的业务团队负责。每个子业务模块进行独立开发、部署、运维。随着对业务场景越来越细的划分模块越来越多整个应用的复杂度也越来越高大量的独立子应用对数据库的独立访问导致后端数据库的压力越来越大需要将各个子应用的重叠逻辑再进行抽取为独立子服务子应用服务之间通过RPC或者消息系统进行相互通信因此出现了分布式应用, 到目前为止的分布式架构已经能够应对大部分高并发大流量的业务场景。06.SOA分布式架构出现之后随着应用的更细力度的拆分逐渐呈现了一个相互依赖、公共的模块这些模块大都依赖于相同的逻辑或者功能代码。这时候就需要把这些应用的公用模块提出来采用独立部署统一管理的方式提高重用度这就是服务导向架构SOA。SOA其实是一种理念它的主要特性面向服务的计算服务之间松散耦合支持服务的封装服务注册和自动发现。但是SOA并没有定义出具体的实现方式目前一种主要的实现方式是企业服务总线Enterprise Service BusESBESB的根本目标是解决异构系统的连通性通过协议转换、消息解析、消息路由把服务提供者的数据传递到服务消费者。所以SOA的中心化虽然重但是会解决一些公用逻辑的问题。07.微服务基于SOA的系统架构实现了松耦合系统之间通过服务接口Service API和中心化管理的企业服务总线ESB进行交互, 但这种拆分往往是业务系统的一种垂直拆分拆分的子系统随着业务的复杂耦合仍然面临难以开发和维护的问题。因此更细粒度的拆分变得必要将子系统功能进一步拆分变成一项项的服务。系统分布式架构服务去中心化实现也即微服务的思想。敏捷开发专家Martin Fowler 在2014年定义了微服务架构。微服务架构风格是一个系统由一套独立运行的微服务组成 这些服务是围绕业务功能构建的服务关注单一业务服务间采用轻量级的通信机制通常是HTTP资源的API可以全自动独立部署可以使用不同的编程语言和数据存储技术。微服务架构通过业务拆分实现服务组件化通过组件组合快速开发系统业务单一的服务组件又可以独立部署使得整个系统变得清晰灵活。但是大量的分布式服务又使得架构实现面临问题如服务注册发现服务统一接入和权限控制服务的负载均衡服务配置的集中管理服务熔断服务监控等。所以在微服务架构中除了业务服务组件外通常会引入服务注册发现组件来进行服务治理引入服务网关组件来提供统一入口和权限控制引入负载均衡组件来提供客户端或服务器端的负载均衡引入集中配置组件来提供服务集中管理引入熔断器组件来提供服务熔断引入服务追踪组件来提供服务监控等。因此微服务架构是由这些基础的服务组件和业务微服务组件共同组成。基本的微服务架构如图所示微服务架构在业界已经有了很多成熟的实践 Netflix推出了经过生产验证的NetflixOSS Pivotal 将 NetflixOSS 开源微服务组件集成到其 Spring 体系推出 Spring Cloud阿里推出了服务治理能力丰富的生产级分布式服务框架Dubbo谷歌推出了基于 protobuf 的强契约编程模型的 RPC 框架gRPC。 服务发现组件除dubbo外还有EurekaConsul和Zookeeper, 服务网关组件有Spring Cloud体系的Zuul基于 Nginx/OpenResty 的 API 网关 Kong 配置中心组件有Spring Cloud 自带 Spring Cloud Config和携程的Apollo服务监控组件有Zipkin、Pinpoint和CAT服务熔断组件有Netflix 的 Hystrix等。微服务的交付除了依赖成熟的框架构建系统外自动化部署也需要自动化部署工具的支持。容器化技术已经成为自动化部署微服务的一种理想手段。Docker 和其他类似的 Linux 容器技术使得软件开发和持续交付变得很容易大大降低了微服务运维的难度也使得系统宕机风险大大降低。采用微服务架构后项目可以快速迭代与持续交付。但是也带了一些弊端开发人员除了需要关注业务逻辑实现外还需要考虑业务的一系列问题比如服务注册服务发现服务通讯负载均衡服务熔断服务超时等这些是非常重要的。大多数时候我们需要依赖第三方库或者组件来提供这些服务像上文提到的Hystrix, Eureka这些组件在其服务组织中起到了广泛的应用。但这些组件的使用是侵入式的这要求开发人员需要额外的精力去关注一些非业务逻辑层面的事情。而服务网格架构Service Mesh的出现让业务开发人员得以真正解脱。服务网格架构是在微服务架构盛行的今天的必然产物服务网格架构可以说是微服务架构的一种实现将开发人员从服务之间的交互中释放出来专心维护业务逻辑。服务网格是一个基础设施层用于代理服务间的通信来负责消息直接按需传递开发人员不需要在考虑服务发现等非业务逻辑服务的治理也上升到统一的层面。服务网格对业务是相对透明的与业务始终部署在一起。上图是一个简单的服务网格例子不同的业务之间通过服务网格进行通讯服务网格根据预先定义好的规则进行流量治理可以配置A/B测试金丝雀发布同样也可以根据服务网格的进行流量的统计。借用服务网格的一个经典的图例在微服务大量部署之后每个服务节点的sidecar进程自然就形成了一个网格。总而言之微服务架构实现了业务的解耦使系统具备了良好的扩展性和伸缩性单个服务组件可以独立部署便于组件的开发测试部署和维护服务自治也可以将数据管理去中心化容器化部署平台也降低了测试、部署和运维的难度使软件开发迭代更加敏捷快速但分布式系统固有的难题如分布式事务等在微服务架构中也依然存在。