use*_*512 7 architecture api rest soa
目前我们有一个巨大的API,我们的后台,我们的前端,以及我们的公共API使用.
这引起了很多麻烦,因为在构建新端点时,我发现代码中有很多特定于应用程序的逻辑,我不一定要在我的端点中包含这些逻辑.例如,创建用户的代码可能包含发送欢迎电子邮件的代码,但由于后台端点不需要,因此我需要添加没有该逻辑的新端点.
我正在考虑使用大型重构来将我们的代码库分解为许多较小的高度特定的服务API,然后在这些API之上构建一组小型应用程序API.
因此,例如,创建新用户的应用程序端点可能会在重构后执行以下操作:
customerService.createCustomer();
paymentService.chargeCard();
emailService.sendWelcomeEmail();
应用程序和服务API将是完全独立的代码库(可能是每个服务单独的代码库),它们也可以使用不同的语言构建.它们只会通过REST API调用进行交互.它们将位于同一个本地网络上,因此延迟不应该是一个大问题.
这是一个坏主意吗？我以前从未见过/曾经在将两者分开的代码库上工作,所以也许有更好的架构来实现我正在寻找的灵活性和可维护性？
建议,链接或评论都将不胜感激.
小智 1
\n\n\n这是一个坏主意吗？
\n
不，但这是一个很大的总体问题，需要能够提供非常具体的建议。
\n\n我想将其分为三个区域：
\n\n逆向工作，技术是最后也是最具体的部分，完全取决于您当前的环境（平台、技能），并且（希望）一旦其他事情进展顺利，对您来说将是合理的不言而喻。
\n\n该设计很好的最终状态 - 拥有多个、具体、集中的 API，每个 API 都有自己的职责。同样，设计的细节将取决于您和您的组织的技能以及您拥有的现有平台。例如，如果您已经在使用 TIBCO（例如）并且投入了大量资金（许可证、平台、工具、人员），那么利用他们发布的一些模式/设计/模板是有意义的；但（可能）如果您还没有接触过 TIBCO，则不会。
\n\n抽象而言，REST API 服务似乎是一个很好的起点 - 在系统的各个级别都有很多用于安全、部署、监控、可扩展性等的工具和平台。如果你是 NGINX 用户，他们有很多关于如何做到这一点的（与平台无关的）想法也在NGINX 博客中，包括一些关于可扩展性和性能的聪明的想法。如果您更具冒险精神，并且拥有一支聪明、热心的团队，请查看事件驱动架构 - 请参阅此
\n\n方法（或过程）是这里的关键。归根结底，这是一次重构，尽管你对“大型重构”的描述确实让我有点害怕 - 这么说吧，听起来你正在谈论一个大爆炸性的变化并称之为重构。也许这只是语言，但我想到的是“将‘一个巨大的 API’演变成多个、特定的、集中的 API（通过重构架构）”。可以从Martin Fowler开始，虽然这本书是关于重构软件的，但原理和方法是相同的，只是处于更高的层次。事实上，他在这里谈论的就是这个
\n\nIBM 谈论重构微服务，并使其听起来很容易一步完成，但事实并非如此（在实验室之外）。
\n\n您有一个现有的 API，为多个内部和外部客户端提供服务。我建议您希望为这些客户保持此界面的稳定性 - 将实现的重构与与外部系统/组联络和协调的其他问题分开。我的高级起始方法是：
\n\n在未来的某个时候，由于其他业务驱动的需求，发布到后端、前端和/或公共客户端的 API 可能会发生变化，但这是一个完全不同的项目。
\n\n正如您所看到的，如果 API 很大（1,000 个方法 => 140 个版本），这将是一个数月的过程，并且具有合理的频繁发布计划非常重要。而且，改进可靠工作且永不更改的代码可能没有任何价值，因此现有 API 的（可能）很大一部分可能会保留，只是被新 API 包装。
\n\n其他考虑因素：
\n\n我能给出的最大的4 条建议可能是：
\n\n| 归档时间： |
|
| 查看次数： |
417 次 |
| 最近记录： |