基于SpringCloud的微服务实践

  微服务不同于单一架构应用, 是典型的分布式场景, 各服务之间通过IPC进行通信. 实现微服务的过程中, 我们需要解决以下问题:

• 服务注册和服务发现.
• 根据应用选择合适的通信协议和数据协议. 例如可以选用thrift, protocol buffer或REST.
• 服务负载均衡. 一个服务一般会部署多个实例. 如果使压力均匀分布是需要考虑的问题.
• 服务路由与限流.
• 容错处理. 相对于单机应用, 分布式环境下错误发生的概率会大大提高, 服务宕机, 网络不可用的情况时常发生.
• 服务监控. 各服务实例的性能指标, 例如请求响应时间, 请求并发数量, 以及服务实例的部署数量等.
• 事务一致性. 一般来说这个问题需要我们结合业务自己处理, 框架不会给我们太多帮助.

  好的微服务框架应该能帮助我们解决上面的全部或者大部分问题.目前常见的微服务相关框架：

• Dubbo、DubboX
• Spring Cloud(Netflix OSS)
• Finagle
• Motan
• Thrift、gRPC

 一、Dubbo优缺点：

   Dubbo几乎是唯一能被称作全栈微服务框架的“框架”，它包含了微服务所需的几乎所有内容，而DubboX作为它的增强，增加了REST支持。

  优点很多，例如：

• 全栈，服务治理的所有问题几乎都有现成答案
• 可靠，经过阿里实践检验的产品
• 实践多，社区有许多成功应用Dubbo的经验

不过遗憾的是：

• 已经停止维护
• 不利于裁剪使用
• “过于Java”，与其他语言相容性一般

二、Motan优缺点：

  Motan是微博平台微服务框架，承载了微博平台千亿次调用业务。优点是：

• 性能好，源自于微博对高并发和实时性的要求
• 模块化，结构简单，易于使用
• 与其他语言相容性好

不过：

• 为“短平快”业务而生，即业务简单，追求高性能高并发。

三、Apache Thrift、gRPC优缺点：

  Apache Thrift、gRPC等虽然优秀，并不能算作微服务框架，自身并不包括服务发现等必要特性。如果说微服务少不了Java，那么一定少不了Spring，如果说少不了Spring，那么微服务“官配”Spring Cloud当然是值得斟酌的选择。优点：

• “不做生产者，只做搬运工”
• 简单方便，几乎零配置
• 模块化，松散耦合，按需取用
• 社区背靠Spring大树

不足：

• 轻量并非全栈
• 没解决RPC的问题
• 实践案例少

根据我们的目标，我们最终选择了Spring Cloud作为我们的微服务框架，原因有4点：

1. 虽然Dubbo基础设施更加完善，但结构复杂，我们很难吃得下，容易出坑
2. 基于Apache Thrift、gRPC自研，投入产出比很差
3. 不想过早引入RPC以防滥用，Restful风格本身就是一种约束。

四、Finagle

  关于Finagle的使用请参见:http://skaka.me/blog/2016/03/19/finagle1/

五、Spring Cloud

    Spring Cloud是一个集成框架，将开源社区中的框架集成到Spring体系下，几个重要的家族项目：

• Spring-boot:一改Java应用程序运行难、部署难，甚至无需Web容器，只依赖JRE即可
• Spring-cloud-netflix:集成Netflix优秀的组件Eureka、Hystrix、Ribbon、Zuul，提供服务发现、限流、客户端负载均衡和API网关等特性支持;
• Spring-cloud-config:微服务配置管理
• Spring-cloud-consul:集成Consul支持

 关于Spring-cloud的使用请参见:http://blog.xujin.org/sc/sc-fx1/

 http://skaka.me/blog/categories/spring-cloud/