技术分享之service mesh (k8s&istio)的那些事儿

http://xiaorui.cc/archives/6051

 

kubernetes是否靠谱？ 中小团队，尤其是小团队是否可以hold的住？

个人认为kubernetes在实践中最难的是网络和存储。网络cni推荐大家使用calico，因为calico对比flannel有更好的想能，另外也完美支持bgp路由协议。如果想更加的易用，可以选择基于overlay的flannel插件。至于存储？ 不推荐… 意思是说，推荐大家把一些有状态的服务，比如postgres、mysql、elasticsearch，放在k8s的pod之外。为啥？ 我问了一圈在各公司搞云平台开发的，他们k8s每次出问题，大概率都是因为存储。  这个很考验基础架构团队的能力。

Istio是否靠谱？

当然，没问题了。不少国外，国内也有不少公司在用了。istio是基于k8s平台做的一层mesh的封装，就算出现了不可控和未知的问题，我们可以把istio的策略都删掉，让pod走原始的k8s service的逻辑。

如何更好的上手kubernetes、istio ？

首先是把官方的文档简略的看一遍，再把组件的原理看一遍。这个实现原理是不能忽视的，不然在实践k8s/istio遇到问题就抓瞎。在了解原理的基础上，可以适当的看他的关键代码实现，像istio的源码还是相对好理解的。

如何减少业务代码嫁接微服务架构的成本?

像我们先前的架构比较复杂，大部分是通过grpc balancer来直接连接的，但还是有部分系统是基于golang nats mq消息总线，主要是使用nats的request/reply的同步语义来实现异步的发布订阅。如果直接把总线改成grpc的方式，代码量其实不小。没有采用grpc直连而总线模式的服务有20来个，怎么用最小的代码来实现？

利用grpc的各种特性来实现的完美兼容，关键词是 grpc.unknownHandler, grpc reflection，静态protobuf描述符。