<返回更多

基于GateKeeper网关的微服务架构

2019-10-25    
加入收藏

什么是微服务?

在了解微服务架构前,我们需要先了解什么是微服务

干货技术分享:基于GateKeeper网关的微服务架构

 

在传统单体架构(如上图左侧)中,我们一个项目的所有模块是聚合在一个程序中。我们所有模块数据都存放到一个数据库中。因为这种架构很简单的原因,所以开发效率很快,部署方便,在项目初期阶段比较常用。但随着项目复杂度增加,开发规模上升缺点也有很多比如:模块之间代码容易引起冲突,因为太容易修改到同一个文件了。还有就是一个小改动也需要整体上线,线上稳定性很难得到保证。

随着软件架构的不断演进,微服务架构逐渐流行起来。在微服务架构(如上图右侧)中,模块是独立运行的进程服务,每个模块都有独立的数据库,当业务流量增大时可以通过增加部署实例的方式来应对。

「 微服务 」的理念提倡每个服务都是单一职责,且每一个服务都能实现自治,因此可以带来一些明显好处:

部署简单:每个微服务都可以独立去部署,方便快捷。

逻辑清晰:将一个独立功能逻辑封装在单一微服务里面,实现整体项目的逻辑清晰。

可扩展:因为可以随时增加和减少微服务,可以很方便的扩展功能。

可靠性高:某一个功能的异常可以隔离在单一微服务里面,可以提高整体可靠性。

微服务架构实现形式

实现形式大致有三种:

基于云原生的微服务

干货技术分享:基于GateKeeper网关的微服务架构

 

当前概念最火的微服务实现方式,这种方式需要依赖k8s集群来管理服务的容器。

如上图,每个微服务其实就一个Service,Pod是每个服务的部署实例。服务的对外访问提供需要依赖Ingress来实现。

优点很多: 需要考虑服务注册发现问题(内部已集成)、支持容器的弹性伸缩等

存在问题: 非云原生的应用无法使用、架构复杂导致运维成本很高、

基于微服务框架的微服务

干货技术分享:基于GateKeeper网关的微服务架构

 

JAVA系的spring-cloud、Go系的go-micro都是微服务框架的代表。 上图以go-micro为例进行说明:

Register确保每个Server的启动和消亡最终写入到Consul。Client是请求服务的接口,请求服务时会先使用Selector选择一个服务器,然后再经过transport和codec的最终抵达目标Server.

优点:内部集成了服务注册发现、服务间调用都是代码形式实现更便捷、插件丰富

缺点:与开发语言强绑定、功能复用性不强(A服务的功能,即使做成公共库其他服务也需要调用才行)

基于网关的微服务

干货技术分享:基于GateKeeper网关的微服务架构

 

基于网关的微服务架构,我们以GateKeeper进行说明。

1、用户通过接入层 (一般选用 Nginx、Haproxy、LVS) 连接到 GateKeeper 实例中。

2、每个 GateKeeper 实例,针对每个子服务模块,单独进行服务探测。

3、在线服务管理时,配置数据先保存到 GateKeeper 配置 DB 中,然后再通过调用配置更新接口( /reload ),更新所有实例机器配置。

基于网关的微服务架构优势:

1、网关提供服务的注册发现机制和负载均衡

2、外部访问可以直接使用网关接入,内部服务互调也可以经由网关接入

3、网关可提供额外的其他功能拓展支持(如:登陆、权限验证)只实现一次多出调用。

4、接入的服务不受语言限制

5、非云原生应用、云原生应用皆可使用。

为什么考虑开发 GateKeeper?

我们公司项目在发展初期时,我们的服务比较少。而且大多是内部服务,对外服务只有一个后端(php)。18年下半年 随着业务发展,增加了N多个服务模块。考虑到之前的单体架构已经无法满足当前需求了,所以开始考虑微服务化划分,在划分好业务边界后,我们整理出共 10+个服务,5个服务需要对外服务。

这5个对外服务在部署完毕后首要解决的问题是需要接入用户权限系统(UPM),因为之前功能是下挂在PHP系统中的,当时我们考虑了三种方式:

1、是多个服务单独接入UPM、SSO系统。这样成本很高而且相同代码需要多出维护。

2、是仍然使用之前的 PHP项目当做外层项目,通过转发请求做统一权限和登陆操作。这是当时成本最低的方式。

3、独立做一个权限和登陆的API gateway,让它作为统一接入服务。以后再加项目时加一个配置即可。

从长远发展以及通用性来说我们最终选择了,独立做一个 API gateway。

为什么不选择主流API gateway,而是采用自研?

首先,当前GO这个技术栈 没有成熟的API gateway。

另外其他主流的API gateway,大多都有依赖软件较多的问题,比如要实现动态服务注册就需要 Consul这类的分布式数据库。

而我们的业务有时候需要本地化部署,这就需要:依赖少、快速简易部署、支持多种权限配置等。

综合以上因素,我们就考虑使用GO自研API网关了。

我们下一步的精力主要会放在三个方面:

1、持续不断推进项目稳定性建设和问题修复。

2、增加示例代码,让使用者更加容易、便捷。

3、增加新特性:熔断机制、基于云原生的部署等

end:如果你觉得本文对你有帮助的话,记得关注点赞转发,你的支持就是我更新动力。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>