一起养成写作习惯！这是我参与「掘金日新计划·4月更文挑战」的第18天，点击查看活动详情。
微服务的风刮了几年，一批人通过这个当上了架构师，晋升成功，写了无数本书。时至今日，市场上确实需要一些新的概念了，炒冷饭老板不想听，观众也不买账。所以Service Mesh的风又开始刮了。这东西不像DDD那样给你画那么大一张饼，而是专注服务的调用给了一个可行的解决方案。其实不是什么新鲜事，但包装一下确实能养活很多人，何乐而不为呢？
概念
首先Service Mesh的核心思路是一个叫sidecar的东西，国内一般的翻译是边车模式，就是在服务的边上再安装一个小的agent，负责服务间的调用。配合着图是相对好理解的，这个小的agent负责了业务无关的序列化与反序列化，网络连接等等功能。为啥要取这个名字呢？sidecar其实是这个东西：
北方人叫这个大胯子，其实边车就是摩托车旁边的车斗子，但自身没有驱动能力，靠摩托车的发动机带动。老外起名字也没那么强嘛。
首先，太阳底下没有新鲜事。这种服务间的代理技术早就有了，很多云服务和厂子自己维护的数据库连接地址一般是一个代理，这么做是为了语言/框架无关。以较小的性能损失，抽象出一个小的代理层，方便跨语言的服务端调用，甚至有些中间件的升级也可以做到业务无感。可如果就对外提供rest api好像也没这些问题，但大厂内部的监控和跨语言服务调用还是很多的，大厂确实还是有点用的。
实践
这不是一个比较抽象空洞的概念，因为有很多前辈的经验了，所以实践落地起来比较容易。比较有名的一个是Istio，提出了数据平面和控制平面的概念。
每次请求都会去过一遍控制层，其实并没有必要。控制层只负责主动推送新的策略即可，让数据层完全独立调用性能会好很多。
