gydtep

Serverless 技术无缝是云计算和云原生应用架构的发展方向，但对于微服务应用的开发者而言，不管是 FaaS 形态，还是 Serverless Kubernetes ，都存在一定的局限性。

gydtep

不是每一种业务都适合通过 FaaS 的方式进行构建，特别是对于链路长，上下游依赖特别明显的应用，根本没有办法进行 FaaS 化改造。即便某些业务系统的 FaaS 化改造被证明可行，把现有的微服务架构改造成 FaaS 架构也需要一定的工作量，并不能做到无缝移植。

gydtep

Serverless Kubernetes 架构虽然能适配所有的业务场景，但对于开发者而言，构建一整套 Kubernetes 体系，需要掌握一系列跟 Kubernetes 相关复杂的概念，有着非常陡的学习曲线。而且 Kubernetes 生态中各种组件的搭建，再加上网络层与存储层的适配，都涉及非常复杂的工作。

gydtep

造成这种局限性的原因很简单，在以 Spring Cloud 为代表的微服务技术阵营中，系统的构建都是围绕着应用（也可以理解为单个的服务）而展开，不管是版本更新还是水平扩展，都是针对应用本身。Serverless Kubernetes 架构的核心在于 Pod ，比应用更偏向系统底层，所以使用者需要投入更多的精力用于应用下层资源的管理。而 FaaS 架构的核心在于函数，比应用更偏向系统上层，因此灵活度会降低，不能适配所有的业务场景。

gydtep

对于使用主流 Spring Cloud 体系或 Dubbo 体系构建微服务应用的开发者而言，如果需要引入一种方案降低资源成本，他的最终诉求一定包含两个方面：

（1）能否零改造成本，或者接近零改造成本；
（2）能否适配所有的业务场景。

gydtep

为什么称之为真正的**多活？**多活已经不是什么新鲜词，但似乎一直都没有实现真正意义上的**多活。一般有两种形式：一种是应用部署在同城两地或多地，数据库一写多读（主要是为了保证数据一致性），当主写库挂掉，再切换到备库上；另一种是单元化服务，各个单元的数据并不是全量数据，一个单元挂掉，并不能切换到其他单元。

gydtep

目前还能看到双中心的形式，两个中心都是全量数据，但双跟多还是有很大差距的，这里其实主要受限于数据同步能力，数据能够在3个及以上中心间进行双向同步，才是解决真正**多活的核心技术所在。

gydtep

提到数据同步，这里不得不提一下DTS(Data Transmission Service)，最初阿里的DTS并没有双向同步的能力，后来有了云上版本后，也只限于两个数据库之间的双向同步，做不到A<->B<->C这种形式，所以我们自研了数据同步组件，虽然不想重复造轮子，但也是没办法，后面会介绍一些实现细节。

gydtep

选择一个数据维度来做数据切片，进而实现业务可以分开部署在不同的数据中心。主键需要设计成分布式ID形式，这样当进行数据同步时，不会造成主键冲突。

gydtep

缺点：

依赖机器时钟，如果时钟错误比如时钟不同步、时钟回拨，会产生重复Id。
容量存在局限性，32位的长度可以使用136年，一般够用。
并发局限性，低于snowflake。
只适用于int64类型的Id分配，int32位Id无法使用。