基于GateKeeper网关的微服务架构 _微服务架构

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

文章插图

在传统单体架构（如上图左侧）中，我们一个项目的所有模块是聚合在一个程序中。我们所有模块数据都存放到一个数据库中。因为这种架构很简单的原因，所以开发效率很快，部署方便，在项目初期阶段比较常用。但随着项目复杂度增加，开发规模上升缺点也有很多比如：模块之间代码容易引起冲突，因为太容易修改到同一个文件了。还有就是一个小改动也需要整体上线，线上稳定性很难得到保证。
随着软件架构的不断演进，微服务架构逐渐流行起来。在微服务架构（如上图右侧）中，模块是独立运行的进程服务，每个模块都有独立的数据库，当业务流量增大时可以通过增加部署实例的方式来应对。
「微服务」的理念提倡每个服务都是单一职责，且每一个服务都能实现自治，因此可以带来一些明显好处：
部署简单：每个微服务都可以独立去部署，方便快捷。
逻辑清晰：将一个独立功能逻辑封装在单一微服务里面，实现整体项目的逻辑清晰。
可扩展：因为可以随时增加和减少微服务，可以很方便的扩展功能。
可靠性高：某一个功能的异常可以隔离在单一微服务里面，可以提高整体可靠性。
微服务架构实现形式
实现形式大致有三种：
基于云原生的微服务

文章插图

当前概念最火的微服务实现方式，这种方式需要依赖k8s集群来管理服务的容器。
如上图，每个微服务其实就一个Service，Pod是每个服务的部署实例。服务的对外访问提供需要依赖Ingress来实现。
优点很多：需要考虑服务注册发现问题（内部已集成）、支持容器的弹性伸缩等
存在问题：非云原生的应用无法使用、架构复杂导致运维成本很高、
基于微服务框架的微服务

文章插图

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，让它作为统一接入服务。以后再加项目时加一个配置即可。