service mesh和istio (1)

Service mesh

Service mesh是一个软件工程的概念。我们知道软件工程许多概念不是必须的（not essential） ，它们的提出都是为了工程上减少开发费用，减少运维费用。很多是一个Art，而不是Science。没有这些，基本程序也还是运行的很好。它们很多有很多高大上的名字，这样才好唬人。

Service mesh也是这样，其实质是为了帮助application developer，把一些通信，RPC的功能offload解耦到专属的软件。我们在写application的时候，经常要调用一些infrastructure library。现在这些infra的部分被抽象出来，单独跑一个进程。业务进程还是要和这个进程通信，仍然是要调用一些API函数。

那Service mesh解决了什么痛点呢？主要是屏蔽了和其它服务之间的交互，而且主要是处理复杂情况，比如重试，服务发现，断路等等。打个比方，service mesh proxy就像一个秘书/assistant，他会替你找人，打电话办事，这中间的繁琐工作他都做了。而且他还能从中间做手脚，比如偷偷把服务版本给换了（好比把服务交给关系户了）。这对DevOps的测试很有用。

对相对简单的部署，没有必要引入Service mesh。这样反而会增加系统的复杂度。就像家里的事，一般没有必要引入秘书，管家这种职位，还要管理他们。但是如果家大业大，一个秘书就是必要的了。

Istio是service mesh理念的著名实现。由于和Kubernetes绑在一起，如虎添翼。

istio[1]

“Istio helps decouple operations of a cluster from the application developer” – Eric Brewer, VP infrastructure, Google
Istio把集群的运行从应用开发者那里解耦出来了。

这个和DevOps的趋势有关，原来应用开发人员要编写软件，用程序来定义程序的Behavior, 然后declare比如timeout值。慢慢的Dev和Ops界限模糊化之后，平台提供一组通用的行为，很多行为可以通过一个Policy被定义出来。比如如何处理fault，circuit breaker的定义等。

平台化的好处是一旦它被接受后，就像UNIX一样，大家都知道如何使用。

istio的独特性在那个sidecar的proxy,called Envoy(使者)，proxy与service的容器共同部署在一个K8S pod里面。因为是数据面的，Envoy是由C++实现的。它offload了service之间的RPC通信（彼此交互），服务发现（与pilot交互），安全（与citadel交互），以及policy检查和telemetry功能（与mixer交互）
load balancing, retry功能等等。

pilot还提供了control plane的配置和管理功能。

Ref:
[1] What is istio? link