整体式服务与微服务：利弊得失

然后，此交付内容将部署在一大堆不同的环境中进行测试、验证，最后投入生产并为其用户提供服务。

这是目前软件开发的现状，这意味着每个人都习惯于按照这个体系结构来思考、设计和工作系统。

检查应用程序的健康状态非常简单，有太多工具可以帮助您做到这一点。

说到工具，在开发人员方面，我们最喜欢的IDE都进行了大量优化，以使用单一的工具：索引、查找引用、重构、调试等。

最后但并非最不重要的一点是：部署非常简单！嗯，至少在大多数情况下是这样。

随着代码库的增长，更新应用程序的技术堆栈变得越来越困难。

随着应用变得越来越复杂，CI/CD(持续集成和持续交付-也称为持续部署)流程需要更长的时间，从而影响反馈周期。

您的系统是如此完整和功能丰富，以至于无论是手动测试还是自动测试，都需要花费很长时间。

这款应用的大小还意味着有一个更大的团队，这意味着项目管理中最大的问题：沟通。

最后但并非最不重要的一点是，整个团队的生产力随着项目的推进而下降：您有600个必须同步的特性分支，即使它们彼此之间没有直接关系。

伸缩很难：还记得帕累托的80/20吗？如果您的用户80%的时间使用20%的功能，当您获得更多用户时，您不能只扩展这20%的功能，您必须100%地扩展生产中的软件。

微服务体系结构通常被描述为一种将应用程序划分为小而独立的服务的方法。如果操作得当，这些小模块可以在多个系统中重用和共享。当其他服务使用时，可以将每个服务单独视为SaaS(软件即服务)。

CI/CD变得更容易了，如果您需要更新服务A，服务B将继续运行。

需要的可扩展性：您可以找出最常用的服务，并为它们提供更多的RAM和CPU，这也会为您节省一些资金。

Bug崩溃的服务B不会关闭服务A，特别是如果您在服务A中实现了一些好的缓存策略(如果它使用了服务B中的一些API)。

可以为每个服务使用不同的技术堆栈，并考虑更适合所需功能的技术堆栈。

不同的微服务可以在许多系统中重复使用，例如，您可能有专门处理支付的微服务，并与您的所有应用程序共享该微服务。

健康检查比较困难，您需要监控每个服务，聚合日志，跟踪每个微服务经过的请求，以便进行正确的调试。

正确地找到服务之间的边界并非易事，因此需要对业务领域有很好的理解，DDD是一个很好的方法，正如域驱动设计：处理软件核心中的复杂性中所描述的那样。

作为分布式系统，您必须处理其他问题，如网络延迟和故障。

即使是独立部署，在进行重大更改时，团队之间也需要一定程度的协调。

这是对微服务主题的第一次介绍，我计划做更多的帖子来进一步探讨它，关于采用的合适时机、实现的实际工具和设计模式。作为一般规则，当存在疑问时，可以从整体方法开始，如果需要，可以转向微服务。