⽹关安全（⼀）-微服务安全⾯临的挑战及常见架构
1、微服务安全⾯临的挑战
  在微服务的架构下，对⽐单体应⽤架构的API安全有哪些新的挑战呢？
  1.1、更多的⼊⼝点，更⾼的安全风险
    单体应⽤的场景下，⼊⼝点只有⼀个，所有的请求都会从这个⼊⼝点进来，在这个⼊⼝点去建⽴⼀组Filter或者Interceptor，就可以控制所有的风险。
    微服务场景下，业务逻辑不是在⼀个单⼀的进程⾥，⽽是分散在很多的进程⾥。每⼀个进程都有⾃⼰的⼊⼝点，这就会导致防范的攻击⾯，⽐原来⼤得多，风险也会⾼的多。
  1.2、性能问题
    单体应⽤的场景下，所有的业务逻辑都在同⼀个进程⾥⾯，关于安全的信息也都在这⾥⾯，想验证⾝份权限，在这个进程⾥可以完成的。
    微服务场景下，需要的安全信息，很可能在当前进程⾥是没有的，⽐如说，访问⼀个订单服务的时候，⽤户的信息、权限的信息，在订单服务中是拿不到的。需要调⽤安全中⼼认证中⼼去获取相关的这些信息。那么，每⼀个请求，不管是从外部进来的，还是服务间的调⽤，都要去做安全校验时，这个远程连接所带来的延迟，有可能会导致服务产⽣⼀些性能问题。尤其是对性能极其敏感的⼀些服务。原来那个服务可能本⾝⼏毫秒就能响应了。因为要做远程调⽤来验证安全，可能⼜增加了⼏毫秒。
  1.3、服务间通讯安全
    单体应⽤的场景下，订单调⽤价格，调⽤物流都是在同⼀个tomcat中，不需要考虑安全问题。
    微服务场景下，当订单去调⽤物流的时候，需要跨⽹络，从⼀个进程进⼊另⼀个进程，要保证这个通讯也是安全的。
  1.4、跨多个微服务的请求难以追踪
    对于⼀个服务来说，可观测性是⼀个很重要的指标。可观测性包含了三⽅⾯的意义：
    1.4.1、log⽇志：在分布式的应⽤中，每⼀个进程会单独记录⼀些⽇志，这时候就需要有⼀个机制把所有的⽇志串起来。
    1.4.2、Metrics指标监控：就是把⽇志的⼀些信息聚合起来，形成⼀个在⼀段时间上的某个指标的统计。⽐如说流量，在单体应⽤中很好控制。但是在微服务中，每个服务能承受的流量不同，需要有⼀个机制能控制整个系统的流控。
    1.4.3、Tracing调⽤链监控：⽐如⼀个请求进来，在订单服务耗时多少，库存服务耗时多少，价格服务服务耗时多少。能看到整个服务的瓶颈在哪⾥，这也是需要解决的。
  1.5、容器化部署问题
    微服务场景下，最常⽤的部署⼿段那就是容器化，证书和IP访问控制⽐以前复杂。
  1.6、微服务间共享⽤户的登录状态
    微服务场景下，如何在多个应⽤之间共享⽤户的登陆状态，在这个请求中，所涉及到的微服务都可以知道当前⽤户是谁。微服务网关和注册中心区别
  1.7、多语⾔架构要求每个团队都要有⼀定的安全经验
    微服务场景下，每个微服务都可以使⽤适合的语⾔开发，有可能订单是java写的，物流是⽤go写的...。这种情况下，要求各个团队都要有安全经验。
2、常见的微服务安全整体架构
上图为常见的微服务安全架构，这⾥我们主要学习安全中⼼、如何在⽹关上做安全处理。