架构师的十八般武艺：可延展性

首先，定义一下可延展性。有两个词 Scalability 和 Extensibility 在中文的翻译都是可扩展性。Scalability 一般指系统可以水平和垂直扩容，具备随负载增加扩展性能的特性。Extensibility 指系统可以快速增加和修改功能以满足未来的需求。本文讨论的是 Extensibility。

传统软件的可延展性设计无非要求系统基于接口设计、高内聚低耦合之类的。但是，在目前云原生、微服务的背景下，对系统可延展性设计有了不同的要求。根据我们日常的支付系统服务设计经验，我们总结了几条在 UVCA 和深水区场景下，对于系统可延展性设计的新的思路：

• 稳定的契约和基于契约的集成。

• 通用服务产品化。

• 新业务快速方案支撑。

• 可抛弃的产品和无感迁移能力。

首先，和基于接口设计的原则类似，在微服务的环境中，系统之间通过契约集成。契约系统能力的暴露方式，作为产品的重要组成部分，尽量保证契约的稳定。稳定不意味着不能升级，而是需要将契约和产品能力很好的结合在一起。契约的升级意味着产品能力的升级和变更。在产品需求没有变化的情况下，保持契约的稳定。同时，系统之间通过契约集成，系统内部的变化不影响契约的定义。系统的变更通过契约测试保证双方都能满足契约，从而保证整体系统间集成的稳定性。

其次，不管是在多 UVCA 和深水区的环境下，系统服务的分类还是可以遵循二八原则的：80%的系统服务基本还是在业界有范例的通用服务，20%才是和行业自身业务环境密切相关的非通用服务。

对于 80%的通用服务，能可采购的可以优先考虑采购，比如账务系统、营销系统、供应链系统、客户服务系统、商户管理系统等，都可以采购成熟的产品。如果采购不能满足业务的可用性、可维护性或者可控性的要求，选择自建的方式，也尽量按照业界流行的设计，进行系统功能的划分和开发。同时，不管是采购还是自建，都按照业界通用的建模定义对外的服务契约。

再次，对于 20%必须自建的非通用服务，大部分可能是和业务深水区相关的新业务支撑。对于这类的服务，不需要考虑太多的抽象、通用。没有范本的摸石头过河，就不要玩太多的花活。按照对业务的准确分析，对现实世界进行映射，按需定义功能和对外契约就可以了。这部分服务具备两个特点：快速支撑和快速试错。所以对系统设计的要求就是要能快速的完成 MVP 的建设，同时如果业务试错了也可以快速下线或者转化为别的服务。

这就引出了最后一点：可抛弃和无感迁移能力。

首先，产品要可抛弃，产品就必须具备完成的生命周期，不能只管开发不管下线。产品服务要下线，就必须有好的安置方案，有新的产品服务能承载，同时可以将老用户迁移到新服务上。

这个迁移主要指的就是数据的迁移。老的业务遗留的数据需要转换成新业务的数据。

对于新老数据的转换，在设计新的业务模型的时候，需要考虑新老模型的映射。有可能老模型可以直接无缝映射为新模型，也可能需要额外补充数据才能映射到新模型。

• 对于可以直接映射的场景，完成迁移逻辑的设计后，无论用双写或者双读的方式，可以很容易的在用户无感下完成新老服务的切换。

• 对于无法直接映射的场景，一般需要用户参与，补充信息。那在用户签约新业务的时候，综合老模型和补充的数据，根据一定的逻辑形成新模型。在这种场景下，按照用户签约的进度逐步迁移服务。

总之，对于没有范例借鉴的部分，快速开发、快速迁移，这个是最经济实用的可延展性设计。