微服务安全面临的挑战
更多的入口点，更高的安全风险
- 单体应用的场景下，入口点只有一个，所有的请求都会从这个入口点进来，在这个入口点去建立一组Filter或者Interceptor，就可以控制所有的风险
- 微服务场景下，业务逻辑不是在一个单一的进程里，而是分散在很多的进程里。每一个进程都有自己的入口点，这就会导致防范的攻击面，比原来大得多，风险也会高的多。
性能问题
- 单体应用的场景下，需要的安全信息，很可能在当前进程里是没有的，比如说，访问一个订单服务的时候，用户的信息、权限的信息，在订单服务中是拿不到的。需要调用安全中心认证中心去获取相关的这些信息。那么，每一个请求，不管是从外部进来的，还是服务间的调用，都要去做安全校验时，这个远程连接所带来的延迟，有可能会导致服务产生一些性能问题。尤其是对性能极其敏感的一些服务。原来那个服务可能本身几毫秒就能响应了。因为要做远程调用来验证安全，可能又增加了几毫秒。
服务间通讯安全
- 单体应用的场景下，订单调用价格，调用物流都是在同一个tomcat中，不需要考虑安全问题。
- 微服务场景下，当订单去调用物流的时候，需要跨网络，从一个进程进入另一个进程，要保证这个通讯也是安全的。
跨多个微服务的请求难以追踪
- 对于一个服务来说，可观测性是一个很重要的指标。可观测性包含了三方面的意义：
- log日志：在分布式的应用中，每一个进程会单独记录一些日志，这时候就需要有一个机制把所
- Metrics指标监控：就是把日志的一些信息聚合起来，形成一个在一段时间上的某个指标的统计。比如说流量，在单体应用中很好控制。但是在微服务中，每个服务能承受的流量不同，需要有一个机制能控制整个系统的流控。
- Tracing调用链监控：比如一个请求进来，在订单服务耗时多少，库存服务耗时多少，价格服务服务耗时多少。能看到整个服务的瓶颈在哪里，这也是需要解决的。
容器化部署导致的证书和访问控制问题
- 微服务场景下，最常用的部署手段那就是容器化，证书和IP访问控制比以前复杂。
如何在微服务间共享用户登录状态
- 微服务场景下，如何在多个应用之间共享用户的登陆状态，在这个请求中，所涉及到的微服务都可以知道当前用户是谁。
多语言架构要求每个团队都有一定的安全经验
- 微服务场景下，每个微服务都可以使用适合的语言开发，有可能订单是java写的，物流是用go写的...。这种情况下，要求各个团队都要有安全经验。
