关于Spring cloud的一些思考

写在开头的一些话

随着分布式架构理念的推广，微服务越来越得到传统企业及互联网行业的青睐，而Spring Cloud由于得到了Spring社区及Netflix的成功经验，正逐步成为了微服务架构下的首选，然而我最近却越来越感觉到Spring Cloud的臃肿及不方便性，以下是本人的一些感想，由于知识面有限的原因，如果有不对之处，属于正常，不喜勿喷

Round 1：全家桶的方式

Spring Cloud的全家桶方式其实在我感觉就是违背了微服务的设计理念，微服务提倡的是小而美的架构，然而Spring Cloud由于依赖了Netflix及Spring社区，依赖是非常之多，有可能用不到但是还是给你依赖进来，这种方式让人在包管理上要花费数倍的时间去解决有可能产生的冲突问题

Round 2：API契约，外部API和内部API无法从技术手段上区分

对于Spring Cloud来说，restful api是SC的基础，不可否认restful是一个良好的契约方式，restful api作为前端和后端的交互契约进而演化为所有大后端的服务调用的契约，所带来的不可约束性太强了，对于一个开发人员来说，他其实在开发时，并不知道我的api是用在最外端的设备端或者PC端调用，最终导致的是，对于许多开发人员来说，面向外部的API和面向内部的API需要有强有力的文档来说明，而最终导致的问题就是开发人员分不清楚这是一个服务化的API还是一个面向外部用户的API

Round 3：Feign客户端调用方式

Feign作为Spring Cloud的Http客户端，Spring Cloud在为了兼容Spring MVC做了很多的工作，看看Feign的定义方式：

 @RequestMapping(value = "/registed", method = RequestMethod.GET)
  public ExchangeVo create(@RequestBody ExchangeVo exchangeVo);

如果使用了RequestBody这样的对象传输方式，Feign是把Get请求强制变为Post请求，估计有的人会喷说，用了这种应该要变成Post，然而我问一个场景，如果一个查询，而查询参数的确是有很多，10多个，这种按照restful的定义是获取资源的，你变成Post不是违背了restful的设计原则么？再有：

希望Feign能够支持参数请求使用POJO的Issue：https://github.com/spring-cloud/spring-cloud-netflix/issues/1253
建议使用Feign原生的注解的Issue：https://github.com/spring-cloud/spring-cloud-netflix/issues/659
建议增强Feign的功能：https://github.com/spring-cloud/spring-cloud-netflix/issues/1360
建议支持可选的Request Body（目前Feign当POST一个null时，会报异常）：https://github.com/spring-cloud/spring-cloud-netflix/issues/1047

Round 3：服务粒度

对于Spring Cloud来说应用作为服务粒度，这种粒度我个人认为太过于粗犷，服务的API无法通过注册中心来获取，而如果要做API的监控，必须要依赖于具体的服务

Round 4：服务提供者上线及时感知

对于Spring Cloud来说，从注册中心拉去服务列表后缓存并推送给Ribbon是作为软负载均衡的前提，这个对于euraka，consul来说也是不得不这样做的，但是带来的问题将是如果有一个提供者实例上线后，并不能马上让服务消费者及时感知，并马上能够进入软负载均衡的列表

Round 5：没有一个官方的Admin OPS管理平台

没有Admin OPS平台的话，让开发人员没有办法OverView一个全局的大概的服务健康状况

Round 5：性能低劣的网关

基于Servlet规范的Zuul性能提升都外包给了Web容器，而这种Web容器并不是为转发请求服务而存在的（Servlet规范在2.0版本是数据传输是同步阻塞的），而Zuul2.0一而再再而三的Delay情况下把业界的耐心给消耗光了，而Spring Cloud也开发了自己的Gateway，然而前提是Spring Boot2.0，JDK1.8以上，并不算一个成熟可以上线的产品

Round 6：Http Restful低劣性能

基于Http文本的方式比不上二进制传输这点大家都知道，而Http短链接和基于网络的长连接相比，性能也是没办法比较，对于真正用户端和服务端来说，网络抖动没办法避免，但是对于内部服务之间的调用来说，同一个IDC下，长连接是最佳选择

总结

以上是一些个人在使用Spring Cloud的感触及感想，从个人角度来说，如果公司规模是小团队，Spring Cloud是一个很好的选择，然后当达到这种中等规模来说，Spring Cloud并不是一个很好的选择，团队的复杂性所带来的人员的沟通的成本是无法估量的，而通过技术手段来解决是一个最好的选择