何时切换到微服务

随着过去几年微服务架构的兴起，许多开发人员发现自己想知道这是否适合他们。 关于微服务，我看到了两个常见问题：

1. 我应该改用微服务吗？
2. 我应该何时以及如何切换到微服务？

您应该切换吗？

是否更改体系结构的重点通常是生产力 。

生产力带动开发人员快乐。 当开发人员具有生产力并能够进行所需的更改时，事情就很好了。 在理想的世界中，程序员将比设计功能少担心实现功能。 最终的目标是我们设计的不仅仅是代码。

所有这些的问题是，随着应用程序的大小和年龄的增长，我们的应用程序变得越来越难更改。 技术债务开始堆积起来，使生产力急剧下降。 曾经被认为是任意更改的内容后来变成了六到八个小时的兔子洞，试图了解为什么更改不起作用。

最终，生产力受到了极大的困扰，因此必须采取一些措施。 在这一点上，微服务开始吸引许多团队。 它们提供了看起来和似宜的步调变化。

但是，微服务不是短期的选择。 他们是一项长期投资。

微服务也不是提高开发人员生产力的整体解决方案。 实际上，它们会改变您团队的整个工作流程，技能需求和思维方式。 为项目实施微服务的初期可能充满了您要避免的垃圾和故障排除。 但是，这种短期的烦恼最终会带回团队所追求的生产力和组织能力。

我了解到正在确定要转向微服务的团队应该问自己几个问题：

我们是否要对我们的应用程序体系结构进行长期投资？

您是否打算最终取消应用程序？ 想一想未来三到五年。

我们是否受到应用程序套件中语言子集的限制？

您是否受语言速度或工具的限制？ 我们经常吹嘘某种语言比我们当前的堆栈更快，更干净，更实用。 但是，如果您可以用“更好”的语言编写服务，实际上会是什么样子？ 这个概念对您和您的团队有吸引力吗？

我们是否想在无服务器服务上投资更多？

无服务器服务是微服务的一种趋势，在微服务中，我们将架构的某些部分委派给第三方服务。 利用AWS Lambda等无服务器服务可能对您的团队开始编写微服务非常有用。

我们的工程师愿意在不同服务中共享问题和问题吗？

大多数小型团队必须能够相互解决微服务问题。 您必须乐于散布知识基础和理解力，这可能比您过去习惯的要多得多。

让我们假设您最终决定要追求微服务，但是您的团队战略中仍然存在一个问题：“我们何时以及如何切换架构？”

注册免费的Codeship帐户

您何时以及如何切换？

事实是，没有完美的时机切换到微服务。 但是，您可以事先考虑一些重要的考虑因素，以尝试使过渡更顺畅：

1. 减少功能流失，并优化要分解为微服务的产品。
2. 承诺使用特定的语言和工具堆栈。
3. 至少通常将产品的设计建立为微服务。

我无法表达将不断变化的应用程序转换为微服务有多么困难。 如果您没有可分解和完善的核心产品，那么您将对服务进行很多多余的更改，而不是使它们变得更稳定。

在实践中，致力于某种语言和/或堆栈要比理论上难一些。 许多公司会告诉您，他们使用某些语言和框架，当然可以。 但是，始终存在着要保持还是继续发展的危机。 提交到特定堆栈（至少在过渡期间）会使分解变得容易得多。 您当然可以尝试在微服务上冒险使用新技术或新想法。 但是，您将为集成新的东西和新的体系结构类型付出代价。

了解您要分解成的内容。 尝试减少使用它的趋势，稍后再更改它，因为它现在的规模较小。 当微服务既模块化又定义明确时，它们的工作效果最佳。

消化全部

尽管将我们的应用程序视为无灵魂的数字机器可能很容易，但是我越来越相信我们应该将它们视为我们的家。 我们希望使我们的代码库更加温暖，并邀请遇到它的任何人和所有人。 例如，您的房屋是否有空间进行精心组织？ 它是否使您能够只允许每个房间中的特定物品？

对于微服务，我们必须优先选择那种组织级别，并且我们需要能够实现这种分离。 但是，您还必须希望每个部分之间的关​​注点更加精细。 如果这个想法在您和您的团队中引起共鸣，那么也许值得研究。

过渡并不容易。 但是，这可能会导致公司的组织更加组织化和持久化。

翻译自: https://www.javacodegeeks.com/2017/11/when-to-switch-to-microservices.html