Serverless Kubernetes 架构虽然能适配所有的业务场景，但对于开发者而言，构建一整套 Kubernetes 体系，需要掌握一系列跟 Kubernetes 相关复杂的概念，有着非常陡的学习曲线。而且 Kubernetes 生态中各种组件的搭建，再加上网络层与存储层的适配，都涉及非常复杂的工作。
造成这种局限性的原因很简单，在以 Spring Cloud 为代表的微服务技术阵营中，系统的构建都是围绕着应用（也可以理解为单个的服务）而展开，不管是版本更新还是水平扩展，都是针对应用本身。Serverless Kubernetes 架构的核心在于 Pod ，比应用更偏向系统底层，所以使用者需要投入更多的精力用于应用下层资源的管理。而 FaaS 架构的核心在于函数，比应用更偏向系统上层，因此灵活度会降低，不能适配所有的业务场景。
对于使用主流 Spring Cloud 体系或 Dubbo 体系构建微服务应用的开发者而言，如果需要引入一种方案降低资源成本，他的最终诉求一定包含两个方面：
（1）能否零改造成本，或者接近零改造成本；
（2）能否适配所有的业务场景。
为什么称之为真正的**多活？**多活已经不是什么新鲜词，但似乎一直都没有实现真正意义上的**多活。一般有两种形式：一种是应用部署在同城两地或多地，数据库一写多读（主要是为了保证数据一致性），当主写库挂掉，再切换到备库上；另一种是单元化服务，各个单元的数据并不是全量数据，一个单元挂掉，并不能切换到其他单元。
目前还能看到双中心的形式，两个中心都是全量数据，但双跟多还是有很大差距的，这里其实主要受限于数据同步能力，数据能够在3个及以上中心间进行双向同步，才是解决真正**多活的核心技术所在。
提到数据同步，这里不得不提一下DTS(Data Transmission Service)，最初阿里的DTS并没有双向同步的能力，后来有了云上版本后，也只限于两个数据库之间的双向同步，做不到A<->B<->C这种形式，所以我们自研了数据同步组件，虽然不想重复造轮子，但也是没办法，后面会介绍一些实现细节。
选择一个数据维度来做数据切片，进而实现业务可以分开部署在不同的数据中心。主键需要设计成分布式ID形式，这样当进行数据同步时，不会造成主键冲突。
缺点：
依赖机器时钟，如果时钟错误比如时钟不同步、时钟回拨，会产生重复Id。
容量存在局限性，32位的长度可以使用136年，一般够用。
并发局限性，低于snowflake。
只适用于int64类型的Id分配，int32位Id无法使用。
FaaS 也引入了一些新的技术挑战，比如冷启动会导致应用响应延迟，按需建立数据库连接成本高等等，需要平台能力的持续增强。
Rehost 新托管 - 简单地通过 lift-and-shfit 方式，将线下物理机替换成为云上虚拟机或者裸金属实例，不改变原有的运维方式。
