微服务框架需要什么

微服务架构本质是分布式系统架构，选型需要考虑CAP原则，具体需要考虑实现服务注册发现、配置中心、负载均衡、熔断、限流、降级、服务监控等功能。

CAP原则指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。 具体选型基本以Spring Cloud为主，现在Alibaba版的Cloud也发布了，估计离生产采用还有一段距离，另外华为开源的ServiceComb已经在Apache毕业，简单试用了下，上手容易，感觉集成的还可以。

服务注册中心

Zookeeper

作为服务注册中心的公司在减少，目前Kafka还依赖zk。

Eureka

Cloud体系的一个 AP 的应用，而且它是去中心化的。但是它有几点不足：

• 在阿里内部的性能测试中，它性能表现非常一般，性能大概只有 Zookeeper 的 60% 左右。
• Eureka 内有一种契约机制，它每隔 30 秒会发起一个续约的请求，如果 3 次没有接收到，它才会过期失效；如果一个服务非正常退出（没有发起解约请求），那么就存在这个超时的间隙期，服务是不可用的。所以在生产环境，对服务敏感的相关应用方是无法满足需求的。
• Netflix 宣布了停止更新 Eureka 2.0。

  Etcd

  Etcd是 Zookeeper 的升级版，它参考了 Zookeeper 的很多实现，同时进行了较多优化。Etcd 的强一致性协议和代码实现更加简单，它的部署方式也更加简单，它支持了 Rest 的方式进行相关访问，它的性能相对 Zookeeper 来说也有了一定的提升。但是它还是一个 CP 的系统，它也是要求数据的强一致性，而牺牲部分的可用性。 ServiceComb的Service Center是基于Etcd实现的。

  Consul[推荐]

  相对前面几个产品来说，Consul更加专注服务注册发现本身，它是一个比较专业的服务注册中心。Consul 有了后台管理页面，它有了健康检查，Consul 原生支持多数据中心。但它的性能上有瓶颈的，它和 Zookeeper 和 ETCD 进行对比，它性能是稍微差一点的；同时 Consul 也要求数据的强一致性而牺牲部分可用性。

  Nacos[推荐]

  是阿里巴巴开源的一个产品，内部系统也在使用，它已经经受了一定流量和用户的考验。现在阿里巴巴集团内部的 Provider 和 Consumer 数量已经到达了亿的级别，它现在能够支撑上亿级别的订阅量，整体经受了一定的实践检验。Nacos 整体设计是去中心化的，而且设计上满足 AP 和最终一致性，性能上和 Zookeeper 比较接近。 Nacos还实现了动态配置功能，依赖MySQL。

服务治理

服务治理包括熔断、限流等
Cloud体系的Hystrix 停更了，在 GitHub 上推荐了 Resillence4j，阿里巴巴也开源了 Sentinel。这里进行一个简单的比较。

Hystrix 的两块功能，隔离和熔断，能满足大部分需求但是停止更新了。 Resillence4j 要求 JDK8 及以上，对 function 编程更加友好。

Sentinel[推荐]

支持流量控制、熔断降级、系统负载保护等功能，在阿里内部使用的范围非常广，已经经受住了一定的考验。每年双十一在买东西的时候，如果出现一个页面上显示系统繁忙请稍候重试，或者显示人太多了请排队，这时候其实就是 Sentinel 在后台发挥作用了。Sentinel OPS 这块做得非常好，达到了开箱即用的标准。

配置中心

Apollo 国内用户比较多，依赖MySQL。 Nacos 前文提到了。

负载均衡

图片处理 thumbor

可以与分布式对象存储minio结合搭建图片服务

云原生基础设施

目前在研究kubesphere，比rancher更贴近应用。

To be continued..