微服务治理是一个老生常谈的架构问题，正如任何的解决方案，解决了以往的一部分问题，却带来了新的问题和挑战。关于微服务解决了什么问题，和带来了什么挑战，可以看看这篇文章： 微服务架构体系的深度治理 ，我觉得这篇文章对于接触微服务较少的人来说可能有点难读懂，读了前半部分的发展历史就好。
为了应对微服务所带来的问题，就引入了一系列的解决办法，统一称为微服务治理，关于微服务治理的一些方法和生态，可以参考：当我们在说微服务治理的时候究竟在说什么。
但是如果通读上面的这篇文章，你就会发现大部分都是说的Java的甚至只限于Spring cloud的生态的东西，那其它语言呢，基本上就没有Java那么好的生态了，就连国内很流行的PHP一样如此。为了解决微服务治理和语言甚至框架组件强耦合的问题，就诞生了Service Mesh。
由于Service Mesh是一个很新的概念，虽然网上很多文章都有说的，但是并没有一个统一的观点。其实架构本质就是为了解决问题的，只有知道Service Mesh是解决了什么问题，才能更好地去理解它。事实上Service Mesh是一种无侵入的语言无关的微服务治理方案，对标的是Spring cloud为代表的侵入式强语言相关的方案，而手段上也大同小异，也是配置中心、服务发现、熔断等等技术。这是一篇不错的关于Service Mesh发展史的文章：解读 2017 之 Service Mesh：群雄逐鹿烽烟起
。
对于微服务治理的各种手段，配置中心、日志平台、链路跟踪几乎是每家有一定规模的互联网公司的标配，而像服务发现、熔断、限流等，非Java系的公司不一定会有。更大型的公司往往会有一个微服务治理的平台，将这种多种手段汇总起来，形成一个可视化的交互良好的平台，极大地提高了微服务治理的效率，可惜这种平台一般都是大公司当成宝贝的存在，一般不会开源出来。
关于微服务治理，我有几点想法：
交互良好易用的界面很重要，比如配置中心，目前国内比较热门的有
Apollo，但是我觉得Apollo使用MySQL作为存储和HTTP协议提供配置明显不是好的选择，而etcd就合理多了，使用了分布性一致性的raft协议，v3的api是使用grpc的，支持watch和心跳功能，这是配置中心很重要的两点，而且etcd还有ttl，一样胜任服务发现的场景（etcd本来就是设计成用来搞配置中心和服务发现）。可惜etcd不是开箱即用的，也没有官方支持的UI，这点Apollo明显有优势得多。链路跟踪目前没有一种碾压性的好用的开源方案，各种开源方案目前处于一种军阀混战的状态，否则也不会有那么多的收费的链路跟踪服务了。不过好消息是巨头们正在搞一个标准了：OpenTelemetry。这个标准的目标也是很宏大，囊括了链路跟踪、性能监控和日志三大方面，不过成熟度还是欠缺的。
Service Mesh是一种非常创新性的设计，但通过代理的方式实现完全无侵入式的服务治理，难度也是很大的，比如目前存在的代理时发生错误难以排查原因的问题。我觉得适当的侵入，让业务程序和sidecar交互或许也是可以考虑的。将来有机会想搞一个开源的服务治理平台，语言首选
Rust，前后端都可以用Rust搞。
此文仅属个人观点，大家有什么观点可以在下方留言。:)
Last modified on 2020-03-26