我有一个现有的遗留.Net webApi项目,每个项目包含~20个控制器和~10个方法。 流量是每秒15个请求。 我想知道采用microServices方法并将其分成几个托管项目是否明智。
由于我无法访问客户端(android,ios,WebSite和第三方),我必须保持现有的API URL工作(http://domainName/API)。
我快速而肮脏的架构是: 1)构建新的托管API流程http://domainName/API1,http://domainName/API2,http://domainName/API3 ... 2)请客户友好地使用新的URL 3)http://domainName/API将作为背景竞争的新流程的路由器
想法?那有没有现有的模式?
答案 0 :(得分:1)
我想知道采用microServices方法并将其拆分为少数托管项目是否明智。
这在很大程度上取决于您今天遇到的组织痛苦程度。您的开发团队是否会通过协调整体开发以及整体块不同部分之间依赖关系引起的问题而失去大量时间?你的巨石需要几个小时才能建成?您的企业会从更快的版本中获益吗?如果答案是肯定的,那么你应该考虑切换到微服务。如果答案是否定或可能,那么你要么设计精良/正常工作,要么改变压力很小。将整体重构为微服务很可能非常昂贵,您必须进行成本/收益计算。这是good read和this too。
想法?是否存在任何现有模式?
我发现这篇文章是关于how to change a monolith的一般指南。此外,还有一些关于一些大公司(Amazon1,Amazon2,Soundcloud,Netflix)体验的资源。
简而言之:
avoid a big bang
重构,尝试一次性更改整个整体或大部分。识别整块中的模块,这些模块在重构为微服务时会带来最大的好处。
首先更改与应用程序的接口,而不更改底层实现(对于最高价值的模块/服务)以反映独立服务。
更改后的接口让您可以按自己的节奏自由地重构实际实现。