Spring Could 问题

作为流行的微服务框架，Spring Could实用但不完美，比如说它只针对Java语言，坚持REST协议做微服务间的通讯等。

Spring Cloud虽然集成了众多组件，可以构建一个完整的微服务应用，但是其中的各个组件却并非完美无缺，很多组件在实际应用中都存在诸多不足和缺陷。因此，需要我们对其中的一些组件进行替换和修改，方能构建一个强大、灵活、健壮的微服务架构应用。

配置中心

Spring Cloud Config可以说是Spring Cloud家族中实现最Low的一个组件，直接采用了本地存储/SVN/Git的方式进行存储。同时，Spring Cloud Config也缺乏一个完整的可视化管理查询后台，当存在比较复杂的权限管理和版本管理需求时，Spring Cloud Config会显得非常力不从心。如果需要在配置修改后，能自动进行配置信息推送的话，使用Spring Cloud Config也无法满足要求，需要自行编写代码进行实现。

目前开源社区中，已经有了很多的开源配置中心实现方案，同时很多公司也自研了自己的配置中心方案。包括淘宝的统一配置中心Diamond（已经多年未更新）、百度的分布式配置管理平台Disconf、携程的开源分布式配置中心Apollo、360的分布式配置管理工具QConf等等。

注册中心

作为Spring Cloud的服务注册中心，从分布式CAP理论来看，Eureka采用是AP型设计，强调的是注册中心的高可用性。和Dubbo常用的服务注册中心ZooKeeper相比，ZooKeeper则是采用的CP型设计，强调的是注册中心数据的一致性。

Eureka的设计确实简单易用，但是默认没有实现对注册中心数据的持久化。同时，在极端场景下，也会出现多个Eureka注册中心节点数据不一致，甚至服务注册数据丢失的情况。当然，从分布式CAP理论来看，理论上是没办法做到同时兼顾CAP三点的。目前也有一些互联网公司对Eureka进行了改造，支持了数据的持久化，但是尚不能完整的支持CAP的全部要求。

API网关

API网关可以说是微服务需求最多，也是最有难点的一个组件。Spring Cloud中集成的Zuul应该说更多的是实现了服务的路由功能，对于负载均衡等其他功能，需要结合Ribbon等组件来实现。对于很多个性化的需求，需要开发者自己来进行编码实现。

和大部分基于Java的Web应用类似，Zuul也采用了Servlet架构，因此Zuul处理每个请求的方式是针对每个请求是用一个线程来处理。同时，由于Zuul是基于JVM的实现，因此性能也会在高并发访问场景下成为瓶颈。虽然网上一些文章评测Zuul和Nginx性能接近，但是在性能要求较高的场景下，JVM的内存管理和垃圾回收问题，仍然是一个很大的问题。所以在实际的应用场景中，通常会采用在多个Zuul几点前面再添加一层Nginx或者OpenResty来进行代理。

为了解决Zuul的性能问题，Netflix将自己的网关服务Zuul进行了升级，新的Zuul 2将HTTP请求的处理方式从同步变成了异步，并且新增诸如HTTP/2、websocket等功能。但是遗憾的是，开源版本的Zuul 2一直处于难产状态中，始终没有和大家正式见面。

熔断器

微服务中对于服务的限流、降级、熔断的需求是多种多样的，需要在API网关和各个具体服务接口中分别进行控制，才能满足复杂场景下微服务架构的应用需求。

单独使用Spring Cloud中的Hystrix无法完整的满足上述的复杂需求，需要结合API网关，并通过Kubernetes对资源、进程和命名空间来提供隔离，并通过部分自定义编码方能实现对全部服务的限流、降级、熔断等需求。

监控系统

无论是Spring Cloud中集成的Spring Cloud Sleuth，还是集成经典的ELK，都只是对日志级别的追踪和监控。在大中型微服务应用架构中，尤其是基于JVM的项目，还需要添加APM的监控机制，才能保证及时发现各种潜在的性能问题。

APM整体上主要完成3点功能：1.日志追踪、2.监控报警、3.性能统计。目前，国内外商业版本的APM方案已经有很多，开源版本的APM方案也开始丰富起来。国内开源的APM方案主要有：大众点评的CAT和Apache孵化中的SkyWalking。这里给大家重点推荐下SkyWalking，SkyWalking是针对分布式系统的应用性能监控系统，特别针对微服务、Cloud Native和容器化（Docker、Kubernetes、Mesos）架构，项目的关注度和发展速度都很快，中文文档资料也比较齐全。

浅谈服务治理、微服务与Service Mesh（二）： Spring Cloud从入门到精通到放弃