写点什么

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

作者:agnostic
  • 2022 年 10 月 07 日
    上海
  • 本文字数:1336 字

    阅读完需:约 4 分钟

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


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

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

  • 通用服务产品化。

  • 新业务快速方案支撑。

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


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


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

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


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


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

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

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

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

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

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


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

发布于: 刚刚阅读数: 2
用户头像

agnostic

关注

还未添加个人签名 2019.02.14 加入

还未添加个人简介

评论

发布
暂无评论
架构师的十八般武艺:可延展性_可延展性_agnostic_InfoQ写作社区