架构遗留应用程序和现代化方案

架构遗留应用程序和现代化方案

      毫无疑问，我们所有从事软件工程师或架构师工作的人都曾在任何时候接触过遗留应用程序。在这篇文章中，我们的目标是了解遗留系统和重构它的方法，同时探索各种迁移到云的方案。我们还将研究遗留应用可以被现代化的其他方面，包括软件开发方法，以及构建和部署程序。

遗留应用
      我们中的许多人喜欢在全新的软件系统中工作，因为它们涉及到从头开始设计的现代技术栈。这样的系统对之前的工作没有什么限制，也不需要和现有的系统进行整合。然而，无论我们今天拥有什么样的新系统，明天都会成为一种遗产。我们经常发现自己在现有的软件系统上工作，能够这样做是一种宝贵的技能。遗留应用是一个现有的软件系统，它仍然在使用，但也难以维护。使用一个遗留的应用程序会产生一些挑战。

问题和挑战
       使用一个遗留的应用程序通常会带来各种需要克服的问题。其中最重要的是难以维护和扩展。它可能包括旧的、过时的技术，此外，往往没有遵循开发的最佳实践。除此之外，还有其他一些问题，如安全、效率低下、不兼容以及与合规/GDPR相关的事情。

一个遗留的应用程序往往是旧的，随着时间的推移，开发人员会添加一些修改。随着这些修改继续在代码库上进行，代码会变得不整齐和混乱，从而导致意大利语代码。

一个遗留系统也会积累一些技术债务。任何为一个应用程序做出的设计决定，即选择了一个更容易、更快速的解决方案，而不是一个更干净的解决方案，但需要更长的时间来实现，都会产生技术债务。技术债务涉及到未来系统改进的返工。

遗留应用的重构方法
     当我们接触到一个遗留的应用程序时，我们希望对其进行重构，以增强可维护性因素。这可能是增加新的功能，修复错误，改进设计，提高质量或整体优化。为了执行这些任务，遗留的应用程序必须处于理想的状态，这样就可以很容易地进行增强或改变，而且没有什么风险。

另外，在进行遗留代码库重构之前，需要有正确的态度。新的开发者/架构师应该尊重早期的开发团队，因为事情以某种方式进行是有原因的，而新手可能并不总是知道所有发生的决定和它们背后的理由。

作为软件开发者/架构师，我们的目标应该是使你一直在监督的遗留应用程序现代化并加以改进。我们应该避免做不必要的修改，特别是在我们没有完全理解这些变化的影响时。在遗留问题重构阶段，会涉及到以下任务。

使得遗留的代码可以测试
删除多余的代码
使用工具对代码进行重构
进行小的、渐进的改变
将单体转变为微服务

使遗留代码可测试
很多遗留的软件应用程序缺乏自动化的单元测试，只有一些有足够的代码覆盖。另外，有一些遗留的应用程序在开发时甚至没有考虑单元测试的范围。由于这个原因，以后很难再增加测试。在遗留系统中，适当的单元测试应该是最重要的。这是因为单元测试是确保新的变化没有引入新的缺陷和功能仍然工作的支柱。

作为构建管道的一部分，定期执行变化后的单元测试将使调试成为小菜一碟。

删除多余的代码
遗留的应用程序是相当老的，而且很可能有重复的代码段。原因是它是由不同的人维护的，因此增加了重复的或过时的代码实例。

减少代码的总行数肯定会降低复杂性，并且更容易被其他工程师同事理解。

一些有用的工具可以识别一些不必要的代码类型。重构无法得到的、死的、被反映出来的和重复的代码将提高系统的可维护性。

使用工具进行重构
最好是利用有许可证的IDE工作台上的开发工具的优势。这些工具可以发现你的代码库中可以重构的地方。

进行小的、渐进式的修改
  在重构工作中，有些变化可能是相当大的。在这种情况下，小的增量修改有时是改善遗留代码库的正确方法。为了避免负面的后果，强烈建议编写和执行单元测试。

每当开发人员有正常的任务，如错误修复，或小的增强，这是一个机会，以改善代码库中被改变的区域。随着时间的推移，代码库的更多部分将得到改善。

过渡到微服务
传统的应用程序有一个单体架构，所有的模块都被打包成一个单元。

将单体应用转换为分散的基于微服务的架构可以解决传统单体中存在的大量问题。微服务是独立的、自成一体的微型服务，可以单独部署。这一部分将在本文后面详细介绍。

遗留程序现代化的策略
对于遗留问题的现代化，有多种战略选择可以采用：

封装。通过封装其数据和功能，利用和扩展应用程序的功能，通过API使它们成为可用的服务。

重新托管。将应用程序组件重新部署到另一个结构（物理、虚拟或云），而不修改其代码、特征或功能。

重新平台。重新安置到一个新的运行时平台，对代码进行最小的修改，但不修改代码结构、特征或功能。

重构。重组和优化现有的代码（尽管不是其外部行为），以消除技术债务并改善非功能属性。

研究架构。从实质上改变代码，使其转向一个新的应用架构，并利用新的和更好的能力。重建。重新设计或从头开始重写应用程序组件，同时保留其范围和规格。

替换。彻底消除以前的应用组件，并替换它，同时考虑新的要求和需要。

将遗留问题转换为基于云的微服务架构
在上述方法中，最好的是使用重构和重新架构的组合，从长远来看，这可以说是最有效的技术。同时，它也带来了一些不确定因素和技能及专业知识。这种策略可以在云上托管的微服务架构的帮助下实施。

让我们看看微服务迁移策略的一些技术方面：

      打包。与其将相关模块捆绑在一起，不如将这些模块拆成独立的包。这涉及到对代码的微小改动或更多的静态内容。
      容器。应用 "每个服务的容器 "部署模式，将其打包到独立的服务器空间，或者最好是自己的容器。
DevOps：一旦所有的组件被分解，你可以通过一个自动化的交付管道来管理每个包。我们的想法是独立构建、部署和管理。

策略1 Strangler模式
      今天，Strangler模式是一种流行的设计模式，通过用新的服务取代特定的功能，将单体应用逐步转化为微服务。一旦新功能准备就绪，旧的组件就会被 "扼杀"，也就是退役，而新的服务就会被投入使用。任何新的开发都是作为新服务的一部分完成的，而不是单体的一部分。

策略2 领域驱动设计
      领域驱动设计是一种有效的模式，用于构建具有复杂和不断变化的业务需求的软件。大多数组织都处于这种情况，因为他们有复杂的业务流程，并在不断发展，变得更加复杂。领域驱动设计（DDD）是由Eric Evans在2003年提出的一种软件开发方法。它要求了解将为之编写应用程序的领域。创建应用程序所需的领域知识存在于了解它的人身上：领域专家。

一般的迁移有三个步骤：

停止向单体应用添加功能
将前台与后台分开
将单体分解并解耦为一系列的微服务

---

今天先到这儿，希望对云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管管，团队建设 有参考作用 , 您可能感兴趣的文章:
领导人怎样带领好团队
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。