![1d1e6be99f52846c99ed6775f1245936.png](https://i-blog.csdnimg.cn/blog_migrate/5e856e73c00481c25bed780c4e790f87.jpeg)
作者:艾彦波,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 容器中运行。
使用上面任何一种方案,对于现有的系统都存在这几个问题