一般初期公司需要面对非常复杂的业务场景，而且随着业务的发展，变化的可能性非常高。所以在微服务架构设计之初，我们就期望我们的微服务体系能：

• 不绑定到特定的框架、语言
• 服务最好是Restful风格
• 足够简单，容易落地，将来能扩展
• 和Docker相容性好

目前常见的微服务相关框架：

• Dubbo、DubboX
• Spring Cloud
• Motan
• Thrift、gRPC

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

它优点很多，例如：

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

不过遗憾的是：

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

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

优点是：

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

不过：

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

Apache Thrift、gRPC等虽然优秀，并不能算作微服务框架，自身并不包括服务发现等必要特性。

如果说微服务少不了Java，那么一定少不了Spring，如果说少不了Spring，那么微服务“官配”Spring Cloud当然是值得斟酌的选择。

优点：

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

不足：

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

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

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

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 Netflix提供了Eureka服务注册的集成支持，不过没选它是因为：

• 更适合纯Java平台的服务注册和发现
• 仍然需要其他分布式KV服务做后端，没解决我们的核心问题

Docker作为支撑平台的重要技术之一，Consul几乎也是我们的必选服务。因此我们觉得一事不烦二主，理所应当的Consul成为我们的服务注册中心。

Consul的优势：

• 使用Raft一致性算法，能保证分布式集群内各节点状态一致
• 提供服务注册、服务发现、服务状态检查
• 支持HTTP、DNS等协议
• 提供分布式一致性KV存储

也就是说，Consul可以一次性解决我们对服务注册发现、配置管理的需求，而且长期来看也更适合跟不同平台的系统，包括和Docker调度系统进行整合。

最初打算自己开发一个Consul和Spring Cloud整合的组件，不过幸运的是，我们做出这个决定的时候， spring-cloud-consul 刚刚发布了，我们可以拿来即用，这节约了很多的工作量。

因此借助Consul和 spring-cloud-consul ，我们实现了

• 服务注册，引用了 srping-cloud-consul 的项目可以自动注册服务，也可以通过HTTP接口手动注册，Docker容器也可以自动注册
• 服务健康状态检查，Consul可以自动维护健康的服务列表
• 异构系统可以直接通过Consul的HTTP接口拉取并监视服务列表，或者直接使用DNS解析服务
• 通过分布式一致性KV存储进行微服务的配置下发
• 为一些业务提供选主和分布式锁服务