瞎聊微服务治理问题
对于一个大型的互联网系统,一般会包含多个应用,而且应用之间往往还存在共同的业务,并且应用之间还存在调用关系。除此之外 ,对于大型的互联网系统还有一些其它的挑战,比如如何应对急剧增长的用户,如何管理好研发团队快速迭代产品研发,如何保持产品升级更加稳定等等 。
因此,为了使业务得到很好的复用,模块更加容易拓展和维护,我们希望业务与应用分离,某个业务不再属于一个应用,而是作为一个独立的服务单独进行维护。应用本身不再是一个臃肿的模块堆积,而是由一个个模块化的服务组件组合而成。
服务化
服务化的特点
上面介绍的分布式架构即服务化。我们再总结一下,服务化主要有如下特点:
-
应用按业务拆分成服务
-
各个服务均可独立部署
-
服务可被多个应用共享
-
服务之间可以通信
服务化的好处
那么企业采用服务化有哪些好处呢?
-
架构上系统更加清晰
-
核心模块稳定,以服务组件为单位进行升级,避免了频繁发布带来的风险
-
开发管理方便
-
单独团队维护、工作分明,职责清晰
-
业务复用、代码复用
-
非常容易拓展
服务化实现方式
如果要实现服务化的话,最常用的方式就是利用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化
-
基于访问压力的实时集群调度与管理
-
弹性云
这里简单介绍一下弹性云的概念,微服务要想提供好服务,保证API不能挂掉并且有好的性能,需要很高的运维要求。这里的弹性云便是自动化运维解决方案,对访问压力进行监控,根据监控解决调度应用的发布和回收。
来源:http://blog.csdn.net/suifeng3051/article/details/53992560