引言
本文承接上文《大话微服务中的边车模式》
写在前面的话：关于服务网格，现在市面上主流的产品是Istio，但是如果这篇文章去讲Istio的搭建与使用、这篇文章会显得又臭又长、因此本文只能侃侃服务网格出现的原因，优缺点等。因此，这篇文章是一篇口水文!
正文
(书接上回)
过了几天，小刘又来找我了！只见小刘说道:"能不能给所有的微服务都搭一个边车(SideCar)，然后用一个平台将边车(SideCar)管理起来，像下面这样"
烟哥回答道：“可以的！这就是去年年初被炒的火热的服务网格(ServiceMesh)模式！传说中这可是很牛逼的 第二代微服务架构啊！”
烟哥嘴角微微一笑，说道:“这么说吧，前几天你把原有的项目进行改造成微服务架构，引入
Spring Cloud的相关组件，这种架构就是
第一代微服务架构！”
"对了，小刘啊，你在改造过程中，有没有遇到什么问题呢？"
小刘想了想，说道:"唉！最明显的一个缺点就是学习成本太大了！你看啊，有
Eureka、
Zuul、
Hystrix..等等一堆的组件需要学习，我光学习这些组件就花了好长时间！而且这还不算，学了这么长时间后，还只能达到
Demo级别！我还去网上搜了一下
Spring Cloud的系列博客，基本都是
Demo级别的文章，真正生产上肯定还有很多问题的！"
说到这里，小刘停了停，继续说道"对了，烟哥，你知道么，Eureka的2.X版本闭源了，以后要接其他注册中心，还要改配置！麻烦！也不懂以后怎么办！唉！"
"嗯嗯，小刘，除此之外还有呢？"
小刘说道:"要非说还有什么缺点，就是不支持跨语言！还有就是如果将来业务发展碰到一些需要的功能，而这些功能恰巧又是Spring Cloud没提供的，那就凉凉了，要自己去二次封装！除此之外，我还真想不到其他的了！"
" 第一代微服务架构的痛点你说的差不多了，其实总结起来，只有三个字———— 难落地！真正要把微服务的每个组件吃透了，这个学习成本很大的！像有些公司，请了一堆人来培训，最后也是徒增开销！"
"小刘，你想啊，我们开发其实关注业务就好啦！关注这么多微服务层级的功能作甚？能不能做出一个通用的平台，包含这些微服务的功能，然后呢我们只要开发业务应用，接入这个平台就行了？OK，这个就是服务网格(Service Mesh)!"
小刘:"烟哥，我懂了！其实用上Service Mesh后，很多功能移到Service Mesh中,而Service Mesh是归运维管的，说到底就是为了职责分明！让开发专注于开发，让运维专注于运维!可是，这和边车(SideCar)模式的区别，你可以详细说说么?"
“主要区别是两个。一个是Service Mesh是由很多边车(SideCar)形成的网络！另一个是，其实边车(SideCar)模式下，并不一定要求所有的服务都要连接边车(SideCar),而在ServiceMesh中，明确要求由ServiceMesh掌管整个网络的流量，因此所有的服务都要连接边车(SideCar)。”
小刘:"听起来好像很不错，哈哈哈，没准未来就不是Spring Cloud的天下，改名叫Spring On ServiceMesh,只要Spring Boot+ServiceMesh就行！"
烟哥:"嗯，说是这样说！但是现在落地的公司还是很少！毕竟你所有的应用，都由ServiceMesh来掌管和监控，这确实降低了开发的负担，但是对运维的要求非常高！必须能够保证ServiceMesh的高可用，以及一系列的监控手段都需要落地。目前国内大部分公司都不具备这样的运维团队，有些公司甚至都没有运维，开发既当爹又当妈！所以再等等，像蚂蚁金服他们就在试行ServiceMesh，看看大厂的采坑经验，我们静观其变吧！"