微服务的环境下，我的业务逻辑不再是在一个单一的进程里，而是分散了很多的进程里。订单、物流、库存、价格。每一个tomcat都是一个进程。
每一个进程，每一个tomcat都有自己的入口点。那么就导致我防范的攻击面比原来大的多 。那么风险也会高的多。
性能问题，原来的所有业务逻辑都在同一个进程里面。那么我需要的安全信息也都在这里面。比如请求进来以后，我想要验一下用户身份、权限。我都是在这个进程里面就可以完成的。
在微服务的架构下，我需要的关于安全信息很可能在我的这个进程里面是没有的，比如说要访问一个订单的服务的时候，那么用户的信息，权限的信息，在这个进程里面，这个tomcat里面是拿不到的，我可能需要一个远程的调用。调用我的安全中心、认证中心去获取相关的这些信息。那么每一个请求，不管是外部进来，还是服务之间的都要去做安全的校验 。那么在做校验的时候，这个远程的链接导致的延迟可能会导致服务产生性能问题。尤其是对性能极端敏感的服务。可能原来我的服务本身几毫秒就响应了。我现在我要做远程调用来验证安全，又增加了几毫秒。增加的几毫秒对于性能极端的服务来说，他的响应时间就增加了一倍。这种时候，这种性能问题也是微服务面临的挑战。
服务之间的安全，原来的时候只需要考虑外部进来的请求是不是安全的，进来以后，从订单调物流，从订单调库存，这都是在我原来tomcat里面的，不需要考虑任何的安全的问题。
但是在微服务的场景下，当我从订单去调用物流的时候，实际上我是需要跨网络。出我的进程，进入另一个进程。这个时候我就要保证这个通讯是安全的。这也是微服务 面临的挑战
跨多个微服务的请求，难以追踪。对于一个服务可观测性，是一个很重要的指标。可观测性包含了三个 log日志、
分布式里面每一个进程会自己记录自己单独的日志，日志是分散来记的。订单自己记日志，库存自己记日志。这时候我就需要一个机制，把所有的日志都串起来。
把日志聚合起来。最典型的就是流量，控制整个服务的留空，而不是单一的控制某一个服务。
一个请求进入每个服务所花的时间
容器化不可变是一个很重要的原则
多语言架构，每个微服务可以用自己适合的语言去创建。
结束