互联网架构演变

全栈程序员站长

发布于 2022-08-04 17:13:41

3200

发布于 2022-08-04 17:13:41

文章被收录于专栏：全栈程序员必看

大家好，又见面了，我是你们的朋友全栈君。

一体架构

在计算机软件发展早期，一般桌面软件都是采用这种架构，不管是界面还是业务处理还是数据处理都放到一个包中。这种其实谈不上架构，但也可以说是很好的架构，因为它足够简单。

mvc架构

但随着浏览器的出现便产生了web应用，web应用的特点是界面部分是显示在浏览器中，服务处理是在服务容器中的，页面显示一般用css+js+html技术来处理，而后端可以用java、php等语言，这就产生了前后端分离。对于web系统，一体架构难以满足前后端分离的开发需求，因而便产生了MVC架构。 MVC才算的上真正意义上的架构，因为它除了解决了前后端分离问题，还引入了一种全新的开发模式，用一种业务逻辑、数据、界面显示分离的方法组织代码，使得整个应用层次更加分明，而且各个层次之间不但减低了耦合性，还提高了各个层次的可重用性。但随着应用规模的不断扩大，应用模块不断增加，整个应用也显得越来越臃肿，维护起来也更加困难，因此便又产生了多应用架构。

多应用架构

多应用架构很简单，就是把原来的应用按照业务特点拆分成多个应用。比如一个大型电商系统可能包含用户系统、商品系统、订单系统、评价系统等等，我们可以把他们独立出来形成一个个单独的应用。多应用架构的特点是应用之间各自独立，不相互调用。

多应用虽然解决了应用臃肿问题，但应用之间相互独立，有些共同的业务或代码无法复用。

分布式架构

对于一个大型的互联网系统，一般会包含多个应用，而且应用之间往往还存在共同的业务，并且应用之间还存在调用关系。除此之外，对于大型的互联网系统还有一些其它的挑战，比如如何应对急剧增长的用户，如何管理好研发团队快速迭代产品研发，如何保持产品升级更加稳定等等。

因此，为了使业务得到很好的复用，模块更加容易拓展和维护，我们希望业务与应用分离，某个业务不再属于一个应用，而是作为一个独立的服务单独进行维护。应用本身不再是一个臃肿的模块堆积，而是由一个个模块化的服务组件组合而成。

流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。平台随着业务的发展从Alin One环境就可以满足业务需求(以Java来说，可能只是一两个war包就解决了) :发展到需要拆分多个应用，并且采用MVC的方式分离前后端，加快开发效率:在发展到服务越来越多，不得不将一些核心或共用的服务拆分出来，提供实时流动监控计算等，其实发展到此阶段，如果服务拆分的足够精细，并且独立运行，这个时候至少可以理解为SOA ( Service-Oriented Architectyre)-架构c 了。

服务化

服务化的特点

上面介绍的分布式架构即服务化。我们再总结一下，服务化主要有如下特点：

应用按业务拆分成服务
各个服务均可独立部署
服务可被多个应用共享
服务之间可以通信

服务化的好处架构上系统更加清晰核心模块稳定，以服务组件为单位进行升级，避免了频繁发布带来的风险开发管理方便单独团队维护、工作分明，职责清晰业务复用、代码复用非常容易拓展
服务化实现方式

如果要实现服务化的话，最常用的方式就是利用RPC框架。因为服务组件一般分布在不同的服务器上，所以要实现服务化需要解决的第一个问题就是RPC远程服务调用。类似于RPC方案有很多，比如：

Java RMI
WebService
Hessian
Http
Thrift
… …

服务化面临的挑战

上面提到要实现服务化首先需要解决远程服务调用问题，除此之外，还有很多其他问题需要解决。

服务越来越多，配置管理复杂
服务间依赖关系复杂
服务之间的负载均衡
服务的拓展
服务监控
服务降级
服务鉴权
服务上线与下线
服务文档
… …

服务治理

上面提到了服务化，其实要想服务化，服务治理是关键。那么有没有好的服务治理方案呢？答案是有的，而且很多人都在用这个框架，他就是-dubbo。dubbo就是一个带有服务治理功能的RPC框架。

dubbo提供了一套较为完整的服务治理方案，所以企业如果要实现服务化的话，dubbo 是很好的一个选择。这里简单介绍一下dubbo服务治理相关方案。

服务发现注册

服务治理领域最重要的问题就是服务发现与注册。dubbo中引入了一个注册中心的概念，服务的注册与发现主要就依赖这个服务中心。

dubbo注册中心服务注册发现的具体过程：

服务提供者启动，向注册中心注册自己提供的服务
消费者启动，向注册中心订阅自己需要的服务
注册中心返回服务提供者的列表给消费者
消费者从服务提供者列表中，按照软负载均衡算法，选择一台发起请求

服务监控、集群容错、负载均衡

Random Loadbalance
RoundRobin
LeastActive
ConsistentHash

dubbo服务治理优势

注册中心只负责注册查找，不负责请求转发，压力小
注册中心宕机影响消费者，消费者本地缓存服务地址列表
注册中心对等集群，宕掉一台自动切换到另外 一台
服务提供者无状态，可动态部署，注册中心负责推送
统计无压力，本地内存中累计次数，每分钟发送注册中心
消费者调用服务者，自动软负载均衡
通过服务中心可追踪依赖关系
监控中心为扩容和降级提供依据
可启用acl机制进行鉴权
与Spring整合，接入简单松耦合
多种序列化协议支持

dubbo的不足

消费者仍需要依赖配置中心
消费者仍需要依赖jar包配置provider
提供者文档管理功能缺失
无统一入口
不支持OAuth2.0
内部鉴权不方便管理
无外部应用鉴权
接口基本裸奔，无法直接对外暴露服务
IT治理不方便

微服务

现在很多人都在谈微服务，那么到底什么是微服务呢？这里谈谈我对微服务的理解。

微服务有两个核心：

微：服务的粒度要细，即服务要细化到API
服务：提供好服务，要让用户感到好用(要做到这一点很不容易)

上面两个核心总结起来，可以用下面这幅图表示：

从上面这幅图看出，微服务特别简单（好的架构就应该简单），我们把服务再拆分成一个个API，API是一个完整的功能。然后我们把API扔到一个“云上”，然后用户就可以到“云上”获取所有API的服务，这个“云”保证能提供好的服务。

我们可以看到，有了微服务之后，服务对用户来说变得特别简单，而且上面dubbo的不足之处在微服务这里都解决了。使用者不再需要依赖任何jar包，不再需要去注册中心查找服务，不再去做鉴权处理，不用担心服务挂掉，不用担心不会使用服务，所有的问题这个“云”都解决了。这也是微服务的核心之一，提供好服务。

微服务的实现

微服务的关键是服务网关，所以，上面提到的“云”就是服务网关。要做微服务，我们先定义一下微服务需要具备的特点。微服务的特点

服务需要再细化成API（服务接口——>服务API）

每个服务由一组API组成
以API形式对外提供统一格式的服务
使用者无需任何配置，直接调用（http）
完整的API文档
API服务安全可靠稳定

微服务要解决的问题

上面提到了，dubbo还存在一些问题，其实dubbo存在的问题就是微服务要解决的问题，这里再总结一下。当然，dubbo和微服务的侧重点不一样，dubbo侧重于内部接口之间的RPC，而微服务则侧重于对外提供服务。

统一入口
安全控制：防刷限流
统一鉴权：应用鉴权、用户鉴权、OAuth鉴权、ACL
协议转换：http、dubbo、Protobuf
API配置管理
API上线、下线
API与服务接口映射
监控与报警
整体架构的可拓展、高并发、分布式
服务容器自动收缩、扩容

实现方案

负载均衡层：nginx/lvs/F5
微服务层 
    高性能服务网关
    统一入口、API配置管理、分流鉴权、服务监控、协议转换
    API映射、OAuth2.0、API文档管理
    分布式、可拓展
服务治理层 
    成熟的服务治理框架dubbo
    MQ服务之间解耦
弹性云 
    服务docker化
    基于访问压力的实时集群调度与管理