从monolith迁移到Micro服务体系结构

Question

我们正在为我的客户设计微服务的初始阶段，他们的标准整体应用程序位于他们自己的数据中心的4台JBOSS服务器上。微服务架构是否仅针对基于云的部署？我可以在内部生产准备好tomcat / JBOSS上部署微服务吗？这是一个不错的选择吗？

Answer 1

当然可以。 微服务架构是一个具有许多小型交互组件的概念，其中每个组件都执行明确定义的工作部分，但很好。

它扩展了Linux方式和解耦组件的概念。

在您的情况下，您可以将服务拆分为多个较小的服务。每个都有自己的开发和部署周期，每个周期都有明确定义的API。

Answer 2

微服务架构仅针对基于云的部署吗？

不，这是用于应用程序开发的体系结构。微服务的基本思想是将复杂的应用程序功能与小功能分开，以降低复杂度并获得高性能。 移动微服务之前，您无需考虑几个原因。

• 1。您的应用规模。

如果您的应用程序包含大量复杂功能，则微服务更好。并将它们分开并分开部署，然后轻松进行更改和维护。

• 2。应用程序的性能

如果某些应用程序功能需要较高的计算能力。您可以分配单独的硬件资源。如果您将其实现为微服务。

• 3。部署和维护

  如果您使用微服务，则可以单独部署和维护服务，而不会影响其他服务。

• 4。数据迁移

如果您的数据库包含较高的数据表关系，那么对于功能数据库（每个微服务都需要每个DB）进行删除将有点困难，因此第一步是将DB保持为与服务无关的整体功能。然后开始反应堆数据库

• 5。调用每个服务

  前端应用程序保持整洁且无逻辑。并使用API​​ Gate方式包装您的微服务，并将所有服务发布为一项服务。

• 6。应用程序安全性

运行在每个服务中的每个服务都无需使用JWT（oAuth2）API安全性进行会话跟踪。

• 7。多种服务和跨国业务

如果您需要处理一个业务功能但有多个服务，则需要检查每个服务功能是否正常**（例如db操作，回滚）**，因此需要开发跨国处理程序

• 实施微服务

没有特定的技术堆栈，但是有更多可用的免费技术     例如：

1. 用于微服务的Java春季启动（具有内置的tom cat服务器）
2. zuul，API门方式的尤里卡

3. oAuth 2和JWT的安全性

   • *注意

没有微服务实现的固定方法，使用正确的技术堆栈来获得性能并实现小型业务功能。与托管在云或本地服务器中无关紧要。 strong文字

Answer 3

无论是在本地，物理服务器还是在云中部署微服务，都没有任何限制。这两种方法都是有效的，但它们有不同的优点和缺点。

使用本地/物理服务器，您将拥有：

• 更大的运营开销（你的团队中有更好的DevOps会更好）
• 手动扩展（当您遇到更大的流量时，您需要手动启动新实例，或使用一些管理工具）
• 手动故障检测 - 如果服务器出现故障（这取决于您/公司的服务器环境），有人需要“手动”修复此问题
• 它更便宜（朋友在亚马逊上购买旧的服务器实例并在其上运行半微服务架构，他计算出这样可以节省相当多的费用）。

借助云基础架构，您可以获得以下一些优势（与上述缺点相反）：

• 减少操作开销（云将负责大部分操作）
• 灵活扩展（当您的流量上升时，云可以自动启动新实例，当它关闭时，它会关闭实例）
• 错误/故障处理 - 如果云中出现问题，则无需担心

我没有提到给定方法的所有优点和缺点，因为它也取决于项目（它会在一天中的不同时间接收不同的流量，是否需要在本地保存数据或者是否可以在国外在云中，......）。