升级遗留代码的最佳实践
云栖号资讯:【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!
在传统企业甚至互联网企业中往往存在大量的遗留代码,这些遗留代码大多都能够正常工作,有的可能还运行着关键业务或者持有核心数据。但是,大部分遗留代码通常经常存在技术陈旧、代码复杂、难以修改等特点。随着时间的推移,遗留代码的维护和管理的成本越来越大。在全面转型微服务的今天,这些遗留代码该如何处理呢?Tomasz Kania-Orzeł 为我们阐述了升级遗留代码的最佳实践,我相信,这篇文章对于拥有大量遗留代码的企业 / 组织很有借鉴意义。
“我在 Ruby on Rails 上有一款可以追溯到 2011 年的应用,在过去五年来没有添加任何新功能。而且它现在运行死慢死慢的,随着我们用户群不断地增长,它已经几乎不能提供服务了。您能帮我们解决这个问题吗?”
这是我在 Monterail 的客户那儿遇到的最常见的情景之一。这种难以维护且存在安全漏洞的遗留代码,对于必须使用它的企业,以及必须处理它的开发人员(比如我们)来说,真不啻噩梦一场。在我担任软件工程师十年左右的时间里,有过很多机会让我得以观察一些开发人员为了更新 Web 应用程序中的遗留代码而进行的技术转变,这些技术转变有成功,也有失败。例如,这可能意味着,从某个框架的版本 2 升级为版本 6,或者从 Ruby 变更为 Python,或者从单体应用转变为微服务架构,或者从手工构建更改为持续交付。为了完成一次无痛(或至少不那么痛苦)更新,你必须确定进行更改是否有必要,确定最合适自己的方法并承诺长期践行。
应该何时进行变更?
糟糕的性能是做出技术变更的原因。另一个原因就是你所使用的技术的普及程度逐渐或突然下降了。毕竟,如果市场上能够支持你工作的开发人员越来越少,那么你的技术存在被封闭的风险就越来越大。有些人早在 2010 年就用 Backbone 构建了他们的应用程序,如今却在努力解决“模型 - 视图 - 控制器”的问题,而其他人都在使用基于组件的框架,如 React 或 Vue 等。如果你选择的框架正在失去积极的支持,那么风险就会更大。还记得 AngularJS 吗?2018 年 7 月,它就进入了长期支持阶段,这意味着 Google 不会再合并新的功能或修补程序,哪怕是一个微小的突破性改动。
译注:“模型 - 视图 - 控制器”(Model–view–controller,MVC),是是软件工程中的一种软件架构模式,把软件系统分为三个基本部分:模型(Model)、视图(View)和控制器(Controller)。MVC 最早由 Trygve Reenskaug 在 1978 年提出,是 Xerox PARC 在 20 世纪 80 年代为程序语言 Smalltalk 发明的一种软件架构。MVC 的目的是实现一种动态的程式设计,使后续对程序的修改和扩展简化,并且使程序某一部分的重复利用成为可能。除此之外,MVC 通过对复杂度的简化,使程序结构更加直观。
当你的技术在人力或机器成本方面过于低效、过于昂贵,这不仅是发起技术变更的一个好机会,而且也可能是你在技术变得不可挽回之前修复它的最后机会。你永远不会想达到这样的地步:创建一个新功能是完全不可行的。欧洲电子商务公司 Zalando 正努力快速扩展其单体 PHP 应用程序,却 无法以快速或高效的方式提供新功能。这促使他们在 2016 年从单体架构应用转向微服务,使不同的团队能够以更快的速度交付功能。
应该如何进行变更
一旦确定你正在开发的产品需要升级,那么就是时候对变更方向做出明智的决定了。代码一旦编写就会成为遗留代码, 没有人能保证你当时编写所用的技术在未来不会失去支持或变得过时。(安息吧,AngularJS。)因此,变更应该支持未来的灵活性。以下是一些选项:
选项一:大爆炸式的重写
第一个也是最明显的选项,就是大爆炸式的重写:从头开始更改代码库,并在一次转换中切换所有用户。但是,完全重写是非常耗时的,而且必然也会产生相当巨大的成本。你也有可能最终得到的是一款在几个月甚至几年内都不适合发布的应用程序,并且在这个过程结束之前,你都无法看到最终结果。另外,应用程序越大,开发者在重写过程中提供维护和添加新功能的难度就越大。如果有文档和技术知识的话,向大型代码库添加新功能就像在公园里散步一样简单。若没有这些的话,要做到这些,真的很难。
选项二:凤凰涅槃
第二个选项是在现有代码库中添加使用新技术构建的新功能。理想情况下,你不应该触及旧技术,而应该将所有新功能分离开来。但不幸的是,这样的原始结果相当罕见:新功能几乎总是需要与旧功能集成。这也需要一个详细的计划,因为事情很复杂,没有周密计划的话很难做好。在复杂的架构中创建新的组件,需要大量关于遗留应用程序中组件运行情况的信息。你需要一个广阔的视角,从新旧两个角度看待这项技术。
使用单体应用程序,你可以在单独部署的新代码库中创建新功能,同时使用与新代码和遗留代码交互的单个数据库来存储数据。这个解决方案看起来很简单,但它能否取得长期成功,要取决于你的承诺是否坚如磐石。(特别是当你的整体系统受到机器性能或并发性问题的影响时,就需要考虑这些问题。)例如,如果你的单体应用程序开始获得更多的用户,那么,单个数据库可能会成为瓶颈。(另一方面,云端中的数据库可以扩展。)由于原始代码库的长期脆弱性,特别是考虑到潜在的安全漏洞或 bug,这种架构并不能持久。实际上,让过时的代码保持原样就意味着你在等待它最终永远失败。
选项三:混合方法
重写整个代码库是一个极端的想法,而且往往考虑不周。在旧代码库上添加新功能更可行,但会带来严重的副作用,例如,如果你的遗留代码是基于较旧的框架版本,那么就会出现安全问题。那么,还有什么事情是你可以做的,而且不那么昂贵,或者不那么危险的? 你还有其他选择吗?
我推荐一种混合方法。这一选项,就像大爆炸式重写一样,也需要对整个旧代码进行变更。但与第一种选项不同的是,重写应该是在一段时间内展开(比如说几年),以最大限度地减少技术债务和财务成本。这种渐进式方法将基于你的愿景,这一点至关重要。你需要知道首先要改变什么:有些功能是核心的,对业务至关重要,而其他功能则更多的是扮演辅助角色。有了明确的目标,在多个层面上工作就会变得更容易。例如,你是否仍然计划在这个转换过程中发布一项新功能?如果是这样的话,你就需要在计划中考虑到这一点。如果没有清晰的路线图,你的代码最终将会变得一团糟,这将会使开发者更难理解。
对我来说,这种方法关乎未来和可扩展性:而且它最容易使用微服务来实现。假设你的遗留代码库是新的微服务生态系统中的一个元素。当然,它太过于庞大,过于复杂,不可能是真正的微服务,但它可以像微服务一样与新功能进行通信。为了处理这种安排,你需要创建 API 或“桥”这样的接口,以允许遗留代码与新技术进行通讯。当你以单独的微服务形式添加新功能时,它们将会一点一点地吞噬遗留代码的业务逻辑。虽然你可以通过向遗留的单体应用程序添加新功能来实现类似的功能,但此举可能会造成技术债务,并失去灵活性。
几乎所有的解决方案都有副作用,包括这种方法。但是我们需要知道如何将副作用最小化。对于 Web 应用的前端,反向代理可以缓和这一变更带来的副作用。使用这种方法,你甚至可以在不触及遗留软件的情况下,替换 Web 应用中为单个 URL 提供服务的逻辑。但这种技术有其自身的要求,例如,如果你有用户登录的话,就应该维护页面之间的状态。我们始终需要存储状态,但在这个解决方案中,我们需要在两个应用之间移动或共享状态。这很难维护,但你还是可以得到更具弹性的基础设施。
更复杂的更改需要对基础设施进行改进,比如,创建一个前端服务器层,你可以从其中呈现来自不同源的应用程序片段,如上面的微服务示例。基于 XML 的标记语言 ESI(Edge Sides Includes)可能适合这项任务,而 Varish 或 Nginx 然后,为了确保你的应用在用户群增长时能够保持性能,请创建负载均衡器和基于上下文的独立数据库,这些数据库在微服务或宏服务中单独使用。
创造一个能够支持这种安排的灵活环境也是一个挑战。转移到微服务时,你只需在基础设施上投资一次,但你将需要进一步支持这种架构的维护。尽管如此,它可能仍然比重写所有代码要便宜得多。
如果你的主要目标是创建一个易于维护的生态系统(而不是关注性能第一,维护第二),你还需要在开发过程中确定系统的关键元素,并创建路线图来对它们进行更改。在这个过程中引入一些持续集成和部署的魔法,其中,CI 和 CD 流程可以在没有 QA 或开发人员的帮助就能自动进行,然后你最终将得到一个结构清晰、易于修改和调整的成熟软件。
当然,这种混合方法并不是世界上唯一可行或正在使用的选项。但是,代码库的增量更改最终导致了完全重写,你得以能够使用工作代码,从而使业务保持安全,同时,微服务使不同团队能够独立地交付新的和不同的功能,提供了一个为长期使用而设计的过程和架构。
要做持久的更改需要什么?
你可能会看着我的首选解决方案,然后心想,“嗯,这有点过于工程化了”,或者“我没有一个团队能胜任这种工作”,或者“这对我的平台来说太过于复杂”,或者甚至“这不是纯粹的微服务架构!”我并不反对你这些想法,但我确实认为,升级你的技术将会迫使你作长远考虑。
我提供的并不是快速解决方案。相反,混合方法为你提供了基于工作基础之上的新技术。通过逐步转向微服务,增量更改允许你轻松地更新应用程序,并利用最新的框架,所有这些都不会迫使你在可靠性上作出妥协。那么,你准备好重新构建你的软件了吗?
【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/zhibo立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
令人兴奋的 2020 年人工智能和机器学习趋势
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 人工智能和机器学习是世界上最繁荣和最革命性的两项技术。 这些技术正在进入世界上几乎所有的领域,并将以有趣的方式影响这些领域。 有成吨的理由说明人工智能 ( AI ) 和机器学习 ( ML ) 已成为世界上最受欢迎的技术之一。 这些技术拥有着改变地球运作方式的力量,且毫无疑问在人工智能和机器学习领域中,一些东西正在不断发生。在本文中,我们将讨论几个顶级的人工智能和机器学习趋势,将塑造新年:2020。 我们还将介绍面部识别技术及其在2020年的应用。 人工智能和机器学习将有新的突破 首先,我们要强调的是:与人工智能相关产业规模将在 2023 年达到 979 亿美元。 这意味着人工智能似乎有很大的潜力。 同时机器学习的领域也发生了很多事情。 而且机器学习解决方案和系统的需求也会相当高。 因为,到目前为止,世界上已经有大量的基于人工智能和机器学习的应用诞生。 2020年人工智能和机器学习趋势搜集 基于人工智能的广告和媒体 虽然,大部分 AI 和 ML 已经与企业联系在一起。人工智能当前主要应用于...
- 下一篇
争议“云游戏”:一个几十亿规模的颠覆者?一场徐虎飘渺的幻梦
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 不久前,游戏直播平台斗鱼上线了自己的云游戏平台,并上架了数十款手游、端游,无需下载,玩家即可斗鱼上玩到《DOTA2》《魔兽世界》等端游,以及《王者荣耀》《和平精英》等手游。 但是玩家们的初体验很糟糕,端游服务器容纳量小、排队体验糟糕,游戏中出现的卡顿、bug等问题更是令玩家头疼,引起玩家们的吐槽。 这些或许不是斗鱼的问题,云游戏的概念已经出现了十年,这些问题从从未消失过。 进入2020年,云游戏在国内开始兴起,但,这是一个充满争议的新领域。 投资机构认为,这是一个规模可以达到几十亿的市场;对于斗鱼、B站,乃至爱奇艺这样的平台而言,似乎看到了一个全新的发展机遇;而原教旨主义的游戏玩家,则对云游戏充满了抵触情绪。 未来,你只需要一部手机,或者iPad,就可以玩诸如《刺客信条》《GTA5》这些3A级大作,而不用为此购买一台游戏主机,或是花费上万元配置高性能电脑。 人们寄希望于5G,以及更多技术的进一步成熟,使得云游戏对整个行业带来颠覆性的影响。 今年2月,微软游戏负责人菲尔·斯宾塞在接受采访时...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Red5直播服务器,属于Java语言的直播服务器
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题