微服务架构核心基础讲解

一.什么是微服务架构?

为了方便理解，我先讲一个小故事：（改编自一知乎答主）

Martin（微服务提出者也叫 Martin）刚来到公司时是一个基层员工，它上面有经理、老板，那个时候所有人都听老板的指挥。但是过了两年，公司的人越来越多，原来的模式下整个公司的运作效率太低，管理也很混乱。

于是已经踏上中层岗位的 Martin 建议老板进行部门划分（服务化），专门的部门只做专门的事情（单一职责）。例如研发部门只做研发，人事部门只做招聘。老板听取了 Martin 的意见，对公司的组织架构进行了调整。

有一天，Martin 发现公司的部门越来越多，各个部门并不能完全知道对方所做的事情，这对跨部门协作（服务调用）带来了困难。

行政部门会（注册中心）来记录所有的部门，每当有新的部门行政都会记录下来（服务注册），然后公布出来让所有部门知道（服务发现）。

在新的组织架构下，公司的效率逐步提高。老板也给 Martin 发了大量奖金作为奖励，Martin 从此赢取白富美走向了人生巅峰。

这是一个公司组织架构演变的故事，主要讲的是随着公司规模的扩大，组织从集中化管理到分布化管理的过程。

映射到我们的信息系统里来也是一样的，随着我们的系统越来越复杂，变得难以管理，也有人想到去拆分然后治理。在解决复杂问题上，分治可以说是一个屡试不爽的办法。关于更多内容,大家可以阅读什么是微服务架构?

二.网关

2.1 为什么需要网关?

当我们的项目曾经还是单体应用的时候，虽然没有网关的概念，但是一般在项目中都会用到filter/过滤器之类的东西，filter 的作用就是把项目中的一些非业务逻辑的功能抽离出来独立处理，避免与业务逻辑混在一起增加代码复杂度。比如 鉴权认证功能、Session处理、安全检查、日志处理等等。

现在我们采用微服务架构了，在一个项目中微服务节点很多，如果让每一个节点都去处理上面这些 “鉴权认证功能、Session 处理、安全检查、日志处理等” 会多出很多冗余的代码，也会给增加业务代码的复杂度，因此我们就需要有一个网关把这些公共的功能独立出来成为一个服务来统一的处理这些事情。

​ 上图是微服务架构网关示意图

2.2 网关的功能

• 路由转发

• 网关是内部微服务的对外唯一入口，所以外面全部的请求都会先发到这个网关上，然后由网关来根据不同的请求转发到不同的微服务节点上。例如可以 根据路径 来转发、也可以 根据参数 来转发。

• 由于内部微服务实例也会随着业务调整不停的变更，增加或者删除节点，网关可以与服务注册模块进行协同工作，保证将外部请求转发到最合适的微服务节点上面去。

• 负载均衡

• 既然网关是内部微服务的单一入口，所以网关在收到外部请求之后，还可以根据内部微服务每个实例的负荷情况进行动态的负载均衡调节。一旦内部的某个微服务实例负载很高，甚至是不能及时响应，则网关就通过负载均衡策略减少或停止向这个实例转发请求。当所有的内部微服务实例都处理不过来的时候，网关还可以采用限流或熔断的形式阻止外部请求，以保障整个系统的可用性。

• 安全认证

• 网关就像是微服务的大门守卫，每一个请求进来之后，都必须先在网关上进行身份验证，身份验证通过后才转发给后面的服务，转发的时候一般也会带上身份信息。同时网关也需要对每一个请求进行安全性检查，例如参数的安全性、传输的安全性等等。

• 日志记录

• 既然所有的请求都需要走网关，那么我们就可以在网关上统一集中的记录下这些行为日志。这些日志既可以作为我们后续事件查询使用，也可以作为系统的性能监控使用。

• 数据转换

• 因为网关对外是面向多种不同的客户端，不同的客户端所传输的数据类型可能是不一样的。因此网关还需要具备数据转换的功能，将不同客户端传输进来的数据转换成同一种类型再转发给内部微服务上，这样，兼容了这些请求的多样性，保证了微服务的灵活性。

三.服务注册和发现

3.1 为什么需要服务注册和发现?

现在我们通过一个小案例来简要阐述微服务的服务注册和发现,加入我们公司有一款产品已经在线上运行，在情人节这天想搞一场促销活动，为了应对此次促销活动我们可能需要新上线三个微服务实例来支撑这场促销活动。那么我们如何让网关知道我们新上线的微服务?从而进行正常的转发。作为苦逼程序员的你就只有手动去 网关API gateway 中添加新增的这三个微服务实例的 ip 与 port ，一个真正在线的微服务系统可能有成百上千微服务，难道也要一个一个去手动添加吗？有没有让系统自动去实现这些操作的方法呢？如下图所示

如图所示，当我们新添加一个微服务实例的时候，微服务就会将自己的 ip 与 port 发送到注册中心，在注册中心里面记录起来。当 API gateway 需要访问某些微服务的时候，就会去注册中心取到相应的 ip 与 port。从而实现自动化操作。所以，服务的注册中心就是维护调用和被调用方的信息。

3.2 服务注册的两种方式

服务注册方式有以下两种：

• 客户端注册客户端注册即为：将服务注册与服务注销的逻辑写进代码里面，当一个微服务启动的时候，将信息写入注册中心，当一个微服务下线的时候，注销相应的信息。且需要不同的编程语言实现相同的一套逻辑。对业务代码有一定的入侵。期间，注册中心与各个微服务之间还需要保持心跳。

• 第三方注册第三方注册由一个独立的服务 Registrar 负责注册与注销。当服务启动后以某种方式通知 Registrar，然后 Registrar 负责向注册中心发起注册工作。同时注册中心要维护与服务之间的心跳，当服务不可用时，向注册中心注销服务。

3.3 服务发现的两种方式

• 客户端发现客户端负责向注册中心获取相应的 ip 与 port ，多种语言需要实现同一套逻辑，有点冗余的感觉。

• 服务端发现由 API gateway 实现服务发现的功能，这样一套语言便可轻松维护服务发现的功能。

四.配置中心

4.1 为什么需要配置中心？

我们先来看看在没有「配置中心」的传统项目中，我们是怎么处理各类配置参数问题的：

1. 一般是静态化配置。大多数在项目中单独写一个配置文件，例如 "config.conf"，然后将各类 参数配置、应用配置、环境配置、安全配置、业务配置 都写到这个文件里。当项目代码逻辑中需要使用配置的时候，就从这个配置文件中读取。这种做法虽然简单，但如果参数需要修改，就非常的不灵活，甚至需要重启运行中的项目才能生效。相信大多数开发同学都深有体会。

2. 配置文件无法区分环境。由于配置文件是放在项目中的，但是我们项目可能会有多个环境，例如：测试环境、预发布环境、生产环境。每一个环境所使用的配置参数理论上都是不同的，所以我们在配置文件中根据不同环境配置不同的参数，这些都是手动维护，在项目发布的时候，极其容易因开发人员的失误导致出错。

3. 配置文件过于分散。如果一个项目中存在多个逻辑模块独立部署，每个模块所使用的配置内容又不相同，传统的做法是会在每一个模块中都放一个配置文件，甚至不同模块的配置文件格式还不一样。那么长期的结果就是配置文件过于分散混乱，难以管理。

4. 配置修改无法追溯。因为采用的静态配置文件方式，所以当配置进行修改之后，不容易形成记录，更无法追溯是谁修改的、修改时间是什么、修改前是什么内容。既然无法追溯，那么当配置出错时，更没办法回滚配置了。

上面只是拿配置文件的形式来举例，有的项目会采用数据库配置，虽然灵活一点，但是依旧不能完全解决上述问题。

4.2 配置中心特点

• 配置集中管理、统一标准

• 配置与应用分离

• 实时更新

• 高可用

具有上述特性的「配置中心」是如何解决上面传统配置所面临的问题的呢？

1. 采用“配置集中管理”，可以很好的解决传统的“配置文件过于分散”的问题。所有的配置都集中在配置中心这一个地方管理，不需要每一个项目都自带一个，这样极大的减轻了开发成本。

2. 采用“配置与应用分离”，可以很好的解决传统的“配置文件无法区分环境”的问题，配置并不跟着环境走，当不同环境有不同需求的时候，就到配置中心获取即可，极大的减轻了运维部署成本。

3. 具备“实时更新”的功能，就是用来解决传统的“静态化配置”的问题。线上系统需要调整参数的时候，只需要在配置中心动态修改即可。

4. 既然配置都统一管理了，那配置中心在整个系统中的地位就非常重要了，一旦配置中心不能正常提供服务，就可能会导致项目整体故障，因此“高可用”就是配置中心又一个很关键的指标了。

五.链路追踪

5.1 为什么需要链路追踪？

由于绝大部分项目只是一味地增加服务，并没有对其妥善管理，当接口出现问题时，很难从错综复杂的服务调用网络中找到问题根源，从而错失了止损的黄金时机。

而链路追踪的出现正是为了解决这种问题，它可以在复杂的服务调用中定位问题，还可以在新人加入后台团队之后，让其清楚地知道自己所负责的服务在哪一环。

5.2 链路追踪实现原理

关于微服务链路追踪的实现原理,大家可以参考这篇文章微服务链路追踪原理

六.负载均衡

关于负载均衡方面,不做太多描述,相关概念大家平时接触也比较多,可阅读这篇文章什么是负载均衡,为什么要做*负载均衡

七.熔断

在微服务架构中，每一个微服务都是一个独立的业务功能单元，而一个应用一般由多个微服务组成，微服务之间的交互是通过 RPC（远程过程调用）完成。

比如，我们的应用是微服务 A 调用微服务 B 和微服务 C 来完成的，而微服务 B 又需要调用微服务 D，微服务 D 又需要调用微服务 E。如果在调用的链路上对微服务 E 的调用，响应时间过长或者服务不可用，那么对微服务 D 的调用就会占用越来越多的系统资源，进而引起微服务 D 的系统崩溃，微服务 D 的不可用，又会连锁反应的引起微服务 B 崩溃，进而微服务 A 崩溃，最终导致整个应用不可用。这也就是所谓的“雪崩效应”。

八.小结

本篇文章中,我们介绍了微服务架构核心,并做了一个基础讲解,方便大家了解各个部分的作用,不做深入展开讲解.

参考文献

1.微服务架构之「 API网关 」

2.微服务架构之「 配置中心」