从单体应用到微服务：使用 NGINX 打破孤岛的基础指南

NGINX 内容编辑

2020-06-26

孤岛，成为了当今企业面临的最大痛点之一。

本文分享了来自赛默飞世尔科技公司前产品负责人 Carlos Ponce 的专家建议，他介绍了弃用单体应用的好处以及使用 NGINX 过渡到微服务的基本步骤。

单体架构阻碍现代化开发

尽管开发团队正竭力追随新技术的发展脚步，满足消费者的期望，但单体系统已成为创新和创造新收入路上的绊脚石。

Carlos 表示：“传统企业和机构倾向于维护大型单体应用，因为它们维系着企业和机构的大量业务收入。与此同时，这些单体应用连接孤立的平台，阻碍了当前的开发进程。”

随着单体应用的规模和范围不断扩大，它们的代码通常也会变得紧密耦合，很难进行扩展或更改。单体系统的互连模块不仅会拖慢开发速度，而且每次部署新功能时都面临着较高的失败风险。

现在，公司的排名取决于将创意转化为产品并为客户创造新价值的速度。事实上，80% 的企业希望靠客户体验 (CX) 来取胜。而现实是残酷的，单体系统阻碍了持续部署和交付，经常让应用团队错过关键的上市窗口。

相比之下，那些借助 DevOps 和敏捷方法交付技术服务的公司提高了竞争标准。

举例来说，大约在十年前，亚马逊过渡到了 DevOps，将物理服务器迁移到了亚马逊云科技 (AWS) 云平台。到了 2015 年，他们每天能够对开发、测试和生产主机进行 5,000 万次部署，即平均每秒一个。那么亚马逊开发人员现在能做什么，我们可想而知。

Carlos 指出：“这类似于 20 世纪 80 年代的制造业革命，那些采用精益原则控制质量、收集更好的反馈并提高了生产力的公司获得了更多的市场份额，而那些没有跟上时代脚步的公司则纷纷倒闭或遭受重创。”

“今天，同样的故事正在上演 —— 这一切都归结于更快速、更可靠的部署。拥有大型单体应用的公司无法随时根据需要交付新功能。”

持续交付、不断试验和收集客户反馈对大型企业未来取得成功十分重要。对于许多企业来说，这意味着从单体架构过渡到微服务。

最好的迁移策略是什么？

Carlos 认为，企业需要重点考虑三点：

毫无疑问，过渡到微服务需要非常仔细和全面的规划。但是我们首先得确定它是正确的选择。瓦解单体系统不仅是一项重大的工程技术投资，而且通常需要进行更广泛的结构转变，统一组织的愿景、目标和人员是获得成功的先决条件。

Carlos 建议企业先花一点时间，好好做一次评估。“你需要仔细地分析迁移到微服务是否值得。例如，如果你实施了微服务，却没有采用敏捷方法，那么你将无法真正获得这种迁移的优势。”

当公司决定迁移到微服务架构时，应用设计和架构的最大变化是功能组件之间通过网络进行通信，而单体应用则是在内存中进行通信。因此，在迁移应用或启动绿地项目时，正确设计和实施网络通信至关重要。

Carlos 建议使用 NGINX 微服务参考架构（MRA），这是一套现成的模型，能够帮助企业创建微服务应用。

Carlos 解释道：“自微服务兴起以来，NGINX 就深耕这一领域，它的高性能、轻量和灵活等特性使其成为微服务的完美之选。

它的模型有简单也有复杂：

代理模型 —— 一种简单的网络模型，适用于将 NGINX Plus 实施为微服务应用的控制器或 API 网关。如果单体应用非常简单，这是一个不错的选择。
路由器网状模型 —— 一种更稳健的网络方法，在每个主机上都配置一个负载均衡器，并管理系统之间的连接。该模型非常适合较复杂的单体应用。
结构模型 —— 该模型在每个容器中都嵌入 NGINX Plus 充当正向和反向代理。它适用于高负载系统，支持所有级别的 SSL/TLS，并通过 NGINX Plus 提供服务发现、降低延迟、实现持久的 SSL/TLS 连接。