微服务架构是从业务方法还是技术方法？
我们的团队正试图分离一个单一的spring mvc管理应用程序（创建、更新、删除），我们希望采用基于微服务的架构。
经过一些研究，似乎最好的办法是根据软件的特定部分解决的问题创建微服务，例如管理客户机。
当我们阅读一些定义时，问题就来了，比如维基百科中的以下定义：
微服务体系结构是否应该基于应用程序的分层组织方式来设计？
谢了。
共有1个答案
我喜欢将每个微服务视为自包含的较小的整体。当您强迫自己将遗留应用程序拆分为更小的整体时，您会发现：
>
60%的代码是脚手架，需要在多个服务中重复。
如果您预先建立了一个什么去哪里的规则，那么就更容易拆分事情（并以这种方式维护它们）。
最常见的方法是按功能区域拆分应用程序。为了回答您的问题，我更同意右上方的图像，假设您打算在那里显示多个容器。
关于上面的第1条，通常有一大堆脚手架模块，您可以避免手工编写。
-
本文向大家介绍什么是微服务架构？相关面试题，主要包含被问及什么是微服务架构？时的应答技巧和注意事项，需要的朋友参考一下 在前面你理解什么是微服务，那么对于微服务架构基本上就已经理解了。 微服务架构 就是 对微服务进行管理整合应用的。微服务架构 依赖于 微服务，是在微服务基础之上的。 例如：上面已经列举了什么是微服务。在医院里，每一个科室都是一个独立的微服务，那么 这个医院 就是 一个大型的微服务架
-
理论基础 概念 多微合适 非代码函数 非重写时间 适合团队最重要 独立业务属性 全功能团队 进程隔离 服务运行在独立的进程中 轻量级通信 协议跨平台 格式语言无关 独立性 独立开发 独立测试 独立部署 本质 服务作为组件 围绕业务组织团队 产品驱动而非项目驱动 技术多样性 业务数据独立 基础设施自动化 演进式架构 优点 按需伸缩 独立部署 业务独立 技术多样性 缺点 1. 运维成本高 环境配置（P
-
Kubernetes 设计之初就是按照 Cloud Native 的理念设计的，Cloud Native 中有个重要概念就是微服务的架构设计，当将单体应用拆分微服务后， 随着服务数量的增多，如何微服务进行管理以保证服务的 SLA 呢？为了从架构层面上解决这个问题，解放程序员的创造性，避免繁琐的服务发现、监控、分布式追踪等事务，Service mesh 应运而生。 微服务 下图是Bilgin Ibr
-
问题内容： 我有一个归档过程，该过程基本上是在设置的天数后删除已归档的记录。编写计划的SQL作业或Windows服务来完成删除是否更好？该数据库是mssql2005。 更新： 要说出下面的一些答案，这个问题是关于内部应用程序，而不是分布式产品。 问题答案： 这取决于您要完成的工作。您想将已删除的档案存储在某个地方吗？记录更改？由于SQL作业直接在数据库中运行，因此它应具有更好的性能，但是更容易为数
-
本文向大家介绍微服务架构中的DRY是什么？相关面试题，主要包含被问及微服务架构中的DRY是什么？时的应答技巧和注意事项，需要的朋友参考一下 DRY 代表不要重复自己。它基本上促进了重用代码的概念。这导致开发并共享库，但是反过来导致紧耦合。
-
本文向大家介绍微服务架构是如何运作的？相关面试题，主要包含被问及微服务架构是如何运作的？时的应答技巧和注意事项，需要的朋友参考一下 微服务架构具有以下组件： Clients – 来自不同设备的不同用户发送请求。 Identity Providers – 对用户或客户端身份进行身份验证，并颁发安全令牌。 API Gateway – 处理客户端请求。 Static Content – 容纳系统的所有内