Eureka服务启动注册的等待时间比较久，注销服务也需要等待，这是最终一致性。导致服务已经下线了，但是服务中心里还有，这时如果接到请求就会出现报错的情况。

Netflix OSS- Ribbon

Ribbon基于客户端的负载。传统的负载分为很多种，比如服务端的负载、客户端的负载、在host上统一的喷发等等。而基于客户端的负载好处就是分部，但本地的服务注册必须要和远程保持同步的状态。

Ribbon还提供了动态路由。有些用过其它框架的用户会质疑，Netflix默认提供的路由rule里，为什么不提供基于权重的路由方式呢？由于每个团队的开发背景不同，Netflix的服务基本上都附属在亚马逊云上，所以对于很多云端的服务强调无状态，在无状态的情况下基于权重的路由方式就没有什么意义了。

基于meta/tag可以使用Ribbon对server instance进行过滤，然后再选择。

Feign是在Ribbon的基础上对HTTP的增强。

Feign有一个默认的重试次数设置。错误重试一次，第一次等待100毫秒重试，最大等待1秒重试。

还有一个超时设置。超时设置分为链接超时和读超时，可以在代码里设置。它默认的connectTimeout为10秒，readTimeout为60秒，默认的retry为4次。外部nginx的proxy_connect/read_timeout设置要大于Feign的配置，才能起到fallback的效果。

Hystrix是由Netflix提出的对业界很重要的一个概念。

如果使用rest分隔进行微服务开发的话，对于Hystrix来说是服务调用失败的，这时就必须要标注Hystrixbadrequest，不然它会把这些异常计算在内，导致整个接口服务的熔断。

Hystrix还能通过线程组达到隔离的效果。

Zuul的提出在当时是为了适配不同的协议格式，给移动端或PC端带来统一的入口。Gateway是有些类似微服务的概念。

作为网关，它可以添加或修改请求参数、header，修改响应body，通过zuul对动态路由进行操作。zuul负责网关层面的统一安全校验，虽然在每个微服务里做了数据权限，但是登录权限还是在网关层做的。而服务聚合如果在网关层做会导致业务逻辑紧密耦合，需要找其它更好的方案去做。

SpringCloud要有动态推送能力，否则手工做refresh太麻烦。

Yaml配置容易因为忽略重复key而出错，需要一个更加友好的工具，进行编辑、校验。

要有更丰富的格式在config的配置，比如json。

集成报警的好处就是在持续集成的时候直观地了解到服务部署的情况并传达出来。

非关键的服务或设备都可以跑在docker上。

1. 基准代码：一份基准代码，多份部署。

2. 依赖：显式声明依赖关系。

3. 配置：在环境中储存配置。

4. 后端服务：把后端服务当作附加资源。

5. 构建，发布，运行：严格区分构建和运行。

6. 进程：将应用程序作为一个或多个无状态进程运行应用。

7. 端口绑定：通过端口绑定提供服务。

8. 并发：通过进程模型进行扩展。

9. 易处理：快速启动和优雅终止可最大化健壮性。

10. 开发环境与线上环境等价：尽可能的保持开发，预发布，线上环境相同。

11. 日志：把日志当作事件流。

12. 管理进程：后台管理任务当作一次性进程运行。

因为我们相信google的能力，所以我们选择了Kubernetes。Kubernetes有自己的master，可以在master下面的每个node里跑docker。

通过虚拟的ClusterIP地址、虚拟端口号，动态负载分发到后端pod。

SpringCloud和k8s有很多功能是重复的，k8s没有熔断功能，也可以通过附加的组件把它加进去。

Codereview是一个非常必要的过程，避免代码腐化。

自动化测试可以大大提高和保证质量。

对于线上来说，每隔几分钟就跑一下服务，以保证线上服务正常。

蓝绿部署和docker紧密结合。在云端空间足够的情况下，可以利用docker容器进行大规模部署。部署一个green并检查，然后生产流量指向进行canary测试，完成后再把流量导过来。

如果服务有bug，还可以趁blue没有销毁，把负载指向blue，尽量避免部署失败。

通过 Eureka实现服务的下线和上线。

整个部署自动化，通过参数控制，保证rolling update服务尽可能是无损的。

我今天的分享就到这里，感谢聆听！