本文基于SpringBoot1.5.7和SpirngCloudDalston.SR5。下面我来逐层介绍一下这个架构图：1.是web服务器的选择。我选择的是nginx+keepalived，haproxy也是一个选项，但是haproxy在反向代理处理跨域访问的时候有很多问题。因此，我们在nginx的某些部分实现了keep-alive模式处理，减少三次握手次数，提高连接效率。keepalived作为nginx的负载，对外虚拟出一个vip，两台nginx做高可用，nginx本身反向代理zuul集群。2、API网关，这里的zuul被很多人诟病，说速度慢，建议直接使用nginx。这里我还是推荐使用zuul。毕竟zuul包含了拦截器和反向代理。在权限管理、单点登录、用户认证方面还是很有用的，zuul自带ribbon负载均衡。如果直接使用nginx，需要单独做一个feign或者ribbon层作为业务集群的负载层。毕竟直接把接口暴露给web服务器太危险了。这里zuul有ribbon负载均衡和hystrix断路器，直接反向代理serviceId可以代理整个集群。3.业务集群。我的一些项目在这一层上分为两层，就是在上面加了一个load层，底层从service开始。底层只是一个简单的接口。controller是feign实现的一个单独的层，内部结构不一样。业务服务接口互调和直接调用controller层只能说效果一般，多了一个tcp连接。所以我推荐合并，因为做过springcloud项目的都知道feign中包含ribbon，zuul也包含ribbon。这样zuul调用服务集群，服务集群之间的接口互调高可用。保证通信稳定性。Hystrix还是需要的。没有断路器很难实现服务降级，大量的请求会被发送到不可用的节点。当然，服务是可以转型的。如果转化为rpc方法，那么服务之间的相互调整又是另外一种情况。那么必须做成负载池和接口服务池。负载池调用接口池，接口池之间通过rpc相互调用，feignclient只是通过实现接口实现了模仿rpc的形式，但是速度表现还是不错的。4、redis缓存池用于session共享，分布式系统中session共享是个大问题。同时，redis作为二级缓存，对于降低整个服务的响应时间，减少数据库访问次数，有很大的帮助。当然是rediscluster还是redissentinel自己选择。5.eurake注册中心的高可用集群有很多细节，比如多久刷新一次列表，多久监听一次心跳等等，非常重要。6.springadmin，这个很推荐，这个功能很强大，可以集成涡轮断路器监控，并且可以定义所有类的日志级别，不用单独配置，也可以查看本地log日志文件进行监控不同服务的机器参数和性能都非常强大。再加上elk动态日志采集系统，非常方便项目运维。7.zipkin，这个有两种方式，直接使用自带的函数接口查看，或者使用elk动态日志系统的stream方式收集。但是不得不说，这对系统性能的损害很大，因为链接跟踪会造成响应等待，而且等待时间很长，接近1秒，在生产环境下是无法忍受的，所以最好关闭生产环境。关掉，调试有问题再打开。8.消息队列是必须的。分布式系统不可能在所有场景下都满足强一致性。在这里，消息队列只能作为缓冲区使用。这里我用的是卡夫卡。9、分布式的东西，我觉得这是分布式最难的地方，因为不同的业务集群对应自己的数据库，相互的数据库是不能互操作的，相互的服务调用只能是相互的接口，有的甚至是在不同的地方。结果是网络延迟导致请求等待，网络抖动导致数据丢失。这些都是很可怕的问题，所以必须处理分布式的东西。我推荐的是使用消息队列，采用两阶段提交协议配合事务补偿机制。具体实现需要结合业务，这里限于篇幅不再赘述。10、config配置中心非常有必要，因为服务太多，配置文件太多，没有这个很难运维。这个一般使用消息队列创建一个springcloudbus，通过git存储配置文件，使用bus总线动态更新配置文件信息。11.实时分布式日志系统。Logstash收集本地日志文件流并将它们传输到elasticsearch。Logstash有两种方法。1、每台机器启动一个logstash服务，读取本地的日志文件，生成并传输给elasticsearch。2、logback引入了logstash包，然后直接产生json传输到一个中央logstash服务器，再传给elasticsearch。Elasticsearch再传给kibana，动态查看日志，甚至zipkin流也可以直接传给elasticsearch。有了springadmin，可以查看动态日志，可以查看本地日志，还可以远程管理不同类型的日志级别，对集成和运维非常有利。最后想说的是springcloud里面很多东西还是比较准确的，比如断路器触发时间，事务补偿时间，http响应时间等等，这些都需要好好设计，有很多点可以进行优化。比如：http通信可以使用okhttp，jvm优化，nio模式，数据连接池等，可以大大提高性能。还有一个docker问题。很多人说没有docker就不算微服务。其实在我个人看来，springcloud本身就是一个微服务，只需要一个jdk环境即可。写一个dockerfile无非就是集成jdk，添加jar包，执行jar，或者使用docker-compose将不同服务的多个镜像组合到容器中。但是也存在很多问题，比如通信问题、服务器性能损失、容器进程崩溃等。当然，如果你有一个成熟的基于k8s的容器管理平台，这是没有问题的。如果不可能，则必须考虑。而springcloud本身就是一个微服务分布式架构，所以个人比较推荐直接机器部署。当然，好的DevOps工具会方便很多。作者github地址：https://github.com/cyc3552637简介面试过程中，面试官喜欢问组件的实现原理，尤其是常用技术。我们平时使用SpringCloud，需要了解它的实现原理，它不仅起到举一反三的作用，它还可以帮助轻松处理各种问题并有针对性地进行扩展。以下是《Java深入微服务原理改造房产销售平台》课程中提到的一些原理图，现免费向大家开放，让大家轻松应对原理性面试题。服务注册发现组件Eureka工作原理服务网关组件Zuul工作原理跨域时序图Eureka与Ribbon集成工作原理解决分布式一致性级联故障处理断路器组件Hystrix工作原理分布式TracingSleuth工作原理SpringBoot自动配置工作原理
