什么是设计？什么是建筑？从头开始构建一个新系统，写的每一行代码都可能成为明天的历史包袱？我们如何有效地处理遗留代码？今天阿里资深技术专家惠子为我们带来了NBF框架下软件工程架构设计的通用方法论，值得细细品读。注：本文以服务为前提，讨论通用的软件工程架构方法论，不涉及微设计或架构的具体细节。前言即使是打码多年的人，也会对这两个问题有些迷茫：什么是设计？什么是建筑？从字面上看：设计是SoftwareDesign，架构是SoftwareArchitecture；相应的作者是：Designer和Architect：Architect都是Designers，但Designers不一定是Architects。正如所有的建筑设计都是设计，但设计不一定是建筑设计；设计侧重于微代码（组件内部），而架构侧重于宏观软件结构（组件之间）；Architect应该都是从Designer成长起来的。毕业后用代码写软件；长大后，我用ppt设计软件；只会ppt设计，代码写得不好的架构师，都是假架构师；我在架构中听到更多的词：Serverless、FAAS、Microservice、multi-layer、Eventdriven、OSGI、NBF……在设计中我听到了很多词：SOLID、DDD、OrthogonalDesign、DesignPattern；想不通SOLID，也不可能把软件层划分好。也无法理解OSGI的价值是什么；一个好的设计师是一个好的建筑师的唯一途径。面向服务架构的基本原则NewSystem从头开始??构建一个新系统，它有几个特点：历史包袱小上下文小设计约束简单新写的每一行代码都可能成为明天的历史包袱由于调用者还没有，新的系统可以完美执行我们预期的架构设计，但是记住，最后一行是最重要的一行：不要让今天的代码成为明天的历史包袱，每一行新的代码都在书写历史。上图中的1、2、3、4代表新体系的顺序：从“相”中抽象出“心”：首先思考这么多中“相”的“心”的共同特征是什么业务场景。又逆用多相，以证心。将“心”表示为领域模型：关注领域模型（DomainModel），解耦数据模型（PersistenceModel）：将TUNNEL转为SPI。SPI领域模型中的依赖：解耦对外部系统的依赖，反转依赖的控制。模拟所有的spi实现，以确保“心脏”领域模型包裹的单元测试完全通过。实现TUNNELBUNDLE：设计数据模型（PersistenceModel），关注“存储”，“获取”不关注领域模型。实现取决于SPI适配BUNDLE：连接到真正的依赖服务。封装领域服务：模型相关，业务无关。根据业务需求组合/安排领域服务，成为场景包或业务SOP。Workingonlegacy对于一个软件工程师来说，写代码最痛苦的就是在legacy上编码，但同时也给了我们各种借口：这些代码太烂了，改起来太费力【需要更多人手】这件事做不成，因为以前是系统架构问题造成的[我不负责]经过我的修改，现在好多了，工单数下降了很多[我有贡献显着]你知道吗：接手你代码的人其实是在重复上面的三件事是如何有效地处理遗留代码的，业界有一本很好的书叫《WorkingEffectivelywithLegacyCode》，它值得精读：图片来源：书♂所以我这里的标题可能不准确，我想讨论的更多是“遗留代码的重构”。架构无法满足下一步业务发展；许多功能已经下线并变得过时，但它们与有用的代码脱节；业务逻辑随着开发分散到不同的应用中，边界不清晰；专家级规划和面向未来的规划和新技术的应用；老大换人了，需要立新flag。架构的基本原理还是上图。然而，根据具体情况，我们的努力和优先事项显然不同。整个阿里系统中的依赖错综复杂，在阿里环境中重构系统是绝对慎重的。为了在如此复杂的系统下完成架构和代码重构，我们必须有条不紊地分离关注点，并一如既往地坚持软件卓越。聚焦与汇聚上游调用解耦下游依赖将旧系统下线切换经过一步步分解，遗留系统已经完全重构，随时可以切换。这里我给出几点建议：首先，将旧实现作为API的默认实现，新实现作为旧实现的降级实现，并使用策略分流部分流量（具体比例与团队的信心）；对于业务需求发生变化的部分，应尽快在新实现中实现，并将新实现作为API的默认实现，旧实现作为新实现的降级实现.策略应该是立即降级，即如果新的实现有问题，立即降级到旧的实现；出现问题后，将所有默认实现切换到新实现，将旧实现作为新实现的降级实现；实际上，即使此时所有切换完成：老的实现始终可以作为新实现的降级实现，也就是我只要升级一次服务，就可以将上一个成功的版本实现为这次降级。这样线上问题的回滚就在秒级了。总结本文基于NBF提供的远程多??态和服务编排能力下的基础数据、商品、网络系统的创建和重构的经验和方法论总结。仅供被架构重构、解耦等问题困扰的技术团队参考。本文作者：惠子
