一.什么是微服务架构?
为了方便理解,我先讲一个小故事:(改编自一知乎答主)
Martin(微服务提出者也叫 Martin)刚来到公司时是一个基层员工,它上面有经理、老板,那个时候所有人都听老板的指挥。但是过了两年,公司的人越来越多,原来的模式下整个公司的运作效率太低,管理也很混乱。
于是已经踏上中层岗位的 Martin 建议老板进行部门划分(服务化),专门的部门只做专门的事情(单一职责)。例如研发部门只做研发,人事部门只做招聘。老板听取了 Martin 的意见,对公司的组织架构进行了调整。
有一天,Martin 发现公司的部门越来越多,各个部门并不能完全知道对方所做的事情,这对跨部门协作(服务调用)带来了困难。
行政部门会(注册中心)来记录所有的部门,每当有新的部门行政都会记录下来(服务注册),然后公布出来让所有部门知道(服务发现)。
在新的组织架构下,公司的效率逐步提高。老板也给 Martin 发了大量奖金作为奖励,Martin 从此赢取白富美走向了人生巅峰。
这是一个公司组织架构演变的故事,主要讲的是随着公司规模的扩大,组织从集中化管理到分布化管理的过程。
映射到我们的信息系统里来也是一样的,随着我们的系统越来越复杂,变得难以管理,也有人想到去拆分然后治理。在解决复杂问题上,分治可以说是一个屡试不爽的办法。关于更多内容,大家可以阅读什么是微服务架构?
当我们的项目曾经还是单体应用的时候,虽然没有网关
的概念,但是一般在项目中都会用到filter/过滤器
之类的东西,filter的作用就是把项目中的一些非业务逻辑的功能抽离出来独立处理,避免与业务逻辑混在一起增加代码复杂度。比如 鉴权认证功能、Session处理、安全检查、日志处理
等等。
现在我们采用微服务架构了,在一个项目中微服务节点很多,如果让每一个节点都去处理上面这些 “鉴权认证功能、Session处理、安全检查、日志处理等” 会多出很多冗余的代码,也会给增加业务代码的复杂度,因此我们就需要有一个网关把这些公共的功能独立出来成为一个服务来统一的处理这些事情。
在这里插入图片描述
上图是微服务架构网关示意图
网关
是内部微服务的对外唯一入口,所以外面全部的请求都会先发到这个网关上,然后由网关来根据不同的请求转发到不同的微服务节点上。例如可以 根据路径 来转发、也可以 根据参数 来转发。
由于内部微服务实例也会随着业务调整不停的变更,增加或者删除节点,网关
可以与服务注册
模块进行协同工作,保证将外部请求转发到最合适的微服务节点上面去。网关
是内部微服务的单一入口,所以网关在收到外部请求之后,还可以根据内部微服务每个实例的负荷情况进行动态的负载均衡调节。一旦内部的某个微服务实例负载很高,甚至是不能及时响应,则网关就通过负载均衡策略减少或停止向这个实例转发请求。当所有的内部微服务实例都处理不过来的时候,网关还可以采用限流
或熔断
的形式阻止外部请求,以保障整个系统的可用性。网关
就像是微服务的大门守卫,每一个请求进来之后,都必须先在网关上进行身份验证,身份验证通过后才转发给后面的服务,转发的时候一般也会带上身份信息。同时网关也需要对每一个请求进行安全性检查,例如参数的安全性、传输的安全性等等。现在我们通过一个小案例来简要阐述微服务的服务注册和发现,加入我们公司有一款产品已经在线上运行,在情人节这天想搞一场促销活动,为了应对此次促销活动我们可能需要新上线三个微服务实例来支撑这场促销活动。那么我们如何让网关知道我们新上线的微服务?从而进行正常的转发。作为苦逼程序员的你就只有手动去 网关API gateway
中添加新增的这三个微服务实例的 ip 与port ,一个真正在线的微服务系统可能有成百上千微服务,难道也要一个一个去手动添加吗?有没有让系统自动去实现这些操作的方法呢?如下图所示
在这里插入图片描述 如图所示,当我们新添加一个微服务实例的时候,微服务就会将自己的 ip 与 port 发送到注册中心,在注册中心里面记录起来。当 API gateway 需要访问某些微服务的时候,就会去注册中心取到相应的 ip 与 port。从而实现自动化操作。所以,服务的注册中心就是维护调用和被调用方的信息。
服务注册方式有以下两种:
我们先来看看在没有「配置中心」的传统项目中,我们是怎么处理各类配置参数问题的:
上面只是拿配置文件的形式来举例,有的项目会采用数据库配置,虽然灵活一点,但是依旧不能完全解决上述问题。
具有上述特性的「配置中心」是如何解决上面传统配置所面临的问题的呢?
由于绝大部分项目只是一味地增加服务,并没有对其妥善管理,当接口出现问题时,很难从错综复杂的服务调用网络中找到问题根源,从而错失了止损的黄金时机。
而链路追踪的出现正是为了解决这种问题,它可以在复杂的服务调用中定位问题,还可以在新人加入后台团队之后,让其清楚地知道自己所负责的服务在哪一环。
关于微服务链路追踪的实现原理,大家可以参考这篇文章微服务链路追踪原理
关于负载均衡方面,不做太多描述,相关概念大家平时接触也比较多,可阅读这篇文章什么是负载均衡,为什么要做*负载均衡
在微服务架构中,每一个微服务都是一个独立的业务功能单元,而一个应用一般由多个微服务组成,微服务之间的交互是通过RPC(远程过程调用)完成。
比如,我们的应用是微服务A调用微服务B和微服务C来完成的,而微服务B又需要调用微服务D,微服务D又需要调用微服务E。如果在调用的链路上对微服务E的调用,响应时间过长或者服务不可用,那么对微服务D的调用就会占用越来越多的系统资源,进而引起微服务D的系统崩溃,微服务D的不可用,又会连锁反应的引起微服务B崩溃,进而微服务A崩溃,最终导致整个应用不可用。这也就是所谓的“雪崩效应”。
本篇文章中,我们介绍了微服务架构核心,并做了一个基础讲解,方便大家了解各个部分的作用,不做深入展开讲解.
参考文献
1.微服务架构之「 API网关 」 2.微服务架构之「 配置中心」