什么时候转向微服务架构才有意义？这是许多组织在评估其现有软件技术架构以提高敏捷性时面临的一个紧迫问题。

作为一个行业，房地产是地方性的。每个州都做同样类型的生意，但方式不同。 房地产是美国第六大房地产经纪公司，也是全球第一家基于云端的房地产公司，这意味着要更新其关键任务业务应用程序 eXp Enterprise。

eXp 代理、承包商和员工使用基于云的应用程序 eXp Enterprise 开发于 Mendix 平台，开展入职和交易登记等核心业务活动。eXp 最初在单片架构上构建了该应用程序。

然而，为了保持竞争力，eXp Realty 工程副总裁 Steve Ledwith 发现需要将应用程序从单体架构重新架构为微服务。考虑到 eXp 的业务遍及全美 50 个州，这次重新架构对公司来说是一项艰巨的任务；但通过确立愿景、获得所有利益相关者的支持并为其开发人员提供支持，eXp 将这个业务关键型应用程序迁移到了微服务。

企业级变革的必要性

多年来，eXp 的业务从 2,500 名代理商发展到 18,000 名代理商。因此，eXp Enterprise 的功能、用户群和托管要求也随之增加，导致 技术债务 这是莱德维斯需要解决的问题。

正确的方式还是现在？

在发布时，eXp Enterprise 有 30 个功能。在不到两年的时间里，eXp 为该应用程序添加了 1,700 个功能，每天有 2,000 名用户使用该应用程序。要管理如此规模的用户群中的这些功能，需要 Ledwith 所称的“立即”方法或对应用程序进行临时开发，以满足即时的业务需求。Ledwith 对这个问题进行了很好的总结，他说：

“因此，我们没有按照正确的方式去做，而是直接去做，而且缺乏很多投入，”莱德维斯说。

对于数据库域模型， Mendix-way 规定了一个干净的模型 – 一个或两个实体和模块。但是，eXp 的代理数据库域模型（其中包含有关代理的信息）是紧密耦合的。

让我们看一些数字：

• 在数据库的一个区域中，eXp 有超过 6,000 个连接。
• 代理实体有 140 多个属性。最佳实践是 20 个。
• 该实体有七个计算属性。因此，每当用户加载代理信息时，该应用程序就会为 126,000 名代理计算约 18,000 个字段。
• 房地产交易涉及的流程多种多样，从签署文件和合同到合规性跟踪、生成审计文件等等。处理一笔房地产交易只需五到六分钟，每天大约有 100 笔交易，eXp 的员工从周一到周日全天工作，只为处理这些交易。

托管挑战：灭霸来了

eXp Enterprise 要求重型 云资源.eXp 最初将应用程序托管在 Mendix Cloud v3。每天有 2,000 名用户，并且具有多种特性和功能，因此其容量很快就超出了其承受范围。

为了解决这个问题，eXp 将应用程序迁移到 Magneto，这是 Mendix Cloud v4。在 90% 的云资源使用率下，Magneto 似乎可以正常工作。但 eXp 也很快耗尽了这个容器。此后不久， Mendix 创建了 Thanos，这是 Ledwith 用于托管 eXp Enterprise 及其企业微服务架构的云容器。

突破 Cloud Foundry 的极限

在规划婴儿食品行业的工艺要求时，安全性和可靠性是工艺设计中最重要的方面。 Mendix 升级 Cloud Foundry 以 Mendix 平台，一切进展顺利 Mendix 用户，除了 eXp Realty，其应用程序破坏了 Cloud Foundry。

eXp 将启动该应用程序，由于其功能众多， 连接，用户应用程序就会失败。正如 Ledwith 所说，“我们的应用程序会启动，我们会让所有用户使用它，然后它就会崩溃。我们会重新启动它，他们大约每两个小时就会再次这样做。”

据莱德维斯称，他从 Mendix 云团队表示，1,000 个线程远远超出了合理的范围 Mendix 平台，所以它没有被测试到。eXp Enterprise 在高峰期每天全天运行 1,250 个线程。Ledwith 需要重新考虑重构应用程序以减少线程数量。

从“现在”到“正确的方式”——微服务

工程团队由大约 80 名开发人员组成，其中 30 名是全职专业人员 Mendix 开发人员——支持 eXp Enterprise 的大规模增长。虽然 eXp 可以继续组建团队来支持该应用程序，但他们很快意识到这个过程并不 可扩展性。eXp 还尝试了其他选择，例如购买更多云容器、重构以及尝试使用中心辐射型架构来改善这种情况，但事实证明这些都不是长期的解决方案。

管理层给了 Ledwith 的团队两周的时间来研究并提出可行的解决方案。他们最终选择了微服务。

正确方法 #1 | 获得支持

当 Ledwith 和他的团队改变技术基础设施时，了解业务痛点并 买进 不仅来自技术团队或管理团队，还来自包括工程、产品和主题专家在内的团队。

事实上，Ledwith 和他的团队花了近两个月的时间向不同的业务团队宣传微服务理念。业务团队的意见对于 Ledwith 来说至关重要，可以确保变革专注于业务的真正需求和价值。

正确方法 #2 | 三管齐下的方法

Ledwith 提出了三头策略来实现微服务。

战略目标

• 帮助业务扩展到 100,000 名代理并实现创新。
• 支持数千 第三方整合 获取房地产公司帮助其代理商销售所需的客户、房源和财务数据。

架构原则

• 建筑帮助指南 治理 降低复杂性——使用正确的工具来实现正确的目的，实现快速开发和反馈

设计和交付

• 限制共享代码，以便不同团队可以更改其应用程序的一部分，而不会影响其他团队。如果某些内容对其他团队是通用的，他们可以使用内部应用商店来共享通用模块。
• 遵循 CI/CD 框架。

正确方法 #3 | 创新团队

eXp 增强了敏捷功能团队，该团队由产品经理、开发人员和 QA 专家组成，并组建了一支包括业务人员在内的创新团队。业务团队着眼于更大的前景 — 如何创造价值、增加收入、减少客户流失并寻找自动化机会。

创新团队拥有他们开发的服务。现在，当团队投入生产时，他们无需将工作移交给运营团队或维护团队，而是在整个生产和维护过程中拥有自己的工作。

正确方法 #4 | 企业微服务思维

Ledwith 认为，树立正确的心态是整个重构过程中取得成功的最重要因素。交付具有真正商业价值的企业级软件需要规划、人才、投入、逻辑、 反馈并精心执行，始终关注业务的真正需求。