引言
本文承接上文《大话微服务中的边车模式》
写在前面的话:关于服务网格,现在市面上主流的产品是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
,看看大厂的采坑经验,我们静观其变吧!"