小蚂蚁说:
2018 年上半年, 蚂蚁金服决定基于 Istio 订制自己的 ServiceMesh 解决方案, 并在 6 月底正式对外公布了 SOFAMesh .
在 SOFAMesh 的开发过程中, 针对遇到的实际问题, 我们给出了一套名为 x-protocol 的解决方案, 本文将会对这个解决方案进行详细的讲解, 后面会有更多内容, 欢迎持续关注本系列文章.
前言
x-protocol 的定位是云原生, 高性能, 低侵入性的通用 Service Mesh 落地方案, 依托 Kubernetes 基座, 利用其原生的服务注册和服务发现机制, 支持各种私有 RPC 协议低成本, 易扩展的接入, 快速享受 Service Mesh 所带来的红利.
具体解决的问题包括:
多通讯协议支持问题, 减少开发工作量, 简单快捷的接入新协议
尽量提升性能, 提供更灵活的性能与功能的平衡点选择, 满足特定高性能场景
兼容现有 SOA 体系, 提供通过接口进行访问的方式, 实现不修改业务代码也能顺利接入 Service Mesh
支持单进程多服务的传统 SOA 程序, 可以在微服务改造之前, 先受益于 Service Mesh 带来的强大功能
在本系列文章中, 我们将对此进行详细的讲解, 首先是 "DNS 通用寻址方案".
SOFA 开源网站:
http://www.sofastack.tech/
背景和需求
SOA 的服务模型
在 SOFAMesh 计划支持的 RPC 框架中, SOFARPC,HSF,Dubbo 都是一脉相承的 SOA 体系, 也都支持经典的 SOA 服务模型, 通常称为 "单进程多服务", 或者叫做 "单进程多接口".(备注: 由于服务一词使用过于频繁, 下文都统一称为接口以便区分)
SOA 标准的服务注册, 服务发现和调用流程如下:
在单个 SOA 应用进程内, 存在多个接口
服务注册时, 以接口为单位进行多次独立的服务注册
当客户端进行调用时, 按照接口进行服务发现, 然后发起调用
当我们试图将这些 SOA 架构的应用搬迁到 ServiceMesh 时, 就会遇到服务模型的问题: 微服务是单服务模型, 也就是一个进程里面只承载一个服务. 以 k8s 的服务注册为例, 在单进程单服务的模型下, 服务名和应用名可以视为一体, k8s 的自动服务注册会将应用名作为服务注册的标示.
这就直接导致了 SOA 模型和微服务模型的不匹配问题:
SOA 以接口为单位做服务注册和服务发现, 而微服务下是服务名
SOA 是 "单进程多接口", 而微服务是 "单进程单服务"
一步接一步的需求
先上车后补票
最理想的做法当然是先进行微服务改造, 实现微服务拆分. 但是考虑到现有应用数量众多, 我们可能更愿意在大规模微服务改造之前, 先想办法让这些应用可以运行在 ServiceMesh 下, 提前受益于 ServiceMesh 带来的强大功能. 因此, 我们需要找到一个合适的方案, 让 ServiceMesh 支持没有做微服务改造依然是 "单进程多接口" 形式的传统 SOA 应用, 所谓 "先上车后补票".
不修改代码
考虑到原有的 SOA 应用, 相互之间错综复杂的调用关系, 最好不要修改代码, 即保持客户端依然通过接口名来访问的方式. 当然, SOA 架构的客户端 SDK 可能要进行改动, 将原有的通过接口名进行服务发现再自行负载均衡进行远程调用的方式, 精简为标准的 ServiceMesh 调用(即走 Sidecar), 因此修改 SDK 依赖包和重新打包应用是不可避免.
支持带特殊字符的接口名
k8s 的服务注册, Service 名是不能携带 "." 号的. 而 SOA 架构下, 接口名有时出于管理方便, 有可能是加了域名前缀, 如 "com.alipay.demo.interface-2". 为了实现不修改原有代码, 就只能想办法支持这种带特殊字符的接口名.
参考 Kubernetes 和 Istio
在进一步讨论解决方案之前, 我们先来看一下 kubernetes 和 istio 中的标准请求寻址方式.
来源: https://juejin.im/post/5c174809e51d457e0019dcd2