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 标准。另外，对于不能合并在一起运行的服务，希望能继续使用 gRP