如何避免新代码变包袱?阿里通用方法来了

什么是设计?什么是架构?从零开始建立一个新的系统,新写的每行代码都可能成为明天的历史包袱?如何能有效的在遗留代码上工作?今天,阿里资深技术专家辉子为我们带来NBF框架下软件工程架构设计通用方法论,值得细细品读。

如何避免新代码变包袱?阿里通用方法来了

Note:本文讨论的是基于服务化前提下的通用软件工程架构方法论,并未涉及到微观设计或架构的具体细节。

前言

即使代码多年的人都会对这两个问题有点蒙圈:什么是设计?什么是架构?

从单词上看:设计是Software Design,架构是Software Architecture;分别对应的作者是:Designer和Architect:

  • Architect都是Designer,但Designer未必是Architect。正如所有的架构设计都是设计,但设计未必是架构设计;
  • Design关注微观代码(inside component),Architecture关注宏观软件结构(between components);
  • Architect应该都是从Designer成长起来的。毕业了用code编写软件;成长了用ppt设计软件;
  • 只会用ppt设计,但代码写得不好的Architect都是假的Architect;
  • Architecture里听到比较多的词语:Serverless、FAAS、Microservice、multi-layer、Event driven、OSGI、NBF......
  • Design里听到比较多的词语:SOLID、 DDD、正交设计、Design Pattern;
  • 搞不清SOLID,也不可能把软件的层次分好,也无法理解什么是OSGI的价值;
  • 好的Designer是通往好的Architect的必经之路。

服务化架构的基本原则

如何避免新代码变包袱?阿里通用方法来了

New System

从零开始建立一个新的系统,有几个特征:

  • 历史包袱小
  • 上下文简单
  • 设计的约束小
  • 新写的每行代码都可能成为明天的历史包袱

由于调用方还没有,新系统可以比较完美的执行我们预想的架构设计,但是切记,最后那行才是最重要的那行:不要让今天的代码成为明天的历史包袱,新的每行代码都在书写历史。

上图的1,2,3,4代表新建系统的顺序:

  1. 由“相”抽象出“心”:先思考,那么多的业务场景下“相”,共同的特征“心”是什么。并反向用更多的相去验证心。
  2. 将“心”具象成领域模型:关注领域模型(Domain Model),解耦数据模型(Persistence Model):将TUNNEL SPI化。
  3. 将领域模型中的依赖SPI化:解耦对外部系统的依赖,反转依赖控制权。
  4. Mock所有spi实现,确保“心”领域模型包裹的单元测试完全通过
  5. 实现TUNNEL BUNDLE:设计数据模型(Persistence Model),关注“存”,“取”不关注领域模型。
  6. 实现依赖SPI适配BUNDLE:连接真实依赖服务。
  7. 包装domain service:模型相关,业务无关。
  8. 根据业务需求组合/编排domain service成为scenario bundle或者业务SOP。

Working on legacy

对于一个软件工程师来讲,写代码最痛苦的事情莫过于coding on legacy,但同时又给了我们各种说辞:

  • 这些代码太烂了,改起来太费劲【需要更多人】
  • 这事做不到,因为以前系统架构问题导致的【责任不在我】
  • 经过我的修改,现在已经好很多了,工单数量大批下降【我功劳显著】
  • 知不知道:接手你代码的人其实也在重复说上述3件事情

如何能有效的在遗留代码上工作,业内有本非常不错的书,叫"Working Effectively with Legacy Code",值得精读:

如何避免新代码变包袱?阿里通用方法来了

图片来源:书籍《Working Effectively with Legacy Code》

所以我这里的标题可能不准确,我要讨论的更多是"遗留代码的重构",什么时候我们开始讨论需要把现有系统重构:

  • 代码确实腐化到无法正常维护,或者新加一个需求代价很大;
  • 目前代码的技术架构满足不了下一步业务的发展;
  • 很多特性已经下线作废,却跟有用的代码藕断丝连;
  • 业务逻辑随着发展分散到不同的应用里,界限不清;
  • 专家级的未雨绸缪,着眼未来的规划和新技术的应用;
  • 换老大了,需要立新的flag。

架构的基本原则依然是上面那幅图。但上下文的不同,我们的发力点和优先级有明显的区别。阿里整个体系里的依赖关系错综复杂,要对阿里环境下的系统做重构是件绝对谨小慎微的事情。为了完成在这么复杂体系下的架构及代码重构,我们必须有条不紊的分离关注点以及一如既往的坚持软件卓越。

聚焦与收敛上游调用

如何避免新代码变包袱?阿里通用方法来了

解耦下游依赖

如何避免新代码变包袱?阿里通用方法来了

以服务为单位切换

如何避免新代码变包袱?阿里通用方法来了

老系统下线

经过一步一步的分解,legacy系统已经完全被重构,并且具备随时切换的准备。这里我给几个建议:

  1. 先把老实现作为API的默认实现,新的实现作为老的实现的降级实现,并使用策略分流一部分流量(具体比例跟团队信心相关);
  2. 对于有业务需求变更的部分应尽快实现在新的实现里,并将新实现作为API的默认实现,老实现作为新实现的降级实现,策略应该是即时降级,也就是新实现出现问题立刻降级到老实现;
  3. 运行一段时间没有问题后,讲所有默认实现切换为新实现,并将老实现作为新实现的降级实现;
  4. 其实这时就算所有切换完毕:老实现可以永远作为新实现的降级实现,也就是只要我升级一次服务,上一次成功版本就可以作为这次的降级实现,这样,线上问题回滚就是秒级的。

总结

相关推荐