Xzizz Asked:2023-07-25 21:25:39 +0000 UTC2023-07-25 21:25:39 +0000 UTC 2023-07-25 21:25:39 +0000 UTC 服务、微服务、控制器——什么是什么？ 772 我经常看到服务、微服务、控制器、存储库等词。 它是什么？在哪里解释的？他们在哪些书中写到了它？ 这适用于建筑吗？去哪里看？ c# 1 个回答 Voted Best Answer tym32167 2023-07-28T01:35:08Z2023-07-28T01:35:08Z 我不会假装是最终的真相，但我会说出我的理解。 在编程中，就像其他地方一样，他们遵循“分而治之”的原则与复杂性作斗争。 因此，当我们开发复杂的系统时，我们将它们划分为更小的子系统，我们划分更小的子系统并继续划分，直到得到无需进一步划分即可解决的最小问题。 例如，我们可以想象某种大型系统“企业管理”，它已经分为以下类型的子系统 会计 仓库和会计 人员管理 员工门禁系统 客户服务系统 其他一些子系统。 每个子系统都可以包含其自己的子系统，依此类推。如果我想描述架构，那么我通常会在子系统已经是单个应用程序的那一刻停止划分子系统。对于单个应用程序，我的意思是它通常具有用于业务逻辑的单个代码库，并且完全部署到服务器。也就是说，您不能只部署应用程序的一半并说它可以工作 - 您要么完全安装它，要么根本不安装它。但是，这将再次成为一个逻辑块，我将不再将其划分为系统架构图。 作为示例，“客户服务系统”可以包含“订单服务”形式的“客户订单服务”子系统。订单服务不再分成部分，因为它是最后的。我知道我的解释有点令人困惑，因此，为了清楚起见，我正在谈论 C4 模型的第三层https://c4model.com/ 所以，这里重要的是要理解“订单服务”更多的是一个逻辑概念。也就是说，某种软件集，它们一起服务订单。通常它只是一个.net应用程序+数据库之类的东西，但有时它是一个应用程序+数据库，+某种队列、触发器、云服务组件等等。 所以服务是一个逻辑概念。 这是一个复杂的系统。他们将其分解为子系统，子系统分解为服务。因此，复杂系统是一组互连的服务。一般来说，这称为 SOA 或面向服务的架构。 该集合需要以某种方式得到支持和开发。那么问题是：如何组织服务，以便于开发、添加新服务、删除旧服务，使系统能够不断更好地运行？然后他们提出了某些规则，比如类的模式，只有这些规则是针对服务的，但原理是相似的。比如服务应该负责一件事，服务应该有自己的数据库等等。满足这些要求的服务称为微服务。 就像只有代码一样，并且有“纯代码”（参见罗伯特·马丁的书）。另外，以此类推，只有面向服务的架构，还有微服务架构。事实上，任何微服务架构都是面向服务的，但反之则不然。总而言之：微服务架构是一种将系统分解为服务的方法，遵循微服务的一些规则。 现在谈谈服务。假设该服务是一个 asp.net 应用程序。该应用程序最终是类的组合。每个班级都有自己的目的。例如，存储库类通常提供将某些数据读/写到某种存储（例如数据库）的访问权限。要了解更多信息，请阅读有关设计模式的书籍。 除了单个类的设计模式之外，还有一些架构模式可以帮助将应用程序的某些部分划分为一组相关的类。相同的 MVC 模式 - 模型-视图-控制器 - 将您的应用程序分为 3 个部分 - 模型、视图、catroller。模型是保存数据的类，视图是显示数据的类，控制器是模型和视图之间的绑定并调用所需的业务逻辑。要了解更多信息，请阅读 MVC、MVP、MVVM 等架构模式。 之前，我们是从上到下，现在，为了巩固，我们是从下到上。 因此，在最低级别我们有代码、类。 类/代码形成服务。服务是一个逻辑概念，实际上它是一个整体来考虑的东西，划分成更小的服务是没有意义的。如果某些服务满足特定标准，则可以将其视为微服务。如果系统中的所有服务都是微服务，那么您就拥有了微服务架构。如果没有，那就只是面向服务的架构。 服务形成子系统。子系统负责某些类别的任务。输入“会计”或“与客户合作的系统”。 子系统形成系统。系统已经是这样一个东西，可以满足你在某个领域的所有需求。例如，在企业管理方面。 没有明确的等级，例如嵌套子系统的数量。您可以看到 System-Subsystems-Subsystems-Services-Code 以及 System-Services-Code。 我希望我能够澄清一些事情，而不是让它变得更加混乱。=) 对于印刷错误，抱歉，如果有人不是太懒的话 - 正确。
我不会假装是最终的真相，但我会说出我的理解。
在编程中，就像其他地方一样，他们遵循“分而治之”的原则与复杂性作斗争。
因此，当我们开发复杂的系统时，我们将它们划分为更小的子系统，我们划分更小的子系统并继续划分，直到得到无需进一步划分即可解决的最小问题。
例如，我们可以想象某种大型系统“企业管理”，它已经分为以下类型的子系统
每个子系统都可以包含其自己的子系统，依此类推。如果我想描述架构，那么我通常会在子系统已经是单个应用程序的那一刻停止划分子系统。对于单个应用程序，我的意思是它通常具有用于业务逻辑的单个代码库，并且完全部署到服务器。也就是说，您不能只部署应用程序的一半并说它可以工作 - 您要么完全安装它，要么根本不安装它。但是，这将再次成为一个逻辑块，我将不再将其划分为系统架构图。
作为示例，“客户服务系统”可以包含“订单服务”形式的“客户订单服务”子系统。订单服务不再分成部分，因为它是最后的。我知道我的解释有点令人困惑，因此，为了清楚起见，我正在谈论 C4 模型的第三层https://c4model.com/
所以，这里重要的是要理解“订单服务”更多的是一个逻辑概念。也就是说，某种软件集，它们一起服务订单。通常它只是一个.net应用程序+数据库之类的东西，但有时它是一个应用程序+数据库，+某种队列、触发器、云服务组件等等。
所以服务是一个逻辑概念。
这是一个复杂的系统。他们将其分解为子系统，子系统分解为服务。因此，复杂系统是一组互连的服务。一般来说，这称为 SOA 或面向服务的架构。
该集合需要以某种方式得到支持和开发。那么问题是：如何组织服务，以便于开发、添加新服务、删除旧服务，使系统能够不断更好地运行？然后他们提出了某些规则，比如类的模式，只有这些规则是针对服务的，但原理是相似的。比如服务应该负责一件事，服务应该有自己的数据库等等。满足这些要求的服务称为微服务。
就像只有代码一样，并且有“纯代码”（参见罗伯特·马丁的书）。另外，以此类推，只有面向服务的架构，还有微服务架构。事实上，任何微服务架构都是面向服务的，但反之则不然。总而言之：微服务架构是一种将系统分解为服务的方法，遵循微服务的一些规则。
现在谈谈服务。假设该服务是一个 asp.net 应用程序。该应用程序最终是类的组合。每个班级都有自己的目的。例如，存储库类通常提供将某些数据读/写到某种存储（例如数据库）的访问权限。要了解更多信息，请阅读有关设计模式的书籍。
除了单个类的设计模式之外，还有一些架构模式可以帮助将应用程序的某些部分划分为一组相关的类。相同的 MVC 模式 - 模型-视图-控制器 - 将您的应用程序分为 3 个部分 - 模型、视图、catroller。模型是保存数据的类，视图是显示数据的类，控制器是模型和视图之间的绑定并调用所需的业务逻辑。要了解更多信息，请阅读 MVC、MVP、MVVM 等架构模式。
之前，我们是从上到下，现在，为了巩固，我们是从下到上。
因此，在最低级别我们有代码、类。
类/代码形成服务。服务是一个逻辑概念，实际上它是一个整体来考虑的东西，划分成更小的服务是没有意义的。如果某些服务满足特定标准，则可以将其视为微服务。如果系统中的所有服务都是微服务，那么您就拥有了微服务架构。如果没有，那就只是面向服务的架构。
服务形成子系统。子系统负责某些类别的任务。输入“会计”或“与客户合作的系统”。
子系统形成系统。系统已经是这样一个东西，可以满足你在某个领域的所有需求。例如，在企业管理方面。
没有明确的等级，例如嵌套子系统的数量。您可以看到 System-Subsystems-Subsystems-Services-Code 以及 System-Services-Code。
我希望我能够澄清一些事情，而不是让它变得更加混乱。=)
对于印刷错误，抱歉，如果有人不是太懒的话 - 正确。