Service Mesh 在有赞的实践与发展
閱讀本文約花費: 20 (分鐘)一、缘起 有赞初期，使用的是 Nginx+PHP-FPM，所有的业务逻辑代码都在一个叫做 Iron 的 PHP 代码仓库里，是一个典型的单体应用 (Monolith)，整体架构可以简单的表示成下图： 架构在有赞初期，团队规模比较小，且业务逻辑相对比较简单的时候，很好的支撑和承载了有赞的核心业务。但是，随着有赞业务和团队规模的极速发展，单体应用的缺陷愈来愈凸显： 耦合性高 隔离性差 团队协作性差 一次发布带来的故障往往需要几个业务团队的人坐在一起，花费数十分钟甚至几个小时才能定位究竟是哪处改动引发的。对单体应用进行微服务改造，势在必行。 综合当时团队和业务发展的实际情况，一方面，有赞选择了国内非常流行且具备良好生态的 dubbo 作为 Java 语言 RPC 框架；另一方面，考虑到团队中有相当数量 PHP 开发的同学，有赞内部孵化出了 ZanPHP——使用 PHP 语言的纯异步 RPC 框架，并选择了 ETCD 作为服务注册和发现中心，开始搭建有赞服务化的整体架构。为了解决跨语言 (Java 与 PHP 语言之间) 的 RPC 通信问题，有赞在 facebook 开源的 thrift 协议基础上进行了二次封装，开发了 NOVA 协议用以支持跨语言 RPC 调用。 综上所述，这一时期，整体的架构选型如下： 尽管将单体应用拆分成微服务能够带来一系列众所周知…