GrowingIO 微服务 SaaS 与私有部署运行实践

发布于: 2020 年 05 月 13 日
GrowingIO 微服务 SaaS 与私有部署运行实践

作者:艾彦波,GrowingIO 服务端架构师,反应式架构践行者。负责 GrowingIO 亿级 DAU 技术架构与演进,目前专注在 Service Mesh 架构上。



GrowingIO 作为国内领先的数据运营解决方案供应商,为上千家企业提供基于用户行为的增长解决方案。



为满足企业的不同侧重与需求,GrowingIO 支持私有化和 SaaS 两种部署方式。两种部署方式的内容架构与交互设计不同,但相同的是产品底层逻辑,以及数据中心、用户库、产品分析、智能运营等产品线。



这些产品线在研发环境中,被设计为多个相互独立的微服务。为避免研发资源浪费,GrowingIO 需要确保同一批微服务可在不同部署模式的环境中均正常运行。



SaaS 与私有部署环境的差别



要解决这个问题,我们需要找到 SaaS 与私有部署之间的差别。根据我们的经验,总结了以下几个主要的差别:



  • 云生态的差别:SaaS 产品部署在公有云环境里,能使用标准的接口管理资源(实例),也可以非常方便地使用公有云的产品生态去架构服务的高可用。在私有部署的环境里面,资源的访问方式,云平台的产品形态都不太一样。

  • 数据隔离级别:SaaS 产品需要有非常完备且严格的多租户数据隔离方案。在私有部署的环境里面,数据隔离的级别会因为客户的需求有细微的区别。

  • 用户访问量:SaaS 需要满足几千家客户业务需求,要支撑这些访问的可靠性,需要有一个可靠的集群。在私有部署的环境里,服务只需要满足 1 家客户的业务需求,客户对资源有一定的预算。

  • 运维方式不同:SaaS 产品有公司专业的 SRE 负责,他们有非常丰富的故障处理经验,每个服务也有非常固定的上线流程。在私有环境里,客户可能不太熟悉服务的架构,服务升级会相对困难,处理故障不会那么快速。



针对上面的这些主要问题,我们在服务端分成 3 个方向去解决:



  • 减少服务个数

  • 减少中间件依赖

  • 插件化个性需求



通过使用这 3 个方面的改进,我们能带来的好处是:降低了服务对最小资源的限制,高可用方案的复杂度,运维的困难性以及满足部分个性化的部署需求。



接下来,聊一聊 GrowingIO 具体是如何做到的:



1,减少服务个数 - 合并微服务独立进程



减少服务个数最简单直接的方式是,将原本在 SaaS 上独立运行的同构微服务,在私有部署的环境中让它们合并在一个进程上运行。这种既能独立又能合并运行的能力,在 Java 领域中已经有成熟的技术:



  • OSGi - Java 动态模型系统,使用标准化原语,将应用程序以组件的方式自由组合运行。

  • Servlet 容器技术 - 应用程序使用标准的 Servlet 接口,将自身以 web jar 的方式部署到像 Tomcat, Jetty 等 Servlet 容器中运行。



使用上面任何一种方案,对于现有的系统都存在这几个问题。首先,需要将现有的服务改造以实现 OSGi 或 Servlet 标准。另外,对于不能合并在一起运行的服务,希望能继续使用 gRPC 的方式进行服务间的通讯,需要找到一种方式能让它们支持发布 gRPC 服务。



因此,我们需要设计一个模块化系统,既能达成让服务一起运行的目标,又只花少量的时间改造。为了让效果更有成效,对这个模块化系统做了几点要求:



  • 使用相同 HTTP 框架的服务(我们使用的框架有:akka-http, undertow, netty)共同使用一个 HTTP 端口

  • 所有服务共同使用一个 gRPC 端口

  • 运行在同一个 JVM 进程上的服务间通讯由 gRPC 远程调用切换成堆栈调用

  • 不同 JVM 之间的服务调用方式保持不变



如下图所示:





要实现这个模块化系统,我们需要想清楚一个问题:服务的本质是什么?在我看来,服务的本质不是一个 HTTP 或 gRPC 接口,服务的本质是真正的业务处理逻辑。HTTP 或 gRPC 只是对外通讯的一个手段而已。



当清楚服务的本质就是业务逻辑时,模块化的定义就变得非常清晰。然后,我们构建这个模块化的运行环境就能使得它们能在一起运行。要构建这个模块化运行环境不必要知道模块里具体实现了什么逻辑,只需要知道这个模块初始化需要什么,依赖了哪些服务,暴露的服务有哪些。根据这些具体的需求,能很清楚地用代码表示:



trait BoxerModule {
// 打开调试模式
def debug(): Unit

def injector: Injector

// 模块是否暴露 HTTP 服务,以及使用的 HTTP 框架
def httpEngine: Option[ServerEngine]

// 模块暴露的 gRPC 服务集合
def grpcServices: Set[BindableService]

// 模块的后台服务集合
def workers: Seq[ServiceBuilder]

// 模块的启动服务集合
def bootstraps: Seq[ServiceBuilder]

// 注入上下文信息
def aware(context: ModuleContext): Unit

}

trait ServiceBuilder {

def build(injector: Injector): Service

}

// 模块上下文信息
trait ModuleContext {

// gRPC 进程内通道
def grpcChannel: ManagedChannel

// 判断某个 gRPC 服务是否可以使用进程内调用
def isInProcessServiceStub(stubClass: Class[_]): Boolean

}



在上面的代码中,我们主要描述了以下几个信息:



  • 模块的上下文信息

  • 模块暴露的服务集合



接下来,要解决的是将多个服务(也就是 ModuleContext)合并在一起运行。在这之前,我们还需要解决几个问题:



  • 用什么样的方式将多个服务合并在一起?

  • 在同一个 JVM 内,怎么保证模块之间的既能相互调用,又能保持相互独立?





如上图,Server A 与 Server B 都有 GlobalConfig 对象,它们的类路径一致,包含的字段属性也一致,但是它们字段属性的值却不一样。如果将这两个服务作为依赖的方式引入到同一个项目里面运行,这种方式虽然简单但是没有解决模块之间的隔离型问题。会发生 A 会覆盖 B 或者 B 覆盖 A 的问题。



那如何做到让它们保持相互独立呢?这时候,我们可以使用 JVM 的 ClassLoader 机制。在 JVM 中,两个非父子关系的 ClassLoader 加载到的内容是相互隔离的。所以,如果我们将不同的模块使用不同的 ClassLoader 加载就能让它们保持相互独立了。如下图:





上图中的 ClassLoader 构造,可以使用下面的代码实现:



val classLoaderA = new URLClassLoader(serverA.libs, parent)
val classLoaderB = new URLClassLoader(serverB.libs, parent)



模块被加载成 ClassLoader 了,初始化模块就变得简单许多了。参考 Java 9 模块化的设计,我们为每个微服务加入了模块描述文件,如下图:我们在 growing-insight 服务里面加入了 BoxerModuleInfo 文件描述模块内容。





上图中的 SimpleBoxerModule 是默认的模块内容描述,如果使用者用标准的模式开发服务,那么他只需要创建一个 BoxerModuleInfo 文件并继承 SimpleBoxerModule 就能完成模块注册。是使用方式及其简单。



class SimpleBoxerModule extends BoxerModule {

private[this] var moduleContext: ModuleContext = _
private[this] lazy val applicationContext = new ApplicationContextLoader(moduleContext).load(GlobalConfig.Server)

override def debug(): Unit = {}

override def injector: Injector = applicationContext.injector

override def httpEngine: Option[ServerEngine] = applicationContext.httpEngineOpt

override def grpcServices: Set[BindableService] = applicationContext.grpcServices

override def hooks: Seq[ApplicationHook] = applicationContext.hooks

override def workers: Seq[ServiceBuilder] = applicationContext.workers

override def bootstraps: Seq[ServiceBuilder] = applicationContext.bootstraps

override def aware(context: ModuleContext): Unit = moduleContext = context
}



根据模块内容描述文件,用下面代码的方式能将 ClassLoader 初始化成一个一个服务模块:



val loader = new ModuleAppClassLoader(urls, parent)
val boxerModuleInfoClass = loader.loadClass("BoxerModuleInfo")
val module = boxerModuleInfoClass.newInstance().asInstanceOf[BoxerModule]



得到了 Module 对象,就能依据它暴露的服务合并在一起发布一个新的服务列表了。接下来,要解决的是如何让原本通过远程调用的 gRPC 服务转换成进程内堆栈调用。这里就不得不提在 BoxerModule 定义中的 ModuleContext 了。通过使用它的 isInProcessServiceStub 方法判断某一个 gRPC 是否可以使用进程内调用,如果可以进程内调用,使用 grpcChannel 初始化 gRPC Stub 就能完成进程内调用了。



以上,是整个模块化系统设计与实现的核心逻辑。不过还能在 ClassLoader 的架构上更进一步,达到上文中提到的减少资源使用的目标。



服务与服务(即模块与模块)之间,除了业务逻辑以及需要隔离的类之外,剩下的框架部分绝大部分是一致的,框架部分的类没有隔离的必要性。如下图,将不需要隔离性的框架类通过 BoxerSuiteClassLoader 管理可以提高内存空间利用率,因为 JVM 类加载器有双亲委派机制,ClassLoader 会优先从父 ClassLoader 加载类信息。





2,减少中间件依赖 - 去掉中心化服务注册中心



在 GrowingIO 的 SaaS 环境中,我们使用 Consul +



Dryad(https://github.com/growingio/dryad 我们开源的一个服务注册发现与配置管理组件) 实现服务的注册与发现。为了降低私有部署的环境复杂性,去掉 Consul 集群是一个有效的方式。因此选择了类似于 nginx 中 upstream 的方式实现服务集群的高可用。私有部署的用户访问流量比起 SaaS 上具有较强的可预测性,不需要经常性地做动态扩容。所以,使用这种方式并不会带来特别高的维护成本。





如上图所示,Server A 在本地维护了 Server B 与 Server C 的地址。在使用的过程中根据 Server Name 可以找到服务具体的地址。这一功能,已经在 Dryad 里开源出来了。使用的过程如下代码:



  • 定义服务具体的地址



dryad {
cluster {
direct = true // 为 true 则直接使用本地的集群配置,为 false 则通过 consul 的方式注册与发现服务
events = [ // events 是服务的名称
{
address = "10.0.0.1"
port = 8080
},
{
address = "10.0.0.2"
port = 8080
}
]
}
}



  • 使用 io.growing.dryad.cluster.Cluster 的 roundRobin 接口获取服务信息



val server = cluster.roundRobin(Schema.GRPC, "events")



3,个性化需求 - 插件化



GrowingIO 服务的 SaaS 版本与私有部署版本使用的是同一个代码分支,在面对私有部署版本中的个性化需求时,使用的是 “插件化” 的思想解决实现不一致的问题。



即使用标准化的接口允许多个不同的实现满足个性化需求。例如,在 SaaS 版本中为了满足多租户数据隔离的需求,有一个专门的服务去管理各个用户的数据作用域。在私有版本中,我们保留了支持多租户数据隔离的这个功能,但是简化了它的实现逻辑。



如下图,GrowingIO 使用接口 + 多个实现的方式满足个性化需求:



|- service // 接口定义
| - impl // SaaS 上的标准实现
| - extension // 私有部署上的个性化实现



在服务启动时,通过配置可以决定需要加载哪种实现,这个过程是自动完成的,不需要在开发过程中干预。



extension {
enabled = true // 是否按照拓展的方式加载实现
key = "extension" // 加载的个性化需求地址(默认是 extension,如果有多个客户的实现不一样,修改 key 的值即可)
}



总结



本文,我们讨论了 GrowingIO 是如何让微服务支持 SaaS 与私有部署 2 种不同的环境的。要去解决它们之间的兼容问题,就需要找到它们之间的差别。很多时候,这 2 个环境的许多部分都是相反的,我们要在架构设计中自顶向下去包容这种矛盾,不能哪里有问题就去解决哪里,这样只会让程序越来越复杂。



发布于: 2020 年 05 月 13 日 阅读数: 1669
用户头像

GrowingIO 技术团队经验分享 2020.05.09 加入

GrowingIO(官网网站www.growingio.com)的官方技术专栏,内容涵盖微服务架构,前端技术,数据可视化,DevOps,大数据方面的经验分享。 公众号:GrowingIO技术团队

评论 (2 条评论)

发布
用户头像
感谢分享,内容推荐到InfoQ官网首页了。
2020 年 05 月 13 日 19:25
回复
谢谢~我们争取产出更多优质内容
2020 年 05 月 14 日 11:59
回复
没有更多了
GrowingIO 微服务 SaaS 与私有部署运行实践