对我来说，这种办法关乎未来和可扩展性：而且它最容易运用微效劳来完成。假定你的遗留代码库是新的微效劳生态系统中的一个元素。当然，它太过于庞大，过于复杂，不能够是真正的微效劳，但它可以像微效劳一样与新功用停止通讯。为了处置这种放置，你需求创立 API 或“桥”这样的接口，以允许遗留代码与新技术停止通讯。当你以独自的微效劳方式添加新功用时，它们将会一点一点地吞噬遗留代码的业务逻辑。虽然你可以经过向遗留的单体运用顺序添加新功用来完成相似的功用，但此举能够会形成技术债务，并失掉灵敏性。

简直一切的处置方案都有反作用，包括这种办法。但是我们需求知道如何将反作用最小化。关于 Web 运用的前端，反向代理可以紧张这一变更带来的反作用。运用这种办法，你甚至可以在不触及遗留软件的状况下，交流 Web 运用中为单个 URL 提供效劳的逻辑。但这种技术有其本身的要求，例如，假设你有用户登录的话，就应该维护页面之间的形状。我们一直需求存储形状，但在这个处置方案中，我们需求在两个运用之间移动或共享形状。这很难维护，但你还是可以失掉更具弹性的基础设备。

更复杂的更改需求对基础设备停止改良，比如，创立一个前端效劳器层，你可以从其中出现来自不同源的运用顺序片段，如下面的微效劳示例。基于 XML 的标记言语 ESI（Edge Sides Includes）能够适宜这项义务，而 Varish 或 Nginx 然后，为了确保你的运用在用户群增长时可以保持功用，请创立负载平衡器和基于上下文的独立数据库，这些数据库在微效劳或宏效劳中独自运用。

发明一个可以支持这种放置的灵敏环境也是一个应战。转移到微效劳时，你只需在基础设备上投资一次，但你将需求进一步支持这种架构的维护。虽然如此，它能够依然比重写一切代码要便宜得多。

假设你的主要目的是创立一个易于维护的生态系统（而不是关注功用第一，维护第二），你还需求在开发进程中确定系统的关键元素，并创立路途图来对它们停止更改。在这个进程中引入一些继续集成和部署的魔法，其中，CI 和 CD 流程可以在没有 QA 或开发人员的协助就能自动停止，然后你最终将失掉一个结构明晰、易于修正和调整的成熟软件。

当然，这种混合办法并不是世界上独一可行或正在运用的选项。但是，代码库的增量更改最终招致了完全重写，你得以可以运用任务代码，从而使业务保持安全，同时，微效劳使不同团队可以独立地交付新的和不同的功用，提供了一个为长期运用而设计的进程和架构。

3. 要做耐久的更改需求什么？

你能够会看着我的首选处置方案，然后心想，“嗯，这有点过于工程化了”，或许“我没有一个团队能胜任这种任务”，或许“这对我的平台来说太过于复杂”，或许甚至“这不是地道的微效劳架构！”我并不支持你这些想法，但我确实以为，晋级你的技术将会迫使你作长远思索。

我提供的并不是快速处置方案。相反，混合办法为你提供了基于任务基础之上的新技术。经过逐渐转向微效劳，增量更改允许你轻松地更新运用顺序，并应用最新的框架，一切这些都不会迫使你在牢靠性上作出妥协。那么，你预备好重新构建你的软件了吗？

作者引见

Tomasz Kania-Orzel，是一名阅历丰厚的软件和 DevOps 工程师，最喜欢研讨前端技术。目前在 Monterail 担任技术主管，指导一支由 75 名开发人员组成的团队。

【编辑引荐】

有了这些开源动效项目，设计和开发不再相杀只剩相爱

谷歌将取消I/O开发者大会，国外大公司开启在线形式

这8个锦囊，助你成为一名优秀的Java开发者

你以为这样写Java代码很6，但我看不懂

关于女性开发者的 8 大曲解

(责任编辑：admin)