内容概要
本系列文章是微博从服务化改造到 Service Mesh 实践整个过程的分享(以微博自研 Service Mesh 解决方案 WeiboMesh 为例),主要是我们在这个过程中遇到的一些问题以及我个人关于服务化和 Service Mesh 的思考。
考虑到有的同学之前可能没有接触过 Service Mesh 这个概念,所以这里我先对 Service Mesh 做一个简单的介绍,作为后续内容的基础。
什么是 Service Mesh
Service Mesh 这个概念最早由开发 Linkerd 的 Buoyant, Inc 公司提出,2016 年 9 月 29 日的 SF Microservices MeetUp 上他们的 CTO Oliver Gould 在关于微服务的分享中首次公开使用了这个术语。
加入 Buoyant 之前, Oliver Gould 是 Twitter 的技术 Leader,也是 Twitter RPC 框架 Finagle 的核心开发者,加入 Buoyant 后他创建了 Linkerd,Linkerd 的 Github 创建日期为 2016 年 1 月 10 日,可见 Service Mesh 这个概念在 Buoyant, Inc 公司内部已经流传很久。
而 Service Mesh 这个概念的定义则是 Buoyant, Inc 公司的 CEO William Morgan 于 2017 年 4 月 25 日在公司官网发布的题为 "What’s a service mesh? And why do I need one?" 的文章中给出的。下面我们来看一下定义的内容:
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. (But there are variations to this idea, as we’ll see.)
原文翻译:Service Mesh 是一个基础设施层,用于处理服务间通信。云原生应用有着复杂的服务拓扑,Service Mesh 保证请求可以在这些拓扑中可靠地穿梭。在实际应用当中,Service Mesh 通常是由一系列轻量级的网络代理组成的,它们与应用程序部署在一起,但应用程序不需要知道它们的存在。
关于这个定义有以下两个值得我们关注的核心点: