天玥运维安全网关默认密码_微服务架构如何保证安全性？

快，关注这个头条号，一起涨姿势～

微服务架构如何保证安全性？

前些天在这4种常用的软件架构，到底有何不同？文章中有提过，我是想写这篇文章的，现在趁着周末抒发一下感情。我主要从以下几个点，分析一下吧，浅薄之见，望各位江湖好汉多多包涵！

• 微服务架构回顾
• 亲身小经历
• gateway
• oauth2.0
• other

一.微服务架构回顾

那我们先回忆一下，常用4种架构之微服务架构。

微服务架构，主要是中间层分解，将系统拆分成很多小应用(微服务)，微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当应用的故障不会影响到其他应用，单应用的负载也不会影响到其他应用，其代表框架有Spring cloud、Dubbo等。其架构图如下所示：

易于开发和维护：一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的，所以整个应用也会被维持在一个可控状态。

单个微服务启动较快：单个微服务代码量较少， 所以启动会比较快。

局部修改容易部署：单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。

技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。例如某些服务可使用关系型数据库MySQL；某些微服务有图形计算的需求，可以使用Neo4j。甚至可根据需要，部分微服务使用Java开发，部分微服务使用Node.js开发。微服务虽然有很多吸引人的地方，但它并不是免费的午餐，使用它是有代价的。使用微服务架构面临的挑战。

运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务服务的正常运行与协作，这给运维带来了很大的挑战。

分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。

接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。

重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这个问题(例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件)，但共享库在多语言环境下就不一定行得通了。

二.亲身小经历

上面扯皮了这么多，还不到关键的地方，到底搞什么鬼呀？我不是有意的，我就想让大家再过过概念。好啦，现在我们开始吧！看看我当时的微服务架构(我那会用Sping Cloud，就根据Sping Cloud讲一讲)，大家看安不安全？以下内容基本使用白话文扯皮子。

看不清楚的，大家可以点击图片放大看一看。从中可以看出这是Spring Cloud微服务架构图，至于Dubbo等微服务架构思路大体也是这样。从中我们看出为了保证安全可靠性，我们用了gateway、oauth2.0。至于这两项技术到底稳不稳，我们分开聊一聊。

三.gateway

1.gateway是什么？

Spring Cloud Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代Netflix ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。

2.gateway怎么用？

Spring Cloud Gateway怎么用，在这里我主要是为了讲述微服务的安全性，我就不上代码了，我就讲讲理论知识，具体细节等下我提供一些我之前的文章链接，供大家学习。

一个组件引入，无非就以下几件事情：

• 引入依赖包。
• 相关yml配置(即文件配置)。
• 上手方式：要么使用文件配置方式、要么使用java api(如果有其它的再说，目前我知道就这两种)，然后就完事了。

3.gateway能为微服务提供什么安全性保障？

Spring Cloud Gateway为我们提供了什么服务？由上面微服务架构图，我们可以看出移动客户端、管理后台访问微服务1、2、3接口必须经过gateway。gateway作为中间件，它的核心方法是filter，它就可以做以下几件事情：

• 按照自定的过滤方式进行拦截，符合约定的就可以通过或者被拦截。这样乱七八糟的接口就不能访问了嘛，这样就可以保证服务微服务的安全性。
• 既然能拦截到一切接口，那就可以对一些热点接口，做一些限流操作，比如a接口在一分钟内访问次数超过2万次，我们就让他降级，让它响应其它事件。
• 容错处理，请求有问题，就做一些特殊回调。
• 其它呀，反正接口都流经过你这里，你想怎么玩就怎么玩咯。

我曾经写过的一些Spring Cloud Gateway文章：

• Spring Cloud之Gateway(一)：基本了解及谓词详解
• Spring Cloud之Gateway(二)：网关过滤器
• Spring Cloud之Gateway(三)：全局过滤器
• Spring Cloud之Gateway(四)：TLS/SSL、配置、跨域访问配置、执行器API、开发人员指南及MVC或Webflux搭建Gateway

四.oauth2.0

oauth2.0按照gateway方式，我们同样从以下三个问题分析一下：

1.oauth2.0是什么？

OAuth2.0协议为用户资源的授权提供了一个安全又简易的标准。与以往的授权方式不同之处是 OAuth的授权不会使第三方触及到用户的帐号信息(如用户名与密码)，即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此 OAuth2.0是安全的。

2.oauth2.0怎么用？

Spring Cloud可以使用OAuth2.0来实现多个微服务的统一认证授权，通过向OAuth2.0服务进行集中认证和授权，获得access_token，而这个token是受其他微服务信任的，在后续的访问中都把access_token带过去，从而实现了微服务的统一认证授权。核心功能主要是以下两点：

• 其一是认证与鉴权，对于请求的用户身份的授权以及合法性鉴权；
• 其二是API级别的操作权限控制，这个在第一点之后，当鉴定完用户身份合法之后，对于该用户的某个具体请求是否具有该操作执行权限进行校验。

OAuth 2.0定义了四种授权方式。

• 授权码模式(authorization code)
• 简化模式(implicit)
• 密码模式(resource owner password credentials)
• 客户端模式(client credentials)

3.oauth2.0能为微服务提供什么安全性保障？

由上可知，只需在访问服务前增加OAuth2.0服务就能保证用户的相对安全了，一个用户能不能访问接口，oauth2.0来做最后一道关闸。这样就能保证微服务架构的相对安全性了。

我曾经写过的一些oauth2.0文章：

• 认证鉴权与API权限控制(一)
• 认证鉴权与API权限控制(二)
• 认证鉴权与API权限控制(三)
• 认证鉴权与API权限控制(四)
• OAuth2.0 授权码模式
• Spring Security(一)：Spring安全架构快速、实用的说明
• Spring Security(二)：HttpSecurity常用方法及说明
• Spring Security(三)：httpSecurity使用示例
• Spring Security(四)：基于表达式的权限控制
• Spring Security OAuth2.0(一)：开发指南
• Spring Security OAuth2.0(二)：使用小工具管理client

五.其它

1.使用nginx服务器，作用如下：

• 反向代理：代理我们要访问的目标服务器。

2.中间件搭建集群。

3.其它，你来补充。

六.总结

扯皮子了这么多，有点晕了，今天就先到这里先。给米兜一个赞，压压惊！！！

END！

请留下你指尖的温度

让太阳拥抱你

记得这是一个有温度的头条号

System.out.println("点个好看吧！");