第四章 网关安全
这一章从简单的API的场景过渡到复杂的微服务的场景
4.1 概述
微服务安全面临的挑战：介绍中小企业的一个微服务架构，相比第三章的单体应用的简单的API所面临的哪些挑战
OAuth2协议与微服务安全：介绍OAuth2中的各个角色，以及相互之间的关系，介绍具体的代码实现
微服务网关安全：搭建网关，安全中心，两个微服务，怎么将安全从微服务中解耦出来放到网关上，与OAuth协议联系起来解决微服务安全面临的新的挑战。
4.2 微服务安全面临的挑战
更多的入口点，更高的安全风险
单体应用，入口点只有一个，有一个Filter/Interceptor 就能控制所有的安全风险。
微服务环境下，业务逻辑不再是在一个单一的进程里，分散在很多的进程里。如图有很多的tomcat，每个tomcat都有自己的入口点，所以要防范的攻击面要比原来大得多，风险也高得多。
性能问题
单体应用下，所有的业务逻辑 和 安全的信息 都在一个进程里，要验一下用户身份、权限都是在一个进程里完成的。
微服务环境下，比如在访问一个订单的时候，用户的信息，权限信息，在订单的tomcat 是拿不到的，需要一个远程调用，调一下安全中心认证中心去或者这些信息。每一个请求，不管是外部进来的，还是服务之间的调用，需要安 全校验的时候，这个远程连接所带来的延迟，有可能导致服务产生性能的问题，尤其是对性能极为敏感的服务。
服务间通讯安全
单体应用下，如订单调库存，订单调物流，都在一个tomcat里，不需要考虑任何安全问题。
微服务环境下，订单调物流，需要跨网络，出我的进程，进到另一个进程，需要保证这个通讯也是安全的。
跨多个微服务的请求难以追踪
对于一个服务来说，可观测性是一个很重要的指标，可观测性包含了三个方面的意义：
1、Log 日志，记录了系统发生了什么。 在单体应用里，记录日志很简单，直接在代码里写就可以了。分布式的应用里，每一个进程会单独去记一些日志。比如访问订单请求，订单又去调库存，调价格，日志是分散来记的，日志自己记了日志，库存、价格也是自个记。这时候就需要一个机制把所有的日志串起来。
2、metrics 指标监控：在一个时间维度上聚合起来的一个数字。当你谈论metrics 的时候，一定要有两个关键要素，第一个就是时间窗口，第二个是一个数字。比如说流量，我们会说在1秒钟有10个请求，一分钟有200个请求，过去三小时下了50个单，我的成交额一天是100万。谈论metrics ，有两个要素，时间窗口，如每秒钟，过去三小时，每一天；第二个就是个数字，30个请求，200个请求，50个订单，100万成交额。这两个聚合起来形成一个metrics 。最典型的metrics 就是流量，每秒钟有多少个请求，在单体应用里很容易就能控制住流量。但是在分布式应用里，可能我的订单能承受的并发量是500，物流能承受的并发量是700，库存能承受的并发量是900。这个时候就需要有一个机制来控制整个的服务的流控，而不是单一的去控制某一个微服务的流控，这也是要解决的一个问题。
3，Tracing ，日志的聚合是一种Tracing，另外一种就是买吉克斯的Tracing，当一个请求进来，在订单服务花了多长时间，在库存服务花了多长时间，在价格服务花了多长时间，最后一眼能看见整个服务的瓶颈在哪里。
容器化部署导致的证书和访问控制问题
~~
如何在微服务间共享用户的登录状态
多语言架构要求每个团队都要有一定的安全经验
原文地址：https://www.cnblogs.com/lihaoyang/p/12043941.html