1. 概述：
- 微服务安全面临的挑战：介绍中小企业的一个微服务架构，相比第三章的单体应用的简单的API所面临的哪些挑战
- OAuth2协议与微服务安全：介绍OAuth2中的各个角色，以及相互之间的关系，介绍具体的代码实现
- 微服务网关安全：搭建网关，安全中心，两个微服务，怎么将安全从微服务中解耦出来放到网关上，与OAuth协议联系起来解决微服务安全面临的新的挑战。
2. 微服务安全的新挑战
2.1 更多的入口点，更高的安全风险
- 单体应用，入口点只有一个，有一个Filter/Interceptor 就能控制所有的安全风险。
- 微服务环境下，业务逻辑不再是在一个单一的进程里，分散在很多的进程里。如图有很多的tomcat，每个tomcat都有自己的入口点，所以要防范的攻击面要比原来大得多，风险也高得多。
2.2 性能问题
单体应用下，所有的业务逻辑 和 安全的信息 都在一个进程里，要验一下用户身份、权限都是在一个进程里完成的。
微服务环境下，比如在访问一个订单的时候，用户的信息，权限信息，在订单的tomcat 是拿不到的，需要一个远程调用，调一下安全中心认证中心去或者这些信息。每一个请求，不管是外部进来的，还是服务之间的调用，需要安全校验的时候，这个远程连接所带来的延迟，有可能导致服务产生性能的问题，尤其是对性能极为敏感的服务。
2.3 服务间通讯安全
单体应用下，如订单调库存，订单调物流，都在一个tomcat里，不需要考虑任何安全问题。
微服务环境下，订单调物流，需要跨网络，出我的进程，进到另一个进程，需要保证这个通讯也是安全的。
2.4 跨多个微服务的请求难以追踪
对于一个服务来说，可观测性是一个很重要的指标，可观测性包含了三个方面的意义：
（1）Log 日志，记录了系统发生了什么。 在单体应用里，记录日志很简单，直接在代码里写就可以了。分布式的应用里，每一个进程会单独去记一些日志。比如访问订单请求，订单又去调库存，调价格，日志是分散来记的，日志自己记了日志，库存、价格也是自个记。这时候就需要一个机制把所有的日志串起来。
（2）metrics 指标监控：在一个时间维度上聚合起来的一个数字。当你谈论metrics 的时候，一定要有两个关键要素，第一个就是时间窗口，第二个是一个数字。比如说流量，我们会说在1秒钟有10个请求，一分钟有200个请求，过去三小时下了50个单，我的成交额一天是100万。谈论metrics ，有两个要素，时间窗口，如每秒钟，过去三小时，每一天；第二个就是个数字，30个请求，200个请求，50个订单，100万成交额。这两个聚合起来形成一个metrics 。最典型的metrics 就是流量，每秒钟有多少个请求，在单体应用里很容易就能控制住流量。但是在分布式应用里，可能我的订单能承受的并发量是500，物流能承受的并发量是700，库存能承受的并发量是900。这个时候就需要有一个机制来控制整个的服务的流控，而不是单一的去控制某一个微服务的流控，这也是要解决的一个问题。
（3）Tracing ，日志的聚合是一种Tracing，另外一种就是买吉克斯的Tracing，当一个请求进来，在订单服务花了多长时间，在库存服务花了多长时间，在价格服务花了多长时间，最后一眼能看见整个服务的瓶颈在哪里。
2.5 容器化部署导致的证书和访问控制问题
在微服务的环境中，常用的部署手段是容器化。在以前的部署里面，要部署一个应用，部署到环境上，就会跟公司要4台服务器，部署4个实例。然后，在这四台机器上去根据IP安装白名单、证书。
但是，在微服务环境下，往往是通过容器化来进行环境部署的。如果没有使用容器化部署，虽然对外说是微服务，但那只是名义上的微服务。
因为微服务会有几十上百个服务在里面，然后每个都是集群的，你要控制的是几百个实例这种。这种量级的系统，如果你使用虚拟机或物理机去部署会非常麻烦的。所以真正的微服务都是使用容器化的。
容器化带来的最大好处就是带来了不可变的服务器，一旦容器产生，里面的服务都不会变化。你可以随时干掉一个容器，然后在另外一个地方启动一个新的服务，因为它是不会变的。或者说当压力大的时候，可以通过再启动几个容器来分担压力。
在这样的情况下，会导致证书、访问控制发生问题，虽然可以将证书、访问控制写入到镜像中，但是要求每一个服务的镜像实际上是不一样的。这种差异会带来维护上的困难。
容器中提供一种安全机制，根据容器的属性不同自动注入的机制将自己注入进去。让每个应用不用关心自己的证书问题。