jmjoy
个人博客
微服务治理生态的个人总结
此文有时间局限性,仅属个人观点

微服务治理是一个老生常谈的架构问题,正如任何的解决方案,解决了以往的一部分问题,却带来了新的问题和挑战。关于微服务解决了什么问题,和带来了什么挑战,可以看看这篇文章: 微服务架构体系的深度治理 ,我觉得这篇文章对于接触微服务较少的人来说可能有点难读懂,读了前半部分的发展历史就好。

为了应对微服务所带来的问题,就引入了一系列的解决办法,统一称为微服务治理,关于微服务治理的一些方法和生态,可以参考:当我们在说微服务治理的时候究竟在说什么

但是如果通读上面的这篇文章,你就会发现大部分都是说的Java的甚至只限于Spring cloud的生态的东西,那其它语言呢,基本上就没有Java那么好的生态了,就连国内很流行的PHP一样如此。为了解决微服务治理和语言甚至框架组件强耦合的问题,就诞生了Service Mesh

由于Service Mesh是一个很新的概念,虽然网上很多文章都有说的,但是并没有一个统一的观点。其实架构本质就是为了解决问题的,只有知道Service Mesh是解决了什么问题,才能更好地去理解它。事实上Service Mesh是一种无侵入的语言无关的微服务治理方案,对标的是Spring cloud为代表的侵入式强语言相关的方案,而手段上也大同小异,也是配置中心、服务发现、熔断等等技术。这是一篇不错的关于Service Mesh发展史的文章:解读 2017 之 Service Mesh:群雄逐鹿烽烟起

对于微服务治理的各种手段,配置中心、日志平台、链路跟踪几乎是每家有一定规模的互联网公司的标配,而像服务发现、熔断、限流等,非Java系的公司不一定会有。更大型的公司往往会有一个微服务治理的平台,将这种多种手段汇总起来,形成一个可视化的交互良好的平台,极大地提高了微服务治理的效率,可惜这种平台一般都是大公司当成宝贝的存在,一般不会开源出来。

关于微服务治理,我有几点想法:

  1. 交互良好易用的界面很重要,比如配置中心,目前国内比较热门的有Apollo,但是我觉得Apollo使用MySQL作为存储和HTTP协议提供配置明显不是好的选择,而etcd就合理多了,使用了分布性一致性的raft协议,v3的api是使用grpc的,支持watch和心跳功能,这是配置中心很重要的两点,而且etcd还有ttl,一样胜任服务发现的场景(etcd本来就是设计成用来搞配置中心和服务发现)。可惜etcd不是开箱即用的,也没有官方支持的UI,这点Apollo明显有优势得多。

  2. 链路跟踪目前没有一种碾压性的好用的开源方案,各种开源方案目前处于一种军阀混战的状态,否则也不会有那么多的收费的链路跟踪服务了。不过好消息是巨头们正在搞一个标准了:OpenTelemetry。这个标准的目标也是很宏大,囊括了链路跟踪、性能监控和日志三大方面,不过成熟度还是欠缺的。

  3. Service Mesh是一种非常创新性的设计,但通过代理的方式实现完全无侵入式的服务治理,难度也是很大的,比如目前存在的代理时发生错误难以排查原因的问题。我觉得适当的侵入,让业务程序和sidecar交互或许也是可以考虑的。

  4. 将来有机会想搞一个开源的服务治理平台,语言首选Rust,前后端都可以用Rust搞。

此文仅属个人观点,大家有什么观点可以在下方留言。:)


Last modified on 2020-03-26