Service Mesh
之前从国外的一篇博客上了解到了ServiceMesh，觉得很感兴趣，感觉它是完全就是为分布式量身定做的以后肯定会大火，不管以后能不能进入运用ServiceMesh思想的公司，先了解是不错的，果不其然，阿里系首先就来了个dubbo mesh和sofa mesh，我参加阿里的dubbo meeting up时，宣布发布了dubbo mesh。以下内容做个这段时间的学习记录。
Service mesh 我理解其实不是新技术是一个新技术理念。
看了很多相关的文章也看了某些案例，准备动手实践一下。很多service mesh的文章和案例通常都会提到两个单词，data-plane和control-plane，即数据面板和控制面板。
顾名思义，我理解数据面主要是负责服务间通信传递信息的相关操作，比如负载均衡、服务发现、心跳检测、路由、监控等等，但是你会发现，如果只有数据面板其实是没用的，因为数据面板功能再多但是它是死的，他就像一台计算机，软硬件都配好了就算你跟他通上电，插好网线他也不能工作，因为它不知道他要做什么和怎么做。
而控制面板恰好就是做这个事的，它告诉控制面板应该做什么怎么做，比如服务间通信的规范、路由的地址以及路由的规则、监控的指标、限流、熔断的机制是什么配置是什么？控制面板才能真正让数据面板变成一套可运行的系统。
其实通过很多案例知道，很多大中型的公司特别是互联网公司，他们很早以前就有了自己的数据面板可能叫代理更合适，因为那时候还没流行service mesh的概念，他们也有控制面板（可能那时候更明确的叫法是库或者配置中心）。所以service mesh只是概念新，但应用应该很早就有了，只是现在的提出的service mesh应该更激进一些，直接把数据面板和控制面板剥离出来作为基础设施，脱离业务。
由于近年云原生、容器、微服务等概念的火热，微服务的落地案例越来越多，带来技术革新的同时也带来了烦恼。即微服务的运维（服务治理、路由策略、性能监控等）复杂度，不管是云原生还是容器都旨在让微服务能更快速更高效的部署，但是服务部署后是需要运行的，这么多服务之间的运行的有效性谁来保证，当然在云原生等概念火热之前，很多公司都有自己的微服务架构，服务之间运维也都有自己的一套。但是很多方案基本上都是把对服务运维的管理的代码或者说库耦合在业务代码里的，比如zk的使用，就是耦合在业务代码中的，而且很多时候是每种编程语言都需要开发一套代码来支持。这就让运维变得越来越繁琐，Dev和Ops耦合程度会越来越高。
现在的Istio、linkerd、sofa mesh等其实就为了解决上面说到的痛点。那怎么解决呢，就是把属于基础设施的组件，属于ops的工作从业务中剥离出来。在业务服务的身边跟他派一个书童，这个书童就是service mesh的应用。书童存在的价值是什么？就是让他的少爷能专心的读书，除了读书其它事情一概不用管。我理解这就是service mesh真正的价值。
关键词解释
云原生（cloud native）
我理解的是什么都在云上做，存储、交付、部署、测试等等，最大的特点就是快。
源引：
本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。