精选留言(4)

• 
  狼鱼

  2019-09-30

  如果采用SpringBoot+K8S的方式进行微服务部署，如果想实现服务的多版本控制有什么好方法吗？ 如果采用Spring Cloud 可使用 metadata 在加版本号，然后扩展ribbon的路由策略来实现。 基于K8S 除了使用Istio 还有其他方法吗？

  作者回复: Istio/ServiceMesh是K8s推荐的流量治理(或多版本控制)机制，这个机制的好处是可以做到应用无关，不足是运维门槛成本较高。
  
  其它方案可以考虑软件方式实现，一般采用功能开关或A/B测试技术实现，这个机制需要侵入代码，但是灵活性更高，参考项目：
  https://github.com/checkr/flagr
  https://github.com/markphelps/flipt
  https://github.com/intuit/wasabi

  

   1
• 
  stone

  2019-09-12

  滚动发布是什么流程呀。波波老师能不能简单说一下呢

  作者回复: k8s默认支持的就是滚动发布(rolling update)，假设你有一个svc v1版本已经发布到k8s，svc v1假设有10个pod实例，那么下次你发布svc的v2新版本，在deployment yml文件中只需修改镜像版本，然后kubectl apply这yml文件，k8s就会自动进行滚动发布，将v2的pod实例陆续拉入，v1的pod实例陆续拉出，例如，k8s会先拉入2个v2的pod实例，然后拉出2个v1的pod实例，间隔一段时间，再拉入2个v2的pod实例，然后拉出2个v1的pod实例，间隔一段时间，依次类推，一直到v2的pod实例全部拉入，v1的pod实例全部拉出，这就是滚动发布的过程，每次拉入拉出的数量(maxSurge)是可以配置的，具体可参考k8s文档:https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

  

   1
• 
  柳旭

  2019-09-09

  再升级，谁是金丝雀呢

  作者回复: 金丝雀是很好理解的，升级时候先上一台新版本去试水，这台新版本就是金丝雀，金丝雀没有问题，继续发全量新版本，同时下老版本；如果金丝雀有问题，则下金丝雀，取消升级。再升级还是这样做。
  
  金丝雀源于过去矿工下矿井前，为防止一氧化碳等中毒，先放一个金丝雀下去试，用在发布上也是这个道理，先上一台新版本去试。

  

   1
• 
  恰饭哒

  2019-12-17

  波波老师，这个怎么解决请求了一半的服务了，一个服务请求在路上，突然把来版本kill的问题

  作者回复: 蓝绿切换后，老版是继续留着一段时间，不是马上kill掉的，这样那些连着老版本的请求将继续得到处理，直到处理完毕，但是新的请求将不会再路由到老版本，而是都路由到新版本，所以蓝绿发布一般是安全的。

  

  