Wul*_*nto 9 architecture n-tier-architecture n-layer microservices
我有一些关于整体和n层架构的问题.
首先,Monolith和n Layer架构之间的区别是什么？
其次,假设我有一个Visual Studio解决方案,它包含多个项目,例如:
那被认为是Monolith还是n层架构？
如果我有微服务(包括说)3 Web API并且我在单独的Visual Studio解决方案中构建每个服务,那么可以实现我以前的项目结构(服务层,业务层,数据层等)吗？
非常感谢你,抱歉我的英语不好.
Pur*_*ome 16
好吧,所以Monolith解决方案是基本上在一个解决方案中拥有一个项目的旧方法,其中包含所有代码.
所以,假设你正在做一个网站.
这意味着您将使用单个项目和所有数据库调用(持久性),逻辑(业务逻辑/服务)创建单个解决方案,并最终确定如何以混乱的方式混合显示计算数据(表示)在那个单一的项目中.有时人们试图将问题分成文件夹,但通常这是一个很大的混乱.这使得应用程序的支持/维护成为一场噩梦.如果您希望对网站/应用程序进行一次更改,整个应用程序将脱机/重新启动.
VS
n-tier / n-layered解决方案/应用.这就是我们在一个解决方案中有多个项目(通常)的地方,它将我们的应用程序的关注点分成更小的组件.这使我们能够将问题空间保持在一个区域,使其更易于维护和支持.这样还可以更轻松地将各种组件/项目/ dll 重用到应用程序的各种其他子系统中.它比旧的整体架构模式更好.但是,如果您希望对网站/应用程序进行一次更改,整个应用程序将仍然脱机/重新启动.
最后,我们有microservices.这是一个更现代的概念,并继续发展monolith -> n tier -> microservices.这时我们将应用程序问题分解为单个应用程序,这样当需要更新一个微服务时,整个应用程序就不会停止.当然,依赖于微服务的应用程序部分可能会停止/受到影响,但整个应用程序可能不会受到影响.
让我们举一个例子:
我有一个销售宠物(猫/狗/等)的网站.我可能将此网站拆分为单独的微服务迷你网站:
所以每个都是一个网站,就像n层架构的应用程序一样.所以它会有一个表示层(MVC网站).一些数据库项目和一些基本服务.
现在,4个微服务(迷你网站)中的每一个都做到了.
现在,您需要使用网站的管理部分更新一些内容.你离线,主网站保持不变.人们仍然可以浏览和购买动物.
所以是的,如果你的应用程序足够大,它有你可能想要分割的区域,那么实现微服务是一件好事.它确实增加了一些复杂性,但它也带来了它自身的优势.
是的,如果您的应用程序不是一些愚蠢的hello-world应用程序或某些研究项目,那么您的微服务应该遵循n层模式.