浅谈服务治理与微服务

た入场券 2022-06-15 11:42 276阅读 0赞

本篇文章先简单介绍了互联网[架构][Link 1]的演变，进而介绍了服务化，最后再介绍微服务，微服务是服务治理的升级也是互联网架构的进一步延伸。

## 互联网架构演变 ##

### 一体架构 ###

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

![这里写图片描述][SouthEast]

### mvc架构 ###

但随着浏览器的出现便产生了web应用，web应用的特点是界面部分是显示在浏览器中，服务处理是在服务容器中的，页面显示一般用css+js+html技术来处理，而后端可以用[Java][]、[PHP][]等语言，这就产生了前后端分离。对于web系统，一体架构难以满足前后端分离的开发需求，因而便产生了MVC架构。

![这里写图片描述][SouthEast 1]

MVC才算的上真正意义上的架构，因为它除了解决了前后端分离问题，还引入了一种全新的开发模式，用一种业务逻辑、数据、界面显示分离的方法组织代码，使得整个应用层次更加分明，而且各个层次之间不但减低了耦合性，还提高了各个层次的可重用性。

但随着应用规模的不断扩大，应用模块不断增加，整个应用也显得越来越臃肿，维护起来也更加困难，因此便又产生了多应用架构。

### 多应用架构 ###

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

![这里写图片描述][SouthEast 2]

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

### 分布式架构 ###

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

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

![这里写图片描述][SouthEast 3]

## 服务化 ##

### 服务化的特点 ###

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

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

### 服务化的好处 ###

那么企业采用服务化有哪些好处呢？

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

### 服务化实现方式 ###

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

*  Java RMI
 *  WebService
 *  Hessian
 *  Http
 *  Thrift
 *  … …

### 服务化面临的挑战 ###

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

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

## 服务治理 ##

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

![这里写图片描述][SouthEast 4]

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

#### 服务发现注册 ####

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

![这里写图片描述][SouthEast 5]

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

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

#### 服务监控 ####

![这里写图片描述][SouthEast 6]

#### 集群容错 ####

![这里写图片描述][SouthEast 7]

#### 负载均衡 ####

*  Random Loadbalance
 *  RoundRobin
 *  LeastActive
 *  ConsistentHash

#### dubbo服务治理优势 ####

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

#### dubbo的不足 ####

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

## 微服务 ##

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

微服务有两个核心：

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

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

![这里写图片描述][SouthEast 8]

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

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

说到这里，大家就应该大体知道该怎么做微服务了，图中的“云”是关键。下面我们就慢慢拨开这朵云。

### 微服务的实现 ###

![这里写图片描述][SouthEast 9]

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

#### 微服务的特点 ####

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

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

#### 微服务要解决的问题 ####

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

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

#### 实现方案 ####

![这里写图片描述][SouthEast 10]

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

#### 弹性云 ####

这里简单介绍一下弹性云的概念，微服务要想提供好服务，保证API不能挂掉并且有好的性能，需要很高的运维要求。这里的弹性云便是自动化运维解决方案，对访问压力进行监控，根据监控解决调度应用的发布和回收。

![这里写图片描述][SouthEast 11]

[Link 1]: http://lib.csdn.net/base/architecture
[SouthEast]: /images/20220615/56fb1e1684374d7bb1a586af6b8597c1.png
[Java]: http://lib.csdn.net/base/javase
[PHP]: http://lib.csdn.net/base/php
[SouthEast 1]: /images/20220615/7d7ac087f9634658b3d8017d549c89c1.png
[SouthEast 2]: /images/20220615/88dd8f1566784756a379970274ae3c9c.png
[SouthEast 3]: /images/20220615/34888b3585a040a49b29c82fb72ca380.png
[SouthEast 4]: /images/20220615/bed3d1a9ccf1470283f139d216892a14.png
[SouthEast 5]: /images/20220615/37fbf798c1434096919c7590dd8f59b5.png
[SouthEast 6]: /images/20220615/00e6617714a94165ba1f282f8985854a.png
[SouthEast 7]: /images/20220615/aac776a92c9e4d08b84fda7e6af69bfb.png
[SouthEast 8]: /images/20220615/4d6d26e042e747a7b25e4162de5425e0.png
[SouthEast 9]: /images/20220615/5278d395947844e49e67b4b2bc8ef7b0.png
[SouthEast 10]: /images/20220615/96ee3de9e3a44038baf82a37a017e7d6.png
[SouthEast 11]: /images/20220615/1d90f97fb2594a3cbae97b660bce969c.png