这周聊了个需求，评估下给客户做一套私有化部署方案要多少成本。
本身我们是一个比较纯粹的saas公司，整个技术架构都是基于云端构建，没有太多私有化部署的经验。
奈何客户给得多呢，也得试着搞一搞。
不过还没确定方案，简单理一理思路吧。
1、微服务saas是怎样的
图片
这是我们一个比较直观的架构图。
以公有云资源为底座，包括云主机和云数据库。
在这之上构建我们的微服务体系，包括k8s、中间件、微服务、监控系统、CI/CD系统。
这么一套东西，该怎么做私有化部署呢？
2、私有化部署的需求有哪些
私有化的需求分为两类，「功能性需求」和「非功能性需求」。
「功能性需求」比较好理解，就是需要哪些产品能力。包括前端哪些功能，以及后端哪些API。
「非功能性需求」是私有化部署的核心，如何将服务部署到用户的私有化环境中。
这种私有化环境还能分为两种模式。
一种是「专有云模式」，客户自己基于公有云的独立账号购买资源，然后我们把代码部署过去。
另一种是「私有云模式」，客户自己的IDC提供服务器，然后我们在服务器上部署数据库和各类服务。
两种模式能不同程度保护客户数据安全性。
3、微服务的私有化之痛
首先根据客户需求，确定产品功能所需的后端服务以及相关API。
这个说起来容易，做起来难。
为什么呢？
因为微服务架构看似松耦合，但是疏于治理，没有真正按照领域能力做模块化隔离，各种服务间无序调用。
基本上只能认为是一个分布式大单体。
所以很难理想化地根据产品功能，来划分出独立的后端服务集合。
往往是像一棵大树，拔起一点点，就能带出一整个盘根错节的树根。
如果不管三七二十一，直接整套部署，那几百个微服务所需要的服务器资源成本将会极高，根本没法用。
几十个接口的功能，总不能打包一个k8s集群、若干中间件、几百个微服务和数据库的大礼包吧。
怎么办？
短期看，可能只能按梳理的功能，临时把所需要的API抽取，集合到一个新的单体服务中，做一些简单的改造适配，成本相对可控。
长期来看，如果要在微服务架构下灵活交付不同私有化版本，需要做好微服务治理，把分布式大单体按照业务领域、功能模块进行合理划分，做好隔离，这样才有可能按需组合使用。
