我读了很多关于微服务及其结构的内容，看来，在可维护性方面有很多优点。
我想用Spring Boot和Phonegap构建一个移动应用程序，它从RESTful Web Services中获取新闻。
所以我认为将其构建为微服务，这样我就可以在不重建整个应用程序的情况下添加其他服务。因为将来我可能想要添加其他服务。
但为这么小的移动应用程序构建基于微服务的应用程序真的值得吗？
答案 0 :(得分：5)
有一个很好的article by Fowler，他提出许多以微服务为基础的设计开始的项目很快会遇到问题。相反，许多成功的基于微服务的应用程序是以整体生命开始的应用程序。
总结这个校长：
...你不应该开始使用微服务的新项目，即使 你确定你的应用程序足够大，可以让它变得有价值。
虽然福勒并未表达他对此的个人意见，但他确实推测了他所谓的“Monlith-First ”的好处。
... monolith-first策略，您应该在其中构建新的应用程序 最初作为一个整体，即使你认为它可能会 稍后将受益于微服务架构......可能难以扩展 设计不良但成功的软件系统，但这仍然是一个 更好的地方比它的逆...你需要优先考虑速度......
因此，Monlith-First方法的好处在于您可以快速构建一个整体，因为通常需求是众所周知的并且相对较少。此外，您可以快速推向市场，然后了解您的应用程序及其在现实世界中的表现。
让我感到震惊的主要好处是，您将更清楚地了解您所支持的业务功能之间的界限自然落在您的应用程序中，而不是您曾尝试预先定义这些边界（必要且非常重要）基于微服务的设计中的设计步骤）。
他继续展示如何有效地规划Monolith-first设计，这主要涉及保持代码良好和模块化，并着眼于未来模块的突破。
...仔细设计一块巨石，注意内部的模块化 软件，包括API边界和数据存储方式。
根据我的经验，基于服务的方法可以很好地与业务领域专家花费大量的前期分析时间，以及一个熟悉基于soa和服务的成熟交付团队。
答案 1 :(得分：3)
对于您的项目，微服务架构似乎有点矫枉过正。微服务确实有很多好处，但它们确实有很多操作开销，并且在分布式服务方面增加了很多复杂性。
听起来你也只有一个主要要求就是拉新闻，在这种情况下，所有与新闻相关的服务都将构成一个微服务的一部分。
一旦开始添加更多不同的需求域，您可以将它们构建为单独的微服务。即便如此，将功能模块化为同一服务中的组件也是谨慎的，并且随着应用程序和系统开始增长，将功能分解为单独的微服务。
答案 2 :(得分：0)
创建微服务肯定会在将来帮助您，原因如下：
<强>可扩展性： 微服务可以独立扩展，而不会干扰应用程序中使用的其他微服务。
<强>敏捷： 微服务的变化可以非常快速，从而适应快速变化的业务场景。
容错： 即使一个微服务失败，其他微服务也可以继续服务，从而最大限度地减少对整个应用程序的影响
多语言持久性： 每个微服务都可以决定自己的数据库机制类型。
我已经部分地介绍了微服务的优点，还有更多。
因此，如果你看看上面的所有要点，绝对值得创建微服务应用程序