这周聊了个需求，评估下给客户做一套私有化部署方案要多少成本。

本身我们是一个比较纯粹的saas公司，整个技术架构都是基于云端构建，没有太多私有化部署的经验。

奈何客户给得多呢，也得试着搞一搞。

不过还没确定方案，简单理一理思路吧。

1、微服务saas是怎样的

图片

这是我们一个比较直观的架构图。

以公有云资源为底座，包括云主机和云数据库。

在这之上构建我们的微服务体系，包括k8s、中间件、微服务、监控系统、CI/CD系统。

这么一套东西，该怎么做私有化部署呢？

2、私有化部署的需求有哪些

私有化的需求分为两类，「功能性需求」和「非功能性需求」。

「功能性需求」比较好理解，就是需要哪些产品能力。包括前端哪些功能，以及后端哪些API。

「非功能性需求」是私有化部署的核心，如何将服务部署到用户的私有化环境中。

这种私有化环境还能分为两种模式。

一种是「专有云模式」，客户自己基于公有云的独立账号购买资源，然后我们把代码部署过去。

另一种是「私有云模式」，客户自己的IDC提供服务器，然后我们在服务器上部署数据库和各类服务。

两种模式能不同程度保护客户数据安全性。

3、微服务的私有化之痛

首先根据客户需求，确定产品功能所需的后端服务以及相关API。

这个说起来容易，做起来难。

为什么呢？

因为微服务架构看似松耦合，但是疏于治理，没有真正按照领域能力做模块化隔离，各种服务间无序调用。

基本上只能认为是一个分布式大单体。

所以很难理想化地根据产品功能，来划分出独立的后端服务集合。

往往是像一棵大树，拔起一点点，就能带出一整个盘根错节的树根。

如果不管三七二十一，直接整套部署，那几百个微服务所需要的服务器资源成本将会极高，根本没法用。

几十个接口的功能，总不能打包一个k8s集群、若干中间件、几百个微服务和数据库的大礼包吧。

怎么办？

短期看，可能只能按梳理的功能，临时把所需要的API抽取，集合到一个新的单体服务中，做一些简单的改造适配，成本相对可控。

长期来看，如果要在微服务架构下灵活交付不同私有化版本，需要做好微服务治理，把分布式大单体按照业务领域、功能模块进行合理划分，做好隔离，这样才有可能按需组合使用。