简单认识互联网架构的演进

type

Post

status

Published

date

Nov 2, 2022

slug

summary

互联网架构从简到繁的演进经历了单体架构-集群架构-分布式架构-微服务架构以及最新的service mesh的演进过程。

互联网架构的演进过程

互联网架构从简到繁的演进经历了单体架构-集群架构-分布式架构-微服务架构以及最新的service mesh的演进过程。

1. 简单架构（单体架构）

网站架构的发展也是由简到繁，早期互联网产品用户量少，并发量低，数据量小，多数只需要单个应用服务器可以满足需要，而数据库和文件服务部署在外部单个服务器上。

特点：

所有业务逻辑均由单个server处理

文件和数据库只部署在外部的单个server中

优点：

只需要部署维护一个应用部署和一个代码仓库即可，相关通用逻辑(中间件/通用业务逻辑)的升级成本也相对较低。（运维）

业务逻辑只需考虑单个应用内的情况，业务请求失败。（开发成本）

存在的问题：

server应用、文件服务、数据库均为单体服务，缺乏故障转移（运维）

在升级维护中必须进行停机，可用性低（开发效率）

2. 缓存与读写分离

随着访问量的激增，数据量的快速膨胀，对应用服务器和数据库服务器的IO性能要求也越来越高。单体服务总是资源有限，而单个数据库的数据流量越来越大，数据的访问性能也明显下降。为了进一步降低数据库的访问压力，对数据库进行读写分离、分库分表等优化。

大部分的业务数据只集中于数据中的一小部分，而有些数据是需要经常读取，但是更新很少，或是访问量非常大的数据块，这些情况下我们引入缓存层, 如果访问命中缓存，既能减小数据库的访问压力，又可以提高数据访问性能。（二八定律，10:1）（ShardingJDBC MyCat Guava EhCache）

优点：

相对于之前性能大大增加

缺点：

高可用

主从一致性

增加研发的难度

3. 动静分离

随着业务量级的继续增加，就需要能够进一步降低服务器的压力，这时候可以采用动静分离技术。动静分离技术是将服务的静态资源与后台应用进行分开部署，提高用户访问静态资源的速度，降低对后台的访问压力。

静态资源一般放在CDN上，部署在网络提供商的机房。用户在访问静态资源时，可以很好的利用CDN的优点，从距离自己最近的网络提供商机房获取数据。(CDN,OSS)

优点：

减轻后端服务压力，提高服务端的处理速度，吞吐量

后端应用更为服务化，只需要提供api接口即可，前端可以通过更加专业的技术提高访问效率

前后端并行开发，提高效率

缺点：

SEO（静态数据更容易被搜索引擎收录）

静态文件的缓存更新以及前后端的更新成本

4. 集群化高可用架构

随着用户规模和业务量的不断上涨，单个应用服务器将出现性能瓶颈，对于PB级的数据和高并发用户大流量访问，单一或者主备的数据库、文件系统都已经不能满足需求，需要集群化来分担负载。当数据规模达到一定规模，传统关系型数据库性能下滑非常严重，通过分库分表也难以应对，为了支撑海量数据和流量，出现了NoSql数据库，它关注对数据高并发地读写和对海量数据的存储。

同时应用服务器从单体变为集群，客户端也不再是直接接入后端应用，而是转而通过负载均衡设备代理后端多个服务器集群，一方面将访问压力分摊到了多个后端应用上，单个应用不再是性能瓶颈，另一方面可以实现服务路由，以及异常熔断等特性。

(Nginx,Envoy)(Redis,Mongodb,Memcache)(Hadoop,MapReduct,Spark,HDFS,Hive)

优点：

相对于之前吞吐量大大增加

一台物理机器故障（本地，异地，云，两地三中心）

缺点：

Session共享？

nginx路由/流量分发策略

5. 业务拆分与分布式

同时随着业务场景的复杂化，存储规模越来越庞大。将业务进行拆分并分而治之成为更好的选择。大型的业务场景被细分为单个更小的业务子场景，按照系统业务功能进行划分，例如：产品中心，订单中心，用户中心等模块。每一个子模块由不同的业务团队负责。每个子业务模块进行独立开发、部署、运维。

随着对业务场景越来越细的划分，模块越来越多，整个应用的复杂度也越来越高，大量的独立子应用对数据库的独立访问，导致后端数据库的压力越来越大，需要将各个子应用的重叠逻辑再进行抽取为独立子服务，子应用服务之间通过RPC或者消息系统进行相互通信，因此出现了分布式应用, 到目前为止的分布式架构已经能够应对大部分高并发，大流量的业务场景。

优点：

拆分团队后单体架构无法支持快速迭代的问题

一定程度上解决了单点风险

缺点：

模块间通讯比较复杂。

模块内业务逻辑更加复杂后，单个模块就像单体应用一样变得笨重和维护成本的急剧上升。

6. 面向服务的架构（SOA）

分布式架构出现之后，随着应用的更细力度的拆分，逐渐呈现了一个相互依赖、公共的模块，这些模块大都依赖于相同的逻辑或者功能代码。这时候就需要把这些应用的公用模块提出来，采用独立部署统一管理的方式，提高重用度，这就是服务导向架构（SOA）。（ESB）

面向服务的计算，服务之间松散耦合，支持服务的封装，服务注册和自动发现。

优点：

通过更高的敏捷性和更有效的开发来降低成本

便于维护

可拓展

更可靠

缺点：

ESB 是个集中式的集群，负载较高，且单点不可用会影响全局服务

7. 微服务架构

基于SOA的系统架构实现了松耦合，系统之间通过服务接口（Service API）和中心化管理的企业服务总线（ESB）进行交互, 但这种拆分往往是业务系统的一种垂直拆分，拆分的子系统随着业务的复杂耦合仍然面临难以开发和维护的问题。因此更细粒度的拆分变得必要，将子系统功能进一步拆分，变成一项项的服务。

为了解决 ESB 的单点风险，出现了另外一种新的 SOA 实现：微服务架构。微服务架构把 ESB 的单点总线服务拆分到了每个服务内部，最处普遍使用 SDK 的方式集成到应用内部。

微服务架构通过业务拆分实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署，使得整个系统变得清晰灵活。

优点：

无单点风险

通过更高的敏捷性和更有效的开发来降低成本

更可靠，内部调试

缺点：

拓展性

运维成本

使用SDK组件集成（Hystrix, Eureka…）

开发人员除了需要关注业务逻辑实现外还需要考虑业务的一系列问题，比如服务注册，服务发现，服务通讯，负载均衡，服务熔断，服务超时等，这些是非常重要的。但这些组件的使用是侵入式的，这要求开发人员需要额外的精力去关注一些非业务逻辑层面的事情。而服务网格架构（Service Mesh）的出现，让业务开发人员得以真正解脱。